Implicit synthesis of `Sendable` conformances for global actor-isolated
class types interacts poorly with the conformance lookup table's
attempt at modeling inherited conformances, so a `Sendable` conformance
will get created and inherited, but is then "missing" when we try to
form the actual inherited conformance.
The proper fix for this issue is likely to eliminate the modeling of
inherited conformances within the conformance lookup table, which
introduces a lot of redundance and, apparently, some bugs. For now,
patch over the issue to work around a crash.
Narrowly works around rdar://81700570.
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
Parse and provide semantic checking for '@unchecked Sendable', for a
Sendable conformance that doesn't perform additional semantic checks
for correctness.
Part of rdar://78269000.
If a conformance is found in an imported module as well as the current module,
and one of the two conformances is conditionally unavailable on the current
deployment target, pick the one that is always available.
Fixes <rdar://problem/78633800>.
The uncached, rarely-used getLocalProtocols() does not benefit from
having its own distinct implementation. Reimplement it on top of
getLocalConformances() to simplify things and benefit from the
request-evaluator infrastructure.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
ProtocolConformanceRef already has an invalid state. Drop all of the
uses of Optional<ProtocolConformanceRef> and just use
ProtocolConformanceRef::forInvalid() to represent it. Mechanically
translate all of the callers and callsites to use this new
representation.
Push the relevant work this was doing down into the callers. Most of them didn't want to validate the entire extension and force its generic parameters, they just wanted to validate the nominal type.
We must eagerly validate the generic signature of extensions, though. This avoids a class of cycles where non-generic members of an extension with a generic signaure will call through to getGenericSignatureOfContext and force the generic signature anyways. When this calls through to protocol witness matching, the signature can be recursively computed.
Like the last commit, SourceFile is used a lot by Parse and Sema, but
less so by the ClangImporter and (de)Serialization. Split it out to
cut down on recompilation times when something changes.
This commit does /not/ split the implementation of SourceFile out of
Module.cpp, which is where most of it lives. That might also be a
reasonable change, but the reason I was reluctant to is because a
number of SourceFile members correspond to the entry points in
ModuleDecl. Someone else can pick this up later if they decide it's a
good idea.
No functionality change.
Most of AST, Parse, and Sema deal with FileUnits regularly, but SIL
and IRGen certainly don't. Split FileUnit out into its own header to
cut down on recompilation times when something changes.
No functionality change.
These can be recreated if needed in a client library. To do this, I've
added a new ConformanceLookupKind::NonInherited, which can also be
used elsewhere in the project where we're already filtering out
inherited conformances some other way.
Note that this doesn't drop inherited conformances from the entire
serialized interface, just from the list that a class explicitly
declares. They still get referenced sometimes.
rdar://problem/50541451 and possibly others
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
Add API to get all of the nominal types directly referenced from the
inheritance clause of a given declaration. Use that to find the protocols
to enter into the conformance lookup table based on a given declaration,
without going through the type checker [*].
[*] Except for unqualified lookup still needing to use the type checker.
Use ExtensionDecl::getExtendedNominal() to wire up extensions to their
nominal types early in type checking (the bindExtensions()) operation,
rather than going through type validation to do so.
If a conformance to a protocol is implied by several other
conformances (i.e. protocol P: Equatable {} and protocol Q: Equatable {} and a
type declares conformance to both P and Q), we should choose a source that's in
the same file as the type, if we can, because automatic synthesis of
conformances (for Equatable, Hashable, etc.) only works in that case.
Fixes rdar://problem/41852654.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
The introduction of the request-evaluator is causing some conformances
to be formed before the nominal type's signature is being checked,
causing a crash while type-checking the standard library. Ensure that this
cannot happen.
Wire up the request-evaluator with an instance in ASTContext, and
introduce two request kinds: one to retrieve the superclass of a class
declaration, and one to compute the type of an entry in the
inheritance clause.
Teach ClassDecl::getSuperclass() to go through the request-evaluator,
centralizing the logic to compute and extract the superclass
type.
Fixes the crasher from rdar://problem/26498438.
Given
protocol P1 {}
protocol P2: P1 {}
protocol P3: P1 {}
struct S<T> {}
extension S: P2 {}
extension S: P3 where T: P1 {}
Per SE-0143, we need to make sure that we notice that we can infer S: P1
completely unconditionally from S: P2, and ignore the constrained
one. This is a fairly crude approximation, because doing it accurately
would make this extremely recursive. The approximation used is a
conformance non-conditional if the conformance is from the type, or
there's syntactically no 'where' clause, which is a sufficient condition
for being non-conditional but not necessary (an extension *could* have a
completely redundant 'where' clause).
The recursion problem is checking if something is truly conditional
requires knowing the generic signature of the DeclContext, but knowing
this generic signature requires validating the extension/knowing the
type's conformances, which means hitting this table. (This is made worse
by actual recursive use of conformances, as in SR-6569.)
We need to be able to find which conformances need to be
declared/constructed without forcing extensions to be completely
validated. This is important for both SR-6569 and
rdar://problem/36499373. The former due to the source-level recursion,
and the latter because implied conformances weren't always
constructed (but are needed for good diagnostics).
They weren't always constructed because:
1. ConformanceLookupTable's updateLookupTable on an early stage (before
implied conformances are found) triggers extension
validation *before* constructing any conformances, but *after*
updating the stage state
2. extension validation validates the conditional requirements
3. validating the conditional requirements requires setting up generic
signatures
4. setting up generic signatures forces the types conformances and so
ends up in updateLookupTable on the same nominal again, skipping over
the earlier stages that are complete/in progress
5. we expand the conformances that are implied by all the conformances we
know about... But we don't know any, because we haven't finished the
first updateLookupTable.
This breaks the loop at step 2: we instead do the minimal work needed to
know what conformances an extension (might) declare, which is connect
the extension to a type, and then resolve the inherited TypeReprs to
Types.
The old `existingEntry->getProtocol() == protocol` condition was always
true (the only way for `existingEntry` to get into the array it comes
from is if is exactly for `protocol`), which meant this checking loop
always bailed out, and that there was never more than one implied
candidate ever. This probably isn't what was intended, given there's
more code for handling this case directly after this condition, and
`compareConformances` has extensive code for ranking two implied
conformances for the same nominal/protocol pair.
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.
When a conformance can either be synthesized or implied, we tend to prefer
implied. However, if the implied conformance comes from a deserialized
conformance, it will lead to an incomplete conformance and cause a crash.
This is a narrow fix for SR-6105 / rdar://problem/34911378.
We allowed them for generic parameter inheritance clauses but
not anywhere else. While arguably this has stylistic benefits,
the restriction was not enforced consistently and was mostly a
result of implementation limitations.
Lift the restriction and fix things up where needed to make them
work. This brings us closer to allowing protocols to constrain
the 'Self' type to a subclass of a class by listing the class in
the protocol's inheritance clause, which was a feature from SE-0156,
but this doesn't quite work.
Fixes <https://bugs.swift.org/browse/SR-4678> and
<rdar://problem/31785092>.
