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
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.
Unless you're familiar with the way the swift source code is organized,
it's not clear what "SourceDocInfo" means, or how it is different from
DocSupport, etc. Move the tests into directories that are named based
on their request (note: we already had one test under CursorInfo, which
just made things even more confusing).
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
Unlike other prefix operators, unary minus is folded into the
NumberLiteralExpr in the parser. This commit recreates this effect in
the lexer-based syntax map so that token ranges will include the leading
minus.
rdar://problem/20205885
D'oh, forgot to resolve a FIXME in my protocol commit. Now working there
too except that it's giving USRs on the original protocol instead of the
extension. It's not clear how to get back to the extension from the
archetype though.
rdar://problem/25128561
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
Treat it like the static Self type, which is good enough for producing
USRs in CursorInfo. This doesn't handle class dynamic self, which needs
some kind of API change to printTypeRef to make it work.
rdar://problem/25128561
