ClassDecl::getSuperclass() produces a complete interface type describing the
superclass of a class, including any generic arguments (for a generic type).
Most callers only need the referenced ClassDecl, which is (now) cheaper
to compute: switch those callers over to ClassDecl::getSuperclassDecl().
Fixes an existing test for SR-5993.
Introduce three new requests for name lookup operations that avoid performing
type checking/semantic analysis. They work using syntactic information
(e.g., TypeReprs) and AST-level name lookup operations that will (eventually)
avoid and calls back into type checking. The new requests are:
* Retrieve the superclass declaration of a protocol or class declaration. Use
this request for ClassDecl::getSuperclassDecl() and
ProtocolDecl::getSuperclassDecl().
* Retrieve the types “directly referenced” by a particular location in
an inheritance clause. This query is based on looking at the TypeReprs
and performing fairly-minimal lookup, so it does not involve any Type
computations.
* Retrieve the types “directly referenced” by the underlying type of
a typealias. This query allows us to desugar a typealias without forming
a type.
Along with these is a core operation to transform a set of TypeDecl*s
into a set of NominalTypeDecl*s, looking through typealiases, and
without involving Type at all. The superclass-decl request does this
to find a ClassDecl; other requests will eventually do this to (e.g.)
find all of the protocols mentioned in an inheritance clause.
Switch a number of callers of the Type-based lookupQualified() over to
the newer (and preferred) declaration-based lookupQualified(). These are
the easy ones; NFC.
In an upcoming patch we're going to start calling computeType() on
constructors and destructors parsed outside type context, so let's
just bail out if we're not in type context, instead of crashing.
...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
Make the core lookupQualified() API accept an array of TypeDecls in which
it should look, rather than looking into a Type. This is in preparation
for breaking more type-checker dependencies in the name lookup code.
Add null type check for `Self` type in `UnqualifiedLookup`. It seems this
doesn't happen in normal compilation. But when code-completion happens in
inactive conditional compilation block, since surrounding context hasn't
been typechecked, `Self` type can be null.
rdar://problem/41234606
When looking for a representative superclass constraint, take into
account other same-type constraints by comparing against the resolved
superclass constraint type rather than the type as spelled.
Fixes SR-8179 / rdar://problem/41851224.
This function (actually checkAccess) was relying on some implicit
assumptions that aren't actually valid in all cases. When they're not,
just fall back to a slower but more correct implementation; when they
are, assert that the two implementations get the same answer. This
allows us to get rid of adjustAccessLevelForProtocolExtension (see
previous commit), though unfortunately not all of the associated hack.
The diff is bigger than I'd like because it includes moving functions
from NameLookup.cpp into Decl.cpp, but most of those didn't change.
- checkAccess only changed in the one if branch for protocols
- ValueDecl::isAccessibleFrom just added the assertion
- AbstractStorageDecl::isSetterAccessibleFrom did not change
No expected functionality change.
This gets adjustAccessLevelForProtocolExtension, a hack of sorts to
begin with, out of ValueDecl's general API, and down to a helper for
isAccessibleFrom and isSetterAccessibleFrom. (The only reason these
two don't go through access scopes is as an optimization.)
...to push people towards getFormalAccessScope. The one use case that
isn't covered by that is checking whether a declaration behaves as
'open' in the current file; I've added ValueDecl::hasOpenAccess to
handle that specific case.
No intended functionality change.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
A better approach would be to split off ASTScopeKind::AbstractFunctionSelf
from ASTScopeKind::AbstractFunctionParams, but for now, hack things up at
the boundary to match the old behavior.
There are two general constructor forms here:
- One took the number of parameter lists, to be filled in later.
Now, this takes a boolean indicating if there is an implicit
'self'.
- The other one took the actual parameter lists and filled them
in right away. This now takes a separate 'self' ParamDecl and
ParameterList.
Instead of storing the number of parameter lists, an
AbstractFunctionDecl now only needs to store if there is a 'self'
or not.
I've updated most places that construct AbstractFunctionDecls to
properly use these new forms. In the ClangImporter, there is
more code that remains to be untangled, so we continue to build
multiple ParameterLists and unpack them into a ParamDecl and
ParameterList at the last minute.
