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.
This method gets the GenericTypeDecl for a typealias, nominal type, or
extension thereof. While the result is typed as GenericTypeDecl, it's
not always generic, so rename it accordingly.
An audit of the callers illustrated that they should be using
different entrypoints anyway, so fix all of the callers and make this
function private.
llvm r283043 and possibly other recent changes switch to use StringRef
instead of char* pointers. Update Swift to match. In some cases, this is
a clear improvement. It would be good to assess the impact on memory use,
particularly for the Filename component of source locations.
Note that the change to SILLocation::isNull fixes an apparent bug where
the location was treated as null when the filename was *not* null.
The IterativeTypeChecker now use loops instead of recursion to help keep the stack size low
We diagnose circular dependencies for protocols in a more efficient manner and also prevent the possibility of infinite loops
A given Objective-C error enum, which is effectively an NS_ENUM that
specifies its corresponding error domain, will now be mapped to an
ErrorProtocol-conforming struct that wraps an NSError, much like
NSCocoaError does. The actual enum is mapped to a nested "Code"
enum. For example, CoreLocation's CLError becomes:
struct CLError : ErrorProtocol {
let _nsError: NSError
// ...
@objc enum Code : Int {
case ...
}
}
This implements bullet (2) in the proposed solution of SE-0112, so
that Cocoa error types are mapped into structures that maintain the
underlying NSError to allow more information to be extracted from it.
Previously, we would only reliably propagate conformances from new extensions to immediate subclasses, since when we visit grandchild classes, we'd see no change in the immediate base class's status. Fix this by walking up the entire superclass chain when we look for new inherited conformances, and track the last processed state of different nominal type decls' extensions separately. Fixes SR-1480.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
