Clang and Swift decls likely have many-to-one mappings; for instance,
a RecordDecl and a TypedefDecl in Clang are both imported as the same Swift
NominalTypeDecl. This commit reduces duplication when we print Clang decls in
Swift. rdar://23275959
Fix spurious docs warning that @in and @in_guaranteed should be ``fn``.
Add ``#ifdef SWIFT_OBJC_INTEROP`` to silence a -Wunused-function
on linux since that function is only used from within that #ifdef
elsewhere.
Fix three -Wunused-function warnings on linux.
Fix two -Wunreachable-code warnings on linux dealing with
SWIFT_HAVE_WORKING_STD_REGEX.
Aligning with our recent changes for Clang doc comments, the three new fields for Swift are
"- keyword:", "- recommended:", and "- recommendedover:". We also manifest their contents in code
completion results to guide users to choose the right API.
When auto-completing import decls, we should prioritize not-yet imported modules
over already-imported modules. To do so, we mark the latter with not-recommended tag.
URLs come through SourceKit as custom <Link> elements which weren't
getting escaped as raw HTML, which would cause URLs with query
strings to get cut off because of ampersands.
rdar://problem/23394719
Similar with @keyword, manifesting @recommended and @recommendedover content in code
completion results can help IDE users to choose the right API in the long candidate list.
This commit extract these two attributes from Clang doc comments and insert/cache them in
code completion results.
rdar://23101030 and rdar://23101029
Conventionally, code completion results are matched with user input solely by
names. However, names are limited in expressiveness. From this comments, we start to
decorate code completion results with @keywords fields extracted from Clang doc comments.
These fields are added by API authors to comment the decl with information that
is not manifested clear enough through names. Code completion users' typing of the
keyword leads to the corresponding code completion results being selected as well.
Keywords can be arbitrarily long and can be multiple.
For instance, a function called "index()" has "@keyword find" in its doc comment.
Users' typing of "find" leads to "index()" being selected in the code completion list.
This avoids us using reserved identifiers as the enum case names of all
our underscored protocols like _ObjectiveCBridgeable. I used the
convention PROTOCOL_WITH_NAME to mirror how the known identifiers work.
Swift SVN r32924
Go beyond the existing keyword completions to include more literal
suggestions: 0, 0.0, "text", [item], [key: value], (item, item)
For rdar://problem/21923069
Swift SVN r32890
This mostly works the same as for functions. It required a slight tweak
to how we handle 'var <complete>' to avoid consuming the code completion
token prematurely.
rdar://problem/21012767
Swift SVN r32844
This crashed until recently, and although I couldn't find a case where
the RHS had a null type anymore, I also couldn't see a reason it
couldn't happen, since we don't always assign types to every expression
in code-completion type-checking.
rdar://problem/23111219
Swift SVN r32793
When not completing a full call pattern for the first argument, such as
here:
foo(<here>, arg2: blah)
we now show the argument label if appropriate.
For rdar://problem/22804670
Swift SVN r32774
Peek at the token following the code completion location to decide
whether or not to provide completions for entire call patterns. When
the next token looks like it's part of an existing call we don't show
the patterns because they will "push out" the existing arguments.
We should now get:
Foo<here> => (blah, blah)
Foo(<here> => ['(']blah, blah)
Foo(<here>) => ['(']blah, blah[')']
Foo(<here>, blah) => just complete the values for arg1**
Foo(<here>blah, blah) => just complete the values for arg1
** A further improvement will be to add the argument label completion
for the first argument (if applicable) when we aren't showing a full
call pattern.
rdar://problem/22804670
Swift SVN r32765
When users try to print the interface of a specific type (most often through cursor
infor query of SourceKit), we should simplify the original decls by replacing
archetypes with instantiated types, hiding extension details, and omitting
unfulfilled extension requirements. So the users can get the straight-to-the-point
"type interface". This commit builds the testing infrastructure for this feature,
and implements the first trick that wraps extension contents into the interface body.
This commit also moves some generic testing support from SourceKit to Swift.
Swift SVN r32630
