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
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.
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
Windows doesn't know what a shebang is, so it's unable to run tests that
use -driver-use-frontend-path with a script. This allows the script
interpreter to be run as the executable with the script as its first
argument. e.g. --driver-use-frontend-path "python;my-script.py"
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
We already have something called "module interfaces" -- it's the
generated interface view that you can see in Xcode, the interface
that's meant for developers using a library. Of course, that's also a
textual format. To reduce confusion, rename the new module stability
feature to "parseable [module] interfaces".
The OutputInfo, ToolChain, and Triple can all be retrieved from the
Compilation, so now that we're passing one of those around we don't
need to pass the others explicitly.
No functionality change.
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.
Previous to this change, the initial inspection of the -{enable,disable}-batch-mode
flag was made separate from the subsequent overriding by -wmo; this in turn meant
that the driver might decide it's "in batch mode" in one place (in particular,
when judging whether to ignore the -num-threads flag) and "in wmo mode" elsewhere
(when judging whether to emit one or multiple outputs, which depends on the
-num-threads flag).
Divergence between these two views caused the driver to effectively drop
the -num-threads flag even when overriding batch mode with wmo; since xcode
assumes that passing -wmo -num-threads _will_ cause multiple outputs, this
in turn caused linking to fail since the expected output files were not found.
Adds a -working-directory option which can be used to modify how
relative paths are resolved. It affects all other paths used in driver
options (controlled by a new ArgumentIsPath flag on options) as well as
the contents of output file maps and auxilliary file paths generated
implicitly by the compiler itself.
rdar://37713856
Previously, Actions were responsible for freeing their inputs...
except for the ones that weren't. Or the ones that were supposed
to, but then they needed to share an input, so they couldn't anymore.
If this sounds ridiculous, you're right; now Actions are just
immediately allocated and owned by the Compilation.
The graph structure of the actions is still useful for some things; in
particular, "top-level" actions get to put their outputs somewhere
permanent rather than TMPDIR. But I expect these things to get cleaned
up in the future too.
Similarly to Clang, the flag enables coverage instrumentation, and links
`libLLVMFuzzer.a` to the produced binary.
Additionally, this change affects the driver logic, and enables the
concurrent usage of multiple sanitizers.
I had set up the driver to invoke a separate frontend invocation with
the "update code" mode. We sort of did this last release, except we
forked to the swift-update binary instead. This is causing problems with
testing in Xcode.
Instead, let's perform a single compile and add the remap file as an
additional output during normal compiles. The driver, seeing
-update-code, will add -emit-remap-file-path $PATH to the -c frontend
invocation.
rdar://problem/31857580
The Swift 4 Migrator is invoked through either the driver and frontend
with the -update-code flag.
The basic pipeline in the frontend is:
- Perform some list of syntactic fixes (there are currently none).
- Perform N rounds of sema fix-its on the primary input file, currently
set to 7 based on prior migrator seasons. Right now, this is just set
to take any fix-it suggested by the compiler.
- Emit a replacement map file, a JSON file describing replacements to a
file that Xcode knows how to understand.
Currently, the Migrator maintains a history of migration states along
the way for debugging purposes.
- Add -emit-remap frontend option
This will indicate the EmitRemap frontend action.
- Don't fork to a separte swift-update binary.
This is going to be a mode of the compiler, invoked by the same flags.
- Add -disable-migrator-fixits option
Useful for debugging, this skips the phase in the Migrator that
automatically applies fix-its suggested by the compiler.
- Add -emit-migrated-file-path option
This is used for testing/debugging scenarios. This takes the final
migration state's output text and writes it to the file specified
by this option.
- Add -dump-migration-states-dir
This dumps all of the migration states encountered during a migration
run for a file to the given directory. For example, the compiler
fix-it migration pass dumps the input file, the output file, and the
remap file between the two.
State output has the following naming convention:
${Index}-${MigrationPassName}-${What}.${extension}, such as:
1-FixitMigrationState-Input.swift
rdar://problem/30926261
