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.
We don't want -enable-resilience to change type checker behavior,
so in a few places we will need to check if a declaration is
"formally fixed-layout", which will be false if the declaration
was not explicitly marked as @_fixed_layout, even when the module
was not built with resilience.
We should have a more general fix that clones the attribute list here,
but it looks like some attributes have parameters and that it could be
a bit more involved than I can tackle at the moment, so I created
https://bugs.swift.org/browse/SR-6741.
DeclContexts as they exist today are "over aligned" when compared to
their natural alignment boundary and therefore they can easily cause
adjacent padding when dropped into the middle of objects via C++
inheritance, or when the clang importer prefaces Swift AST allocations
with a pointer to the corresponding clang AST node.
With this change, we move DeclContexts to the front of the memory layout
of AST nodes. This allows us to restore natural alignment, save memory,
and as a side effect: more easily avoid "over alignment" in the future
because DeclContexts now only need to directly track which AST node
hierarchy they're associated with, not specific AST nodes within each
hierarchy.
Finally, as a word of caution, after this change one can no longer
assume that AST nodes safely convert back and forth with "void*". For
example, WitnessTableEntry needed fixing with this change.
We translate IUOs to Optionals when generating signatures, but were
failing to look through inout in the process, so we were allowing
functions to be overloaded by Optional vs. IUO when the parameter was
inout.
Fixes https://bugs.swift.org/browse/SR-6685 / rdar://problem/36255630.
Redeclaration checking was validating all declarations with the same
base name as the given declaration (and in the same general nominal
type), even when it was trivial to determine that the declarations
could not be conflicting. Separate out the easy structural checks
(based on kind, full name, instance vs. non-instance member, etc.) and
perform those first, before validation.
Fixes SR-6558, a case where redeclaration checking caused some
unnecessary recursion in the type checker.
We need to use ObjC dispatch to get to the witness of an ObjC protocol requirement. The wrong answer here was causing us to do the wrong thing when producing identifiers for key paths that refer to ObjC protocol requirements.
Inline bitfields are a common design pattern in LLVM and derived
projects, but the associated boilerplate can be demotivating and
brittle. This new header makes it easier to define and use inline
bitfields in Swift.
This also reorders some fields for better code generation.
Code-completion of generic types expects to get a DeclContext for the
subscript, so make sure we recover well enough to produce a
SubscriptDecl.
rdar://35619175
