Note that in all cases it was either nullptr or ctx.getLazyResolver().
While passing in nullptr might appear at first glance to mean something
("don't type check anything"), in practice we would check for a nullptr
value and pull out ctx.getLazyResolver() instead. Furthermore, with
the lazy resolver going away (at least for resolveDeclSignature() calls),
it won't make sense to do that anymore anyway.
The only place this was used in Decl.h was the failability kind of a
constructor.
I decided to replace this with a boolean isFailable() bit. Now that
we have isImplicitlyUnwrappedOptional(), it seems to make more sense
to not have ConstructorDecl represent redundant information which
might not be internally consistent.
Most callers of getFailability() actually only care if the result is
failable or not; the few callers that care about it being IUO can
check isImplicitlyUnwrappedOptional() as well.
let _: [Foo] = [
.create(str: Int)
.create(#^COMPLETE^#)
]
Previously, this completion used to fail because the array expression
isn't typechecked. We need to analyze the context type of the array
literal first, that defines the type of the unresolved member
expression.
rdar://problem/50696432
struct Wrap<T> {
func method<U>(_ fn: (T) -> U) -> Wrap<U> {}
}
func testGenricMethodOnGenericOfArchetype<Val>(value: Wrap<Val>) {
value.method(#^HERE^#)
}
In this case, the type of value is `Wrap<Val[archetype]>`.
`Type::getTypeOfMember()` for 'method' method returns
`( (Val[archetype]) -> U[generic param]) -> Wrap<U[generic param]>`
which crashs 'mapTypeIntoContext()' because it already hass archetype.
rdar://problem/52386176
```swift
protocol Proto {}
struct ConcreteProto {}
struct MyStruct<T> {}
extension MyStruct where T: Proto {
static var option: MyStruct<ConcreteProto> { get }
}
func foo<T: Proto>(arg: MyStruct<T>) {}
func test() {
foo(arg: .#^HERE^#)
}
```
In this case, the type of `MyStruct.option` is `MyStruct<ConcreteProto>`
whereas the context type is `MyStruct<T> where T: Proto`.
When checking the convertibility of them , we need to "open archetype types".
rdar://problem/24570603
rdar://problem/51723460
For example:
let x: MyClass = .create(<#COMPLETE#>)
This expression ends up with:
(call_expr
(dot_syntax_self_apply_expr
(decl_ref_expr decl='C.create(_:arg1)'
(type_expr type=MyClass))))
So we need to look through 'DotSyntaxSelfApplyExpr' to get the decl.
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`.
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.
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.
When completing in the only expression of closure, use the return type
of the closure as the type context for the code-completion. However,
since code-completion may be on an incomplete input, we only use the
return type to improve the quality of the result, not to mark it
invalid, since (a) we may add another statement afterwards, or (b) if
the context type is Void it doesn't need to match the value.
To return accurate type of the expression.
i.e.
MyType.foo(#^COMPLETE^# // -> (MyType) -> (args...) -> Result
MyType().foo(#^COMPLETE^# // -> (args...) -> Result
Instead of re-typechecking parsed expression, find typechecked
expression that corresponds to the parsed expression from the
typechecked decl context, because the sub expressions of the parsed
expression can be weirdly mutated/replaced by decl context typechecking.
rdar://problem/48141174
For `Initializer` decl context, type context analyzer should look into
its parent context because that might constrain initializer's type.
rdar://problem/48208253
`source.request.conformingmethods` is a new SourceKit request which
receives a source position and a list of protocol namses, returns a list
of methods whose return type conforms to the requested protocols.
rdar://problem/44699573
