These results are cached, so we can't use the type-relation. Instead we
use a small hack of checking the textual return type for "Void". This
is obviously not ideal, but it lets us detect the most important cases.
rdar://problem/22810741
As implied in rdar://24818863, striking through a module name may be an overkill to suggest the module is redundant to import. We try to
fine-grain not-recommended-reason so that proper UI cue can be adopted in the future.
Instead of using 'key.usr' and 'key.synthesizedusr', we start to use 'key.usr' and 'key.original-usr' so
that 'key.usr' is consistently being the unique ID for a code entity.
Moved getTrimmedTextForLine & getExpandedIndentForLine
This help reduce the coupling to SwiftEditor Document and allows us
to format any text, whether or not is currently in an editor doc.
Move FormatContext & FormatWalker into new file.
Move CodeFormatOptions out of SwiftEditorDocument.
Move functions getTrimmedLineOffset & getLineOffset
out of SwiftEditor Document.
Rename Offset of Line functions
Declaring that the get the offset of some line index is more clear.
experimental code-completion path. Move them right before "other module"
results. This is a bit of a hack. Ideally, we would have a much better
idea which keywords are actually legal/likely in a given context and
could prioritize them even more. Since today we basically splat in all
the keywords, keep them below the current module results so they don't
overwhelm us.
rdar://problem/25119529
We may know syntactically that we have an operator without being able to
find the associated operator decl when the input is invalid/incomplete.
Don't crash when that happens, and just fallback to a "free function"
decl kind.
rdar://problem/25196625
... in the experimental code-completion path. They seem to be generally
useful as a baseline result still as long as they are guaranteed to be
the first result.
rdar://problem/25177968
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.
