-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement consecutive shorthand projections (associated type paths) like T::AssocA::AssocB
#126651
base: master
Are you sure you want to change the base?
Conversation
T::AssocA::AssocB
T::AssocA::AssocB
T::AssocA::AssocB
T::AssocA::AssocB
This comment has been minimized.
This comment has been minimized.
99bfdeb
to
6fc5c3c
Compare
Res::SelfTyParam { trait_: param_def_id } | ||
| Res::Def(DefKind::TyParam, param_def_id), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated: are there ever cases where we have a ty::Param
with a different res? and if so, do we want to support them? we can go from the index of the param to its def_id after all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self params dont resolve to DefKind::TyParam, they resolve to the trait defid and DefKind::Trait iirc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually wait im blind thats SelfTyParam already
// FIXME(fmease): Add UI tests for `feature(more_qualified_paths)` (e.g., `T::A::B { … }`). | ||
(ty::Alias(ty::Projection, alias_ty), _res) => { | ||
// FIXME: Double-check that this doesn't lead to any unwanted cycle errors. | ||
let predicates = tcx.item_bounds(alias_ty.def_id).instantiate(tcx, alias_ty.args); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this cycle for
trait Foo {
type FooAssoc;
}
trait Bar<T> {}
trait Trait {
type Assoc: Foo + Bar<Self::Assoc::FooAssoc>;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it does. I guess there's no way around introducing a specialized variant of item_bounds
if at all possible (well, HIR ty lowering is notorious for following such an approach).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that may work 🤔 an easier alternative may be to forbid the consecutive shorthand in item bounds and super traits. It's not great, but it does avoid the issue
// FIXME(fmease): | ||
// Should we require the pre-lowered projectee (the HIR QSelf) to be a `Res::Def(DefKind::AssocTy, _)`? | ||
// Rephrased, should we flat out reject `Identity<T::Assoc>::Assoc` even if `T::Assoc::Assoc` typeck's? | ||
// For comparison, `Identity<T>::Assoc` gets rejected even if `T::Assoc` passes typeck. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, so wrt to my first comment, this is about non-lazy type aliases?
I would expect that this would then break with lazy type aliases unless we explicitly normalize them here. Because of that I feel like we should restrict it based on the res?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm referring to eager type aliases here. Makes sense to restrict them to have parity with lazy type aliases +1.
As mentioned by in me in one of the source code comments, that's gonna be a bit of a pain to impl because Res
is actually Err
in this scenario right now but let's see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned by in me in one of the source code comments, that's gonna be a bit of pain to impl because
Res
is actuallyErr
in this scenario right now but let's see.
that's something that has annoyed me for years and should ideally be changed/fixed regardless imo, has also recently affected @camelid's work on const generics iirc?
6fc5c3c
to
ed8def2
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Implement consecutive shorthand projections (associated type paths) like `T::AssocA::AssocB` I'd like to resolve / get feedback on the `FIXME` concerning "`Identity<T::Assoc>::Assoc`". Then I'll polish up this PR and make it ready for a types FCP (i.e., tests, tests, tests). Addresses rust-lang#126360 (comment). CC rust-lang#22519 (arbitrary shorthand projections).
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (2084985): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -2.1%, secondary -2.9%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -3.9%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 695.82s -> 696.616s (0.11%) |
c81ea1f
to
d56708a
Compare
This comment was marked as resolved.
This comment was marked as resolved.
d56708a
to
0664285
Compare
☔ The latest upstream changes (presumably #130674) made this pull request unmergeable. Please resolve the merge conflicts. |
Addresses #126360 (comment).
CC #22519 (arbitrary shorthand projections).
FIXME:
tests/ui/coroutine/coroutine-in-orphaned-anon-const.rs
(I'm stumped atm)Def::TypeDependent
"