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 a new filetype for this mode option: "Raw LLVM IR". When the mode
option is emit-irgen, the new filetype will be the output kind;
conversely when determining the mode option to use, if the output kind
is the new filetype, the mode option will be emit-irgen.
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)
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.
When building a module from its interface, do not diagnose whether or not a
feature is available in production compilers. This is important since older
compilers may be expected to build .swiftinterfaces that were produced by newer
compilers where the feature has been enabled by default.
Resolves rdar://125500318
It has an extension .package.swiftinterface and contains package decls
as well as SPIs and public/inlinable decls. When a module is loaded
from interface, it now looks up the package-name in the interface
and checks if the importer is in the same package. If so, it uses
that package interface found to load the module. If not, uses the existing
logic to load modules.
Resolves rdar://104617854
An "API descriptor" file is JSON describing the externally accessible symbols
of a module and metadata associated with those symbols like availability and
SPI status. This output was previously only generated by the
`swift-api-extract` alias of `swift-frontend`, which is desgined to take an
already built module as input. Post-processing a built module to extract this
information is inefficient because the module and the module's dependencies
need to be deserialized in order to visit the entire AST. We can generate this
output more efficiently as a supplementary output of the -emit-module job that
originally produced the module (since the AST is already available in-memory).
The -emit-api-descriptor flag can be used to request this output.
This change lays the groundwork by introducing frontend flags. Follow up
changes are needed to make API descriptor emission during -emit-module
functional.
Part of rdar://110916764.
When we run an interface verification tasks with Explicit module builds, we directly invoke a '-explicit-interface-module-build' instance with a '-typecheck-module-from-interface' action. So the builder needs to recognize this as a typechecking invocation. In implicit builds, this gets lowered into a separate compiler sub-instance with a '-typecheck' action, for some reason.
resolves rdar://115565571
This action is currently just an alias of the `-resolve-imports` action.
However, it's named to more clearly reflect the purpose which is to do the
minimal typechecking needed in order to emit the requested outputs. This mode
is intended to improve performance when emitting `.swiftinterface` and `.tbd`
files.
Experimental mode for generating module interfaces without running
primary file type-checking. The idea is that the ASTPrinter triggers
requests to only do the minimum amount of type checking work
possible while printing the interface for a module's public
declarations.
These requests may emit diagnostics, but the ASTPrinter should in
theory already be robust against invalid code.
-typecheck-module-from-interface doesn't emit textual output as
configured in frontend option. The real output is diagnostics but that
is not tracked by output computer which is using the option.
Teach `swift-frontend` that it doesn't actually emit any real output and
tell serialization not to emit swiftmodule.
Allow `-typecheck-module-from-interface` using explicit module instead
of building implicit module.
This setups swift-frontend to accept explicit module build arguments and
loading explicit module during verifying. SwiftDriver needs to setup
correct arguments including the output path for swift module to fully
enable explicit module interface check.
This change removes the -emit-cxx-header option, and adds a new -emit-clang-header-path option instead. It's aliased to -emit-objc-header-path for now, but in the future, -emit-objc-header-path will alias to it. After this change Swift can start emitting a single header file that can be expose declarations to C, Objective-C, or C++. For now C++ interface is generated (for all public decls) only when -enable-cxx-interop flag is passed, but that behavior will change once attribute is supported.
Add new `-print-ast-decl` frontend option for only printing declarations,
to match existing behavior.
Some tests want to print the AST, but don't care about expressions.
The existing `-print-ast` option now prints function bodies and expressions.
Not all expressions are printed yet, but most common ones are.
This additional supplement output should capture semantic info the compiler has
captured while building a Swift module. Similar to the source info file, the content of
the semantic info file should only be consumed by local tooling written in Swift.
We have implemented a libSwiftDriver-based tool to generate prebuilt module cache for
entire SDKs. Anchored on the same infrastructure, we could also generate ABI baselines
for entire SDKs.
For now, force the clang-based actions to skip the end of the pipeline. This restores the previous behavior of the frontend, but may not be desirable in the long run. For example, one may want to dump clang stats after running an -emit-pch job, but that is impossible without forcing the end of the pipeline to be more tolerant of ObjCHeader/modulemap-only inputs.
rdar://68587228
For the issue mentioned in rdar://67079780, swift-driver needs to run clang dependencies
scanner multiple times with different target triples for a Swift target. This patch adds
a new scanning action to generate the JSON file for a given clang module to accommodate
this requirement.
Resolves: rdar://problem/67269210
Expand the FrontendOptions to allow the enabling
of the dependency tracker for non-system
dependencies, and switch the previous clients of
`createDependencyTracker` over to using this
option. This ensures that the dependency tracker
is now set only during `CompilerInstance::setup`.
Implement a new "fast" dependency scanning option,
`-scan-dependencies`, in the Swift frontend that determines all
of the source file and module dependencies for a given set of
Swift sources. It covers four forms of modules:
1) Swift (serialized) module files, by reading the module header
2) Swift interface files, by parsing the source code to find imports
3) Swift source modules, by parsing the source code to find imports
4) Clang modules, using Clang's fast dependency scanning tool
A single `-scan-dependencies` operation maps out the full
dependency graph for the given Swift source files, including all
of the Swift and Clang modules that may need to be built, such
that all of the work can be scheduled up front by the Swift
driver or any other build system that understands this
option. The dependency graph is emitted as JSON, which can be
consumed by these other tools.
Frontend outputs source-as-compiled, and source-ranges file with function body ranges and ranges that were unparsed in secondaries.
Driver computes diffs for each source file. If diffs are in function bodies, only recompiles that one file. Else if diffs are in what another file did not parse, then the other file need not be rebuilt.
This flag, currently staged in as `-experimental-skip-non-inlinable-function-bodies`, will cause the typechecker to skip typechecking bodies of functions that will not be serialized in the resulting `.swiftmodule`. This patch also includes a SIL verifier that ensures that we don’t accidentally include a body that we should have skipped.
There is still some work left to make sure the emitted .swiftmodule is exactly the same as what’s emitted without the flag, which is what’s causing the benchmark noise above. I’ll be committing follow-up patches to address those, but for now I’m going to land the implementation behind a flag.
