wfcheck: name the item that discards an unused type parameter by Dnreikronos · Pull Request #161467 · rust-lang/rust

Dnreikronos · 2026-08-21T15:02:20Z

label was "T is named here, but is likely unused in the containing type". the "likely" is the part that bugs me. we can just go look, so now it does:

LL |     bar: Bar<T>,
   |              - `T` is named here, but `Bar` does not use it

while collecting the usage spans it holds on to the outermost thing that throws the argument away. adts are easy, bivariant param in variances_of. aliases have no variances so you expand them and see what's left, and my first version of that only looked for the param in the rhs, which is wrong. type Alias<T> = DropFirst<T, u8> mentions T and still drops it. so it walks the expansion skipping bivariant slots. (nested args blame the outer one, Bar<Vec<T>> points at Bar.) if it can't work out who's responsible it falls back to "this does not constrain T".

warning for whoever touches this next: type_of doesn't expand free aliases and you can't chase them yourself. type Recur<T> = Recur<(T,)> never repeats its args so there's nothing to stop on, stack goes. expand_free_alias_tys is the one with the limit. variance-overflow.rs has a comment at the top saying exactly this and i wrote it wrong anyway, so i stuck a case in there for the diagnostic path.

tests in variance-unused-type-param.rs, new file for alias chains.

there's a separate bug in the "only used recursively" branch right next to this one that i left alone, wrote up why in a comment.

Dnreikronos · 2026-08-21T16:07:17Z

on the "only used recursively" branch, since i kept almost fixing it and stopping.

it kicks in whenever the param is mentioned and the item turns out cyclical, but it only checks the item is on a cycle, never that the param goes round it. so

struct Bar<X> {}
struct Foo<T> { bar: Bar<T>, next: Option<Box<Foo<u8>>> }

blames bar: Bar<T> when the cycle is Foo<u8> and has nothing to do with T. beta does it too so it isn't from this pr.

what's here gives that code the piece it was missing, we now know which item discards each mention. but you can't just drop the discarded ones. with two mutually recursive structs the param is bivariant because of the cycle you're trying to confirm, so you'd throw out your own evidence. it has to follow param slots rather than defids. i had that working and it came out bigger than the fix in this pr, so i took it back out.

happy to do it as a follow up.

mejrs · 2026-08-26T23:39:29Z

This isn't something I'm familiar with.

r? @fmease maybe? or reroll?

fmease · 2026-09-20T15:16:47Z

+        for arg in args.args {
+            let hir::GenericArg::Type(ty) = arg else {
+                intravisit::walk_generic_arg(self, arg);
+                continue;
+            };
+            let outer = self.discarded_by;
+            if self.discarded_by.is_none() && self.discards_nth_ty_arg(def_id, nth_ty_arg) {
+                self.discarded_by = Some(def_id);
+            }
+            self.visit_ty(ty);
+            self.discarded_by = outer;
+            nth_ty_arg += 1;
+        }


All of this is so much checking for no practical benefit IINM. Re-querying the variances of ADTs in two separate places even just to double-check that the parameters are bivariant.

Can you come up with an example of any type expression that mentions an (unconstrained) bivariant type parameter but does not "use" it? Personally speaking I couldn't & I really tried. As soon as it's mentioned somewhere it's either used and thus not bivariant or unused & bivariant.

So what I'm saying is that we don't need to perform any of these complex checks. I would even accept a PR that just drops the word likely from … is named here, but is likely unused in the containing type but I guess "containing" is indeed a bit jargon-y. So just reword it to "… is named here, but is not used in the type that wraps it".

View changes since the review

To illustrate what I mean (maybe not needed): Let's assume we're looking at struct MainType<T> { ... }, we know that T is bivariant & unconstrained thus reaching report_bivariance & we're now trying to find usages of T in ....

Then what are the options? If we encounter Adt<..., T, ...> we know that it is not used¹ by Adt. Otherwise it wouldn't be bivariant or it would be constrained. Personally speaking, I don't consider constrained bivariant parameters to be used for the purposes of this diagnostic. In any case, we know that the requirement is not satisfied in MainType & that we emit an additional "trait bound unsatisfied" diagnostic which is probably more helpful in such situations anyway.

Etc. you get my point.

Footnotes

or only used recursively, of course. ↩

I've removed the wrapper tracking and alias traversal and restored the original span collector. I wanted to name the type that drops the parameter because I thought that would make the error easier to follow, especially through aliases. But by the time we reach report_bivariance, the caller has already ruled out parameters constrained by variance or associated-type equalities. We already know enough to say the parameter is unused without checking those paths again.

I don't think naming the wrapper adds enough here to justify all that extra code. Your wording, "is named here, but is not used in the type that wraps it", gets the point across and removes the uncertainty that bothered me in the original message. I've used that and updated the test expectations. All four relevant UI tests pass.

