Arbitrary self types v2: no deshadow pre feature. #134524
Conversation
The arbitrary self types v2 work introduces a check for shadowed methods, whereby a method in some "outer" smart pointer type may called in preference to a method in the inner referent. This is bad if the outer pointer adds a method later, as it may change behavior, so we ensure we error in this circumstance. It was intended that this new shadowing detection system only comes into play for users who enable the `arbitrary_self_types` feature (or of course everyone later if it's stabilized). It was believed that the new deshadowing code couldn't be reached without building the custom smart pointers that `arbitrary_self_types` enables, and therefore there was no risk of this code impacting existing users. However, it turns out that cunning use of `Pin::get_ref` can cause this type of shadowing error to be emitted now. This commit adds a test for this case. As we want this test to pass without arbitrary_self_types, but fail with it, I've split it into two files (one with run-pass and one without). If there's a better way I can amend it.
rustbot
added
S-waiting-on-review
| // as we don't enable arbitrary self types. | ||
| // This will turn into an error if arbitrary_self_types feature is enabled. | ||
|
|
||
| //@ run-pass |
There was a problem hiding this comment.
This doesn't need to be run pass if it's not exercising any runtime behavior.
Also you should use revisions rather than making two tests.
There was a problem hiding this comment.
I couldn't figure out how to do that. This is what I know how to do:
//@ revisions: default feature
#![cfg_attr(feature, feature(arbitrary_self_types))]but I want it to compile in one case, and not in the other. Even without the //@ run-pass it still complains at me unless both revisions emit a compile error. Can you advise?
There was a problem hiding this comment.
it should be //@[feature] check-pass
and check-pass since as i said above you're not exercising runtime behavior
| let pinned_a: Pin<&mut A> = pin!(A); | ||
| let pinned_a: Pin<&A> = pinned_a.as_ref(); | ||
| let _ = pinned_a.get_ref(); | ||
| //~^ ERROR: multiple applicable items |
There was a problem hiding this comment.
I don't want to hold up this PR because adding the feature gate check is absolutely necessary as the other test case shows, but what is the plan for stabilizing the feature with regards to this check?
We can't just report this error when the feature is stabilized because that could break existing code. If we need to log an unresolved question for this, that's fine!
The arbitrary self types v2 work introduces a check for shadowed methods, whereby a method in some "outer" smart pointer type may called in preference to a method in the inner referent. This is bad if the outer pointer adds a method later, as it may change behavior, so we ensure we error in this circumstance.
It was intended that this new shadowing detection system only comes into play for users who enable the
arbitrary_self_typesfeature (or of course everyone later if it's stabilized). It was believed that the new deshadowing code couldn't be reached without building the custom smart pointers thatarbitrary_self_typesenables, and therefore there was no risk of this code impacting existing users.However, it turns out that cunning use of
Pin::get_refcan cause this type of shadowing error to be emitted now. This commit adds a test for this case.As we want this test to pass without arbitrary_self_types, but fail with it, I've split it into two files (one with run-pass and one without). If there's a better way I can amend it.
Part of #44874
r? @wesleywiser