Fix the debug info emitted for bridging header PCH when compilation
caching is used. This includes:
* Bridging header should have the correct dwo_name that uses CASID
* The search_path for PCH should be the cache key that can load the PCH
just like other modules.
`-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.
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