Add a shared library with a C API that provides access to the syntactic parser with callbacks for the inference of raw syntax nodes.
This is primarily intended to be used by SwiftSyntax to speed-up source code parsing for it.
Instead of creating syntax nodes directly, modify the parser to invoke an abstract interface 'SyntaxParseActions' while it is parsing the source code.
This decouples the act of parsing from the act of forming a syntax tree representation.
'SyntaxTreeCreator' is an implementation of SyntaxParseActions that handles the logic of creating a syntax tree.
To enforce the layering separation of parsing and syntax tree creation, a static library swiftSyntaxParse is introduced to compose the two.
This decoupling is important for introducing a syntax parser library for SwiftSyntax to directly access parsing.
Redesigns the `SwiftLang.parse` API to accommodate a format parameter which can be used to request a ByteTree-serialized syntax tree instead of JSON-serialized. This gives us a convenient way to use the fastest currently available combination of tools for parsing a file into a syntax tree.
The new API only accepts paths, not source buffers, and returns JSON as `Data` instead of `String`, which are both better directions in the long run. The format type is extensible so that it can easily be extended to support "direct" parsing into a SyntaxSourceFile.
Deprecated wrapper methods with the old names and signatures are still available for any existing clients.
With this change, you will no longer receive
"error when parsing the compiler arguments". Instead, you will
receive the underlying error, like
"error: unable to load output file map 'output_file_map.json': No such file or directory"
The order of argument evaluation is reversed on Windows, and the move is
evaluated prior to the stream being passed. This is resulting in the
remarks file not being prepared for use.
If one thinks about it, swift's build has two sections: a runtime or target
section (i.e. ./stdlib) and a host section (everything
else). swift-reflection-test is an abberation from that pattern since it is
built for target platforms but is in the section of host tools.
In this commit, I move it into ./stdlib. Beyond being a bitter location
conceptually this will additionally allow me to avoid a dependency cycle in
between the compiler and the stdlib build.
After this, there is only one more target in the compiler code: swift-lang. From
talking with Xi Ge, we can move that into its own separate project as a
package. Once that is done, I will not have any more cycles.
`-fblocks` is a core driver option now, so it can be used with both the GCC
style driver as well as the cl style driver. Simplify the logic for the
handling of this option.
When debugging Objective-C or C++ code on Darwin, the debug info
collected by dsymutil in the .dSYM bundle is entirely
self-contained. It is possible to debug a program, set breakpoints and
print variables even without having the complete original source code
or a matching SDK available. With Swift, this is currently not the
case. Even though .dSYM bundles contain the binary .swiftmodule for
all Swift modules, any Clang modules that the Swift modules depend on,
still need to be imported from source to even get basic LLDB
functionality to work. If ClangImporter fails to import a Clang
module, effectively the entire Swift module depending on it gets
poisoned.
This patch is addressing this issue by introducing a ModuleLoader that
can ask queries about Clang Decls to LLDB, since LLDB knows how to
reconstruct Clang decls from DWARF and clang -gmodules producxes full
debug info for Clang modules that is embedded into the .dSYM budle.
This initial version does not contain any advanced functionality at
all, it merely produces an empty ModuleDecl. Intertestingly, even this
is a considerable improvement over the status quo. LLDB can now print
Swift-only variables in modules with failing Clang depenecies, and
becuase of fallback mechanisms that were implemented earlier, it can
even display the contents of pure Objective-C objects that are
imported into Swift. C structs obviously don't work yet.
rdar://problem/36032653
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
This option access a file that lists protocol names that are 'whitelisted' for getting new protocol requirements.
This allows the SDK checker to avoid flagging protocol method additions for protocols that we know are not intended
for user classes to conform to.
Rather than using the `LINK_LIBRARIES` option, use target_link_libraries
like clang does. Because these are all host tools, there is no name
mangling done for the libraries making this a no-op change.
Remove the unncessary link against the DebugInfoCodeView component. THe tools
seem to build without the dependency. The dependency issue in the linkage
seems to have been resolved.
