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()`).
When provided, this flag warns about implicit overrides, where a
declaration overrides another declaration but is not marked with the
‘override’ keyword. The warning can be suppressed by either providing
‘override’ or ‘@_nonoverride’.
At present, this only happens with overrides in protocols.
For explicit abstract protocol floating requirement sources, get the source location from the protocol requirement rather than delegating to the parent `RequirementSource`.
Rather than using RequirementRequest::visitRequirements() for its side
effects, then reading from the TypeLocs left behind, start eliminating
TypeLoc-based APIs so we pass Type and TypeRepr separately.
Add some utilities to dig into a possibly-null RequirementRepr* and dig
out the appropriate TypeReprs.
Introduce a new form of request that produces the ith Requirement of the
where clause of a given entity, which could be a protocol, associated type,
or anything with generic parameters. The requirement can be evaluated
at any type resolution stage; the “interface” type stage will be cached
in the existing RequirementReprs.
Fixes SR-8119 / rdar://problem/41498944.
Extend the inputs to InheritedTypeRequest, SuperclassTypeRequest, and
EnumRawTypeRequest to also take a TypeResolutionStage, describing what
level of type checking is required. The GenericSignatureBuilder relies
only on structural information, while other clients care about the
full interface type.
Only the full interface type will be cached, and the contextual type
(if requested) will depend on that.
- 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.
