This is required to bootstrap the `-static-stdlib` support for Windows.
With this, we are able to properly build the Swift SDK both dynamically
and statically, which is needed to enable us to make further progress
towards an early swift-driver.
IterableDeclContext::checkDeserializeMemberErrorInPackage recursively checks if
decls and their member decls are deserialized correctly into another module.
This PR adds a check to make sure the inspected decls are from another module,
and provides an opt-in flag to fail fast on deserialization failure if found.
rdar://143830240
Add ability to automatically chaining the bridging headers discovered from all
dependencies module when doing swift caching build. This will eliminate all
implicit bridging header imports from the build and make the bridging header
importing behavior much more reliable, while keep the compatibility at maximum.
For example, if the current module A depends on module B and C, and both B and
C are binary modules that uses bridging header, when building module A,
dependency scanner will construct a new header that chains three bridging
headers together with the option to build a PCH from it. This will make all
importing errors more obvious while improving the performance.
Checking each module dependency info if it is up-to-date with respect to when the cache contents were serialized in a prior scan.
- Add a timestamp field to the serialization format for the dependency scanner cache
- Add a flag "-validate-prior-dependency-scan-cache" which, when combined with "-load-dependency-scan-cache" will have the scanner prune dependencies from the deserialized cache which have inputs that are newer than the prior scan itself
With the above in-place, the scan otherwise proceeds as-is, getting cache hits for entries still valid since the prior scan.
This only takes the existing AST information and writes it as JSON
instead of S-expressions. Since many of these fields are stringified,
they're not ideal for the kind of analysis clients of the JSON format
would want to do. A future commit will update these values to use a
more structured representation.
decl being accessed is correct. When this assumption fails due to a deserialization error
of its members, the use site accesses the layout with a wrong field offset, resulting in
UB or a crash. The deserialization error is currently not caught at compile time due to
LangOpts.EnableDeserializationRecovery being enabled by default to allow for recovery of some
of the deserialization errors at a later time. In case of member deserialization, however,
it's not necessarily recovered later on.
This PR tracks whether member deserialization had an error by recursively loading members and
checking for deserialization error, and fails and emits a diagnostic. It provides a way to
prevent resilience bypassing when the deserialized decl's layout is incorrect.
Resolves rdar://132411524
Add a -nostdlibimport (analagous to clang's -nostdlibinc) to remove the SDK paths from the import search paths, but leave the toolchain paths.
rdar://139322299
When Swift passes search paths to clang, it does so directly into the HeaderSearch. That means that those paths get ordered inconsistently compared to the equivalent clang flag, and causes inconsistencies when building clang modules with clang and with Swift. Instead of touching the HeaderSearch directly, pass Swift search paths as driver flags, just do them after the -Xcc ones.
Swift doesn't have a way to pass a search path to clang as -isystem, only as -I which usually isn't the right flag. Add an -Isystem Swift flag so that those paths can be passed to clang as -isystem.
rdar://93951328
* Make pointer bounds non-experimental
* Rename @PointerBounds to @_SwiftifyImport
* Rename filenames containing PointerBounds
* Add _PointerParam exception to stdlib ABI test
* Add _PointerParam to stdlib API changes
* Rename _PointerParam to _SwiftifyInfo
- Don't use CommaJoined, since profile-sample-use only takes one file
- Specify that the flag is only supported by the new swift-driver.
for rdar://135443278
This results in an automatic wrapper function with safe pointer types
when the imported function has bounds attributes. This exercises similar
pathways as the recently added functionality for specifying macros from
swift_attr. The new functionality is guarded by the experimental
language feature SafeInteropWrappers.
rdar://97942270
This makes sure that the compiler does not emit `-enable-experimental-cxx-interop`/`-cxx-interoperability-mode` flags in `.swiftinterface` files. Those flags were breaking explicit module builds. The module can still be rebuilt from its textual interface if C++ interop was enabled in the current compilation.
rdar://140203932
To allow feature build settings to be composed more flexibly, allow an
`-enable-upcoming-feature` flag to be overridden by a
`-disable-upcoming-feature` flag. Whichever comes last on the command line
takes effect. Provide the same functionality for `-enable-experimental-feature`
as well.
Resolves rdar://126283879.
The `-include-submodules` flag causes the synthesized interface to include
implicit Clang submodules of the module being printed. Since these are
automatically made visible when importing the corresponding top-level module,
it's often useful to have them present in the same synthesized Swift
interface instead of having to make separate invocations to get each
submodule separately.
The `-print-fully-qualified-types` causes type names to be printed with
full module qualification. This is useful when using the synthesized
interface for some other kind of analysis, because it ensures that all
type references explicitly indicate which module they came from, instead
of having to guess scoping and import resolution rules to figure out
which module a reference comes from.
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.
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
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.
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.
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.
This mode is similar to `swift-symbolgraph-extract`; it takes a subset of compiler
flags to configure the invocation for module loading, as well as a module name
whose contents should be extracted. It does not take any other input files. The
output is a single text file specified by `-o` (or `stdout` if not specified).
While the most common use case for this would be viewing the synthesized Swift
interface for a Clang module, since the implementation simply calls
`swift::ide::printModuleInterface` under the hood, it's usable for any module
that Swift can import. Thus, it could also be used to view a synthesized textual
representation of, say, a compiled `.swiftmodule`.
One could imagine that in the future, we might add more flags to
`swift-synthesize-interface` to modify various `PrintOptions` used when
generating the output, if we think those would be useful.
Do not add CAS configurations into cache key computation. This ensure if
the cache keys are identical if two functionally equivalent plugins are
used. This is safe to do because if any of the CAS configurations
changes how the cache key is computed, they are going to be directly
reflected in the cache key without adding its configuration into the
key.
rdar://137091843
