GenericArgs::types triage + possible fixes - #159899
Open
LorrensP-2158466 wants to merge 3 commits into
Open
Conversation
rustbot
added
A-LLVM
Contributor
Author
|
Don't know what tests can/will fail, so i'll see what a CI run says and go from there. |
rustbot
added
A-CI
LorrensP-2158466
force-pushed
the
generic_args_terms
branch
2 times, most recently
from
July 25, 2026 16:36
a16db39 to
ea9f31c
Compare
Contributor
Author
|
This is all of the list posted in #t-types/call-for-participation > `args.types()` triage and fixes expect 2, both seem to be a bit harder to fix (to me at least:).
ping @lcnr |
LorrensP-2158466
marked this pull request as ready for review
July 27, 2026 10:42
rustbot
added
the
S-waiting-on-review
Collaborator
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt
cc @rust-lang/clippy Some changes occurred in need_type_info.rs cc @lcnr |
rustbot
removed
the
S-waiting-on-author
Collaborator
|
r? @chenyukang rustbot has assigned @chenyukang. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
- be explicit when only needing types of `GenericArgs`
LorrensP-2158466
force-pushed
the
generic_args_terms
branch
from
July 27, 2026 12:08
26018f7 to
043bfcc
Compare
| && matches!(cx.tcx.get_diagnostic_name(adt_def.did()), Some(sym::Rc | sym::Arc)) | ||
| { | ||
| args.types().next() == Some(parent_ty) | ||
| args.iter().filter_map(ty::GenericArg::as_type).nth(0) == Some(parent_ty) |
Contributor
Author
There was a problem hiding this comment.
From @lcnr in the zulip discussion:
yeah, the fact that accessing just types is often vaguely wrong and doesn't allow for random access, so doing iter().filter_map(GenericArg::as_type).nth(1) is beter for that
Contributor
There was a problem hiding this comment.
that can just be next().as_type() 🤔
Member
|
is it this PR still in WIP? |
LorrensP-2158466
changed the title
GenericArgs::types triage + possible fixesGenericArgs::types triage + possible fixes
lcnr
reviewed
Aug 6, 2026
| fn get_ty_param(ty: Ty<'_>) -> Option<Ty<'_>> { | ||
| if let ty::Adt(_, subs) = ty.kind() { | ||
| subs.types().next() | ||
| subs.iter().filter_map(ty::GenericArg::as_type).nth(0) |
Contributor
There was a problem hiding this comment.
subs.iter().filter_map(ty::GenericArg::as_type).next() .nth(0) is always worse than next 🤔
Contributor
Author
There was a problem hiding this comment.
so iter().next().as_type(), gotcha.
khyperia
reviewed
Aug 7, 2026
Member
There was a problem hiding this comment.
nice, thanks! lcnr asked me to take a peek.
I have a vague preference for .iter().nth(N).and_then(ty::GenericArg::as_type) over .iter().filter_map(ty::GenericArg::as_type).nth(N) when fetching the Nth type arg of a known type (the latter gives me spidey sense tingles around weird indexing, even though they're both equivalent since there's only type args for these known types), but that's an opinion that you're free to disregard~
| }, | ||
| // FIXME: check const parameters better as well. Currently this will consider `Array<5>` the same as | ||
| // `Array<6>` | ||
| (ty::TermKind::Const(c1), ty::TermKind::Const(c2)) if c1 == c2 => todo!(), |
Member
There was a problem hiding this comment.
there's a todo!() here - probably should either keep the old behavior of considering all consts to be equal, or properly implement this, instead of panicing~
(today I learned that tidy doesn't run on src/tools/clippy, todo!() is banned by tidy)
Contributor
Author
There was a problem hiding this comment.
Yeah, I meant to ask a follow up question on this.
Consts are interned as well, right? But are there cases where they are not the same "const" but are still the same? Otherwise this can just return true indeed.
(today I learned that tidy doesn't run on src/tools/clippy, todo!() is banned by tidy)
Yeah me to :D.
Contributor
Author
There was a problem hiding this comment.
I changed it to => true for now.
Member
There was a problem hiding this comment.
For purposes of this real wonky function, yeah, consts can contain params. IMO, drop the guard, just have (ty::TermKind::Const(c1), ty::TermKind::Const(c2)) => (), to retain the old behavior, with the old comment. This function is only called in clippy::transmute_undefined_repr, which "has had multiple problems in the past and was moved to nursery" rust-lang/rust-clippy#8496 so preserving whatever wonky behavior it has for now seems best. (Hypothesizing a future fix, this should probably be a type relation or somesuch rather than doing a wonky custom relation on just ADTs? I mean, properly, I think maybe it should be doing a trait solver .eq() and checking if there's a solution. Idk.)
(Also, shouldn't return true but rather continue to the next term)
Contributor
Author
I can get behind why this is better in the case of a known type. I'll change them. |
Contributor
Author
|
So i went with the recommendation of lcnr, doing @rustbot ready. |
This comment has been minimized.
This comment has been minimized.
Contributor
Author
|
@rustbot author |
rustbot
removed
the
S-waiting-on-review
Collaborator
|
Reminder, once the PR becomes ready for a review, use |
rustbot
added
the
S-waiting-on-author
khyperia
reviewed
Aug 10, 2026
| fn get_ty_param(ty: Ty<'_>) -> Option<Ty<'_>> { | ||
| if let ty::Adt(_, subs) = ty.kind() { | ||
| subs.types().next() | ||
| subs.iter().next().and_then(ty::GenericArg::as_type) |
Member
There was a problem hiding this comment.
could do subs.iter().next()?.as_type() in a few of these places, but whatever, that's a style choice, I don't care :P
Contributor
Author
There was a problem hiding this comment.
I mean, why not :D? It does look cleaner.
Contributor
Author
There was a problem hiding this comment.
Oh, I just now noticed that using types() is actually correct here.
it is also used on the Cow<'a, T> type, and the first parameter is the lifetime. That's why the filter_map is correct here and that this new change cause a ci job to fail.
Contributor
Author
|
@rustbot ready |
rustbot
added
S-waiting-on-review
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot)Important For more information how to resolve CI failures of this job, visit this link. |
Contributor
|
☔ The latest upstream changes (presumably #161031) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
View all comments
cc #t-types/call-for-participation > `args.types()` triage and fixes