It's like Builtin.gep, but marks the resulting `index_addr` as a projection, meaning the result can only reach the single element at the given index and cannot be used for general pointer arithmetic by chaining `index_addr` instructions.
**Overview**:
This PR introduces the basic infrastructure needed to eventually migrate
derived macros generation from hand-crafted AST nodes to macros. No
conformance have been migrated yet.
**Motivation**:
Derived conformances (e.g. `Equatable`, `Hashable`, `Codable`, ...) are
currently implemented as a special case in the compiler, producing
synthetic AST nodes directly. Migrating this to macros will hopefully
unify the code path with the existing macro expansion infrastructure,
make conformance synthesis easier to extend and test as well as reducing
the amount of special cases in the compiler.
**Changes**:
- New experimental feature flag `DeriveConformancesViaMacros`:
Introduces the flag that will eventually gate the new derived
conformance code paths. It does not control any behaviour for the moment
as none have been migrated yet but this enables future changes to be
built incrementally.
- New GeneratedSourceInfo and SourceFile kinds `SyntheticMacro`:
Introduces new GSI and SourceFile kinds named `SyntheticMacro` to
represent macros synthesized by the compiler. Since macros need a real
buffer to expand, this is the kind of source file and GSI associated
with those buffers.
- Conformance derivation via macros API:
Introduces the `deriveRequirementViaMacro` function that produces the
required witness via macro expansion.
See https://github.com/swiftlang/llvm-project/pull/13124 for
llvm-related changes.
**Next steps**:
- Macros do not contain any semantic information, especially regarding
types. Therefore it is necessary to provide them with type information
as an argument so they can eventually derive the conformances. A
separate PR is being created to generate this type information as
strings containing swift-parsable code for easy parsing on the macro
end.
- Implement derived conformance synthesis for individual protocols using
the new infrastructure, like `Equatable` or `Hashable` for starters.
- Wire the experimental flag to gate the new path once an implementation
exists
---------
Co-authored-by: Hamish Knight <hamish_knight@apple.com>
This is a follow-up to 6c464579.
Importing superclasses of C++ foreign reference types can introduce source breaks in Swift under some circumstances.
This change puts the feature behind an experimental flag.
rdar://178736469
Previously, the Sema changes that defer checking of global-actor-isolated
initializers (and the global-actor-isolated stored properties they access) to
the SIL-level flow-isolation pass were enabled unconditionally whenever strict
concurrency was complete.
This introduces a new experimental feature, FlowIsolationGlobalActor, and gates
those two Sema delegation code paths behind it:
- isolatedConstructorRequiresFlowIsolation's GlobalActor case, which makes
synchronous global-actor-isolated nominal-type initializers use
flow-sensitive isolation.
- ActorReferenceResult::Builder::build's checkedByFlowIsolation delegation,
which suppresses the cross-isolation Sema diagnostic in favor of the
flow-isolation pass.
With the feature off, we restore the prior Sema behavior. Since the SIL passes
key off usesFlowSensitiveIsolation, gating Sema is sufficient end-to-end.
The dedicated flow_isolation_* tests and the shared tests whose expectations
were updated for this behavior now enable the feature explicitly. A small,
standalone flow_isolation_no_feature.swift test validates that the old behavior
is restored without the flag and is easy to delete once the feature becomes the
default.
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.
@_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
In non-resilient modules, stored properties are implicitly exported for layout purposes, preventing the use of types from an internal
bridging header. This adds the AbstractStoredPropertyLayout experimental feature flag that suppresses the exportability diagnostic
specifically for layout-contributing stored properties (ImplicitlyPublicVarDecl and ImplicitlyPublicVarDeclOpenClass), enabling a
public struct to contain private stored properties of C types imported via -internal-import-bridging-header.
This is the first step toward encoding abstract layout information in the .swiftmodule so that clients can allocate, copy, and
destroy values without loading the internal C dependency.
The @diagnose attribute only affects local diagnostic behavior within a declaration's body and has no API or ABI impact. It should not appear in .swiftinterface files, and should not cause declarations to be wrapped in #if $SourceWarningControl feature guards.
Support for existentials in Embedded Swift has been available for a
little while now and appears to be solid. Remove the ability to disable
them (via `-disable-experimental-feature EmbeddedExistentials`), both
because it simplifies the code and because it's an ABI break to
disable the feature.
The only known condfail scenario is inheriting from
a protocol P that inherits from a reparentable one R.
We already guard P if it mentions R in its inheritance clause.
So older compilers will simply report that "P" is missing in the
interface, which is a better error message than virally guarding
everything mentioning P. It's an ABI break anyway to do that
without introducing a `@reparented` extension, which needs a guard.
In theory, older compilers shouldn't have too much go wrong if they
were to ignore `@reparentable`, though the RequirementMachine and
witness tables will look different.
rdar://174263176
Otherwise we can emit those funcs into clients whose SDK doesn't know
about the builtins and fail compilation with module 'Builtin' has no member named 'taskCancellationShieldPush'
resolves rdar://173170400
I can't quite enable modeling their stack effects in this patch because
SILGen generates improperly-nested allocations; that'll be fixed in a
follow-up.
The feature was added only to avoid a reverse-condfail
in the initial bring-up of noncopyable generics.
Nearly 2 years have passed since the last time I tried
to remove this old technical debt [1] and had to revert
it due to outdated build bots [2]. Hoping that won't be
a problem this time.
[1] 5b2f2cbfcf
[2] https://github.com/swiftlang/swift/pull/75267
resolves rdar://131560183
rdar://158239258
This change adds logic in the compiler to compute malloc type ids and emit them together with typed allocation calls. It also adds the new runtime function swift_allocObjectTyped, which calls typed malloc.
This gates the ability to use the BorrowingSequence protocol's name (and
the names of the related types) behind a feature flag.
Landing this separately from #87483.
ForEach support for Borrowing sequence
For testing purposes, this commit includes _BorrowingSequence and _BorrowingIterator protocols, with conformance for Span and InlineArray.
This change adds an experimental feature 'LiteralExpressions` which allows for use of simple binary expressions of integer type composed of literal value operands.
For now, such literal expressions are only supported in initializers of '@section` values.
Enable the feature by default, and add an experimental feature
`DeprecateCompatMemberwiseInit` to control the deprecation behavior
which was deferred from the proposal.
A protocol that's been reparented declares it
by writing `@reparented` in its inheirtance clause
for each new parent. You can introduce a `@reparented`
parent to a pre-existing ABI-stable protocol's
inheritance hierarchy.
Only protocols declared to be `@reparentable` can be
used to reparent other protocols. Adding or removing
the `@reparentable` attribute is ABI-breaking, as it
effects the type metadata layout. Thus, reparentable
protocols must be born as such to use them with
protocols that are already ABI-stable.
This set of changes does not include the actual
implementation of ABI-stable reparenting.
Meghana Gupta
Erik Eckstein
Paul Passeron
Egor Zhdan
Konrad `ktoso` Malawski
Michael Gottesman
Michael Gottesman
Alejandro Alonso
Doug Gregor
Kavon Farvardin
Artem Chikin
Xi Ge
John McCall
Susana Monteiro
Dario Rexin
Allan Shortlidge
Nate Cook
Joe Groff
John Hui
elsa
Elsa Keirouz
Hamish Knight
Aidan Hall
Aidan Hall