[CodeCompletion] Wrap base expression with CodeCompletionExpr

[rintaro]

For example, for:

funcName(base.<HERE>)

Wrap base with CodeCompletionExpr so that type checker can check base independently without affecting the overload choice of funcName.

This increases the chance of successful type checking.

rdar://problem/63965160

[rintaro]

@swift-ci Please smoke test

[rintaro]

@swift-ci Please smoke test

[rintaro]

Not sure this is desirable. But this is needed to preserve the current behavior in several test cases.

[benlangmuir]

Am I reading this correctly that we are saying that in

foo(something.<complete>)

the type of something.completed_expr must be defaultable to the type of something? What kinds of tests changes do you see without this?

[rintaro]

ConstraintKind::Defaultable means "the first type can be defaulted to the second", not "must be defaultable", IIUC. It's something like "fallback" type.

The failing test case was:

let val = Something.<HERE>

In this case val is type checked to the type of Something so each result has type relation (e.g. Invalid for Void result). Without Defaultable, since val cannot be resolved, there's no expected type here. (I'm not saying that val as Something is the right thing)

[benlangmuir]

I see. That seems like an unfortunate way to say "non-Void". What happens if there is an expected type and it really is Void?

[xedin]

It seems like what we really want here is for code completion expression to be marked as a hole by default, just like we do in some other cases, that would solve a case where there is absolutely no contextual information available (let _ = foo.<#complete#> just like Rintaro mentioned).

I'm still thinking about this but it might be possible to generate constraints here in a way which would match what we do for DefineMemberBasedOnUse fix if member couldn't be found, that would guarantee that there is either a type or a hole inferred for a member reference.

[xedin]

I think the least disruptive change would be to default code completion to UnresolvedType regardless of whether it's a member lookup or not, we also currently use UnresolvedType to indicate holes so it's fitting.

[benlangmuir]

Conceptually seems reasonable to me, but the CSGen change doesn't make sense to me.

[benlangmuir]

Am I reading this correctly that we are saying that in

foo(something.<complete>)

the type of something.completed_expr must be defaultable to the type of something? What kinds of tests changes do you see without this?

[rintaro]

@swift-ci Please smoke test

[rintaro]

The test case is

var topLevelVar1 = #^TOP_LEVEL_VAR_INIT_1^#
// Check that the variable itself does not show up.
// TOP_LEVEL_VAR_INIT_1_NEGATIVE-NOT: topLevelVar1

This used to work only because typechecking this decl was failed. Now that it's typechecked to UnresolvedType so it revealed the existing issue(rdar://problem/56755598).

[rintaro]

This is a regression. For example:

let _ = [<HERE>: 1]

Previously this used to be type checked to [AnyHashable : Int], but now it's [<<unresolved type>> : Int]. It's unfortunate, but in practice, I don't think this causes a big difference.

[rintaro]

@swift-ci Please smoke test

[rintaro]

@swift-ci Please smoke test

[rintaro]

Decided not to default it to UnresolvedType for now.

[xedin]

LGTM! We'll iterate on how to make code completion expressions proper "holes".