Clearing the cache and the end of the for loop invalidates the interator
and prevents iterating through the rest of the vector. This should be
cleared after we're done iterating.
When performing keypath dynamic member lookup, avoid substituting the
base type in override detection and completion, as the base type of the
lookup is not the base type of the member. For now, we just avoid the
substitution entirely to fix potential crashes; in a future commit we
will change to using the subscript return type and substituting with the
base type of the subscript instead of the base type of the lookup.
rdar://50449788
This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
To represent the abstracted interface of an opaque type, we need a generic signature that refines
the outer context generic signature with an additional generic parameter representing the underlying
type and its exposed constraints. Opaque types also need to be keyed by their originating decl, so
that we can treat values of the same opaque type as the same. When we check a FuncDecl with an
opaque type specified as its return type, create an OpaqueTypeDecl and associate it with the
originating decl. (A representation for *types* derived from the opaque decl will come next.)
Ensure the various entity walkers handle the implicit subscript
reference correctly (usually by ignoring it) and fall through to the
underlying declarations.
rdar://49028895
When building the implicit subscript expression, set the "implicit" bit
correctly and pass it through in the indexer so that we get implicit
refernces to the subscript. This would be useful for e.g. searching for
all uses of the dynamic subscript.
Currently includes both the implicit references to the
subscript(dynamicMember:) and the explicit references to the underlying
property/subscript declarations.
rdar://49028783
Once the '@escaping' bit is removed from TupleTypeElt, it no longer makes
sense to print argument lists as if they were TupleTypes or ParenTypes,
since function types are '@escaping' by default inside tuples but not
in argument lists.
Instead, print ArrayRef<AnyFunctionType::Param> directly. For now this
introduces some awkward usages of AnyFunctionType::decomposeInput();
these will go away once the AST is changed to represent the argument list
as a list of expressions and not a single tuple expression.
Instead of building ArgumentShuffleExprs, lets just build a TupleExpr,
with explicit representation of collected varargs and default
arguments.
This isn't quite as elegant as it should be, because when re-typechecking,
SanitizeExpr needs to restore the 'old' parameter list by stripping out
the nodes inserted by type checking. However that hackery is all isolated
in one place and will go away soon.
Note that there's a minor change the generated SIL. Caller default
arguments (#file, #line, etc) are no longer delayed and are instead
evaluated in their usual argument position. I don't believe this actually
results in an observable change in behavior, but if it turns out to be
a problem, we can pretty easily change it back to the old behavior with a
bit of extra work.
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
This adds an implicit body so that we can dig out the return type
context the same way as a normal function. For now, we are also treating
the first expression in a multi-statement implicit getter body the same
way; we'll need to refactor how we complete in accessors to
differentiate those cases.
Extend the support for single-expression closures to handle
single-expression functions of all kinds. This allows, e.g.
func foo() -> MyEnum { .<here> }
to complete members of `MyEnum`.
For unresolved member completion, member decls in `Optional`
referenceable by implicit member expression are useless in most cases.
- `init(_: <#Wrapped#>)`
- `init(nilLiteral: ())`
- `.some(<#Wrapped#>)`
- `.none`
Instead, provide `nil` with erasing `.` instruction.
rdar://problem/47806831
The parsed expression may be wrapped with various implicit expressions.
For example, if the expression is only element in array literal, it's
wrapped with `(arrayLiteral: <expr>)`.
Right now we use TupleShuffleExpr for two completely different things:
- Tuple conversions, where elements can be re-ordered and labels can be
introduced/eliminated
- Complex argument lists, involving default arguments or varargs
The first case does not allow default arguments or varargs, and the
second case does not allow re-ordering or introduction/elimination
of labels. Furthermore, the first case has a representation limitation
that prevents us from expressing tuple conversions that change the
type of tuple elements.
For all these reasons, it is better if we use two separate Expr kinds
for these purposes. For now, just make an identical copy of
TupleShuffleExpr and call it ArgumentShuffleExpr. In CSApply, use
ArgumentShuffleExpr when forming the arguments to a call, and keep
using TupleShuffleExpr for tuple conversions. Each usage of
TupleShuffleExpr has been audited to see if it should instead look at
ArgumentShuffleExpr.
In sequent commits I plan on redesigning TupleShuffleExpr to correctly
represent all tuple conversions without any unnecessary baggage.
Longer term, we actually want to change the representation of CallExpr
to directly store an argument list; then instead of a single child
expression that must be a ParenExpr, TupleExpr or ArgumentShuffleExpr,
all CallExprs will have a uniform representation and ArgumentShuffleExpr
will go away altogether. This should reduce memory usage and radically
simplify parts of SILGen.
When CursorInfo finds a reference to a VarDecl that's implicit but has a parent
VarDecl (according to VarDecl::getParentVarDecl), act as if we found the parent
instead.
There should be escaped identifiers in code completion:
- As primary expression: Any keyword name except for `self` and `Self`.
- After dot: Something named `init`.
rdar://problem/16232627
Ensure that we get the correct behaviour when we are not in the
single-expression case, and remove code that handled 0-element bodies,
which is no longer needed after the parser change.
