"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
Calculate and set the type relation in each result building logic which
knows the actual result type.
CodeCompletionResultBuilder couldn't know the actual result type. From
the declaration alone, it cannot know the correct result type because it
doesn't know how the declaration is used (e.g. calling? referencing by
compound name? curried?)
The tests were matching the previous implementation's output, which sometimes produced 'unknown' and sometimes 'unrelated' in cases where there was no expected type from the context.
This was not needed. The list of depenencies should not be changed
during fast-completion sessions.
This was also harmful because it calls stat(2) for all the dependency
files.
rdar://problem/67773257
'SM.getCodeCompletionBufferID()' returns the buffer ID of the previous
code completion. 'CI.getCodeCompletionFile()->getBufferID()' always
returns the original source buffer ID of the current file in the main
module. The latter is needed for excluding buffer ID for dependency checking.
rdar://problem/66301353
`PreCheckFunctionBuilderRequest` applies `PreCheckExpression` to the
expressions inside the function body. Previously it used to receive only
`AnyFunctionRef` (`FunctionDecl` or `ClosureExpr`) as the parameter.
However, when fast-completion kicks-in, it replaces the body of the
function, then tries to call `PreCheckFunctionBuilderRequest` again, with
the same function decl as before. It used to return cached "Success"
result, but it didn't actually apply `PreCheckExpression`. So any
`UnresolvedDeclRefExpr` remained unresolved.
In this patch, make `PreCheckFunctionBuilderRequest` receive "body" of the
function as well, so it doesn't return the cached result for the *previous*
body.
rdar://problem/65692922
Return type in the closure signature is often redundant when expanding
placeholders, because the type of the clossures are usually inferred
from the context (i.e. calling function), users don't need to write the
return type explicitly.
They are not only redundant, but also sometimes harmful when the return
type is a generic parameter or its requirement. Actually, there is no
correct spelling in such cases.
So omit the return type and the parentheses around the parameter clause.
rdar://problem/63607976
Out of all operating systems ever supported by Swift, only Ubuntu 14.04
had libstdc++ 4.8, and Swift has sunset support for Ubuntu 14.04 for a
while now.
When completing a single argument for a trailing closure, pre-expand the
closure expression syntax instead of using a placeholder. It's not valid
to pass a non-closure anyway.
rdar://62189182
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
Check if dependencies are modified since the last checking.
Dependencies:
- Other source files in the current module
- Dependent files collected by the dependency tracker
When:
- If the last dependency check was over N (defaults to 5) seconds ago
Invalidate if:
- The dependency file is missing
- The modification time of the dependecy is greater than the last check
- If the modification time is zero, compare the content using the file
system from the previous completion and the current completion
rdar://problem/62336432
For exmaple:
func foo(_: Int, _: IntOption)
func foo(_: Float, _: FloatOption)
foo(intVal, .<HERE>)
Previously code completion suggests static member from 'IntOption' and
'FloatOption' without any prioritization. Prioritize members from
'IntOption' because the user probably wants to input them.
In such cases, 'CodeCompletionExpr' at the cursor position is
pre-typechecked to 'IntOption'. So mark results with matching type with
'ExprSpecific'.
rdar://problem/62121221
For instance:
--
let globalVar = {
func something(arg: Int) -> Int {
#^HERE^#
}
return something(12)
}()
--
We want to consider this as a top-level completion, not a function body
completion.
rdar://problem/60838686
Pass '-fbuild-session-timestamp' and '-fmodules-validate-once-per-build-sessio'
to ClangImporter so that module validation happens only once for the
SourceKit lifetime.
rdar://problem/59567281
e.g. Playground.
A single file script is like a single function body; the interface of
the file does not affect any other files.
So when a completion happens in a single file script, re-parse the whole
file. But we are still be able to reuse imported modules.
rdar://problem/58378157
In fast-completion, a function body can be replaced with another function
body parsed from a new buffer. In such cases, during typechecking the
expressions in the *new* function body, a source location range check in
UnqualifiedLookup didn't work well because they are not from the same
buffer.
This patch workaround it by skipping the source range checks and returns
'success' in such cases.
rdar://problem/58881999
If a CC token is right after the '{' we still don't know it's an implicit
getter or a start of a accessor block. Previously, the parser used to
parse it as an accessor block, but it prevents fast-completion kicks in.
Instead handle it as a part of function body parsing so the
fast-completion works.
rdar://problem/58851121
Doug Gregor
Rintaro Ishizaki
Nathan Hawes
Argyrios Kyrtzidis
Dmitri Gribenko
Ben Langmuir
Saleem Abdulrasool