Just like we do with SILFunction, allow a code generation model to be
specified on a SILGlobalVariable and maintain that through the printed
and serialized forms.
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.
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.
Follow-up to https://github.com/swiftlang/swift/pull/88733,
enabling the example in rdar://172511809 ([nonescapable] Allow a
nonescaping function to be a lifetime dependency source):
```swift
@_lifetime(body) // Inferred dependence kind: copy
func foo(body: () -> Span<Int>) { body() }
```
or
```swift
// Inferred: @_lifetime(copy body)
func foo(body: () -> Span<Int>) { body() }
```
Follow-up: Consider also disallowing borrow dependence on `@noescape`
closures.
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
---------
Co-authored-by: Andrew Trick <atrick@apple.com>
@_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.
When an `if #unavalable` statement also includes a secondary (non-availability)
condition, the availability scope for the else branch should not be refined.
The else branch can be reached because the secondary condition failed, in which
case the availability condition may not hold.
Resolves rdar://165863221.
When a newer toolchain (Swift >=6.2) is used with an older SDK whose
stdlib predates Swift 6.2, the Cxx module interface references
`Swift.Span` and `Swift.MutableSpan` which don't exist in the older
stdlib, causing build failures.
Guard individual declarations in the Cxx overlay that reference
`Span`/`MutableSpan` behind `#if canImport(Swift, _version: 6.2)`. The
guard wraps (rather than replaces) existing feature-based guards like
`$LifetimeDependence`, so both compiler capability and stdlib
availability are checked.
rdar://176312542
We need to follow up to avoid linear memory growth. This is not a major problem
today because AllocateCopy will almost always be called with zero size.
**Explanation**:
Implementation of `Continuation` as proposed in upcoming SE proposal:
https://github.com/swiftlang/swift-evolution/pull/3246
This is a ~Copyable Continuation with much stronger safety guarantees
and no runtime overhead. Refer to proposal for details.
Initial work by @fabianfett.
**Scope**: Adds a new continuation type.
**Risk**: Low, adds new type, allows `~Copyable` into existing builtin
-- I believe this change should be safe (?)
**Testing**: Added lots of tests covering problems this aims to prevent.
**Issues**:
resolves rdar://174826360
Somewhat relevant to rdar://139975911
Co-authored-by: Fabian Fett <fabianfett@apple.com>
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.
Resolves the following warning:
```
ASTContext.cpp:5475:47: warning: first argument in call to 'memcpy' is a pointer to non-trivially copyable type 'swift::LifetimeDependenceInfo' [-Wnontrivial-memcall]
```
Fixes a regression from https://github.com/swiftlang/swift/pull/87217.
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.
`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`.
Fix a Swift 6.3 regression in which extension members that are obsolete in the
current Swift language version are still considered available in contexts that
are also obsolete in the current Swift language version.
When computing the AvailabilityConstraints for a member of an extension,
constraints are first gathered for the member and then again for the extension
in case there are some attributes on the extension that should be effectively
inherited by the member. After gathering constraints, the core implementation
of `getAvailabilityConstraintsForDecl()` removes any constraints that can be
ignored in the given `AvailabilityContext`. That determination depends on the
kind of declaration the constraints are for, though, and it was being performed
first for the member on its own constraints and then again for the extension
for the combination of their constraints. This could result in member
constraints being ignored incorrectly.
The fix is to check whether a constraint ought to be ignored before adding it
to the set in the first place, rather than post-processing the entire
collection of constraints.
Resolves rdar://165942115.
When a pattern conformance in the pack is invalid (e.g. its underlying
conformance failed because of a prior diagnostic),
`getAssociatedConformance` returned an invalid `ProtocolConformanceRef`
whose `getType()` is null. The null type was pushed into `packElements`
and tripped an assertion in `PackType::get`. Substitute `ErrorType` for
the null so substitution can complete and the existing diagnostics
surface to the user.
Fixes https://github.com/swiftlang/swift/issues/88434.
If the fix-it would remove a range that is followed by a newline and the
remaining text on the line is empty or all whitespace then remove the entire
line. This produces better results when a fix-it removes an attribute that is
written on a line by itself.
Doug Gregor
Xi Ge
Patryk Stefanski
Michael Gottesman
Kavon Farvardin
Aidan Hall
Allan Shortlidge
Michael Gottesman
Dario Rexin
Aidan Hall
Andrew Trick
Konrad `ktoso` Malawski
Artem Chikin
Slava Pestov
Itai Ferber
Ben Cohen