[IDE] Resolve [.]Type completion for (any P). to produce singleton metatype instead of existential metatype.

[Rajveer100]

Resolves #65843

The type completion for (any P). is a singleton meta type which currently falsely produces any P., i.e, an existential meta type.

[Rajveer100]

@AnthonyLatsis
Could you trigger the CI to see if it breaks other tests?

[AnthonyLatsis]

@swift-ci please smoke test Linux

[Rajveer100]

Currently IDE/complete_value_expr.swift test fails. Would the following also be considered a singleton meta type:

protocol ExistentialProto {
  static func staticMethod()
  func instanceMethod()
}

func testExistential() {
  let _ = ExistentialProto.#^PROTOCOLTYPE_DOT_1^#
// PROTOCOLTYPE_DOT_1: Begin completions, 3 items
// PROTOCOLTYPE_DOT_1-DAG: Keyword[self]/CurrNominal:          self[#(any ExistentialProto).Type#]; name=self
// PROTOCOLTYPE_DOT_1-DAG: Keyword/CurrNominal:                Protocol[#(any ExistentialProto).Type#]; name=Protocol
// PROTOCOLTYPE_DOT_1-DAG: Keyword/CurrNominal:                Type[#any ExistentialProto.Type#]; name=Type

[AnthonyLatsis]

What are your thoughts on these three completions: Does either look incorrect to you? If so, why?

[Rajveer100]

I think according to my changes since we are checking the canonical type to be ExistentialMetatypeType, the completion should be Type[#(any ExistentialProto).Type#]

[AnthonyLatsis]

P.Type is equivalent to any P.Type.

I think accordingly my changes since we are checking the canonical type to be ExistentialMetatypeType

According to this logic, the result of appending .Type is:

• An existential metatype if the type we are completing is also an existential metatype. This is not true: appending .Type to (any P.Type), which is an existential metatype, produces the singleton metatype (any P.Type).Type.
• A singleton metatype otherwise. This is also not true: appending .Type to any P, which is not an existential metatype, produces the existential metatype any P.Type.

[Rajveer100]

At the moment, the expected output as per my logic is Type[#(any ExistentialProto).Type#] which obviously fails. What I meant to say is, if the test is right, i.e, it's an existential meta type, the canonical type parameter which I added to the conditional check should succeed yielding the result.

[AnthonyLatsis]

#65843 (comment)

[Rajveer100]

In terms of the implementation, I feel like the syntactic sugar for parenthesis, i.e (...) affects the outcome although the canonical type is correctly parsed for the AST?

[AnthonyLatsis]

What do you mean by outcome, and what type are you referring to?

[Rajveer100]

With the latest changes, the test passes.

[AnthonyLatsis]

Please check that other IDE tests pass too.

[Rajveer100]

All tests pass:

Testing Time: 40.10s
  Excluded         : 9854
  Unsupported      :    6
  Passed           :  480
  Expectedly Failed:    1

2 warning(s) in tests

[AnthonyLatsis]

@swift-ci please smoke test Linux

[Rajveer100]

@AnthonyLatsis
Are there any other changes needed?

[AnthonyLatsis]

Please add a test for (P).. P.Type == (P).Type, so the completion should be an existential metatype. I will try to find a better place for these tests in the meantime. Issue-specific test files are more of a last resort in organizing tests.

[AnthonyLatsis]

Sorry, I accidentally truncated my reply. I meant the test case to be (P), not P.Type, etc.

[Rajveer100]

Ok.

[Rajveer100]

This test currently fails as expected, since the paren sugar check would work for (any P). and not for (P)..

[AnthonyLatsis]

Yeah, this is the right direction. But there really is no guarantee that the semantic type will retain the parentheses. A better option is to check the parsed type representation, which is meant to preserve the structure of the written type. You can get it from the type expression.

[Rajveer100]

Wouldn't this check ensure that?

if (isa<TypeExpr>(ParsedExpr)) {
  // ...
}

[AnthonyLatsis]

I think you misunderstand. I am suggesting to check for parentheses in the type representation as opposed to the semantic type. The type representation is stored in the type expression.

[Rajveer100]

The type representation doesn't actually have a function for checking this, rather has a function to retrieve the expression without the parenthesis, do we want to introduce this?

[AnthonyLatsis]

I think the existing function is optimal here.