In derivatives of loops, no longer allocate boxes for indirect case payloads. Instead, use a custom pullback context in the runtime which contains a bump-pointer allocator.
When a function contains a differentiated loop, the closure context is a `Builtin.NativeObject`, which contains a `swift::AutoDiffLinearMapContext` and a tail-allocated top-level linear map struct (which represents the linear map struct that was previously directly partial-applied into the pullback). In branching trace enums, the payloads of previously indirect cases will be allocated by `swift::AutoDiffLinearMapContext::allocate` and stored as a `Builtin.RawPointer`.
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)
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.
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.
We were reporting methods that return function types that return void (rather
than returning void directly) as being invalid in contexts that expect non-void
expressions and testing for that incorrect behavior.
This happens when, e.g. an expression being switched on is invalid so
expression patterns in the switch cases (which may contain the completion
expression) are not checked.
Also setup the Lookup object to handle member completion in ObjC selector
expressions correctly, and fix passing the wrong expression when computing
isStaticallyDerivedMetatype().
This hooks up member completion to the new typeCheckForCodeCompletion API to
generate completions from all solutions the constraint solver produces (include
ones requiring fixes) rather than relying purely the single solution being
applied to the AST (if any). This lets us still give completion results in
ambiguous and invalid code.
Since the user can now write additional member accesses off of an UnresolvedMemberExpr, we should offer all available completions rather than just those that match the contextual type.
