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
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.
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.
With the new option, when doing caching we write the hash that we already
computed for the main output file to an extended attribute (xattr) on the file.
This is equivalent to clang's -fwrite-output-hash-xattr option.
The format of the xattr is
name: com.apple.clang.cas_output_hash
data:
* Null-terminated hash schema name, e.g. llvm.builtin.v2[BLAKE3].
* Hash length (4 bytes, little-endian).
* Hash bytes
rdar://171185394
This no longer causes a regression in number of CAS instances.
Prefer llvm::cas::CASConfiguration where it used to clang::CASOption.
(cherry picked from commit 4f059033bb)
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
When building the `OSLog` module, look for a variable named
`osLogStringSectionName`. It must have a string literal as its
initializer, which provides the section name where the log strings
should be emitted. The `OSLog` module should contain something like
this:
let osLogStringSectionName = "__TEXT,__logit"
When not present, the compiler will default to
`__TEXT,__oslogstring,cstring_literals`, which was previously the
hardcoded section name. Now, OSLog can customize the name.
Implements rdar://171571056
`-enable-experimental-feature SourceWarningControl` guards the actual *use* of `@warn` attribute, but it did not guard this logic which queries it, which is meant to be general in the absense of the attribute as well.
We are seeing some unintended compile time performance implications from this logic, so for now guard it behind the same experimental feature flag.
Related to rdar://171506799
This mirrors Clang's `-fsanitize=fuzzer-no-link`, which applies the
appropriate instrumentations but does not attempt to link to the
runtime library. More importantly, this suppresses the check in the
driver that fails the build if the library cannot be found. Since
libfuzzer is not distributed with Xcode, this allows users to build
it themselves or take it from a swift.org toolchain and use it
without having to physically copy/link it into their toolchain's
runtime directory.
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.
LLDB defines `lldb::private::swift::` which causes ambiguity for
lookups. Use aliases and fully qualified names to avoid the ambiguity.
This fixes some errors with building on Windows with the GNU driver.
This replaces #87114, aligning the `BorrowingSequence` protocols and
related types to the Swift Evolution proposal, and without included
reparenting of `Sequence`.
Doug Gregor
Michael Gottesman
Kavon Farvardin
Michael Gottesman
Artem Chikin
Henrik G. Olsson
Xi Ge
Pavel Yaskevich
Alejandro Alonso
Henrik G. Olsson
Aidan Hall
Aidan Hall
CognitiveDisson
Tim Kientzle
Meghana Gupta
Alexis Laferrière
Meghana Gupta
Konrad `ktoso` Malawski
Allan Shortlidge
Pavel Yaskevich
John McCall
Ben Langmuir
Dario Rexin
Steven Wu
Tony Allevato
Hamish Knight
Tony Allevato
Saleem Abdulrasool
Nate Cook
Slava Pestov