rustbot · 2026-09-22T14:54:11Z

⚠️ Warning ⚠️

This PR is based on an upstream commit that is older than 28 days.

It's recommended to update your branch according to the rustc-dev-guide.

Dnreikronos · 2026-09-25T13:17:17Z

@rustbot ready

fmease

Thanks for applying my feedback & for your patience!

@bors rollup
@bors r+ squash

View changes since this review

* Name the item that discards an unused type parameter E0392 pointed at the mention of the parameter with a label saying it "is likely unused in the containing type", which doesn't say much. It's unclear what the containing type is meant to be, and we hedge with "likely" even though we can just go look. Track the outermost item that throws the argument away while collecting the usage spans, and name it instead. For ADTs that's a bivariant parameter in `variances_of`. Type aliases have no variances of their own, so expand them and check whether the parameter reaches a position that constrains it -- an alias can mention the parameter and still discard it by handing it to something else that ignores it. Free aliases go through `expand_free_alias_tys` rather than `type_of`, since a diverging one would otherwise recurse forever. When none of that pins down a culprit, fall back to saying the mention doesn't constrain the parameter instead of guessing. * Cover free alias types in the unused type parameter error A chain of free aliases used to hide the item doing the discarding, and the same alias applied to different arguments has to be expanded twice or a use of the parameter goes missing. The overflow case is worth a test of its own: with a growing argument there's no repeated alias to spot the divergence with, so the recursion limit is the only thing that stops the walk. * Simplify the unused type parameter diagnostic Variance and associated-type constraints are checked before this diagnostic runs. Restore the span collector and use a definite label without identifying which wrapper discards the parameter. Update the diagnostic expectations and test comments accordingly.

rust-bors · 2026-10-01T13:12:38Z

🔨 3 commits were squashed into 7ede218.

rust-bors · 2026-10-01T13:12:39Z

📌 Commit 7ede218 has been approved by fmease

It is now in the queue for this repository.

…ame_discarding_item, r=fmease wfcheck: name the item that discards an unused type parameter fixes rust-lang#161365 label was "`T` is named here, but is likely unused in the containing type". the "likely" is the part that bugs me. we can just go look, so now it does: ``` LL | bar: Bar<T>, | - `T` is named here, but `Bar` does not use it ``` while collecting the usage spans it holds on to the outermost thing that throws the argument away. adts are easy, bivariant param in variances_of. aliases have no variances so you expand them and see what's left, and my first version of that only looked for the param in the rhs, which is wrong. `type Alias<T> = DropFirst<T, u8>` mentions T and still drops it. so it walks the expansion skipping bivariant slots. (nested args blame the outer one, `Bar<Vec<T>>` points at Bar.) if it can't work out who's responsible it falls back to "this does not constrain `T`". warning for whoever touches this next: type_of doesn't expand free aliases and you can't chase them yourself. `type Recur<T> = Recur<(T,)>` never repeats its args so there's nothing to stop on, stack goes. expand_free_alias_tys is the one with the limit. variance-overflow.rs has a comment at the top saying exactly this and i wrote it wrong anyway, so i stuck a case in there for the diagnostic path. tests in variance-unused-type-param.rs, new file for alias chains. there's a separate bug in the "only used recursively" branch right next to this one that i left alone, wrote up why in a comment.

…uwer Rollup of 9 pull requests Successful merges: - #163461 (Improve diagnostic deduplication) - #159021 (windows-gnu: enable native TLS) - #161467 (wfcheck: name the item that discards an unused type parameter) - #162618 (trait_selection: Preserve eager normalization failures) - #163064 (Avoid computing overflowed goal chains for crate dependencies) - #163360 ([rustdoc] Correctly handle rustc_allow_incoherent_impl on primitive methods) - #163385 (GVN transmutes of Immediate::Uninit to Immediate::Uninit) - #163590 (Make `AllocatorNightly` less clever) - #163599 (Add union pattern reference change to relnotes)

…uwer Rollup of 20 pull requests Successful merges: - #163483 (Bump bootstrap compiler to 1.100.0 beta) - #161380 (only rerun const eval in next-solver if the const actually references opaques) - #162900 (Some refactorings around metadata encoding) - #163461 (Improve diagnostic deduplication) - #163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`) - #163584 ([triagebot] Ping me for debugger visualizer changes) - #159021 (windows-gnu: enable native TLS) - #161467 (wfcheck: name the item that discards an unused type parameter) - #162618 (trait_selection: Preserve eager normalization failures) - #162904 (Fix ICE for ambiguous candidates on method probing) - #163064 (Avoid computing overflowed goal chains for crate dependencies) - #163281 (Add `f16` inline ASM support to `spirv.rs`) - #163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`) - #163360 ([rustdoc] Correctly handle rustc_allow_incoherent_impl on primitive methods) - #163385 (GVN transmutes of Immediate::Uninit to Immediate::Uninit) - #163405 (Remove some #[linkage] options) - #163530 (`const impl PartialEq` for `f16b`) - #163581 (do not suggest precise capturing when the opaque span is in a macro expansion) - #163590 (Make `AllocatorNightly` less clever) - #163599 (Add union pattern reference change to relnotes)

