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.
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
The ArchetypeTransformer isn't actually limited to transforming archetypes
but can transform arbitrary types. Thus, we can rename it to TypeTransformer
Cursor info requires access to the underlying AST, which is not
thread-safe. This manifest as crashes when performing concurrent
cursor-info requests on the same generated interface. We already
prevented concurrent cursor-infos on regular Swift files by using the
ASTManager, but generated interfaces use the InterfaceGenContext which
may use either an ASTUnit or its own internal CompilerInstance.
rdar://problem/27311624
Typically, users jump to type-specific interface from a member of that type, for
instance, a.getSomething(). To generate the interface, we need to report the USR
of the container type of "getSomething()", which is the USR for the type of a,
when cursor info is requested for this function call.
The mangled name of the type is identical to those for debugger. These
mangled names allow us to reconstruct the type from AST and generate interface
specifically for that type.
Related rdar://27306890
This eventually calls the code from ReconstructType to try to find the
Decl for a USR. For now, only works in a file, not a generated
interface.
rdar://problem/25017817
Pass through the original Type in addition to the TypeDecl so that we
can distinguish DynamicSelfType with underlying ClassType from just any
old ClassType.
rdar://problem/25158493
For now, only do this in SourceKit (printQuickHelpDeclaration), but
there are probably other printing modes that should do this.
rdar://problem/24292226
Move the type callbacks into the respective type/typerepr printers so
taht we get these callbacks even when we print the type directly, or in
a nested fashion. Also make the returntype more explicit than just
"inside a function type", since visiting the function type currently
visits the input argument tuple (which is different than e.g. the
function *decl* printing, which walks the parameter list explicitly).
rdar://problem/24292226
As a first foray into annotating attribute, add tags around attribute
names. For now, treat any decl-modifiers as keywords. We will also want
to wrap the whole attribute (including any parameters) into tags as
well, but that will require more work in the callback hanlding.
Also factor the attribute printing to handle any special cases early,
which will simplify wrapping attributes in tags, since we can then just
put the whole switch intside the pre/post callbacks.
rdar://problem/24292226
I want to start using this for other things like function types and
attributes, so rename it to reflect the new scope. I'm not really happy
with "PrintStructureKind", etc. but haven't come up with anything
better so far.
The current approach of visiting the param decl won't work when we want
to visit the parameters of function *types*, or when visiting tuple
elements (which aren't themselves decls).
rdar://problem/24292226
