It is unsound to expose `package` declarations in textual interfaces without a
package identity for them to belong to so we should not offer this flag.
Resolves rdar://139361524.
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.
C++ swift::Parser is going to be replaced with SwiftParser+ASTGen.
Direct dependencies to it should be removed. Before that, remove
unnecessary '#include "swift/Parse/Parser.h"' to clarify what actually
depends on 'swift::Parser'.
Split 'swift::parseDeclName()' et al. into the dedicated files.
If an upcoming feature was enabled by passing it via `-enable-experimental-feature`,
downgrade the `already enabled` diagnostic to a warning.
Resolves rdar://139087679.
This achieves the same as clang's `-fdebug-info-for-profiling`, which
emits DWARF discriminators to aid in narrowing-down which basic block
corresponds to a particular instruction address. This is particularly
useful for sampling-based profiling.
rdar://135443278
This is something that I have wanted to add for a while and have never had the
need to. I need it now to fix a bug in the bots where I am forced to use IRGen
output to test ThunkLowering which causes platform level differences to show up
in the FileCheck output. With this, I can just emit the actual lowered SIL
output and just test it at that level. There are other cases like this where we
are unable to test lowered SIL so we use IRGen creating this brittleness.
Hopefully this stops this problem from showing up in the future.
rdar://138845396
Teach dependency scanner to construct build commands using resolved
plugin search path option. This ensures the modules that do not have
access to the macro plugins will not have a different variant due to
different plugin search path.
rdar://136682810
Add flag `-load-resolved-plugin` to load macro plugin, which provides a
pre-resolved entry into PluginLoader so the plugins can be loaded based
on module name without searching the file system. The option is mainly
intended to be used by explicitly module build and the flag is supplied
by dependency scanner.
This change refactors the top-level dependency scanning flow to follow the following procedure:
Scan():
1. From the source target under scan, query all imported module identifiers for a *Swift* module. Leave unresolved identifiers unresolved. Proceed transitively to build a *Swift* module dependency graph.
2. Take every unresolved import identifier in the graph from (1) and, assuming that it must be a Clang module, dispatch all of them to be queried in-parallel by the scanner's worker pool.
3. Resolve bridging header Clang module dpendencies
4. Resolve all Swift overlay dependencies, relying on all Clang modules collected in (2) and (3)
5. For the source target under scan, use all of the above discovered module dependencies to resolve all cross-import overlay dependencies
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.
Based on preliminary work from @rmaz.
The compilation arguments for a swiftinterface file are preprocessed to
modify the `-target` argument to match the preferred target (which comes
from the command line) in cases in which the sub-architecture differs,
but it is compatible (for example using `arm64e` when `arm64` is being
compiled), but this was not done for the target variant, which ended up
with mismatches on the sub-architecture used by the target and target
variant, which fails an assert in assert toolchains.
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.
