The default code generation model for Embedded Swift is "inlinable".
DeferredCodeGen made the default code generation model
"implementation", and there was no spelling for "interface".
Introduce the experimental feature CodeGenerationModel=<model>, which
can be any of those three options. The default remains "inlinable", but
one can now specify "implementation" (which keeps most everything in
SIL) or "interface" (which only keeps the generic things in SIL). The
"interface" mode is more like non-embedded Swift for non-generic
declarations, emitting them into the IR (only) but not SIL. Generic
declarations would remain in SIL.
Implements rdar://172433062.
The code generation model for a particular declaration or conformance
can be defined explicitly with `@export(interface)`,
`@export(implementation)`, or `@inlinable` (for declarations),
indicating where the definition will occur.
Embedded Swift also has some limitations on what can be emitted into
IR. For example, a generic function cannot be `@export(interface)`
because Embedded Swift does not support unspecialized generics.
Compute the effective code generation model based on what was
explicitly specified, the limitations of the model, and the default
code generation model for the given module, which defaults to
"inlinable" but can be made "implementation" by the DeferredCodeGen
feature. Use the effective code generation model for IR- and SIL-level
determinations of linkage and where to emit symbols.
[WIP] Start computing and using the "effective" code generation model
FIXUP linkage of the alias symbol
The substitution is driven by a canonical type to mangled name table on ASTContext,
populated by exportability checking at the same site where the corresponding
diagnostics are suppressed. After this change, the module emitter and module
loader see hidden types differently: the emitter still sees the real types
defined in the bridging header, while the loader sees only a mangled name
wrapped in a HiddenType placeholder.
This is not supported for the same reason you can't have a noncopyable
variadic parameter, but the code was hard-coded to check for copyability
only.
Generalize this to apply the generic signature for Array via the
common code path, and add a custom note to explain why those requirements
are checked in the first place.
Cleaning this up also fixed some fuzzer crashes.
Reported on the forums:
https://forums.swift.org/t/variadic-escapable-arguments-crash-the-compiler/86727/2
Add the module-format machinery that lets a Swift library record the
physical layout of hidden types (currently limited to C types imported via internal bridging header).
into binary modules, so downstream consumers can pull the layouts of these hidden types without
loading the internal dependency.
To test this, this change also added a frontend action to print hidden types' layouts
from both the module under compilation and all the modules being imported.
The “no unsafe operations occur within ‘unsafe’ expression” diagnostic was not part of any warning group.
The new group also includes the matching “try” and “await” warnings.
@_preInverseGenerics(except: <inverses>) is an extension of the existing
@_preInverseGenerics attribute that provides selective control over which
inverse requirements are mangled into a declaration's symbol name.
While the bare @_preInverseGenerics strips all inverse constraints
(~Copyable and ~Escapable) from mangling, the 'except:' form allows specific
inverses to be retained. This is needed when a type like Span already had
~Copyable mangled into its ABI-stable symbols and now needs to retroactively
adopt ~Escapable without changing those existing symbols. You can now express
that with `@_preInverseGenerics(except: ~Copyable)` to strip-out every inverse
except ~Copyable to preserve the pre-existing ~Copyable-containing symbols.
It requires the new experimental feature `PreInverseGenericsExcept`.
rdar://176395527
llvm::cl::opt flags are compiled out in non-asserts builds, making these
debug flags unavailable in an important category of use cases — debugging
a release compiler in lldb. By promoting them to Swift frontend flags stored
in DiagnosticOptions/SILOptions, they are available in all build
configurations.
The three existing flags are migrated:
-diagnostics-assert-on-error
-diagnostics-assert-on-warning
-sil-region-isolation-assert-on-unknown-pattern
(backing field renamed to AbortOnUnknownRegionIsolationPatternError)
A new flag is added:
-diagnostics-assert-on-group <group>
Traps when any diagnostic belonging to the named group is emitted,
allowing targeted breakpoints on a single diagnostic group rather than
all errors or all warnings.
The assert-on-{error,warning,group} flags are intentionally kept separate
from the normal diagnostic suppression/escalation machinery so that they
remain useful while other diagnostics are also being emitted.
Tests are added for all four flags.
The diagnostic for an async sequence `for` loop missing a `try` got
accidentally dropped during the `for` loop desugaring rework. Restore
it here.
rdar://177062849
If a C++ method is not static, let's not allow changing its parent struct type to a different type, since the implicit `this` parameter would have an incompatible type.
This fixes an assertion that would previously fire for this scenario.
rdar://161208348
Now that module selectors (SE-0491) are used by default when printing
.swiftinterface files, the following warning is unnecessary:
```
public struct <name> shadows module <name>, which may cause failures...
```
Remove the implementation of the warning entirely. Technically, we could keep
diagnosing the issue when use of module selectors in .swiftinterface files is
disabled via the `-disable-module-selectors-in-module-interface` flag, but on
balance it does not seem worth it since we don't anticipate any uses of that
flag aside from temporarily working around compiler bugs.
Resolves rdar://176476640.
HiddenType is a new TypeBase subclass that carries a mangled name
without leaking the actual type definition. It serves as a type-slot
placeholder for stored-property types that have been elided from a
serialized binary module, so that the client side can either
(1) resolve this mangled name to the real type if the client has access to the owning module, or
(2) use the mangled name as a key to query abstract layout information also serialized in the binary module.
As an example — a library with a hidden field of a bridging-imported type:
```
// Utility.h (internal bridging header)
// typedef struct { int value; } Wrapper;
public struct S {
private var w: Wrapper
public var weight: Double
}
In the serialized module, the client's view reconstructs as:
public struct S {
private var w: @_hidden("$sSo7Wrappera")
public var weight: Double
}
```
Protocol conformances normally have shared linkage in Embedded Swift.
However, allow the use of @export(interface) on conformances (by way
of their enclosing nominal type or extension), which will emit the
witness tables for those conformances as strong symbols in the owning
module, and references to these symbols from other modules.
@export(interface) makes it so that Embedded Swift will emit a strong
definition of a symbol in its defining module, and use that symbol in
other modules. Extend this notion to non-generic types, where we will
emit a strong definition for the full type metadata, and let it be
referenced from other modules rather than the lazy, shared emission.
Implements rdar://176392354.
Computes per-field abstract layout (offset, size, alignment, mangled name,
bitwiseCopyable, isOpaque) for structs with both Clang-imported and Swift-native fields.
This API will be used from the library-side to serialize layout information to binary modules.
Adds a new DynamicMemberLookupSubscriptRequest type for evaluating and
caching the validity of a `SubscriptDecl`'s usage to fulfill a
`@dynamicMemberLookup` requirement for a specific usage.
Adds support for `SubscriptDecl`s to fulfill `@dynamicMemberLookup`
requirements if they have additional arguments after `dynamicMember:` so
long as those arguments have default values, or are variadic.
This allows exposing values like `#function`, `#fileID`, `#line`, etc.
to dynamic member lookup.
`SubscriptDecl`s may get checked multiple times for eligibility in
fulfilling `@dynamicMemberLookup` requirements; since the checks are
non-trivial and the result doesn't change, this eligibility can be
cached in the decl's `Bits`.
Doug Gregor
Xi Ge
Slava Pestov
Jamie
Michael Gottesman
Hamish Knight
Guillaume Lessard
elsa
Kavon Farvardin
Aidan Hall
Michael Gottesman
Egor Zhdan
Allan Shortlidge
Aidan Hall
Artem Chikin
Karoy Lorentey
Pavel Yaskevich
Gábor Horváth
Itai Ferber
Itai Ferber