Some Darwin platforms like DriverKit use a system prefix on all of their search paths. Even though DriverKit isn't supported, add support to get the system prefix from SDKSettings when constructing the default search paths.
This requires the DarwinSDKInfo to be gotten earlier in CompilerInvocation, pass that down to ASTContext through CompilerInstance.
-platform-availability-inheritance-map-path is no longer needed to support visionOS in tests, remove that and its supporting code that gets an alternative DarwinSDKInfo.
rdar://166277280
The exclusivity enforcement command-line flags currently impact the
generation of SIL within the current module. However, it does not
impact any SIL that was deserialized from another module, which means
that `-enforce-exclusivity=unchecked` doesn't actually remove all of
the dynamic exclusivity checks.
When dynamic exclusivity is disabled, lower SIL
begin_access/end_access instructions to nothing to ensure that we
won't do any dynamic exclusivity checks.
Use this to better model the reality of dynamic exclusivity checking
in Embedded Swift, which effectively turned off all dynamic
exclusivity checking by having empty stub implementations of
swift_(begin|end)Access. Instead, have Embedded Swift default to
`-enforce-exclusivity=unchecked`, so that it never emits calls to
swift_(begin|end)Access. Remove the stub implementations of
swift_(begin|end)Access from the Embedded Swift runtime, since we will
no longer generate calls to them by default.
Moving forward, this will allow us to conditionally enable the new
implementation of dynamic exclusivity checking by specifying
`-enforce-exclusivity=checked` for Embedded Swift builds. We'll stage
that in over time to avoid breaking existing Embedded Swift clients.
The old `-module-interface-preserve-types-as-written` workaround flag prevents module selectors from being printed into module interfaces even when they have been explicitly requested. Disable it and emit a warning when it’s used in combination with `-enable-module-selectors-in-module-interface`.
Fixes rdar://166237384.
This prevents stuff like memcmp from SwiftShims from being imported with
@_SwiftifyImport, which would then result in name lookup errors as it
does not import the Swift standard library module. This makes the
previous approach to disable safe interop when compiling with
-parse-stdlib redundant.
irdar://165856959
The SWIFT_ENABLE_DIRECT_RETAIN_RELEASE option controls the default value of the option to enable direct retain/release. It's off by default, meaning direct RR is off by default. Setting SWIFT_ENABLE_DIRECT_RETAIN_RELEASE to true will build a compiler where direct RR is on by default.
rdar://163568311
Enables upcoming features that aim to provide a more approachable path to Swift Concurrency:
- `DisableOutwardActorInference`
- `GlobalActorIsolatedTypesUsability`
- `InferIsolatedConformances`
- `InferSendableFromCaptures`
- `NonisolatedNonsendingByDefault`
Resolves: rdar://166244164
This removes the C++ interop compat version mechanism. It was added in mid-2023 and was never used. It complicates the testing story, and makes it harder to reason about the compiler's behavior. It also isn't compatible with explicit module builds.
The flag `-cxx-interoperability-mode` is preserved, so projects that use the flag will continue to build normally.
rdar://165919353
In multi-threaded WMO builds, the frontend didn't properly handle per-file
supplementary outputs specified via output file maps or command-line
arguments.
This enables swift-driver to use -supplementary-output-file-map for
per-file outputs in multi-threaded WMO, instead of generating multiple
individual flags that the frontend rejects.
This is similar to SuppressedAssociatedTypes, but infers
default requirements when primary associated types of
protocols are suppressed. This defaulting for the primary
associated types happens in extensions of the protocol,
along with generic parameters, whenever a source-written
requirement states a conformance requirement for the protocol.
Thus, the current scheme for this defaulting is a simplistic,
driven by source-written requirements, rather than facts
that are inferred while building generic signatures.
Defaults are not expanded for infinitely many associated types.
rdar://135168163
This reverts commit 4f059033bb. The change
is actually not NFC since previously, there is a cache in the
CompilerInvocation that prevents the same CAS from the same CASOptions
from being initialized multiple times, which was relied upon when
running inside sub invocation. When switching to a non-caching simple
CASOption types, it causes every single sub instance will create its own
CAS, and it can consume too many file descriptors and causing errors
during dependency scanning.
rdar://164903080
Upstream LLVM in llvm/llvm-project#139584 changed `DiagnosticOptions`
from being a referenced counted object to just be a reference, not owned
by the `clang::DiagnosticEngine`.
In 0981b71090 (part of #82243), the usages
of the Swift repository were adapted to the new memory model, but it
introduced at least one use-after-free and a potential one around the
usage of Clang in the Clang Importer.
This commit tries to fix the use-after-free in both cases, by returning
a `unique_ptr` to the `clang::DiagnosticOptions`, which makes the
lifetime of the `DiagnosticOptions` match the lifetime of the variable
that uses it (normally a `CompilerInvocation`).
Other cases in 0981b71090 should be safe
because the lifetime of the `DiagnosticOptions` do not seem to propagate
beyond the scope of the functions where they live (but I am not fully
sure about the one in `IDETool/CompilerInvocation.cpp` completely).
This was causing compiler crashes during the test
`Interop/Cxx/stdlib/unsupported-stdlib.swift` which eventually uses
`createClangDriver` and tries to emit a diagnostic, which in some cases
was reading the memory from `DiagnosticOptions` when it was already out
of scope.
Bring back legacy prefix map option to allow an older swift-driver to
work with newer swift-frontend. For old swift-driver, it will always
send the old style prefix map option, so the new compiler needs to
support that.
rdar://164208526
Currently symbol graphs are always written in files that contain 1 to 2
module names. It's possible for Swift module names to be very long, so
combining 2 of them in file name like `module1@module2...` in the same
path component means the name can be too long for some file systems. The
new option `-symbol-graph-shorten-output-names` changes the symbol graph
output files to use a MD5 hash of the module name(s) as the filename and
outputs an additional JSON file with the original names mapped to the
real filename. The module names JSON can be used to construct a VFS
overlay with the original naming scheme.
fix#83723
I considered using vfsoverlay, which seems like a viable solution, but
the vfsoverlay options don't seem to apply to any of the outputs from
the compiler. When I set an overlay to remap the symbol graph file
outputs, the remapped external paths aren't used so the root problem of
too long file names remains.
This adds the -Rmacro-expansions flag. It provides similar functionality
to -dump-macro-expansions, but instead of dumping the macro expansion to
stderr, it emits it line by line as remarks. This is useful for testing
with -verify, where both macro expansion content and warnings need to be
tested at the same time.
This is currently disabled by default. Building the client library can be enabled with the CMake option SWIFT_BUILD_CLIENT_RETAIN_RELEASE, and using the library can be enabled with the flags -Xfrontend -enable-client-retain-release.
To improve retain/release performance, we build a static library containing optimized implementations of the fast paths of swift_retain, swift_release, and the corresponding bridgeObject functions. This avoids going through a stub to make a cross-library call.
IRGen gains awareness of these new functions and emits calls to them when the functionality is enabled and the target supports them. Two options are added to force use of them on or off: -enable-client-retain-release and -disable-client-retain-release. When enabled, the compiler auto-links the static library containing the implementations.
The new calls also use LLVM's preserve_most calling convention. Since retain/release doesn't need a large number of scratch registers, this is mostly harmless for the implementation, while allowing callers to improve code size and performance by spilling fewer registers around refcounting calls. (Experiments with an even more aggressive calling convention preserving x2 and up showed an insignificant savings in code size, so preserve_most seems to be a good middle ground.)
Since the implementations are embedded into client binaries, any change in the runtime's refcounting implementation needs to stay compatible with this new fast path implementation. This is ensured by having the implementation use a runtime-provided mask to check whether it can proceed into its fast path. The mask is provided as the address of the absolute symbol _swift_retainRelease_slowpath_mask_v1. If that mask ANDed with the object's current refcount field is non-zero, then we take the slow path. A future runtime that changes the refcounting implementation can adjust this mask to match, or set the mask to all 1s to disable the old embedded fast path entirely (as long as the new representation never uses 0 as a valid refcount field value).
As part of this work, the overall approach for bridgeObjectRetain is changed slightly. Previously, it would mask off the spare bits from the native pointer and then call through to swift_retain. This either lost the spare bits in the return value (when tail calling swift_retain) which is problematic since it's supposed to return its parameter, or it required pushing a stack frame which is inefficient. Now, swift_retain takes on the responsibility of masking off spare bits from the parameter and preserving them in the return value. This is a trivial addition to the fast path (just a quick mask and an extra register for saving the original value) and makes bridgeObjectRetain quite a bit more efficient when implemented correctly to return the exact value it was passed.
The runtime's implementations of swift_retain/release are now also marked as preserve_most so that they can be tail called from the client library. preserve_most is compatible with callers expecting the standard calling convention so this doesn't break any existing clients. Some ugly tricks were needed to prevent the compiler from creating unnecessary stack frames with the new calling convention. Avert your eyes.
To allow back deployment, the runtime now has aliases for these functions called swift_retain_preservemost and swift_release_preservemost. The client library brings weak definitions of these functions that save the extra registers and call through to swift_retain/release. This allows them to work correctly on older runtimes, with a small performance penalty, while still running at full speed on runtimes that have the new preservemost symbols.
Although this is only supported on Darwin at the moment, it shouldn't be too much work to adapt it to other ARM64 targets. We need to ensure the assembly plays nice with the other platforms' assemblers, and make sure the implementation is correct for the non-ObjC-interop case.
rdar://122595871
