Fix indexing constructors with generic parameters #65597
Conversation
|
@swift-ci please test |
|
the failure here is actually real, the problem is with nested types it moves the initializer to the parent type, which is wrong 😕 |
keith
force-pushed
the
ks/fix-indexing-constructors-with-generic-parameters
branch
from
89cc2ff to
00cf28a
Compare
| @@ -129,7 +129,7 @@ class GenCls<T> { | |||
| } | |||
|
|
|||
| func test2() { | |||
| // CHECK: <Class@[[@LINE-19]]:7>GenCls</Class><<iStruct@>Int</iStruct>>() | |||
| // CHECK: <Ctor@[[@LINE-17]]:3-Class@[[@LINE-19]]:7>GenCls</Ctor><<iStruct@>Int</iStruct>>() | |||
There was a problem hiding this comment.
this was wrong before for the same reason
|
fixed that failure with a new way to compute the correct location that seems to work in all cases |
|
@swift-ci please test |
|
this breaks the |
keith
force-pushed
the
ks/fix-indexing-constructors-with-generic-parameters
branch
from
00cf28a to
6ce9562
Compare
|
pushed a version w/ that new case fixed, and |
|
@swift-ci please test |
keith
force-pushed
the
ks/fix-indexing-constructors-with-generic-parameters
branch
from
6ce9562 to
c807ab8
Compare
|
@swift-ci please test |
|
I hope re-pushing cancels previously running tests 😬 |
It does (or more accurately, triggering the tests again cancels any previous runs) :) |
keith
force-pushed
the
ks/fix-indexing-constructors-with-generic-parameters
branch
from
c807ab8 to
9d2de8e
Compare
|
@swift-ci please test |
Previously in the case of a constructor like `A<Int>(value: 1)` `Fn->getLoc()` returned the location of `>(value: 1)` while the actual location we're looking for is correctly the start of `A<Int>(value: 1)`. This adjusts the location we're looking up to use the start location of the constructor instead. Fixes: swiftlang#54532
keith
force-pushed
the
ks/fix-indexing-constructors-with-generic-parameters
branch
from
9d2de8e to
9c42f7a
Compare
|
@swift-ci please test |
| if (auto *TE = dyn_cast<TypeExpr>(Ctor->getBase())) | ||
| CtorLoc = TE->getTypeRepr()->getWithoutParens()->getLoc(); |
There was a problem hiding this comment.
I think there may be some other TypeReprs that this doesn't quite handle correctly e.g X?(y), I believe the location in that case will be on the ?. That being said, I'm still happy to take this given it's a strict improvement over what we have currently. I've started looking into refactoring this so we can walk the references separately, which should avoid the need to do this.
There was a problem hiding this comment.
Hrm what's the scenario more specifically? this code:
protocol P {
init(value: Int)
}
func foo<T: P>(A: T.Type?) {
_ = A?(value: 0)
}Forces you to do A?.init so it ends up working fine
There was a problem hiding this comment.
I mean like this:
struct S {}
func foo(_ x: S) {
_ = S?(x)
}Optional has an init that takes the wrapped value
There was a problem hiding this comment.
ah yep, that case doesn't work you're right, i'll file that example
) Previously in the case of a constructor like `A<Int>(value: 1)` `Fn->getLoc()` returned the location of `>(value: 1)` while the actual location we're looking for is correctly the start of `A<Int>(value: 1)`. This adjusts the location we're looking up to use the start location of the constructor instead. Fixes: swiftlang#54532 (cherry picked from commit f5fbee2 / swiftlang#65597)
) Previously in the case of a constructor like `A<Int>(value: 1)` `Fn->getLoc()` returned the location of `>(value: 1)` while the actual location we're looking for is correctly the start of `A<Int>(value: 1)`. This adjusts the location we're looking up to use the start location of the constructor instead. Fixes: #54532 (cherry picked from commit f5fbee2 / #65597)
Previously in the case of a constructor like
A<Int>(value: 1)Fn->getLoc()returned the location of>(value: 1)while the actual location we're looking for is correctly the start ofA<Int>(value: 1). This adjusts the location we're looking up to use the start location of the constructor instead.Fixes: #54532