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>.
ASan found this amusing stack-use-after-scope problem in the AST
that's been around for a long while. It was introduced when
`ModuleDecl::lookupConformance()` changed from returning an
llvm::PointerIntPair<ProtocolConformance *, 2>
to an
Optional<ProtocolConformanceRef>
In the former, `getPointer()` grabbed the `ProtocolConformance*`, which
was fine. In the latter, it produced a `ProtocolConformanceRef*`
pointing into a temporary value.
Fixes rdar://problem/31708629.
NormalProtocolConformance has the only correct implementation of this
functionality. Instead, providing a safer getWitnessDecl() that
doesn't promise substitutions that are incorrect (and not actually
used by any clients).
Add a 'hasExplicitAnyObject()' bit to ProtocolCompositionType
to represent canonical composition types containing '& AnyObject'.
Serialize this bit and take it into account when building
ExistentialLayouts.
Rename ProtocolCompositionType::getProtocols() to getMembers()
since it can contain classes now, and update a few usages that
need further attention with FIXMEs or asserts.
For now, nothing actually constructs these types, and they will
trigger arounds asserts. Upcoming patches will introduce support
for this.
* Use the presence of an argument type to check for associated values
hasOnlyCasesWithoutAssociatedValues returns true for any serialized
enum declaration whether or not it has cases. This never really came
up because it's mostly relevant to Sema's proto-deriving mechanism. Fix
this by using the presence of the case's argument type instead.
* Separate checks for presence of cases and enum simplicity
Necessary because the old behavior was an artifact of the
implementation.
This reverts part of #4038 which made the compiler consider it to be an `Explicit` conformance, breaking source code that was accepted in Swift 3.0 which declared a raw type as well as explicit conformance to `RawRepresentable` (reported as rdar://problem/30386658). While I'm here, a couple of spot fixes:
- Ensure an enum's raw value exprs are type-checked before checking conformances of any of its extensions, since the RawRepresentable conformance derivation will blow up if the raw value exprs haven't been checked. Fixes an order dependency issue if `extension Foo: RawRepresentable {}` gets checked before `enum Foo: Int { ... }`.
- Don't display the custom `enum_declares_rawrep_with_raw_type` diagnostic if the source location for the enum's inheritance clause is invalid, so that we don't emit a dislocated diagnostic.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
