With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
This makes us more lenient about what we accept for Objective-C
selectors by allowing you to include or not include the trailing colons.
We don't actually need that information, because we have access to the
declaration, so it was only being used for validation, which made the
API harder to use for clients that didn't carefully track zero vs
one-arg selector names.
Also remove the colons from the response, and instead add a bit to say
whether it is a zero-arg or one-arg selector. This makes the response
easier to use for clients that don't care about this information, and
more consistent with the change to the input.
rdar://problem/32177934
The OncePerASTToken machinery lets us automatically cancel "stale"
requests after a new one comes in. This avoid wasting time processing
requests that have been superceded, which is common for cursor-info, but
sometimes you really want to get results even later, so this commit adds
a way to opt out of the cancellation.
Incidentally, disable cancellation of name translation, which doesn't
really make sense and no one should be relying on that.
rdar://problem/31905379
We were checking only for the specific loc of the declaration of the
param, but that didn't handle references to a local parameter inside the
body.
rdar://problem/32019195
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
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.
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 typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
Like cursor-info, range info (""source.request.cursorinfo"") answers some
questions clients have for a code snippet under selection, for instance, the type of a selected
expression. This commit implements this new quest kind and provides two
simple information about the selected code: (1) the kind of the
snippet, currently limited to single-statement and expression; and (2)
the type of the selected expression. Gradually, we will enrich the
response to provide more insight into the selected code snippet.
