This item is to associate a usr with a special case Id, however, it's
up to the migrator to interpret the special case Id and apply proper
transformations.
This handles optionality changes and type rewrites in function param and return types and constructor param and failability types.
Resolves rdar://problem/31766010
These data files are installed into runtime resource directory so that migrator can pick them automatically according to specific platforms. To support testing, a front-end option -api-diff-data-file can be used to specify the data file to use and it will overwrite the default ones from resource directory.
This structure serves multiple purposes:
a. Allow migrator to speak in the same language with swift-api-digester in terms of API changes.
b. Serialize/Deserialize detected API change items in JSON format.
c. Manage memory after deserializing API change items.
d. Facilitate look up by USRs of APIs under migration.
The structure is tested by round-trip serialization and deserialization.
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 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.
* [RangeInfo] Perform complete walk on the last node in a given range to avoid missing information due to early abort.
* [RangeInfo] For declared decls in a given range, report whether they are referenced outside of the range.
* [RangeInfo] Report the contained (topmost) ASTNodes inside a selected range.
