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.
Typealiases were getting type-checked in their parent's context, not
their own context. For non-generic typealiases this is fine, because
the generic environment is inherited. Generic typealiases, on the
other hand, have their own generic environment that should be used. Do
so.
We cannot properly determine the context type of any parameter
(including 'self') until after we have determined the generic
environment for the enclosing function.
This makes sure that removed constraints are returned back to the
system after current run, otherwise only constraint graph would
get them back since it has its own scope.
The generic environment of a GenericTypeToArchetypeResolver may be
`nullptr`, as returned by DeclContext::getGenericEnvironmentOfContext,
during prechecking of closure expressions at the necessarily non-generic
top level.
Fixes a couple of crashers.
The code here is unprincipled, and mixes archetypes from
multiple sources:
1) The callee's generic environment
2) The caller's generic environment
3) Any random archetypes appearing in the original types of
typealiases, which could come from any generic environment
Initially, an UncurriedCandidate's type starts out as #1,
and then we sometimes set it to type #2 if the candidate is
a method on a base class.
We get #3 by virtue of walking the original types of
SubstitutedTypes created as part of dependent member type
substitution.
However, it turns out the real reason the SubstitutedType
walk existed was so that #2 archetypes that appear in the
UncurriedCandidate's type map to themselves. This doesn't
require looking at the original type of a SubstitutedType
at all; instead we just walk the UncurriedCandidate's type
normally, collecting archetypes.
If we do this, the code doesn't (erroneously) pick up random
archetypes from typealiases, and this changes the output in
the RangeDiagnostics test. While we can debate if the new
diagnostics are better or worse (I think it's either a wash,
or slightly better) the reason they changed is because more
in-depth diagnostic code is now executing, without breaking
things randomly as before. I suspect this is a good thing.
With erroneous code, such as in code-completion, it's not safe to assume
that the constructor is inside a nominal decl context.
rdar://problem/28867794
We already fail early on a missing body in normal type-checking, but we
missed the case where we call typeCheckAbstractFunctionBodyUntil
directly, as in code-completion.
rdar://problem/28822204
This eliminates a usage of SubstitutedType.
Unfortunately, we still need a simpler version of the old
check for the case where a 'var' has no explicit type written,
and instead the type is inferred from the initializer
expression.
The check for inferred types of vars no longer looks at
SubstitutedType, so it misses the accessibility of dependent
typealias members. A new test case demonstrates the problem.
Note that dependent typealiases were substituted away as far as
the user is concerned anyway, not showing up in generated
interfaces or diagnostics.
Also the new logic is more accurate in the case where a
TypeRepr is present, which is most of the time.
Another oddly-named utility function with poorly-defined behavior.
It returned true for archetypes, generic parameters, existential
types, and metatypes of existential types.
However, it would return false for dependent member types, or
metatypes of archetypes, and so on.
All the callers were doing something bad to begin with, so
changing them over to more precise predicates improved the code.
In particular, this simplifies substitution construction in
the SIL parser, and makes it stricter, which turned up a couple
of mistakes in the SIL tests where we were doing stuff with
non-conforming types.
This function did three things:
- In debug builds, record an association between the newly-created
context archetypes and the current DeclContext.
- Set the accessibility of the GenericTypeParamDecls as appropriate.
- Re-check the types written in the GenericParamList.
The last step was not needed, because we no longer serialize
GenericParamLists, or care if the RequirementRepr contains valid
types at all. The other two have been moved elsewhere.
First, ensure all ParamDecls that are synthesized from scratch are given
both a contextual type and an interface type.
For ParamDecls written in source, add a new recordParamType() method to
GenericTypeResolver. This calls setType() or setInterfaceType() as
appropriate.
Interestingly enough a handful of diagnostics in the test suite have
improved. I'm not sure why, but I'll take it.
The ParamDecl::createUnboundSelf() method is now only used in the parser,
and no longer sets the type of the self parameter to the unbound generic
type. This was wrong anyway, since the type was always being overwritten.
This allows us to remove DeclContext::getSelfTypeOfContext().
Also, ensure that FuncDecl::getBodyResultTypeLoc() always has an interface
type for synthesized declarations, eliminating a mapTypeOutOfContext()
call when computing the function interface type in configureInterfaceType().
Finally, clean up the logic for resolving the DynamicSelfType. We now
get the interface or contextual type of 'Self' via the resolver, instead
of always getting the contextual type and patching it up inside
configureInterfaceType().
PotentialArchetype::getNestedType() was effectively reimplementing a
simplified form of mapTypeOutOfContext(), missing some cases in the
process. Just use mapTypeOutOfContext() and resolveArchetype(). While
here, stop re-implementing the addSameType* operations; just call them
directly. With these changes, we no longer need the "typealias in
protocol is too complex" diagnostic.
Eliminates another use of getSelfTypeInContext().
The code that diagnosed availability for types was reverse-engineering
the Type itself, rather than making use of the declaration already
stored within the TypeRepr.
More importantly, it would completely skip nested types, so it would
fail to diagnose a deprecated/unavailable “Bar” in “Foo.Bar”.
Replace the type-inspecting check with a much-simpler walk over the
components of the IdentTypeRepr that looks at the declarations stored
in the IdentTypeRepr directly. This provides proper source-location
information and handles nested types.
This is a source-breaking change for ill-formed Swift 3 code that used
nested type references to refer to something that should be unavailable.
Given that such Swift 3 code was ill-formed, and most uses of it would
crash at runtime, we likely do not need to provide specific logic to
address this in Swift 3 compatibility mode.
Use a syntax that declares the layout's generic parameters and fields,
followed by the generic arguments to apply to the layout:
{ var Int, let String } // A concrete box layout with a mutable Int
// and immutable String field
<T, U> { var T, let U } <Int, String> // A generic box layout,
// applied to Int and String
// arguments
After recent changes, this asserts on all decls that are not VarDecls,
so we can just enforce that statically now. Interestingly, this turns
up some dead code which would have asserted immediately if called.
Also, replace AnyFunctionRef::getType() with
AnyFunctionRef::getInterfaceType(), since the old
AnyFunctionRef::getType() would just assert when called on
a Decl.
Consider expression with an implicit 'self.' reference:
extension Sequence {
func test() -> Int {
return max(1, 2)
}
}
We currently shadow names that appear in nested scopes, so the
top-level two-argument min()/max() functions are shadowed by the
versions of min()/max() in Sequence (which don’t take the same
number of arguments). This patch aims to improve situation on this
front and produce better diagnostics when that happens, hinting
the user about what went wrong and where matching function is
declared.
Resolves <rdar://problem/25341015>.
The previous patches regressed a test where we used to diagnose
(poorly) a circular associated type, like so:
associatedtype e: e
With the error "inheritance from non-protocol, non-class type 'e'".
This error went away, because we end up not setting the interface
type of the associated type early enough. Instead, we return an
ErrorType from resolveTypeInContext() and diagnose nothing.
With this patch, emit a diagnostic at the point where the ErrorType
first appears.
Also, remove the isRecursive() bit from AssociatedTypeDecl, and
remove isBeingTypeChecked() which duplicates a bit with the same
name in Decl.
A pointless use of polymorphism -- the result values are not
interchangeable in any practical sense:
- For GenericTypeParamDecls, this returned getDeclaredInterfaceType(),
which is an interface type.
- For AssociatedTypeDecls, this returned the sugared AssociatedTypeType,
which desugars to an archetype.
- For TypeAliasDecls, this returned TypeAliasDecl::getAliasType(),
which desugars to a type containing archetypes.
- For NominalTypeDecls, this returned NominalTypeDecl::getDeclaredType(),
which is the unbound generic type, a special case used for inferring
generic arguments when they're not written in source.
