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>
The cooperative global executor uses <chrono> for its handling of
times. This creates a dependency on a C++11 standard library, and
doesn't actually work with freestanding implementations like we want
for Embedded Swift.
Replace this <chrono> usage with swift_sleep / swift_get_time from
the concurrency library, which already considers various
platform-specific implementations before falling back to <chrono>.
Enable -ffreestanding for the embedded Concurrency library and its
support libraries.
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.
Add -ipi-clang-module flag to enforce IPI library level for Clang modules.
Compiler stores names of those modules and checks them during typechecking.
rdar://177196788
The suppression can help us avoid a typechecking condfail,
though the mangled names of any symbols will be wrong as we simply
omit the attribute in this simplistic suppression strategy.
related to rdar://176395527
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.
This change adds support for raw identifiers when renaming APIs in
Swift. This includes APIs defined in Swift (using the
`@availability(..., renamed: ...)` attribute), as well as C/Objective-C
(using either the `swift_name` attribute or APINotes). All of these take
decl names as strings, and so the parsing for these requires that any
decl name components (the base name or the argument labels) must have
surrounding backticks in order to be treated correctly as a raw
identifier.
Getting this working required some refactoring of `ParsedDeclName`
since it previously assumed that it could just split around delimiters
like `.`, `(`, and `:`. That's no longer guaranteed to work, so I've
introduced backtick-aware split helpers to deal with this. Likewise,
`ParsedDeclName` now keeps track of special decl base names (like
`init` and `subscript`) to ensure that they're handled properly and
not incorrectly escaped under the new logic.
@_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.
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.
This feature is just to enable a new set of diagnostics
that one can opt-into with `@diagnose` (nee `@warn`) or
with `-Wwarning`/`-Werror`.
There's no material impact on programs; it's more of a SIL pass
that you can opt into turning on that will emit diagnostics.
The current implementation does slightly change the emitted
code, so it's not just on-always until it's fully tested.
For example, it does change how no-implicit-copies enforcement
happens for `borrowing` parameters of functions, making it
effectively optional based on your preference for seeing warnings
about `SemanticCopies`. I think that's a better direction to head
towards anyway.
rdar://175897573
Normally macro expansions are typechecked through the normal traversal
of the AST. This does not happen with macro expansions in clang modules
however, since the clang module is not traversed by the typechecker.
This is not too problematic, since all the code in clang modules is
generated by the toolchain, so incorrect code would only occur when
there's a bug in the toolchain. Catching these bugs would be a lot
easier if we actually ran the typechecker during testing. We don't want
to do this normally, as it breaks the laziness of the typechecking, so
this adds -eager-macro-checking to specifically enable this behavior.
It's intended for testing purposes only.
With this option enabled the DiagnosticVerifier enforces a strict child
note hierarchy: if a note has a parent diagnostic (which it should), it
can only be matched by an expected-note matcher in the {{children:}}
block of the matcher of its parent diagnostic. This makes it clear when
reviewing which note belongs to which diagnostic, and lets
update-verify-tests keep that structure (support in update-verify-tests
not yet added). If the note is far away from the parent it can be
matched with a line marker (#foo on the line of the emitted note).
Without this option enabled (default behavior) {{children:}} blocks are
an error.
Additionally, change the verification error sort order to use buffer
ID as the primary key (address within buffer as secondary), so that
error output is stable across source files in multi-file compilations.
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.
For a given function, we might end up emitting it's definition as
object code, serialized SIL, or both. The @export, @inlinable, and
@inline(always) attributes provide control of this behavior at the
declaration level.
Centralize the query function that will look for each of these
attributes and map down to a specific "code generation model", whose 3
options follow the naming from SE-0497: interface, inlinable, and
implementation. Use this one computation to back the queries for
"always emit into client", "never emit into client", and "inlinable"
so we can't get inconsistent results from places that are doing
one-off checks for these attributes.
Back in January, I updated the swiftinterface _reading_ code to accept either
`read`/`modify` or `yielding borrow`/`yielding mutate`. That update has been
around for long enough that we can now switch over the swiftinterface _writing_
code to emit the standard final `yielding borrow`/`yielding mutate` spellings.
Interface files written with the old spellings will continue to be
accepted for some time (likely a year or more).
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
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
It was originally introduced as an upcoming feature, but there isn't any
precedent for using upcoming features as a way to opt-in to type checking fixes
without an associated Swift Evolution proposal. Rather than using a "feature" to
control this behavior, it would probably be better to offer a way to use
`-Werror` to upgrade these warnings to errors.
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.
Meghana Gupta
Erik Eckstein
Paul Passeron
Doug Gregor
Tony Allevato
Egor Zhdan
Michael Gottesman
Michael Gottesman
Konrad `ktoso` Malawski
Sam Pyankov
Alejandro Alonso
Henrik G. Olsson
Kavon Farvardin
Anthony Latsis
Tony Allevato
Artem Chikin
Xi Ge
Pavel Yaskevich
Henrik G. Olsson
Aidan Hall
Aidan Hall
CognitiveDisson
Tim Kientzle
Meghana Gupta
Alexis Laferrière
Allan Shortlidge
Pavel Yaskevich
John McCall