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.
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.
This reverts commit bb16ee049d,
reversing changes made to a8d831f5f5.
It's not sufficient to solve the problem, and the choices were to do
something more complicated, or just take a simple brute force
approach. We're going with the latter.
...and fix places where it was being used inappropriately.
- Don't use 'open' on non-class members in the importer.
- Use the existing 'copyFormalAccessFrom' instead of an ad hoc version
for synthesized typealiases for protocol conformances. (This can
change 'internal' down to 'fileprivate', but only where the
enclosing type was already 'private' or 'fileprivate'.)
- Fix 'copyFormalAccessFrom' to not copy '@usableFromInline' onto
declarations that don't support it (namely, the above typealiases).
This should have no visible effect in practice.
Since 'private' means "limit to the enclosing scope (and extensions
thereof)", putting it on a member means that the member can't be
accessed everywhere the type might show up. That's normally a good
thing, but it's not the desired effect for synthesized members used
for derived conformances, and when it comes to class initializers this
actually violates AST invariants.
rdar://problem/39478298
A protocol extension of a private protocol can define internal
or public members. We should not be able to find these members
from another file or module if an internal or public type
conforms to the protocol.
Fixes <rdar://problem/21380336>.
LLDB creates global typealiases that have archetypes in them, which
violates AST invariants and trips up the AST verifier. Introduce a specific
bit that LLDB can set to indicate that a given typealias is such an alias.
We'll skip AST verification for such typealiases.
As a way to stage in this change without requiring synchronization
across the Swift and LLDB repos, also match typealiases with the names
$.*lldb in the AST verifier and skip verification. Once LLDB is
setting the bit appropriately, we'll remove this hack.
Instead of passing the base expression of a member access to `getAccessSemanticsFromContext`, we now just pass a bool flag for whether this is a member access on the implicit 'self' declaration.
Currently we always directly access a member when mutating it in its own didSet/willSet observer (in order to prevent infinite recursion). However we also do this even when accessing the same member on a *different* instance.
This commit changes the behaviour such that only member accesses on the implicit 'self' declaration are accessed directly within that member's own willSet/didSet.
Note that this change has the potential to cause recursion in cases where it didn't previously, for example this will now infinitely recurse:
struct S {
var i = 0 {
didSet {
var s = self
s.i = 5
}
}
}
var s = S()
s.i = 2
I don't know how serious this impact is though.
Resolves SR-419.
- Reuse existing logic to curry the signature type with the 'self' of the context (in addition we no longer use a MetatypeType for the 'self' of a static member as they don't have conflicting signatures with instance members anyway)
- Limit the fix for SR-7251 to Swift 5 mode
- Add tests for generic subscripts
I also tried to move the early attribute validation bit into this enum,
but as it turns out, decls aren't consistent about when they do early
attribute checking relative to calling setIsBeingValidated(). Some do early
attribute checking before validation, others do it after, and some do it
during. I tried to make early attribute checking be consistently early,
but that broke a few tests.
Currently we only give subscripts and var decls custom overload types if they're in generic extensions. However, because we give them no custom overload type in any other case, we don't detect for example a conflict with a previous declaration in the body of the extended type.
This commit changes the overload type logic such that properties and subscripts are always given custom overload types, which is determined by:
- The interface type of the decl (for subscripts only; as variables cannot be overloaded by type)
- The 'self' type of the context, if any
- The generic signature of the context, if any
Additionally, this commit adds a new `swift::conflicting` overload to ensure that different declarations always conflict even if their overload types are different.
Resolves SR-7249, SR-7250 & SR-7251.
Warn in Swift 4 mode and error in Swift 5 mode when switching on a
non-frozen enum without providing a default case.
Note that this is a preliminary implementation, in order to test the
rest of the feature.
We have a predicate in ClassDecl, 'inheritsSuperclassInitializers',
that is used in a few places to decide if we need to do lookups into a
superclass to find all relevant initializers. That's useful, but the
actual work being computed in that function is almost identical to the
work done in figuring out whether the class has provided all its
superclass's /required/ initializers, which is part of the type
checker operation 'resolveImplicitConstructors'. Furthermore,
'inheritsSuperclassInitializers' is /already/ calling
'resolveImplicitConstructors' because those implicit constructors
might affect the result.
Simplify this whole mess and prevent further inconsistencies like the
previous commit by just making 'resolveImplicitConstructors' decide
whether superclass convenience initializers are inherited. It does
make that function more complicated, but with the benefit of not
having duplication anymore.
No intended user-visible change, except that this bit is now
serialized instead of being recomputed, which means the module format
changed.
Implements the minimum specified by the SE-proposal.
* Add the CaseIterable protocol with AllCases associatedtype and
allCases requirement
* Automatic synthesis occurs for "simple" enums
- Caveat: Availability attributes suppress synthesis. This can be
lifted in the future
- Caveat: Conformance must be stated on the original type
declaration (just like synthesizing Equatable/Hashable)
- Caveat: Synthesis generates an [T]. A more efficient collection
- possibly even a lazy one - should be put here.
