Follow-up to f577578a6a. The same
treatment for ternary expression (IfExpr). Plus, fix a regression
introduced in f577578a where infix operators were disappeard from
results.
foldSequence() may hoist these expression up by mutating their sub
expression. When completing operators, this behavior ruins reusability
of operand. Since these expression doesn't affect completion, we can
strip them out.
rdar://problem/42452085
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
Now, an AbstractFunctionDecl always stores a single parameter list.
Furthermore, ConstructorDecl and DestructorDecl always store a
ParamDecl for 'self'.
FuncDecl only has a 'self' if it is a member of a nominal type or
extension, so we tail-allocate the storage for it.
At some point we stopped completing keywords after `else` in an if
statement. Bring back the completion of `if`, which is the only valid
continuation other than a brace.
rdar://37467474
Completing signature depends on its GenericEnvironment which is set
during typechecking. Previously, completing signature using generic type
used to cause assertion failure. e.g.
extension Collection {
subscript(some index: Int) -> Iterator.<COMPLETE HERE>
rdar://problem/41227754
In getOperatorCompletions(), for each every known operators, temporary
expressions are created and typechecked. In this process, typechecker
may set the type of the parsed expression. That may cause non-accurate
completion results or crash at worst.
rdar://problem/28188259
Refactor the interface to return a bit vector. Along the way, fix up
the callers and remove some dead usages of the defaults information
that were copied and pasted around Sema.
Calling '@objc optional func' requires '?' or '!' after its name. When
completing method calls for them, 'key.sourcetext' should have '?'
whereas 'key.name' shouldn't.
Note that we deliberately do not use optional type name for
'key.typename'. This is consistent with optional chain '?.<propertyName>'
behavior.
rdar://problem/37904574
For call argument completion, if the expected type and completion result type are
both GenericTypeParameterTypes, comparing them doesn't make sense we can't account
for their different contexts at this point in the code, and hit assertions in the
constraint solver if we try.
For now, don't attempt to add a type relation for this case.
Resolves rdar://problem/38153332.
This was caused by two separate issues:
1. If given a function type with an IUO return, it would add function call
completions, set Done=true, and then progress to some logic to add
completions for the unwrapped type of optionals. That code would check if
the corresponding decl has the IUO attribute set and, if it was but couldn't
be unwrapped, assert. For function types, it now early exits after adding
call completions.
2. If given the type of a bound (`blah?.`) or forced (`blah!.`) optional,
the type is non-optional and can't be unwrapped and the decl still has the
IUO so it asserts. Refined the assertion to account for this case.
Resolves rdar://problem/38188989.