Rollup merge of #161467 - Dnreikronos:wfcheck/unused_param_name_discarding_item, r=fmease wfcheck: name the item that discards an unused type parameter fixes #161365 label was "`T` is named here, but is likely unused in the containing type". the "likely" is the part that bugs me. we can just go look, so now it does: ``` LL | bar: Bar<T>, | - `T` is named here, but `Bar` does not use it ``` while collecting the usage spans it holds on to the outermost thing that throws the argument away. adts are easy, bivariant param in variances_of. aliases have no variances so you expand them and see what's left, and my first version of that only looked for the param in the rhs, which is wrong. `type Alias<T> = DropFirst<T, u8>` mentions T and still drops it. so it walks the expansion skipping bivariant slots. (nested args blame the outer one, `Bar<Vec<T>>` points at Bar.) if it can't work out who's responsible it falls back to "this does not constrain `T`". warning for whoever touches this next: type_of doesn't expand free aliases and you can't chase them yourself. `type Recur<T> = Recur<(T,)>` never repeats its args so there's nothing to stop on, stack goes. expand_free_alias_tys is the one with the limit. variance-overflow.rs has a comment at the top saying exactly this and i wrote it wrong anyway, so i stuck a case in there for the diagnostic path. tests in variance-unused-type-param.rs, new file for alias chains. there's a separate bug in the "only used recursively" branch right next to this one that i left alone, wrote up why in a comment.

…uwer Rollup of 20 pull requests Successful merges: - rust-lang/rust#163483 (Bump bootstrap compiler to 1.100.0 beta) - rust-lang/rust#161380 (only rerun const eval in next-solver if the const actually references opaques) - rust-lang/rust#162900 (Some refactorings around metadata encoding) - rust-lang/rust#163461 (Improve diagnostic deduplication) - rust-lang/rust#163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`) - rust-lang/rust#163584 ([triagebot] Ping me for debugger visualizer changes) - rust-lang/rust#159021 (windows-gnu: enable native TLS) - rust-lang/rust#161467 (wfcheck: name the item that discards an unused type parameter) - rust-lang/rust#162618 (trait_selection: Preserve eager normalization failures) - rust-lang/rust#162904 (Fix ICE for ambiguous candidates on method probing) - rust-lang/rust#163064 (Avoid computing overflowed goal chains for crate dependencies) - rust-lang/rust#163281 (Add `f16` inline ASM support to `spirv.rs`) - rust-lang/rust#163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`) - rust-lang/rust#163360 ([rustdoc] Correctly handle rustc_allow_incoherent_impl on primitive methods) - rust-lang/rust#163385 (GVN transmutes of Immediate::Uninit to Immediate::Uninit) - rust-lang/rust#163405 (Remove some #[linkage] options) - rust-lang/rust#163530 (`const impl PartialEq` for `f16b`) - rust-lang/rust#163581 (do not suggest precise capturing when the opaque span is in a macro expansion) - rust-lang/rust#163590 (Make `AllocatorNightly` less clever) - rust-lang/rust#163599 (Add union pattern reference change to relnotes)

…uwer Rollup of 20 pull requests Successful merges: - #163483 (Bump bootstrap compiler to 1.100.0 beta) - #161380 (only rerun const eval in next-solver if the const actually references opaques) - #162900 (Some refactorings around metadata encoding) - #163461 (Improve diagnostic deduplication) - #163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`) - #163584 ([triagebot] Ping me for debugger visualizer changes) - #159021 (windows-gnu: enable native TLS) - #161467 (wfcheck: name the item that discards an unused type parameter) - #162618 (trait_selection: Preserve eager normalization failures) - #162904 (Fix ICE for ambiguous candidates on method probing) - #163064 (Avoid computing overflowed goal chains for crate dependencies) - #163281 (Add `f16` inline ASM support to `spirv.rs`) - #163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`) - #163360 ([rustdoc] Correctly handle rustc_allow_incoherent_impl on primitive methods) - #163385 (GVN transmutes of Immediate::Uninit to Immediate::Uninit) - #163405 (Remove some #[linkage] options) - #163530 (`const impl PartialEq` for `f16b`) - #163581 (do not suggest precise capturing when the opaque span is in a macro expansion) - #163590 (Make `AllocatorNightly` less clever) - #163599 (Add union pattern reference change to relnotes)

