null in StatementTransformer with definite initialization in for + else

[CeylonMigrationBot]

[@lucaswerkmeister] ```ceylon
class C() {
shared String s;
for (arg in {}) {
s = arg;
break;
} else {
s = "";
}
}

(A more useful example would iterate over something better, and include some test in the loop body.)

The typechecker correctly detects that `s` is assigned exactly once, but the Java backend can’t handle it:
> error: compiler bug: null at com.redhat.ceylon.compiler.java.codegen.StatementTransformer$ForStatementTransformation.transform([StatementTransformer.java:1999](https://github.com/ceylon/ceylon-compiler/blob/44c00dac014715f31803d9318488edcc2cbd2a0a/src/com/redhat/ceylon/compiler/java/codegen/StatementTransformer.java#L1999))
error: variable string might not have been initialized

If you make `s` `variable`, or unshare it, the error disappears.

As always, [generated code](https://gist.github.com/lucaswerkmeister/1b10af196c44989f7b27), `@noanno`’ed (for `variable` and unshared as well). (The reason for the “might not have been initialized” error is obvious: The exception produced a completely empty constructor body.)

[Migrated from ceylon/ceylon-compiler#1818]
[Closed at 2014-09-24 10:12:52]

[CeylonMigrationBot]

[@lucaswerkmeister] Found while updating SparseFormattingOptions for @akberc / eclipse-archived/ceylon-ide-eclipse#987 (comment). I can probably work around it (with an extra auxiliary variable), but I’d prefer not to. Any estimate if this is particularly difficult? And @akberc would you like me to update SparseFormattingOptions right now or can it wait a bit?

[CeylonMigrationBot]

[@akberc] I plan to add the rest of the options today evening and the single parse of sample to improve performance. No rush, I can continue to add methods for each constructor like this: https://github.com/ceylon/ceylon-ide-eclipse/blob/formatter-profiles/plugins/com.redhat.ceylon.eclipse.ui/src/com/redhat/ceylon/eclipse/code/style/FormatterPreferences.java#L84

We can always change back later, and maybe move the wrapper to the new Ceylon package in the iDE and use named parameters, so you can wait for this issue to be resolved. Variable attributes in SparseFormattingOptions would be nice but not a blocker.

[CeylonMigrationBot]

[@lucaswerkmeister] Oh, I think I see what you’re doing… and perhaps I should just work around it for now, that huge SparseFormattingOptions constructor looks awful. As it stands now, the class is obviously unsuitable for use without named arguments :D

[CeylonMigrationBot]

[@lucaswerkmeister] Alright, as it turns out this bug no longer affects me. See eclipse-archived/ceylon.formatter@eb00aeb.