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
(and when the struct in question is non-fixed-layout, which was
already implemented)
This ensures that these initializers are never fieldwise in Swift 5
mode, which makes it safe for library authors to add new fields.
In Swift 4, properties declared with a sugared Optional type,
like Int?, have a default value of nil. This can be observed
in two ways:
- Classes and structs get an implicit no-argument initializer
- Designated initializers don't have to initialize this property
Note that this did not apply in general to properties where
the type was spelled explicitly as Optional<Int>, etc, mostly
because of implementation restrictions -- when we check if a
type has implicit initializers, we have not realized types for
all stored property members yet, and doing so is not really
possible without the iterative decl checker.
However, in some cases, we *did* perform default initialization
for Optional<Int>, because of some code duplication and
divergent code paths.
A recent refactoring cleaned up some of the mess in this area,
but accidentally broke source compatibility with code that
relied on the broken Optional<Int> case.
Fix this by simulating the old behavior in -swift-version 4,
and preserving the more correct behavior in -swift-version 5.
Fixes <rdar://problem/35319847>.
Initializers for non-fixed-layout structs that are inlinable or
are defined in a different module are treated as delegating
initializers.
Previously, only initializers containing a 'self.init' call were
delegating; initializers that assigned to 'self' were not, which
resulted in DI treating them as a root initializer where the
stored 'self' value was exploded into a series of stores to each
stored property member.
They were not resilient as a result.
Fixes <https://bugs.swift.org/browse/SR-5649>,
<rdar://problem/33767516>.
Again, since there's no distinction between an enum initializer that
delegates to 'self.init' from one that assigns to 'self', we can remove
the special handling of enum initializers in the 'root self' case.
Now, 'root self' is only used for designated initializers in classes
with no superclass, and struct initializers that perform memberwise
initialization of stored properties.
This regresses some diagnostics, because the logic for delegating
init diagnostics is missing some heuristics present in the root self
case. I will fix this in a subsequent patch.
Previously protocol extension initializers which called 'self.init' were
considered 'delegating', and ones that assign to 'self' were considered
'root'.
Both have the same SIL lowering so the distinction is not useful, and
removing it simplifies some code.
Except GenericEnvironment.h, because you can't meaningfully use a
GenericEnvironment without its signature. Lots less depends on
GenericSignature.h now. NFC
... using an inline namespace as the parent of the outermost
declaration(s) that have private or fileprivate accessability. Once
LLDB supports this we can retire the existing hack of storing it as a
fake command line argument.
rdar://problem/18296829
Use the "override" information in associated type declarations to provide
AST-level access to the associated type "anchor", i.e., the canonical
associated type that will be used in generic signatures, mangling,
etc.
In the Generic Signature Builder, only build potential archetypes for
associated types that are anchors, which reduces the number of
potential archetypes we build when type-checking the standard library
by 14% and type-checking time for the standard library by 16%.
There's a minor regression here in some generic signatures that were
accidentally getting (correct) same-type constraints. There were
existing bugs in this area already (Huon found some of them), while
will be addressed as a follow-up.
Fies SR-5726, where we were failing to type-check due to missed
associated type constraints.
When an associated type declaration “overrides” (restates) an associated
type from a protocol it inherits, note that it overrides that declaration.
SourceKit now reports overrides of associated types.
