`SWIFT_IMPORT_UNSAFE` is an escape hatch that can be used to make the Swift compiler ignore its usual safety heuristics for C++ types.
`BridgedOwnedString` fits into the definition of a self-contained C++ type in Swift: it manages the lifetimes of its own fields.
This removes the usages of `SWIFT_IMPORT_UNSAFE` for C++ functions that return `BridgedOwnedString`, and annotates `BridgedOwnedString` as a self-contained type.
This commit adds new compiler options -no-warning-as-error/-warning-as-error which allows users to specify behavior for exact warnings and warning groups.
The old analysis pass doesn't take into account profile data, nor does
it consider post-dominance. It primarily dealt with _fastPath/_slowPath.
A block that is dominated by a cold block is itself cold. That's true
whether it's forwards or backwards dominance.
We can also consider a call to any `Never` returning function as a
cold-exit, though the block(s) leading up to that call may be executed
frequently because of concurrency. For now, I'm ignoring the concurrency
case and assuming it's cold. To make use of this "no return" prediction,
use the `-enable-noreturn-prediction` flag, which is currently off by
default.
We're not caching this now, but it lets us dodge annoying layering
issues because ASTGen (where this is available) sits on top of the C++
parser, which needs to call it.
The reason why I am making this change is because I want to put a merge
operation on DiagnosticBehavior. This merge operation allows for
DiagnosticBehavior to work like a lattice. When one merges, one moves
potentially from fatal, error to things like note, ignore.
Allow any declaration to be marked with `@unsafe`, meaning that it
involves unsafe code. This also extends to C declarations marked with
the `swift_attr("unsafe")` attribute.
Under a separate experimental flag (`DisallowUnsafe`), diagnose any
attempt to use an `@unsafe` declaration or any unsafe language feature
(such as `unowned(unsafe)`, `@unchecked Sendable`). This begins to
define a "safe" mode in Swift that prohibits memory-unsafe constructs.
This makes sure that Swift respects `-Xcc -stdlib=libc++` flags.
Clang already has existing logic to discover the system-wide libc++ installation on Linux. We rely on that logic here.
Importing a Swift module that was built with a different C++ stdlib is not supported and emits an error.
The Cxx module can be imported when compiling with any C++ stdlib. The synthesized conformances, e.g. to CxxRandomAccessCollection also work. However, CxxStdlib currently cannot be imported when compiling with libc++, since on Linux it refers to symbols from libstdc++ which have different mangled names in libc++.
rdar://118357548 / https://github.com/swiftlang/swift/issues/69825
This patch allows controlling the automatic import of private dependencies
separately from the DebuggerSupport option, which currently also triggers this
behavior. With explicit modules + precise compiler invocations LLDB is moving
towards no longer needing this behavior.
rdar://133088201
(cherry picked from commit a1ba7159e3)
This concrete implementation of the BuildConfiguration allows the use of
the SwiftIfConfig library's APIs where the build configuration comes from
the compiler itself.
The changes to allow for partial consumption unintentionally also allowed for
`self` to be consumed as a whole during `deinit`, which we don't yet want to
allow because it could lead to accidental "resurrection" and/or accidental
infinite recursion if the consuming method lets `deinit` be implicitly run
again. This makes it an error again. The experimental feature
`ConsumeSelfInDeinit` will allow it for test coverage or experimentation
purposes. rdar://132761460
The reverse-condfail workaround needs to be removed, and this is the
first step to allowing the stdlib to build with conditionally escapable
types.
resolves rdar://132453000
