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.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
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
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.
Previously (a03c40cb2c) we assumed all Swift enums were non-frozen in
ObjC, a weird choice in retrospect. Now that we actually distinguish
frozen and non-frozen enums in Swift, we can use the
'enum_extensibility' attribute to mark them as open or closed in ObjC.
Note that this only matters for Swift libraries compiled with
-enable-resilience, i.e. those that might get a new implementation at
runtime. Everyone else is now declaring a "closed" enum, matching the
behavior in Swift.
"Formally non-resilient" in this new world means "the enum has a fixed
representation", which implies a fixed layout algorithm. We're not
there yet, but non-exhaustive enums should be able to be fixed-layout
as well by picking a general representation that won't need to grow.
Specifically, that's enums with raw types, and possibly also indirect
enums as well.
(It's likely the '_fixed_layout' /attribute/ on enums will go away,
but the concept of a fixed-layout enum is still useful.)
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.
This restriction came from wanting to make resilient and non-resilient
code follow the same rules whenever possible, but after thinking about
it a bit more we realized there was no reason why you /wouldn't/ just
mark your structs @_fixed_layout in non-resilient libraries anyway.
Since that (currently?) doesn't affect what you can do with the struct
across module boundaries, and since the layout of the struct is
available anyway in a non-resilient library, there's no real downside,
which means it's a meaningless restriction.
The same logic doesn't /quite/ apply to classes, since classes are
normally much more flexible than structs. (For example, you could add
a stored property to a class without recompiling clients, as long as
no initializers are inlined.) But it's close enough that we don't want
to put in the restriction at this time.
All of this is about attributes that haven't been finalized yet anyway
(hence the leading underscore), but it's still useful information.
rdar://problem/37408668
This is mostly intended to be used for testing at this point; in the
long run, we want to be using availability information to decide
whether to weak-link something or not. You'll notice a bunch of FIXMEs
in the test case that we may not need now, but will probably need to
handle in the future.
Groundwork for doing backward-deployment execution tests.
Before matching witnesses, ensure that we have a valid signature, and be
more tolerant of null generic environments by using the
mapTypeIntoContext entry point meant to handle null.
We haven't managed to get a decent reproducer for this, but it's
happening often enough, and this change hardens the affected code
paths.
Should fix rdar://problem/37255982.
* Implement #warning and #error
* Fix #warning/#error in switch statements
* Fix AST printing for #warning/#error
* Add to test case
* Add extra handling to ParseDeclPoundDiagnostic
* fix dumping
* Consume the right paren even in the failure case
* Diagnose extra tokens on the same line after a diagnostic directive
Also remove the decl from the known decls and remove a
bunch of code referencing that decl as well as a bunch of other
random things including deserialization support.
This includes removing some specialized diagnostics code that
matched the identifier ImplicitlyUnwrappedOptional, and tweaking
diagnostics for various modes and various issues.
Fixes most of rdar://problem/37121121, among other things.
This new format more efficiently represents existing information, while
more accurately encoding important information about nested generic
contexts with same-type and layout constraints that need to be evaluated
at runtime. It's also designed with an eye to forward- and
backward-compatible expansion for ABI stability with future Swift
versions.
We don't want @_fixed_layout to apply to static properties, or you
get fun consequences like not being able to change static stored
properties defined in extensions of imported types to computed.
Adding getAsGenericContext() cleans up some code, and improves the
Swift.swiftmodule build time by almost half a percent on LLVM
top-of-tree and with a simulated fix for LLVM PR35909.
This is technically a source break, but the @_fixed_layout attribute
is not official yet. If anyone really cares, we can make this
conditional on -swift-version 5 later, but I'd rather not.
This change is necessary so that we can give property initializers
non-public linkage. Currently they are public, because they can be
referenced from inlinable initializers.
Now that property initializers inside a @_fixed_layout type can
only reference public symbols, they no longer have to be public,
but making that change requires a bit more work.
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
