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.
Introduce a warning about redeclaring the associated types from an
inherited protocol in the protocol being checked:
* If the new declaration is an associated type, note that the
declaration could be replaced by requirements in the protocol's
where clause.
* If the new declaration is a typealias, note that it could be
replaced by a same-type constraint in the protocol's where clause.
This manifested as test/Prototypes/PatternMatching.swift failing
under 'ninja check-swift-validation-optimize'.
I'll add a test later if I have time to reduce a test case, but this
whole hack is hopefully going away soon anyway.
Fixes one of the three failures outlined in <rdar://problem/31780356>.
Instead of just falling back to module lookup any time conformance
substitution fails, only do it in the case we know doesn't work.
This should shake out some more bugs, hopefully without causing
too much pain.
Looking up the conformance @dynamic_self C<T> : P simply returns
the normal conformance C<T> : P.
If we later apply a substitution map to the conformance to
specialize T, we would call isSpecialized() on the substituted
type, which would return false. We would then hit an assertion
because the type type @dynamic_self C<Int> is not equal to the
(erroneously unsubstituted) conformance type C<T>.
Tweak the logic slightly to avoid this.
We would consider types that structurally contain generic parameters as being depthless, leading to same-type requirements being printed at the wrong depth, defeating the SIL parser. Superclass constraints can also involve a generic base class referring to generic parameters at depth.
There's a more pervasive issue here that needs further study;
essentially, we can end up with self-derived sources getting
reinjected later, and will either need to avoid that reinjection or
need to expand what this localized hack does, filtering out
self-derived constraints when we enumerate requirements.
Add CGFloat (and other types that this applies to) as a trivial type even after
the one-time initialization of the ForeignRepresentableCache.
This allows
let str = ""
import Foundation
let pt = CGPoint(x: 1.0, y: 2.0)
to work.
Before we would populate the cache the first time on the first line "let str =
..." and because the CoreGraphics module was not loaded we would not add CGFloat
as a trivial type. When we come to query for CGFloat on the third line we would
return NSNumber instead of CGFloat as a type and that would crash IRGen.
rdar://31610342
This stops after 5 recurrences of the same associated type. It is a
gross hack and a terrible idea, here as a placeholder to prevent us
from running off the rails in ill-formed code. This will go away when
we get further along the path with recursive protocol constraints.
When we’re determining what type should be used to key a ProtocolRequirement based on the source’s potential archetype and the target’s potential archetype, use potential archetype identity (==) rather than equivalence-class membership to cover the basis case. This ensures that interesting identity relationships in the enclosing context (e.g., the current GenericSignatureBuilder) don’t cause us to compute incorrect stored types.
When computing the connected components of within an equivalence class (based on derived same-type requirements), we might need derived-via-concrete constraints to maintain connectedness of the larger graph. Therefore, delay their removal until after we’ve computed connected components.
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).
