[CodeCompletion] Wrap base expression with CodeCompletionExpr #32184

rintaro · 2020-06-04T17:39:16Z

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 · 2020-06-04T17:39:24Z

@swift-ci Please smoke test

rintaro · 2020-06-04T17:48:02Z

@swift-ci Please smoke test

rintaro · 2020-06-04T17:51:19Z

lib/Sema/CSGen.cpp

+      // Defaults to the type of the base expression.
+      if (auto base = E->getBase()) {
+        CS.addConstraint(ConstraintKind::Defaultable, ty, CS.getType(base),
+                         locator);
+      }


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

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?

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)

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?

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.

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 · 2020-06-04T18:37:19Z

lib/Sema/CSGen.cpp

+      // Defaults to the type of the base expression.
+      if (auto base = E->getBase()) {
+        CS.addConstraint(ConstraintKind::Defaultable, ty, CS.getType(base),
+                         locator);
+      }


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 · 2020-06-05T16:08:42Z

@swift-ci Please smoke test

rintaro · 2020-06-05T16:36:03Z

test/IDE/complete_at_top_level.swift

@@ -10,7 +10,8 @@

 // RUN: %target-swift-ide-test -code-completion -source-filename %s -code-completion-token=TOP_LEVEL_VAR_INIT_1 > %t.toplevel.txt
 // RUN: %FileCheck %s -check-prefix=TOP_LEVEL_VAR_INIT_1 < %t.toplevel.txt
-// RUN: %FileCheck %s -check-prefix=TOP_LEVEL_VAR_INIT_1_NEGATIVE < %t.toplevel.txt
+// FIXME: rdar://problem/56755598
+// RUN: not %FileCheck %s -check-prefix=TOP_LEVEL_VAR_INIT_1_NEGATIVE < %t.toplevel.txt


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 · 2020-06-05T16:45:37Z

test/IDE/complete_expr_postfix_begin.swift

-// NOTE: [Convertible] to AnyHashable.
+// FIXME: '/TypeRelation[Convertible]' to AnyHashable.
 // IN_FOR_EACH_4-NOT: Decl[LocalVar]
-// IN_FOR_EACH_4: Decl[LocalVar]/Local/TypeRelation[Convertible]: local[#Int#];
+// IN_FOR_EACH_4: Decl[LocalVar]/Local: local[#Int#];
 // IN_FOR_EACH_4-NOT: after
-// IN_FOR_EACH_4: Decl[LocalVar]/Local/TypeRelation[Convertible]: arg[#Int#];
+// IN_FOR_EACH_4: Decl[LocalVar]/Local: arg[#Int#];


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 · 2020-06-05T16:45:57Z

@swift-ci Please smoke test

For example for: funcName(base.<HERE>) Wrap 'base' with 'CodeCompletionExpr' so that type checker can check 'base' independently without preventing the overload choice of 'funcName'. This increases the chance of successful type checking. rdar://problem/63965160

rintaro · 2020-06-05T23:01:13Z

@swift-ci Please smoke test

rintaro · 2020-06-05T23:29:30Z

Decided not to default it to UnresolvedType for now.

xedin

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

rintaro force-pushed the ide-completion-rdar63965160 branch from c510db9 to f67c1b5 Compare June 4, 2020 17:47

rintaro requested a review from xedin June 4, 2020 17:47

rintaro commented Jun 4, 2020

View reviewed changes

rintaro requested a review from benlangmuir June 4, 2020 18:21

benlangmuir reviewed Jun 4, 2020

View reviewed changes

rintaro force-pushed the ide-completion-rdar63965160 branch from f67c1b5 to 0ed063d Compare June 5, 2020 16:06

rintaro commented Jun 5, 2020

View reviewed changes

rintaro force-pushed the ide-completion-rdar63965160 branch from 0ed063d to 12493c6 Compare June 5, 2020 16:38

rintaro commented Jun 5, 2020

View reviewed changes

xedin approved these changes Jun 5, 2020

View reviewed changes

rintaro mentioned this pull request Jun 5, 2020

[5.3][CodeCompletion] Wrap base expression with CodeCompletionExpr #32207

Merged

rintaro force-pushed the ide-completion-rdar63965160 branch from 12493c6 to 3ec250f Compare June 5, 2020 23:00

xedin approved these changes Jun 10, 2020

View reviewed changes

rintaro merged commit 4205e46 into swiftlang:master Jun 10, 2020

[CodeCompletion] Wrap base expression with CodeCompletionExpr #32184

[CodeCompletion] Wrap base expression with CodeCompletionExpr #32184

Uh oh!

Conversation

rintaro commented Jun 4, 2020

Uh oh!

rintaro commented Jun 4, 2020

Uh oh!

rintaro commented Jun 4, 2020

Uh oh!

rintaro Jun 4, 2020

Choose a reason for hiding this comment

Uh oh!

benlangmuir Jun 4, 2020

Choose a reason for hiding this comment

Uh oh!

rintaro Jun 4, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

benlangmuir Jun 4, 2020

Choose a reason for hiding this comment

Uh oh!

xedin Jun 4, 2020

Choose a reason for hiding this comment

Uh oh!

xedin Jun 4, 2020

Choose a reason for hiding this comment

Uh oh!

benlangmuir left a comment

Choose a reason for hiding this comment

Uh oh!

benlangmuir Jun 4, 2020

Choose a reason for hiding this comment

Uh oh!

rintaro commented Jun 5, 2020

Uh oh!

rintaro Jun 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rintaro Jun 5, 2020

Choose a reason for hiding this comment

Uh oh!

rintaro commented Jun 5, 2020

Uh oh!

rintaro commented Jun 5, 2020

Uh oh!

rintaro commented Jun 5, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xedin left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rintaro Jun 4, 2020 •

edited

Loading

rintaro Jun 5, 2020 •

edited

Loading

rintaro commented Jun 5, 2020 •

edited

Loading