A substitution map contains conformances, and a conformance can contain
a substitution map. This will always be a DAG, but not a tree, and to
avoid exponential blowup in certain edge cases, let's cache the work to
avoid visiting the same substitution map repeatedly, if multiple
conformances refer to the same substitution map.
Tracking seen declarations and substitution maps only detects the
situation where the opaque type's underlying type contains itself
with the same substitution map. However, it is also possible to
recurse with a different substitution map.
In general termination is undecidable with a problem like this,
so instead of trying to catch cycles, just impose a termination
limit.
This converts a stack overflow into an assertion, which is still
not ideal; we should really diagnose something instead. But this
is a first step.
Use these queries to replace some duplicated code. Also, move the
`attr_inlinable_available.swift` test to the `Availability` sub-directory since
the test has more to do with availability checking than it has to do
specifically with the `@inlinable` attr.
Previously this flag was only used to pass explicit dependencies to compilation tasks. This change adds support for the dependency scanner to also consider these inputs when resolving dependencies.
Resolves https://github.com/swiftlang/swift-driver/issues/1951
We sometimes don't have the information in the modulemaps whether a
module requires ObjC or not. This info is useful for reverse interop.
This PR introduces a frontend flag to have a comma separated list of
modules that we should import as if they had "requires ObjC" in their
modulemaps.
In implicit contexts that are universally unavailable, allow writable key paths
to be formed to properties with setters that are also marked as universally
unavailable. This fixes a regression from the previous commit where the code
synthesized for `@Observable` properties in universally unavailable classes was
rejected by the availability checker.
While the intent behind this functor was noble, it has grown in complexity
considerably over the years, and it seems to be nothing but a source of
crashes in practice. I don't want to deal with it anymore, so I've decided
to just subsume all usages with LookUpConformanceInModule instead.
The previous message was just suggesting unchecked Sendable, but instead
we should be suggesting to add final to the class. We also don't
outright suggest using unchecked Sendable -- following
https://github.com/swiftlang/swift/pull/81738 precedent.
Resolves rdar://155790695
In the provided test case, the generic signature of the
protocol requirement is
<Self, T where Self == T.A, T: P2>
The conformance requirement `Self: P1` is derived from `T: P2`
and `Self.A: P1` in P1. So given a substitution map
`{ Self := X, T := T }` that replaces T with a concrete type X
and T with a type parameter T, there are two ways to recover a
substituted conformance for `Self: P1`:
- We can apply the substitution map to Self to get X, and look
up conformance of X to P1, to get a concrete conformance.
- We can evaluate the conformance path `(T: P2)(Self.A: P1)`,
to get an abstract conformance.
Both answers are correct, but SILGenModule::emitProtocolWitness()
was assuming it would always get a concrete conformance back.
This was the case until e3c8f423bc,
but then we started returning an abstract conformance. SILGen
would then mangle the protocol witness thunk in a way that was
not sufficiently unique, and as a result, we could miscompile
a program where two witness tables both hit this same scenario.
By using contextual types in the getRequirementToWitnessThunkSubs()
substitution map, we ensure that evaluating the conformance path
against the substitution map produces the same result as performing
the global lookup.
Also, to prevent this from happening again, add a check to SILGen
to guard against emitting two protocol witness thunks with the
same mangled name.
Unfortunately, this is done intentionally as part of some
backward deployment logic for coroutine accessors. There is a
hack to allow duplicate thunks with the same name in this case,
but this should be revisited some day.
Fixes rdar://problem/155624135..
Functions or template instantiations with Obj-C types should always be
behind a macro to make sure the interop header compiles cleanly in C++.
rdar://152836730
Since LayoutPrespecialization has been enabled by default in all compiler
invocations for quite some time, it doesn't make sense for it to be treated as
experimental feature. Make it a baseline feature and remove all the
checks for it from the compiler.
