This makes the demangler about 10 times faster.
It also changes the lifetimes of nodes. Previously nodes were reference-counted.
Now the returned demangle node-tree is owned by the Demangler class and it’s lifetime ends with the lifetime of the Demangler.
Therefore the old (and already deprecated) global functions demangleSymbolAsNode and demangleTypeAsNode are no longer available.
Another change is that the demangling for reflection now only supports the new mangling (which should be no problem because
we are generating only new mangled names for reflection).
If a documentation comment has a - LocalizationKey: field, strip it
out of the documentation body and report it in cursor/doc info with
the key "key.localization_key".
rdar://problem/30383329
Add an option to the lexer to go back and get a list of "full"
tokens, which include their leading and trailing trivia, which
we can index into from SourceLocs in the current AST.
This starts the Syntax sublibrary, which will support structured
editing APIs. Some skeleton support and basic implementations are
in place for types and generics in the grammar. Yes, it's slightly
redundant with what we have right now. lib/AST conflates syntax
and semantics in the same place(s); this is a first step in changing
that to separate the two concepts for clarity and also to get closer
to incremental parsing and type-checking. The goal is to eventually
extract all of the syntactic information from lib/AST and change that
to be more of a semantic/symbolic model.
Stub out a Semantics manager. This ought to eventually be used as a hub
for encapsulating lazily computed semantic information for syntax nodes.
For the time being, it can serve as a temporary place for mapping from
Syntax nodes to semantically full lib/AST nodes.
This is still in a molten state - don't get too close, wear appropriate
proximity suits, etc.
This provides a stream utility for writing to a underlying string buffer multiple string pieces and retrieve them later as StringRef when the underlying buffer is stable.
This has the effect of propagating the search path to the clang importer as '-iframework'.
It doesn't affect whether a swift module is treated as system or not, this can be done as follow-up enhancement.
Extensive cross-language tooling support needs to bridge decl names between two different languages more freely. This SourceKit request is designed to translate Objc names to Swift names and vice versa. Working similarly to cursor-info requisition, the name translation request requires a Swift reference to a Swift/Clang decl, and the preferred name to translate from, and language kind that the given name belongs to. If the translation succeeds, SourceKit service responds with the corresponding name than belongs to the other kind of language.
Newly introduced keys:
“key.namekind": “source.lang.name.kind.objc” | "source.lang.name.kind.swift"
“key.basename”: “name"
“key.argnames”: [“name"]
“key.selectorpieces”: [“name[:]"]
This commit only implements translation from Objc to Swift.
This is necessary when we want to differentiate between type reference
on extension declaration's start, e.g "extension A {}", and other
references of "A". NFC on existing functionality.
The Linux build has a dependency on the libdispatch library,
which is needed by the various native libraries for sourcekitd.
On macOS, the dependency for libdispatch is satisfied directly through
the base OS, but on Linux no such dependency exists.
Modify this so that if the SourceKit library is built, and the
libdispatch library is already present, then we shell out to make
the libdispatch binary project when the SourceKit is built.
Issue: SR-1676
The Linux build has a dependency on the libdispatch library,
which is needed by the various native libraries for sourcekitd.
On macOS, the dependency for libdispatch is satisfied directly through
the base OS, but on Linux no such dependency exists.
Modify this so that if the SourceKit library is built, and the
libdispatch library is already present, then we shell out to make
the libdispatch binary project when the SourceKit is built.
Issue: SR-1676
