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.
Tiny start-up time optimization noticed while looking at how we do
PrettyStackTraceProgram. Also add PrettyStackTraceProgram to a few
more of our testing tools, via the new PROGRAM_START macro.
Using Clang to compile API notes introduces a dependency on the
underlying Clang, which can cause problems as Clang's support for API
notes evolves. Re-introduce the "-apinotes" driver flag into the Swift
driver to allow us to compile API notes, and use that (rather than
Clang) to precompile API notes for the overlays.
- This allows 'swift <FOO>' to be used to invoke swift-<FOO>, so that we can
use 'swift' as a namespace for additional commands (like ones used for the
package manager.
- This patch just adds the basic subcommand functionality, but doesn't rework
either 'swift-autolink-extract' or 'swift -frontend' to follow this code path.
- <rdar://problem/22844530> Provide 'swift' support for subcommands
Swift SVN r32367
I also added a macro called INITIALIZE_LLVM(argc, argv) which moves this logic
into one place and should be used at the beginning of *all* binaries. It
initializes an LLVM shutdown object, sets up the pretty stack trace, and then
initializes all of the parts of LLVM. This will make it easy to update this in
the future.
The reason why a macro was required was because of llvm_shutdown_obj, an RAII
object that cleans up LLVM. It has to be at the function level scope of the main
function.
Swift SVN r31815
inside a swift ast section in an object file so it can be passed to the
linker. The driver automatically wraps merged swiftmodules iff the target
is ELF.
rdar://problem/22407666
Swift SVN r31641
