Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
In Swift 4, properties declared with a sugared Optional type,
like Int?, have a default value of nil. This can be observed
in two ways:
- Classes and structs get an implicit no-argument initializer
- Designated initializers don't have to initialize this property
Note that this did not apply in general to properties where
the type was spelled explicitly as Optional<Int>, etc, mostly
because of implementation restrictions -- when we check if a
type has implicit initializers, we have not realized types for
all stored property members yet, and doing so is not really
possible without the iterative decl checker.
However, in some cases, we *did* perform default initialization
for Optional<Int>, because of some code duplication and
divergent code paths.
A recent refactoring cleaned up some of the mess in this area,
but accidentally broke source compatibility with code that
relied on the broken Optional<Int> case.
Fix this by simulating the old behavior in -swift-version 4,
and preserving the more correct behavior in -swift-version 5.
Fixes <rdar://problem/35319847>.
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
