There was an inconsistency between the logic for synthesizing
initializer expressions and the validation logic for the
@requires_stored_property_inits attribute. As a result, 'let'
bindings of optional types were not diagnosed in Sema, triggering
crashes in DI.
Swift SVN r32857
var/let bindings to _ when they are never used, and use some values that
are only written. This is a testsuite cleanup, NFC. More to come.
Swift SVN r28406
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
This condition is already checked from defineDefaultConstructor's only caller,
addImplicitConstructors, and the two conditions had drifted. This was causing
issues in the multi-file case, where the optionals hadn't been given an
explicit initial value yet.
rdar://problem/18716572
Swift SVN r23017
This is a recent regression that caused us to reject globals of
optional type that didn't have initializers <rdar://problem/16953669>.
Swift SVN r18332
by allowing default initializing let properties. In classes, the property
is mutable in init, and the default initialization is useful. The benefit we
gain by banning this is outweighed by the important usecases that get closed
off by doing so.
Swift SVN r18213
have been type checked. This allows us to reliably determine the type of the variable
and to know whether it actually needs default initialization or not.
This fixes:
<rdar://problem/16620121> Initializing constructor tries to initialize computed property overridden with willSet/didSet
which was because we were doing default initialization before computing override sets.
This does regress on one case, where our fiddly default init code isn't realizing that
a default initializer will be generated. I fixme'd the case and filed:
<rdar://problem/16921173> implicit constructor synthesization runs too early
to track this.
Swift SVN r18094
