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.
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
Rather than call through the LazyResolver (when available) to satisfy
queries that may require type checking, call into the evaluator
directly: it will make use of the type checker (via the lazy resolver)
when necessary. This change should allow us to use the
request-evaluator’s cache for state rather than mutable AST state,
as well as the ability to see requests that were evaluated after
type checking.
The “isObjC” bit, once computed, provides the authoritative answer. The presence of
ObjCAttr is mostly incidental, although an implicitly-created one is sometimes
needed to store additional information (“inferred with Swift 3 rules” and a
specific Objective-C name).
The patch that nailed down our semantics here missed an additional case that
required a compatibility hack: a property on a generic type and a same-named one
in an (unconstrained) extension:
struct Foo<T> {
var x: Int { return 0 }
}
extension Foo {
var x: Bool { return false }
}
Fixes rdar://problem/40685642.
Client code can make a best effort at emitting a key path referencing a property with its publicly exposed API, which in the common case will match what the defining module would produce as the canonical key path component representation of the declaration. We can reduce the code size impact of these descriptors by not emitting them when there's no hidden or possibly-resiliently-changed-in-the-past information about a storage declaration, having the property descriptor symbol reference a sentinel value telling client key paths to use their definition of the key path component.
Syntactically, Attributes for AccessorDecl are not part of AccessorDecl,
but part of PatternBindingDecl. When the selected range is the brace for
implicit getter, it should be considered as selecting getter decl
regardless of the attributes.
Conversely, we should widen source range for PatternBindingDecl by
looking into declared VarDecls because, in AST, attributes on
PatternBindingDecl are attached to VarDecls.
rdar://problem/41073182
Implement TypeChecker::resolveInheritedProtocols() in terms of
"getInheritedType()" queries, instead.
[Sema] Put back resolveInheritedProtocols().
We're still depending on it to update state in some cases.
Wire up the request-evaluator with an instance in ASTContext, and
introduce two request kinds: one to retrieve the superclass of a class
declaration, and one to compute the type of an entry in the
inheritance clause.
Teach ClassDecl::getSuperclass() to go through the request-evaluator,
centralizing the logic to compute and extract the superclass
type.
Fixes the crasher from rdar://problem/26498438.
Introduce some metaprogramming of accessors and generally prepare
for storing less-structured accessor lists.
NFC except for a change to the serialization format.
