Extend the module trace format with a field indicating whether a given
module, or any module it depends on, was compiled with strict memory
safety enabled. This separate output from the compiler can be used as
part of an audit to determine what parts of Swift programs are built
with strict memory safety checking enabled.
The symbol graph output from a module can contain an arbitrary number of
files, depending on what extensions it contains, so cache a list of
symbol graph files with their base name and contents so that they can be
replayed.
rdar://140286819
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
This patch adds support for serialization and deserialization of
debug scopes.
Debug scopes are serialized in post order and enablement is
controlled through the experimental-serialize-debug-info flag which
is turned off by default. Functions only referred to by these debug
scopes are deserialized as zombie functions directly.
It might be unexpected to future users that `-swift-compiler-version`
would produce a version aligned to .swiftinterface instead of one used
to build the .swiftmodule file. To avoid this possible confusion, let's
scope down the version to `-interface-compiler-version` flag and
`SWIFT_INTERFACE_COMPILER_VERSION` option in the module.
If swiftinterface doesn't have `-swift-compiler-version` flag
it means that it was generated with an older version of the
Swift compiler. In such cases it would be incorrect to use
"current" compiler version because the field is intended to
indicate the compiler the swiftinterface was built with.
When setting up the ModuleInterfaceChecker, prefer using the module
cache path from command-line invocation `-module-cache-path` before
falling back to clang options.
Usually those two yield the same result, except for LLDB under direct
cc1 argument mode and explicit module build. Under such mode, the cc1
option for module cache path will be stripped since the output PCMs are
explicit passed as output. When LLDB attempted to do an implicit module
compilation for the swift interface, it will not be able to locate the
module cache path from cc1 arguments. On the other hand, the module
cache option has already be inherited by the sub-instance so it can just
directly be located there.
rdar://137610484
to verify ExportedSourceFileRequest == 0.
In release mode only non-zero stats are printed by default now.
Fix diagnostic when compiler is built without statistics support.
Use IncludeTreeFileList instead of full feature CASFS for swift
dependency filesystem. This allows smaller CAS based VFS that is smaller
and faster. This is enabled by the CAS enabled compilation does not
need to iterate file system.
rdar://136787368
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
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.
This fixes the debugger's ability to perform expression evaluation when debugging an
executable that was built with both under the following circumstances:
1. explicit module build
2. `-application-extension`
The fix is to include `-fapplication-extension` as an XCC field in the swiftmodule.
This primes the debugger's ClangImporter with the correct flag needed to load the
explicitly built pcm files generated at build time.
When direct cc1 mode is used, the cc1 arguments are generated from extra
clang targets so there is no need to add this extra argument.
Furthermore, the `--target=` is a clang driver argument and is not valid
under cc1 mode.
Needed for: rdar://134090397
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
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
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.
Previously we would call `getMembers`, which could
kick delayed member parsing. Instead, propagate a
`parseIfNeeded` flag through the ASTDumper logic,
and use it to determine whether to parse a
SourceFile, type/extension body, or function body.
This is needed for things like `-dump-parse` which
expects to dump the entire AST tree.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
We cannot always rely on being able to do so only as an overlay query upon loading 'requires cplusplus' modulemap modules. The 'requires' statement only applies to submodules, and we may not be able to query language feature modulemap attributes in dependency scanning context.
This is a regression causing lots of cached diagnostics tests not
functioning since the cached diagnostics processors are not initialized
for those tests which are supposed to test diagnostics caching.
The regression is caused by the fix that the typecheck module interface
job need to run a typecheck job in the sub-invocation. Now the typecheck
module interface job is correctly setup to avoid diagnostics about
unsupported file system error.
Add a fast path to create swift CompilerInstance when it is only used to
replay output when there is a cache hit. The normal `setup` function is
very expensive to call, especially in cache mode to setup inputs, and it
needs to be called once per input file from libSwiftScan API due to the
current caching granularity.
The fast path will only construct the part that is needed for output
replay, including the CAS, the output backend and caching diagnostic
processor.
rdar://127062609
SILOptions::EnableSerializePackage info is lost.
SILVerifier needs this info to determine whether resilience
can be bypassed for decls serialized in a resiliently
built module when Package CMO optimization enabled.
This PR adds SerializePackageEnabled bit to Module format
and uses that in SILVerifier.
Resolves rdar://126157356
Improve swift dependency scanner by validating and selecting dependency
module into scanner. This provides benefits that:
* Build system does not need to schedule interface compilation task if
the candidate module is picked, it can just use the candidate module
directly.
* There is no need for forwarding module in the explicit module build.
Since the build system is coordinating the build, there is no need for
the forwarding module in the module cache to avoid duplicated work,
* This also correctly supports all the module loading modes in the
dependency scanner.
This is achieved by only adding validate and up-to-date binary module as
the candidate module for swift interface module dependency. This allows
caching build to construct the correct dependency in the CAS. If there
is a candidate module for the interface module, dependency scanner will
return a binary module dependency in the dependency graph.
The legacy behavior is mostly preserved with a hidden frontend flag
`-no-scanner-module-validation`, while the scanner output is mostly
interchangeable with new scanner behavior with `prefer-interface` module
loading mode except the candidate module will not be returned.
rdar://123711823
Relying on the corresponding field in the '-explicit-swift-module-map-file' provided by the driver.
Only bridging headers require a module map because that's what aids header include resolution. With lazy module loading today, '.modulemap' parsing which happens when instantiating Clang is responsible for associating headers with modules. Then upon encountering a header include inside the bridging header the compiler knows which module corresponds to said header and is then able to load explicitly-provided PCM for that module. For all other module dependencies, they are only ever queried by-name from Swift, so '.modulemap' parsing is not necessary.
