These are synthesized to satisfy associated type requirements, but
they're not needed in source, and they look like self-referential
definitions (`typealias X = X`).
...even if the base decl isn't.
This isn't normally possible, but it can come up when an imported type
is import-as-member'd onto an internal Swift declaration. This isn't
even such an unreasonable thing to do, since internal Swift
declarations are exposed in the generated header for an app.
rdar://problem/43312660
This patch removes the need for Request objects to provide a default
cycle-breaking value, instead opting to return llvm::Expected so clients
must handle a cycle failure explicitly.
Currently, all clients do the 'default' behavior, but this opens the
possibility for future requests to handle failures explicitly.
When we fail to find a particular superclass type of a type in ill-formed
code, make sure that we were right to look here at all. This re-establishes
a check I had recently weakened.
Add all of the generic parameters from outer contexts as well. This only
occurs in ill-formed code, but maintains a GenericSignatureBuilder
invariant that it knows about all of the generic parameters in play.
The name-lookup behavior that avoids looking for members of a nominal type
or extension therefore when resolving the inheritance clause is now
handled by UnqualifiedLookup, so remove it from the type checker itself.
Fixes rdar://problem/39130543.
Without this, we were firing off way more InheritedDeclsReferenced-
Requests than were actually needed. This drops it way down in the
profile, for what I /think/ is minor wins in type-checking the
stdlib...but it's hard to tell, since the time varies from run to run.
There's already a field for this in GenericContext, which ProtocolDecl
indirectly inherits. Protocols may have slightly different treatment
of their where-clauses, but not enough to justify a separate field.
No functionality change.
Rather than require clients of lookupQualified() to resolve
their type declarations to nominal type declarations (and
separately cope with modules), have lookupQualified() accept
an array of TypeDecls and handle the resolution to nominal
type declarations (where it can look directly) and module
declarations, combining the results.
We’re not using this parameter, and don’t expect to do so in the future,
so remove it. Also fold away TypeBase::usesNativeReferenceCounting()
and irgen::getReferenceCountingForType(), both of which are trivial.
Rather than validating the signature of any declaration found by
name lookup, first check whether there is a collision on the full name
of the declaration. This should result in fewer declaration validations.
The property that we are checking for here isn’t really local to the
nominal type or extension declaration, and triggers semantic queries
that aren’t needed elsewhere. Remove it, because it’s not adding value.
That is, don't look through InOutType anymore, and update callers to
call getInOutObjectType() as well (or not, where it was obvious to me
that InOutType could not appear).
This surfaces more remaining uses of getInOutObjectType() directly.
Name lookup within a protocol extension also looks into protocols and
superclasses on the right-hand side of Self constraints in the where
clause, e.g., "Self: Foo". Turn that function into a request to avoid
infinite recursion on invalid code.
Within unqualified name lookup, replace uses of Type-based lookup
(formed from calls to getSelfTypeInContext()) with declaration-based
name lookup, so that name lookup doesn't depend directly on the type
checker.
The main oddity here is that we need to consider "Self: Foo"
requirements within a protocol extension during name lookup, so that
we will also look into "Foo". This is handled via the basic
name-lookup facilities that allow us to resolve TypeReprs to
declarations without going through the type checker.
Even with an opaque abstraction pattern, we must explode a
parameter list containing __shared and __owned elements.
Otherwise, we produce invalid lowered SIL types.
Note that this is already an issue, because the stdlib has a
handful of declarations using __owned.
This is a legacy holdover from when tuple types had default
arguments, and also the constraint solver's matching of function
types pre-SE-0110.
Well, move the last live usage to CSDiag, where it can die a slow
painful death over time. The other usages were not doing anything.
This is mostly NFC; the output of the api-digester test changed because
the interface type of an enum element now has parentheses around the
'Self' parameter type. This is more consistent with everything else
(and in the future, all function types will have "parentheses").
This converts a list of ParameterDecls into a list of
AnyFunctionType::Params; it will eventually replace
these methods on ParameterList:
- getType() (both overloads)
- getInterfaceType()
- getFullInterfaceType()
