Strip TypeExpr of its TypeLoc #31253
Conversation
Remove duplication in the modeling of TypeExpr. The type of a TypeExpr node is always a metatype corresponding to the contextual type of the type it's referencing. For some reason, the instance type was also stored in this TypeLoc at random points in semantic analysis. Under the assumption that this instance type is always going to be the instance type of the contextual type of the expression, introduce a number of simplifications: 1) Explicit TypeExpr nodes must be created with a TypeRepr node 2) Implicit TypeExpr nodes must be created with a contextual type 3) The typing rules for implicit TypeExpr simply opens this type
Make it slightly easier to enforce the invariant that implicit TypeExpr nodes have a contextual type set.
|
@swift-ci test |
|
@swift-ci test source compatibility |
| @@ -116,7 +116,7 @@ _ = [Int!]() // expected-error {{'!' is not allowed here; perhaps '?' was intend | |||
| let _: [Int!] = [1] // expected-error {{'!' is not allowed here; perhaps '?' was intended?}}{{12-13=?}} | |||
| _ = Optional<Int!>(nil) // expected-error {{'!' is not allowed here; perhaps '?' was intended?}}{{17-18=?}} | |||
| let _: Optional<Int!> = nil // expected-error {{'!' is not allowed here; perhaps '?' was intended?}}{{20-21=?}} | |||
| _ = Int!?(0) // expected-error {{'!' is not allowed here; perhaps '?' was intended?}}{{8-9=?}} | |||
| _ = Int!?(0) // expected-error 3 {{'!' is not allowed here; perhaps '?' was intended?}}{{8-9=?}} | |||
There was a problem hiding this comment.
@xedin I don't know how concerned we are about this case, but it's triple-diagnosing because precheck and the solver are resolving the underlying type separately. The only thing stopping it from doing that before was that it was storing the instance type in the TypeLoc and using that to bypass type resolution.
There was a problem hiding this comment.
That's unfortunate but as far as I understand if we stop trying to lookup members in resolveDeclRefExpr this should no longer be a problem, is that correct?
There was a problem hiding this comment.
I bet that tackles one of them. The one in precheck was always suspicious because it relied on the order of validation. That leaves the only strictly necessary one: The one in the solver.
| // HACK: If there's not enough information in the constraint system, | ||
| // create a garbage base type to force it to diagnose | ||
| // this as an ambiguous expression. | ||
| typeExpr = TypeExpr::createImplicitHack(loc, ErrorType::get(ctx), ctx); |
There was a problem hiding this comment.
@DougGregor This seems... less than ideal. But I'm not sure what else to do about this case.
|
Build failed |
|
@swift-ci test |
|
@swift-ci test source compatibility |
|
@swift-ci test source compatibility Debug |
|
Build failed |
|
@swift-ci test Linux |
|
Debug compat died and release is unrelated. Will give it a try when the bots are in better shape |
| @@ -116,7 +116,7 @@ _ = [Int!]() // expected-error {{'!' is not allowed here; perhaps '?' was intend | |||
| let _: [Int!] = [1] // expected-error {{'!' is not allowed here; perhaps '?' was intended?}}{{12-13=?}} | |||
| _ = Optional<Int!>(nil) // expected-error {{'!' is not allowed here; perhaps '?' was intended?}}{{17-18=?}} | |||
| let _: Optional<Int!> = nil // expected-error {{'!' is not allowed here; perhaps '?' was intended?}}{{20-21=?}} | |||
| _ = Int!?(0) // expected-error {{'!' is not allowed here; perhaps '?' was intended?}}{{8-9=?}} | |||
| _ = Int!?(0) // expected-error 3 {{'!' is not allowed here; perhaps '?' was intended?}}{{8-9=?}} | |||
There was a problem hiding this comment.
That's unfortunate but as far as I understand if we stop trying to lookup members in resolveDeclRefExpr this should no longer be a problem, is that correct?
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci test Linux |
|
@swift-ci test |
|
⛵ |
Remove duplication in the modeling of TypeExpr. The type of a TypeExpr
node is always a metatype corresponding to the contextual
type of the type it's referencing. For some reason, the instance type
was also stored in this TypeLoc at random points in semantic analysis.
Under the assumption that this instance type is always going to be the
instance type of the contextual type of the expression, introduce
a number of simplifications:
This opens the door for the further removal of
TypeLocs fromExprnodes by replacing them with theTypeExprs.