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
