Now that arguments are marked up with whether they have a default or
not, clients may not need the extra call (that has no default
arguments). Add an option to allow not adding this item.
Resolves rdar://85526214.
"add inits to toplevel" and "call pattern heuristics" are only used in
code completion. Move them from LangOptions to CodeCompletionContext so
that they don't affect compiler arguments.
The various keyword/recommended/etc fields were parsed and added to
completions, but never actually plumbed through SourceKit. Since they're
still unused and the implementation is not particularly lightweight,
just remove for now.
Resolves rdar://82464220
* Implement 'getDiagnosticSeverity()' and 'getDiagnosticMessage()' on
'CodeCompletionResult'
* Differentiate 'RedundantImportIndirect' from 'RedundantImport'
* Make non-Sendable check respects '-warn-concurrency'
rdar://76129658
* 'CodeCompletionContext' now has 'requiresSourceFileInfo()' flag
* When 'true', 'SourceFiles' is populated.
* 'SourceFiles' is a list of pairs of a known module source
file path and its up-to-date-ness
* Clients (i.e. 'CodeCompletionConsumer') can retrieve it from
'CodeCompletionContext' in 'handleResults'
* Each completion item now has 'SourceFilePath' property
* C-APIs to get those informations
To describe fine grained priorities.
Introduce 'CodeCompletionFlair' that is a set of more descriptive flags for
prioritizing completion items. This aims to replace '
SemanticContextKind::ExpressionSpecific' which was a "catch all"
prioritization flag.
'InvalidAsyncContext' depends on the decl context. That may case
"sticky" not-recommended If it's cached for a non-async context.
To workaround this, stop checking 'InvalidAsyncContext' when collecting
completion items for caching. Also consistently use the 'SourceFile' as
the decl context to avoid decl context specific behavior.
rdar://78315441
struct Foo {
init(_ arg1: String, arg2: Int) {}
init(label: Int) {}
}
func test(strVal: String) {
_ = Foo(<HERE>)
}
In this case, 'strVal' was prioritized because it can use as an argument
for 'init(_:arg2:)'. However, argument labels are almost always
preferable, and if the user actually want 'strVal', they can input a few
characters to get it at the top. So we should always prioritize call
argument patterns.
rdar://77188260
Combine IsNotRecommended with NotRecommendedReason and improve the names
of the existing cases to more clearly identify the cases they apply to.
Now all not-recommended completions are required to have a reason.
Thanks to Ben Barham for spotting this:
sizeof(~static_cast<uint8_t>(...)) is 4, but we need to write a single
byte here. Thankfully this code was probably not being hit in the
current caching scheme, which only caches declarations.
Looking at the history, this code was broken by d8fbaa01eb, which was
fixing an MSVC warning in this code. Unfortunately I do not have access
to the version of MSVC to check if there is still a warning here or for
what.
func foo() {}
let a: Int = #^HERE^#
Previously, we marked 'foo()' as 'NotRecommented' because 'Void' doesn't
have any member hence it cannot be 'Int'. But it wass confusing with
'deprecated'.
Now that we output 'typerelation' which is 'invalid' in this case. So clients
can deprioritize results, or even filter them out.
rdar://problem/57726512
This fixes a source of non-determinism. The IDE/complete_constructor
test would sometimes fail depending on the order in which prior tests
ran, since those prior tests might populate the code completion cache.
In the new code-completion code path, force any known operators to go
through a fixed sort order. To identify operators unambiguously, add a
new BuiltinOperator code-completion kind to handle non-decl operators
(!, ., ?., and =).
rdar://problem/25994246
rdar://problem/23440367
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.
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.
When we miss the in-memory (libcache-based) code completion cache, we
can now chain to an on-disk code completion cache. This drastically
improves the time and peak memory usage it takes to do the first code
completion (ie. before the in-memory cache is warm) if we've done the
same lookup before.
The on-disk cache, like the in-memory cache is tied to the specific
compiled swift and clang module files (.swiftmodule and .pcm), and will
consider itself out of date if they are modified. Responsibility for
deleting completely dead/unreachable cache files falls to the client.
Most of this commit is adding a simple serialization and deserialization
for CodeCompletionResults and CodeCompletionStrings. The format is very
simple, using an array of fixed size CodeCompletionResults, with offsets
into two blobs: one for CodeCompletionString::Chunks, and one for
strings. Currently that gives us about 5.8 MB for all the results in
Cocoa, but it's very compressible if we decide we want to reduce it
(gzip'd it is ~1.2 MB for the same data).
Swift SVN r28369