…uwer Rollup of 20 pull requests Successful merges: - rust-lang/rust#163483 (Bump bootstrap compiler to 1.100.0 beta) - rust-lang/rust#161380 (only rerun const eval in next-solver if the const actually references opaques) - rust-lang/rust#162900 (Some refactorings around metadata encoding) - rust-lang/rust#163461 (Improve diagnostic deduplication) - rust-lang/rust#163580 (Provide better doc code example for `UnixDatagram::bind_addr` and `UnixListener::bind_addr`) - rust-lang/rust#163584 ([triagebot] Ping me for debugger visualizer changes) - rust-lang/rust#159021 (windows-gnu: enable native TLS) - rust-lang/rust#161467 (wfcheck: name the item that discards an unused type parameter) - rust-lang/rust#162618 (trait_selection: Preserve eager normalization failures) - rust-lang/rust#162904 (Fix ICE for ambiguous candidates on method probing) - rust-lang/rust#163064 (Avoid computing overflowed goal chains for crate dependencies) - rust-lang/rust#163281 (Add `f16` inline ASM support to `spirv.rs`) - rust-lang/rust#163314 (move `#[macro_export]` on declarative macro check to `rustc_attr_parsing`) - rust-lang/rust#163360 ([rustdoc] Correctly handle rustc_allow_incoherent_impl on primitive methods) - rust-lang/rust#163385 (GVN transmutes of Immediate::Uninit to Immediate::Uninit) - rust-lang/rust#163405 (Remove some #[linkage] options) - rust-lang/rust#163530 (`const impl PartialEq` for `f16b`) - rust-lang/rust#163581 (do not suggest precise capturing when the opaque span is in a macro expansion) - rust-lang/rust#163590 (Make `AllocatorNightly` less clever) - rust-lang/rust#163599 (Add union pattern reference change to relnotes)

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 21, 2026

Dnreikronos marked this pull request as ready for review August 21, 2026 16:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 21, 2026

rustbot assigned mejrs Aug 21, 2026

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 21, 2026

This comment was marked as outdated.

Sign in to view

Dnreikronos marked this pull request as draft August 21, 2026 16:07

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 21, 2026

Dnreikronos marked this pull request as ready for review August 21, 2026 17:20

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 21, 2026

rustbot assigned fmease and unassigned mejrs Aug 26, 2026

fmease reviewed Sep 20, 2026

View reviewed changes

fmease added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 20, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 25, 2026

fmease approved these changes Oct 1, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

rust-bors Bot force-pushed the wfcheck/unused_param_name_discarding_item branch from 5b6650e to 7ede218 Compare October 1, 2026 13:12

JonathanBrouwer mentioned this pull request Oct 1, 2026

Rollup of 9 pull requests #163605

Closed

JonathanBrouwer mentioned this pull request Oct 1, 2026

Rollup of 20 pull requests #163609

Merged

rust-bors Bot merged commit 5770588 into rust-lang:main Oct 2, 2026
14 checks passed

rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 2, 2026

rustbot added this to the 1.101.0 milestone Oct 2, 2026

Navigation Menu

Repository navigation

wfcheck: name the item that discards an unused type parameter - #161467

wfcheck: name the item that discards an unused type parameter#161467
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
Dnreikronos:wfcheck/unused_param_name_discarding_item

Dnreikronos commented Aug 21, 2026 •

edited

Loading

Uh oh!

This comment was marked as outdated.

Dnreikronos commented Aug 21, 2026

Uh oh!

mejrs commented Aug 26, 2026

Uh oh!

fmease Sep 20, 2026 •

edited by rustbot

Loading

Uh oh!

fmease Sep 20, 2026

Uh oh!

Dnreikronos Sep 22, 2026

Uh oh!

rustbot commented Sep 22, 2026

Uh oh!

Dnreikronos commented Sep 25, 2026

Uh oh!

fmease left a comment •

edited by rustbot

Loading

Uh oh!

This comment has been minimized.

rust-bors Bot commented Oct 1, 2026

Uh oh!

rust-bors Bot commented Oct 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

Dnreikronos commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

Dnreikronos commented Aug 21, 2026

Uh oh!

mejrs commented Aug 26, 2026

Uh oh!

fmease Sep 20, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Sep 20, 2026

Choose a reason for hiding this comment

Footnotes

Uh oh!

Dnreikronos Sep 22, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Sep 22, 2026

Uh oh!

Dnreikronos commented Sep 25, 2026

Uh oh!

fmease left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

rust-bors Bot commented Oct 1, 2026

Uh oh!

rust-bors Bot commented Oct 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Dnreikronos commented Aug 21, 2026 •

edited

Loading

fmease Sep 20, 2026 •

edited by rustbot

Loading

fmease left a comment •

edited by rustbot

Loading