Add flag `-debug-module-cache-key` and flag `-debug-module-self-key` to
support embedded swift module output in the debug info via CASID.
rdar://169110002
If a .swiftinterface file does not include an explicit `-language-mode` option
(or its predecessor `-swift-version`) and needs to be built as a dependency of a
client compilation, then the invocation to build the module from interface
would end up inheriting the language mode that the client code is built with.
This can result in spurious type checking diagnostics or even mis-compilation.
To ensure that a module interface is always built using the language mode that
its source code was originally built with, require an explicit `-language-mode`
option when emitting swiftinterface files.
In #84307 this diagnostic was downgraded to a warning. The failures it caused
in PR testing should now be resolved.
This is a re-attempt of https://github.com/swiftlang/swift/pull/84327.
Resolves rdar://145168219.
As specified in SE-0441, -language-mode should appear in help output
while -swift-version should be the hidden alias.
Related to swiftlang/swift-driver#1894
During explicit module build, teach dependency scanner to emit the
module trace file instead of each following compile job command. This
reduces the duplicated info, and allows supporting fully cached build
that only loads module from CAS thus cannot produce the path to the
original module file on disk.
rdar://170007480
swift-synthesize-interface needs to match the safe interop wrappers
setting of the compiler invocation that built the Swift module, but
doesn't have -enable/disable-experimental-feature options. Instead of
introducing them for a single feature, which isn't even experimental,
this introduces the -disable-safe-interop-wrappers instead.
This enables the stable subset of safe interop wrappers by default. It
can be manually disabled using
`-disable-experimental-feature StabilizedSafeInteropWrappers`.
rdar://148994016
Calling `setCurrentWorkingDirectory` on `getRealFileSystem` sets the
working directory for the process itself. This is unsafe for clients
such as SourceKit which can process multiple concurrent requests,
and may be used as an in-process library in e.g sourcekit-lsp. Switch
to `createPhysicalFileSystem` instead, where setting the working
directory is done locally on the FileSystem itself.
This optimizes for the case where we have a disjunction that contains an
operator defined in a protocol, and a protocol defined in a protocol
extension, and furthermore, the protocol extension operator's type is a
refinement of the protocol requirement operator's type.
In this case, there are three possibilities:
- Either the operator requirement is witnessed by a concrete operator
in the conforming type, in which case the solution involving the
protocol extension operator is going to be worse, so we can skip this
choice.
- Otherwise, the protocol requirement operator is witnessed by the same
protocol extension operator that we skipped, in which case we will find
the same solution if we just pick the protocol requirement operator
anyway.
- The only other possibility is that the protocol requirement operator
is witnessed by a protocol extension operator, but also, a more
refined protocol extension operator exists. However, it appears that in
this case, solution ranking _also_ picks the solution involving the
protocol requirement operator, as the new test case demonstrates.
Thus, we gain nothing by considering these protocol extension operators.
Skip them when forming the disjunction.
For testing, we need to make sure that we pick up `libswiftCore.dll`
from the `bin` directory, rather than the copy in `lib`. Otherwise,
when we use the interpreter mode, we'll `LoadLibrary` the one from
`lib`, but Windows found the one in `bin` already, so we end up with
two `libswiftCore.dll`s in the same process, which is bad.
rdar://101623384
When both `-alias-module-names-in-module-interface` and `-enable-module-selectors-in-module-interface` are turned on, the compiler now disables the former with a warning. Eliminates workaround hacks that should no longer be necessary.
Fixes rdar://problem/169132519.
We need to stage in the behavior change to enable dynamic exclusivity
checking for Embedded Swift. For now, ignore
`-enforce-exclusivity=checked` in Embedded Swift unless the
experimental feature `EmbeddedDynamicExclusivity` is also enabled.
Addresses rdar://168618037, a regression in Embedded Swift code that
is passing `-enforce-exclusivity=checked` explicitly.
This new OSSA invariant simplifies many optimizations because they don't have to take care of the corner case of incomplete lifetimes in dead-end blocks.
The implementation basically consists of these changes:
* add the lifetime completion utility
* add a flag in SILFunction which tells optimization that they need to run the lifetime completion utility
* let all optimizations complete lifetimes if necessary
* enable the ownership verifier to check complete lifetimes
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.
Adrian Prantl
Steven Wu
Slava Pestov
Allan Shortlidge
finagolfin
Ryan Mansfield
Becca Royal-Gordon
Henrik G. Olsson
Henrik G. Olsson
Anthony Latsis
Hamish Knight
Alastair Houghton
Artem Chikin
Jamie
Alexis Laferrière
Doug Gregor
eeckstein
Pavel Yaskevich
Yuta Saito
Yuta Saito
Ian Anderson