The empty sentinel in the lookup table caused recursion-breaking to bottom
out in slightly different order than the old eager code, making certain
order-sensitive tests fail.
Right now if convert_function is used incorrectly by SILGen, we get an error via
the SILVerifier after we have finished building the entire function. This is a
pain in the butt to track down. Using this refactor, I am able to just assert in
the SILBuilder itself.
On another note, down the line we should just separate the dataflow checker part
of the verifier from specific SILInstruction verification. This would allow for
SILBuilder to perform the SILInstruction verification upon creation giving the
same effect. Such a change is a much larger change though and this is just a
commit chopped off a larger commit.
rdar://34222540
Conditional conformances aren't quite ready yet for Swift 4.1, so
introduce the flag `-enable-experimental-conditional-conformances` to
enable conditional conformaces, and an error when one declares a
conditional conformance without specifying the flag.
Add this flag when building the standard library (which will vend
conditional conformances) and to all of the tests that need it.
Fixes rdar://problem/35728337.
Both AnyFunctionType and SILFunctionType reserve 16 bits in the TypeBase
for their respective "ExtInfo" bits, but then these types use less than
half of the bits they reserve. This patch changes AnyFunctionType and
SILFunctionType to only reserve what they need and then verify at
construction time that ExtInfo bits are not being truncated.
This change is motivated by the need to have more TypeBase bits
available for other uses.
Finally, this change fixes a copy-and-paste error introduced when
AnyFunctionType and SILFunctionType stopped sharing the same ExtInfo
data structure.
conformsToProtocol() is the main way in which we check whether a given type
conforms to a given protocol. Extend it to check conditional requirements by
default, so that an unmodified caller will get the "does not conform" result
(with diagnostics when a location is present) rather than simply ignoring
the conditional requirements.
Some callers take responsibility for conditional requirements, e.g., to
push them into the constraint system. Allow those callers to opt out of
this checking, and do so wherever appropriate.
Fixes rdar://problem/35518088, where we were ignoring the conditional
requirements needed to verify that Equatable synthesis could be performed.
Sometimes we end up mapping a conformance into and then out of a
particular context, which led to "stacked" specialized conformances
that were basically a no-op. Look through these to collapse them
eagerly.
Collapses 15786 conformances in the standard library.
This enables one to control via SILOptions whether or not normal arguments are
emitted as guaranteed. In a subsequent commit, I am going to add support for
triggering this via a frontend option.
I also got rid of the default Owned argument to DefaultConvention. Now
everywhere we create a DefaultConvention, we must be explicit about our normal
parameter convention.
rdar://34222540
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
We would miscompile in mixed-language-version projects when a Swift class was compiled for one language version, while using Objective-C-imported types that are only available to that version, and then imported into a Swift module with a different language version that wasn't able to see all of the properties because of incompatible imported types. This manifested in a number of ways:
- We assumed we could re-derive the constant field offsets of the class's ivars from the layout, which is wrong if properties are missing, causing accesses to final properties or subclass properties to go to the wrong offsets.
- We assumed we could re-derive the instance size and alignment of a class instance in total, causing code to allocate the wrong amount of memory.
- We neglected to account for the space that stored properties take up in the field offset vector of the class object, causing us to load vtable entries for following subclass methods from the wrong offsets.
Eventually, resilience should reduce our exposure to these kinds of problems. As an incremental step in the right direction, when we look at a class from another module in IRGen, treat it as always variably-sized, so we don't try to hardcode offsets, size, or alignment of its instances. When we import a class, and we're unable to import a stored property, leave behind a new kind of MissingMemberDecl that records the number of field offset vector slots it will take up, so that we lay out subclass objects and compute vtable offsets correctly. Fixes rdar://problem/35330067.
A side effect of this is that the RemoteAST library is no longer able to provide fixed field offsets for class ivars. This doesn't appear to impact the lldb test suite, and they will ultimately need to use more abstract access patterns to get ivar offsets from resilient classes (if they aren't already), so I just removed the RemoteAST test cases that tested for class field offsets for now.
This fixes a serious false negative in static exclusivity enforcement when
a noescape closure performs an access that conflicts with an in-progress access
but is not reported because the closure is passed via a reabstraction thunk.
When diagnosing at a call site, the enforcement now looks through partial
applies that are passed as noescape arguments. If the partial apply takes
an argument that is itself a noescape partial apply, it recursively checks
the captures for that partial apply for conflicts and diagnoses if it finds one.
This means, for example, that the compiler will now diagnose when there is a
conflict involving a closure with a concrete return type that is passed to a
function that expects a closure returning a generic type. To preserve source
compatibility these diagnostics are emitted as warnings for now. The intent is
that they will be upgraded to errors in a future version of Swift.
rdar://problem/35215926, SR-6103
Rather than storing contextual types in the type witnesses and associated
conformances of NormalProtocolConformance, store only interface types.
@huonw did most of the work here, and @DougGregor patched things up to
complete the change.
