Use the interface type of the underlying type in the GSB in as many
cases as possible except for one important one: requirement signature
computation. There, use the structural type so we don't wind up
recursively validating the requirements of an incomplete protocol.
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.
This avoids making the structural type dependent on whether the interface type has been computed and neatly avoids special-casing non-parsed declarations which set their underlying type up front.
Computing the interface type of a typealias used to push validation forward and recompute the interface type on the fly. This was fragile and inconsistent with the way interface types are computed in the rest of the decls. Separate these two notions, and plumb through explicit interface type computations with the same "computeType" idiom. This will better allow us to identify the places where we have to force an interface type computation.
Also remove access to the underlying type loc. It's now just a cache location the underlying type request will use. Push a type repr accessor to the places that need it, and push the underlying type accessor for everywhere else. Getting the structural type is still preferred for pre-validated computations.
This required the resetting of a number of places where we were - in many cases tacitly - asking the question "does the interface type exist". This enables the removal of validateDeclForNameLookup
Computing the generic signature changes the way that cycles appear in the compiler. For now, break these cycles. We should investigate each place where hasComputedGenericSignature() is used in service of breaking cycles. See rdar://55263708
Unify a bunch of quasi-independent callsites into a single request that
builds up a generic signature from a variety of inference sources. This
draws the extension typealias workaround for SE-0229 into TypeCheckDecl
where we can better work on refactoring it. The goal is to use this as
a springboard to requests that compute generic environments for various
and sundry decls.
When a request for an abstract generic signature contains noncanonical
types, first compute the abstract generic signature for the
canonicalized types, then map back to the provided generic
parameters. Clients of this request generally work in canonical types
already, but it's a small win.
Introduce a request to form an abstract generic signature given a
base signature, additional generic parameters, and additional
requirements. It is meant to provide a caching layer in front of the
generic signature builder.
Switch one direct client of the generic signature builder over to this
mechanism, the formation of a generic signature for an existential
type.
We've fixed a number of bugs recently where callers did not expect
to get a null Type out of subst(). This occurs particularly often
in SourceKit, where the input AST is often invalid and the types
resulting from substitution are mostly used for display.
Let's fix all these potential problems in one fell swoop by changing
subst() to always return a Type, possibly one containing ErrorTypes.
Only a couple of places depended on the old behavior, and they were
easy enough to change from checking for a null Type to checking if
the result responds with true to hasError().
Also while we're at it, simplify a few call sites of subst().
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
-verify-generic-signatures didn't catch the bad case from
<https://bugs.swift.org/browse/SR-10752>. Add a new check and
make sure it now catches this kind of failure.
This check wasn't ever correct, because the fact that the the protocol comes
from another module doesn't change the fact that the type is valid for lookup
within this module. It incorrectly rejects the following, valid code:
```swift
// In A.swift
public protocol A {}
```
```
// In B.swift
import A
extension A {
typealias B = Int
func b(_ b: Self.B) {}
}
```
The GSB should avoid triggering declaration validation where
possible, to avoid problems resulting from circularity and as
a general performance rule-of-thumb.
This last call was there to catch self-recursive protocol
typealiases. However, we can diagnose this problem elsewhere,
which allows us to emit a more accurate diagnostic as well.
Replace most remaining uses of isRequirementSignatureComputed by
isRequirementSignatureComputing which uses Evaluator::hasActiveRequest
to detect if the requirements are currently being computed.
Replaces the explicit call to computeRequirementSignature from
validateDecl with a lazy getRequirementSignature. A side effect is that
the generic params of a ProtocolDecl are no longer computed from
validateDecl and must be computed lazily too.
Opaque result type archetypes can involve type variables, which
then get introduced into GenericSignatureBuilders and the
generated GenericSignatures. Allocate them in the proper arena
So we don’t end up with use-after-free errors.
Fixes rdar://problem/50309503.
Fixes crashes in 28437-swift-typechecker-validatedecl.swift (from previous commit)
and the compiler crasher 28861-gpdecl-getdepth-generictypeparamdecl-
invaliddepth-parameter-hasnt-been-validated.swift.
Swap the `array_pod_sort` to `sort`. `array_pod_sort` is meant to be
used with POD types only. Switching to `std:sort` should be slightly
faster, and more importantly, allows the emission of the warnings on
Windows to be sorted identically to Linux and macOS.
Calling DependentMemberType::get() repeatedly pollutes the processor
caches because the global hash table can be quite large. With this
change, we either precompute DependentMemberTypes or cache them on
demand. This change makes the release/no-assert build of
Swift.swiftmodule 4.1% faster.
We generated a mix of "inferred" and "nested type name match"
constraints for the case where we had two nested types with the same
name and inferred that they are equal. Make them consistent by always
using nested type name match constraints. This fixes a bug where we
would get different canonical generic signatures in different source
files because we inferred the same-type constraint with different
requirement sources.
Fixes rdar://problem/48049725.
* [diag] add a diagnostic note for the fixit
* [gsb] emit a diagnostic with fixit to replace ':' with '=='
* [gsb] rename variable
* [gsb] replace dyn_cast with isa
* [test] add a test case
* [test] update tests
* [gsb] emit diagnostic for protocols as well
* [gsb] simplify if statement
* [gsb] rename a variable
* [gsb] Create a helper to remove Self. prefix and add a new test case
* [gsb] simplify checks
* [gsb] move the diagnostic code to finalize()
* [gsb] re-indent
* [gsb] fix a typo
* [gsb] pass values as copy
* [gsb] show a fixit if the subject type is a member type
* [test] update diagnostics in existing tests
* [gsb] check if the subject type has an assoc type decl
* [gsb] use requirement source
* [test] add new tests
* [gsb] use constraint struct and rename to invalidIsaConstraints
This test case used to crash because the source-location-based order
here did not handle invalid source locations, but Doug fixed it already
in #21656. However, fixing it to sort invalid locations after valid
locations meant that the diagnostic code would pick the invalid location
to emit the diagnostic on, so no diagnostic was emitted.
This is not a big deal since the diagnostics in question are warnings,
but we do want to emit these redundant constraint warnings to avoid
confusing users if possible so let's fix it to do the right thing.
More completely fixes rdar://problem/46848889 (but it was already not
crashing after Doug's fix).
This reverts commit c725660cc9. It
uncovered a use-after-free in the GenericSignatureBuilder. Apologies
for the lack of a test case here; I'm still looking for something
small enough to commit.
Fixes rdar://problem/46772328.
