* add the (still empty) libswift package
* add build support for libswift in CMake
* add libswift to swift-frontend and sil-opt
The build can be controlled with the LIBSWIFT_BUILD_MODE cmake variable: by default it’s “DISABLE”, which means that libswift is not built. If it’s “HOSTTOOLS”, libswift is built with a pre-installed toolchain on the host system.
This removes the `#ifdef __APPLE__` guard that restricts this forwarding to Apple platforms only.
If a given build/toolchain does not build or include the `swift-driver` executable alongside the compiler executables, the driver will still safely default to the legacy driver.
Resolves rdar://75534188
Otherwise, if it is last then it will come after the input input source-file arguments. And in immediate (`swift`) mode, things that come after input source-file arguments are considered to be arguments to the underlying script and are placed after the `--`.
Resolves rdar://75039518
Add a new swift-frontend driver option that extract APIs in the swift
module and print in JSON format. This is to allow tooling to understand
and process swift APIs without the need to be a swift compiler or
understand swift module/AST.
We've seen bad file descriptor errors in certain build environments (rdar://73157185) and retrying
opening those files seems to be a walkaround. In this change, we allow the
compiler to retry expanding reponse files in argument lists.
rdar://73892564
In order to extract the module dependency graph from the compilation the driver just ran, define a separate semantic type to hold a result code and the graph itself.
This obviates the need for "-frontend", although we still accept it
for backward compatibility. Switch lit's %target-swift-frontend et al
over to calling swift-frontend.
There are a few references to "subcommands" in the repository, but no
explanation of what they are. Beef up the docblock for
`shouldRunAsSubcommand()` to make things a little clearer.
Specifically, I'd like to make the difference between driver jobs and
driver subcomnmands clearer.
In addition, remove a double negative comment, "If we are not run as
'swift', don't do anything special", and replace it with something a
little clearer (in my opinion).
Adds a tool `swift-symbolgraph-extract` that reads an existing Swift
module and prints a platform- and language-agnostic JSON description of
the module, primarly for documentation.
Adds a small sub-library `SymbolGraphGen` which houses the core
implementation for collecting relevant information about declarations.
The main entry point is integrated directly into the driver as a mode:
the tool is meant to be run outside of the normal edit-compile-run/test
workflow to avoid impacting build times.
Along with common options for other tools, unique options include
`pretty-print` for debugging, and a `minimum-access-level` options for
including internal documentation.
A symbol graph is a directed graph where the nodes are symbols in a
module and the edges are relationships between them. For example, a
`struct S` may have a member `var x`. The graph would have two nodes for
`S` and `x`, and one "member-of" relationship edge. Other relationship
kinds include "inherits-from" or "conforms to". The data format for a
symbol graph is still under development and may change without notice
until a specificiation and versioning scheme is published.
Various aspects about a symbol are recorded in the nodes, such as
availability, documentation comments, or data needed for printing the
shapes of declarations without having to understand specifics about the
langauge.
Implicit and public-underscored stdlib declarations are not included by
default.
rdar://problem/55346798
As pointed out on a recent JIRA, crash traces don't mention what
version of Swift you were running. Usually that can be gleaned from
the path, but not always.
We don't use this feature anymore (see 0149129ed), and now that we've
branched Swift 5.0 for the last time it's time to rip it out of swiftc
(and then from Clang).
No functionality change, unless someone was compiling their own API
notes. If you were doing that, just copy them into place as text.
On the master-next branch, the InitLLVM class used by the PROGRAM_START
macro can modify the argc/argv values (currently only on Windows).
Expanding response files before initializing the stack trace also modifies
the arguments so use a separate SmallVector for each copy of the argument
vector.
Shuffle the responsibility for creating the TaskQueue out of the
Compilation's internal job state object and into the driver. Expose
a builder convenience function that handles the argument parsing.
