This is a new SourceKit request which receives a position in the source
file, returns possible expected types and their members which can be
referenced by "implicit member expression" syntax.
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"
`-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
These were recently added to support returning the SyntaxTree in the bytetree
from SourceKit but were never added in SwiftLang (the Swift layer wrapping
SourceKit).
sourcekitd_variant_t is only safe to use while the sourcekitd_response_t it was
retrieved from is still alive, so keep a strong reference to SourceKitdResponse
(the Swift wrapper of sourcekitd_response_t) in each Variant (the Swift wrapper
of sourcekitd_variant_t).
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
Ensure that we install the client header for the InProc sourcekitd. This is
needed to actually make it usable. With this, it is now possible to develop
against SourceKit on Linux and Windows.
Set all the target properties in a single shot. This avoids the multiple string
parsing within CMake. Although this makes no noticable differnce, it is
slightly more efficient and also colocates all the target properties.
Libraries in sourcekitd depending on the external libdispatch project
appear to only depend on the *build* step, but really need the install
to happen as well since we are linking to the installed location.
Attempt to use the host compiler when building libdispatch for SourceKit. This
is needed for cross-compiling scenarios (e.g. building the Windows toolchain on
Linux). However, unfortunately, the Ubuntu 14.04 build bots are using an
ancient compiler, so we cannot use that for building libdispatch. Add a
fallback to the just built clang. Ensure that the fallback only activates when
compiling on the same host as the target.
