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().
-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.
- The GenericSignatureBuilder assumed it didn't have to look in
protocol extensions to resolve member types.
- Serialization was incorrectly filtering out such typealiases when
trying to resolve a cross-module reference to one.
rdar://problem/46103190
Instead of using `std::sort`, transform source-ordered edge vector
to reference `IntercomponentEdge *` instead of their indices in
`intercomponentEdges` vector and use `llvm::array_pod_sort` to sort them.
Instead of trying to order based on the "nested depth", let's
always prefer canonical ordering of type parameters when it comes
to picking representative equivalence class.
Resolves: rdar://problem/45957015
We diagnose and flag these in finalize(), but we can encounter one
even earlier through resolveDependentMemberTypes(). Do the same
thing there that we already do in EquivalenceClass::getTypeInContext().
Fixes <rdar://problem/45328122>, <https://bugs.swift.org/browse/SR-9022>.
In structural lookup mode, let's resolve protocol typealiases to
dependent member types also. This is because areSameType() has
no way to see if a type alias is going to be equal to another
associated type with the same name, and so it would return false,
which produced ambiguity errors when there should not be any.
This exposes a deficiency in how we diagnose same-type constraints
where both sides are concrete. Instead of performing the check on
the requirement types, which might be dependent member types that
later on resolve to concrete types, do the check on the actual
equivalence classes further down in the GSB instead.
However, this in turn produces bogus diagnostics in some recursive
cases where we add same-type constraints twice for some reason,
resulting in a warning the second time around. Refine the check by
adding a new predicate to FloatingRequirementSource for requirements
that are explicitly written in source... which is not what
isExplicit() currently means.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
Most callers aren't concerned about the difference between the two (and those that are are already exercising the appropriate assertions with e.g the use of `getFirstType()`).
