This bool was true only for single-expression closure and function bodies that
do not have an explicit `return` in the source. Rename it and its associated
methods, to avoid confusion with the hasSingleExpressionBody methods on
ClosureExpr and AbstractFuncDecl. Those don't care whether the expression was
explicitly written in the source or not.
Following on from updating regular member completion, this hooks up unresolved
member completion (i.e. .<complete here>) to the typeCheckForCodeCompletion API
to generate completions from all solutions the constraint solver produces (even
those requiring fixes), rather than relying on a single solution being applied
to the AST (if any). This lets us produce unresolved member completions even
when the contextual type is ambiguous or involves errors.
Whenever typeCheckExpression is called on an expression containing a code
completion expression and a CompletionCallback has been set, each solution
formed is passed to the callback so the type of the completion expression can
be extracted and used to lookup up the members to return.
Using canonical types. Otherwise 'Optional<T>' and 'T?' aren't
considered the same.
Also, for example, the expected context types are 'T?' and 'T', don't
get results from 'T' twice.
rdar://problem/71063455
Strings are a single token, so the previous check would treat
completions inside string interpolations as being outside of the
initializer.
Grab the end of the token from the Lexer, but wrap in a context check to
avoid performing that for every declaration found in the lookup.
Resolves rdar://70833348
`::lookupVisibleDecls` had an inline consumer in order to remove
"unusable" results. Refactor this method, moving the consumer (now
`UsableFilteringDeclConsumer`) to allow its use when looking up top
level module declarations.
Also use the `AccessFilteringDeclConsumer` in preference to a condition
in `addVarDecl`.
Resolves rdar://56755598
Solver-based member completion performs a lookup per solution, but if the base
types in each solution are variations of the same generic (e.g. Array<Int>,
Array<String>), we can end up with the same result appearing twice (e.g. count)
Take type body fingerprints into account for inteface hash checking.
Since `SourceFile.getInterfacehash()` doesn't digest the type body
fingerprints in the file, enabling type body fingerprints regressed
fast-completion.
rdar://problem/69890297
To help consolidate our various types describing imports, this commit moves the following types and methods to Import.h:
* ImplicitImports
* ImplicitStdlibKind
* ImplicitImportInfo
* ModuleDecl::ImportedModule
* ModuleDecl::OrderImportedModules (as ImportedModule::Order)
* ModuleDecl::removeDuplicateImports() (as ImportedModule::removeDuplicates())
* SourceFile::ImportFlags
* SourceFile::ImportOptions
* SourceFile::ImportedModuleDesc
This commit is large and intentionally kept mechanical—nothing interesting to see here.
Code completion used to avoid forming single expression closures/function
bodies when the single expression contained the code completion expression
because a contextual type mismatch could result in types not being applied
to the AST, giving no completions.
Completions that have been migrated to the new solver-based completion
mechanism don't need this behavior, however. Rather than trying to guess
whether the type of completion we're going to end up performing is one of
the ones that haven't been migrated to the solver yet when parsing, instead
just always form single-expression closures/function bodies (like we do for
regular compilation) and undo the transformation if and when we know we're
going to perform a completion kind we haven't migrated yet.
Once all completion kinds are migrated, the undo-ing code can be removed.
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.
Also perform the plumbing necessary to convince the rest of the compiler that they're just ordinary external dependencies. In particular, we will still emit these depenencies into .d files, and code completion will still index them.
This was happening in the error recovery path when parsing accessors
on a pattern binding declaration that does not bind any variables, eg
let _: Int { 0 }
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?)
When performing code completion inside the declaration of a type with
the function builder attribute, also include completions for all of
the possible "build" functions.
