The specific case where this happened here is:
```
// Worklist = [
%0 = struct $Int (...)
%1 = $Klass
%2 = tuple (%0, %1)
(%3, %4) = destructure_tuple %2
store %3 to [trivial] %3stack
store %4 to [init] %4stack
```
What would happen is we would visit the destructure_tuple, replace %3 with %0
but fail to propagate %4:
```
%0 = struct $Int (...)
%1 = $Klass
%2 = tuple (%0, %1)
(%3, %4) = destructure_tuple %2
store %0 to [trivial] %3stack
store %4 to [init] %4stack
```
This then causes the tuple to be added to the worklist. When we visit the tuple,
we see that we have a destructure_tuple that is a user of the tuple, we see that
it still has that Struct as a user despite us having constant propagated that
component of the tuple. This then causes us to add the struct back to the
worklist despite that tuple component having no uses. Then when we visit the
struct. Which causes us to visit the tuple, etc.
rdar://49947112
Just as with conformances, we can detect that a delayed function
needs to be added to the queue from 'first principles' rather than
walking the ExternalDefinitions list.
This completely eliminates the ExternalDefinitions walk from SILGen,
which has several advantages:
- It fixes a source of quadratic behavior. In batch mode, type checking
produces a list of external definitions shared across all primary
files. Then, SILGen runs once per primary file, building a delayed
emission map every time.
- It allows SILGen to emit external definitions which only come into
existence as a result of lazy conformance checking. Previously,
anything that was added after SILGen performed its walk over the
external definitions list would not be emitted.
An inout capture of 'self' is not lowered as a SIL argument inside
an initializer, so add a new check to handle this case.
Fixes <rdar://problem/50412872>.
When a class has missing vtable entries, we don’t allow it to be subclassed. This is unnecessarily restrictive for resilient classes, and @_implementationOnly imports now make missing vtable entries much more common. This commit carves out an exception to that rule for resilient classes.
Fixes <rdar://problem/50902125>.
This option stopped working when clang changed its default behaviour to
-fmodules-validate-system-headers; we now need to explicitly disable it
to preserve the behaviour of our flag.
rdar://problem/50908762
Because opaque types are currently limited so that they only have immediate
protocol constraints, and therefore don't interact with the outer generic
parameters at all, we can get away without adding same-type constraints for
the outer generic parameters to their substitutions in the generic signature
builder when setting up the environment for an opaque archetype. This
avoids the strict assertion that opaque types not appear in other decls'
interface types. rdar://problem/50509030
Adding where clauses would break this hack.
If syntax trees are requested, we shouldn't skip inactive code. Notice the
inactive code won't be skipped in SwiftSyntax because we always set
PerformConditionEvaluation false for the in-process parser.
This is mostly needed for testing purposes where we add -verify-syntax-tree
to regular compiler invocations.
rdar://50837165
That is, if a struct's generic requirements can't be deserialized,
drop the struct. This is the same logic that's already in play for
enums and (as of the previous commit) classes, so it should be pretty
well tested by now. (Hence the sole test I'm adding here, snuck into
superclass.swift because it's a superclass /constraint/ being tested.)
I don't know of any outstanding issues caused by this, but it was
weird to have it for enums and classes but not structs, so here we
are.
...instead of crashing. Also drop the class if its generic
requirements depend on a type that can't be loaded (instead of
crashing).
rdar://problem/50125674
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
A number of tests exercise features only available in Apple OSes that
shipped with Swift 5.0 in the OS; this includes the following versions:
- macOS 10.14.4
- iOS 12.2
- tvOS 12.2
- watchOS 5.2
Previously these tests were restricted to running on macOS only, with
an explicit -target x86_64-apple-macosx10.14.4. To get better test
coverage, add a new %target-stable-abi-triple substitution which
expands to a triple with the correct OS version on all Apple platforms.
On non-Apple platforms, this is the same as %target-variant-triple,
but for now any test that uses this exercises Apple platform features
anyway.
One caveat is that since iOS 12.2 does not have a 32-bit slice, we
have to skip any tests that use -target %target-stable-abi-triple
on this platform. A new swift_stable_abi feature flag can be tested
with 'REQUIRES: swift_stable_abi'. To get maximum test coverage,
I split off a 'stable_abi' version of a few tests that build with both
an old and new deployment target. This allows the old deployment
target case to still be tested on 32-bit iOS.
The logic I had here checked whether an extension used an
implementation-only type whenever there was a declaration within that
extension that needed checking...but unfortunately that included not
just PatternBindingDecls (whose access is filtered at a later step)
but things like IfConfigDecls (#if). Change this to only check
signatures of extensions with ABI-public members, something that is
tested once when visiting an ExtensionDecl.
Additionally, skip AccessorDecls entirely, since they'll be tested
as part of the corresponding subscript or var. This saves a duplicate
diagnostic.
rdar://problem/50541589
Some of the tests in KVOKeyPaths.swift check problems that were not fixed
until Swift 5.1 so they are not expected to pass when running with the
5.0 libraries.
rdar://problem/50173830
In SILGenPattern, we need to be able to unforward cleanups when we explode
tuples. Thus we can't use RValue in SILGenPattern since it may implicitly
explode tuples (which without modifying RValue itself we can not
unforward). This patch removes a specific RValue usage that we can replace with
the use of a ManagedValue instead.
rdar://49903264
