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