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.
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.
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.
...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.
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.
Constructors and methods had two parameter lists, one for self and one
for the formal parameters. Destructors only had one parameter list,
which introduced an annoying corner case.
The GenericSignatureBuilder is generating a *huge* number of invocations
of AssociatedTypeDecl::getOverriddenDecls(), causing contention in
the request-evaluator’s core data structures and a significant
slow-down in compile-time performance when the request-evaluator is
handling this computation.
Those data structures need to be optimized, but in the meantime,
introduce a performance hack to use the cached entry without going
through the request-evaluator. This will MISS dependencies and needs
to go away quickly.
SourceKit queries for the Objective-C selector as part of its syntax
model, which is a semantic query. This manifests as a crash because
the type-checking requests haven’t been wired up at this point.
For now, route around the issue by not forcing computation of the
Objective-C name if there is no lazy resolver, but longer term we need
to decide whether (1) we should allow semantic queries here or (2) we
should codify such a “best effort” computation, or (3) SourceKit should
stop doing this.
The computation of Objective-C selector names is still stateful,
triggered by computing `isObjC()`. So, trigger `isObjC()` when
asking for an Objective-C selector name.
Support an existing quirk where one can override a (dynamic) @objc
declaration with a @nonobjc one, which suppresses the inference of
‘dynamic’. In such cases, be aware that there is no vtable entry to
override.
Separate out the semantic state for the ‘dynamic’ check (from the
presence of the attribute), and move all of the computation of the
‘dynamic’ bit into the request-evaluator.
In the process, this fixes a bug where implicitly-synthesized initializers
in subclasses of imported classes would not be implicitly made ‘final’.
Introduce a new request kind to capture the computation of the set of
overridden declarations of a given declaration, eliminating the
stateful “setOverriddenDecls()” calls from the type checker.
From the perspective of the compiler implementation, they're elements. But users will think of these as cases—and many diagnostics already refer to these as enum cases.
Pass through the location of the equal '=' token for pattern binding decl entries, and use this location for the immediate deallocation diagnostic. Previously, we were just diagnosing on the start of the initialiser expression.
Additionally, this commit moves the call to `diagnoseUnownedImmediateDeallocation` from `typeCheckBinding` to `typeCheckPatternBinding`. This not only gives us easier access to the PBD entry, but also avoids calling the diagnostic logic for statement conditions such as `if let x = <expr>`. We currently never diagnose on these anyway, as the 'weak' and 'unowned' keywords cannot be applied to such bindings.
Resolves [SR-7340](https://bugs.swift.org/browse/SR-7340).
It’s quite common to emit a diagnostic about a specific declaration, where the
“location” of the is the declaration itself. Add a helper method
Decl::diagnose() to get the diagnostics engine from the ASTContext and
emit a diagnostic associated with this declaration.
Because subscripts can be generic, this isn't quite as universally useful
as you might think; it's pretty much only useful when mapping types into
the context of the declaration, e.g. into an accessor.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
Several kinds of declarations can override other declarations, but the
computation and storage for these “overridden” declarations was scattered in
at least 3 different places, with different resolution paths. Pull them
all together into two bits of LazySemanticInfo in ValueDecl (“have we computed
overrides?” and “are there any overrides?”), with a side table for the
actual list of overrides.
One side effect here is that the AST can now represent multiple overridden
declarations, although only associated type declarations track this
information.
Start using LazyResolver::resolveOverriddenDecl() more consistently, unifying
it with the separate path we had for associated type overrides. All of this
is staging for a move to the request-evaluator for overridden declaration
computation.
This function was checking isObjC() first, which is potentially expensive to
compute, and *then* performing structural checks. Re-order the checking
so that we perform the (cheap, lower-dependency) structural checks first,
and then semantic isObjC() check later.
To help us isolate the state that is primarily managed through the
request-evaluator, encapsulate that information in a LazySemanticInfo member
(as we do with superclass info and enum raw type info) rather than scattering
it around the AST.
Previously, some PBDs weren't being marked implicit even though the associated vars were implicit. PatternBindingDecl::createImplicit will be even nicer when we start parsing the location of the equals token.
