[Dependency Scanning] Disable validation of Swift dependency modules' existing pre-built candidate binary module files in the scanner, on a non-caching build.
Don't try to figure out the executable names during replay from
libSwiftScan.dylib. The actual executable path for the process actually
doesn't matter in this case to reconstruct the invocation and might
actually be misleading.
Just use `swift-frontend` as a placeheader executable name for
in-process cache replay.
rdar://132758308
As-is, this default interferes with the incremental build machinery which conservatively assumes that binary module dependencies must cause dependents to be re-built.
With `-experimental-lazy-typecheck` specified during module interface emission,
`collectProtocols()` may be the first piece of code to request the extended
type for a given extension and it therefore needs to ignore invalid extensions
and ensure that diagnostics are emitted.
Also, add some `PrettyStackTrace` coverage to `ModuleInterfaceSupport.cpp` to make
investigating future issues easier.
Resolves rdar://126232836.
Conflicts:
- `test/Interop/Cxx/class/method/methods-this-and-indirect-return-irgen-itanium.swift`
previously fixed on rebranch, now fixed on main (slightly differently).
When the swiftmodule is built with different clang importer arguments,
they can have the same module hash, causing them to be wrongly re-used even
they contains different interfaces. Add ReducedExtraArgs to the module hash to
disambiguate them.
However, some Xcc arguments, most commonly `-D` options do not affect the
swiftmodule being generated. Do not pass `-Xcc -DARGS` to swift
interface compilation to reduce the amount of module variants in the
build.
rdar://131408266
The scanning action does not have any need for handling `-llvm` options, since it will never perform any code-gen. LLVM option processing relies on global option parsing structures, and the scanner has needed to carefully attempt to synchronize access to them. This change guards the configuration of LLVM options to not happen at all for dependency scanning actions, and removes calls to `llvm::cl::ResetAllOptionOccurrences()` that were previously needed.
Resolves rdar://120754696
This introduces a secondary flag `-sysroot` for the non-Darwin targets,
primarily Unicies. The intention here is to support a split `-sdk`,
`-sysroot` model where the `-sdk` parameter provides the Swift "SDK"
which augments the native platform's C sysroot which is indicated as
`-sysroot`. For the case of Android, this would allow us to provide a
path to the NDK sysroot and the Swift SDK allowing us to cross-compile
Android binaries from Windows.
This patch adds support for MCCAS when a cache hit is encountered when
trying to replay a compilation, and uses the MCCAS serialization code
to materialize the object file that is the main output of the
compilation.
When MCCAS is used, filter the object file from the CASOutputBackend
because we do not want to write the object file in the CAS, we want
to associate the MCCAS top level CAS Object to the main output of the
CASOutputBackend.
Fix few issues from previous implementation from explicit module build
with macros and accurate macro dependency scanning in
https://github.com/swiftlang/swift/pull/73421.
First, there is a crash when propagating the macro dependencies. It
turns out that the current macro plugin implementation doesn't need the
downstream users to know about the plugin search path from the upstream
dependencies.
Secondly, fix a bug that the swiftinterface that has macro usage won't
build because the build command doesn't inherit the plugin search path
option.
Finally, add JSON output for macro dependencies so it is easier to
debug the macro dependencies.
rdar://131214106
Add support for swift style diagnostics for swift caching. This includes
pre-populate the GeneratedSourceInfo with macro name so it doesn't need
to infer from an ASTNode, which the caching mechanism cannot preserve.
Still leave the default diagnostic style to LLVM style because replaying
swift style diagnostics is still very slow and including parsing source
file using swift-syntax.
rdar://128615572
There are two axes on which a saved frontend flag can be categorized for
printing in a `.swiftinterface` file:
1. Whether the flag is "ignorable" or not.
2. Which levels of interface the flag should be in (public, package).
This refactor ensures that those two axes are modeled independently and
prepares the infrastructure to allow flags to appear in the private and package
interfaces without being included in the public interface.
