Skip to content

fix: avoid double_must_use in macro-generated code - #17547

Merged
blyxyas merged 2 commits into
rust-lang:masterfrom
saberoueslati:fix/double-must-use-macro-expansion
Aug 19, 2026
Merged

blyxyas merged 2 commits into
rust-lang:masterfrom
saberoueslati:fix/double-must-use-macro-expansion

Conversation

@saberoueslati

@saberoueslati saberoueslati commented Aug 11, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #17529

double_must_use and must_use_unit now ignore #[must_use] attributes generated by macro expansion, while continuing to lint user-written attributes passed through procedural macros.

changelog: [double_must_use]: Fixed false positives from macro-generated #[must_use] attributes.

@rustbot rustbot added S-waiting-on-community-reviews Status: This is awaiting for positive reviews from the community before a maintainer is assigned. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Aug 11, 2026
@rustbot

rustbot commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the pull request. A reviewer will take a look after it receives 2 community reviews.

In the meantime, we would highly appreciate if you could try to review any of PRs waiting on community reviews.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@blyxyas blyxyas left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a bit of a nit to make the new auxiliary function more robust, everything else is looking great!

View changes since this review

Comment thread tests/ui/auxiliary/proc_macro_attr.rs
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Aug 13, 2026
@rustbot

rustbot commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@saberoueslati

Copy link
Copy Markdown
Contributor Author

@rustbot ready

@rustbot 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 from the author. (Use `@rustbot ready` to update this status) labels Aug 18, 2026
@saberoueslati
saberoueslati requested a review from blyxyas August 18, 2026 01:00

@blyxyas blyxyas left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for addressing this issue! ❤️ ฅ•ω•ฅ

View changes since this review

@blyxyas
blyxyas added this pull request to the merge queue Aug 19, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Aug 19, 2026
@saberoueslati

Copy link
Copy Markdown
Contributor Author

@blyxyas should I correct the CI issue that stopped the merge ?

@blyxyas
blyxyas added this pull request to the merge queue Aug 19, 2026
@blyxyas

blyxyas commented Aug 19, 2026

Copy link
Copy Markdown
Member

@blyxyas should I correct the CI issue that stopped the merge ?

It was a spurious network issue. We'll re-try

Merged via the queue into rust-lang:master with commit bdce5b9 Aug 19, 2026
11 checks passed
@rustbot rustbot removed S-waiting-on-community-reviews Status: This is awaiting for positive reviews from the community before a maintainer is assigned. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Aug 19, 2026
@cschramm

cschramm commented Sep 3, 2026

Copy link
Copy Markdown

@rustbot label +beta-nominated

@rustbot rustbot added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 3, 2026
@blyxyas

blyxyas commented Sep 3, 2026

Copy link
Copy Markdown
Member

@cschramm what's the reason for the beta nomination? Are you encountering a specially-awful occurrence of this bug?
(ㅇㅅㅇ❀)

@cschramm

cschramm commented Sep 3, 2026

Copy link
Copy Markdown

It depends on what you consider especially awful, but for any code base with reasonable usage of e.g. async-trait and double_must_use on deny (-D clippy::all in my case), it means that 1.99.0 will come with a regression. You'll be forced to either weaken your checks or to ban 1.99.0 from your toolchain.

@cschramm

Copy link
Copy Markdown

@rustbot label -beta-nominated

Disregard. async-trait already resolved this in 0.1.92, released 2026-08-08 and I'm not aware of other such popular crates that are affected.

@rustbot rustbot removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 21, 2026
shingonoide added a commit to BarraDev/slashit that referenced this pull request Oct 1, 2026
## Why

CI selected the floating `stable` channel. When stable moved from 1.98.1
to 1.99.0, `cargo clippy ... -D warnings` started failing on unchanged
`main` with `clippy::double_must_use` on the `#[async_trait]` expansion
of `ExecutionOwnership` (`src-tauri/src/lifecycle.rs`). That is a Clippy
false positive on macro-generated code (rust-lang/rust-clippy#17529),
fixed by rust-lang/rust-clippy#17547 and present in 1.100 beta/nightly,
but not in any stable release yet.

## What

- Add `rust-toolchain.toml` (channel `1.98.1`, profile `minimal`) as the
only place the Rust version is declared. rustup applies it to every
`cargo`/`rustc` run in a checkout: local, agent workspaces, CI and
release.
- Replace the five `dtolnay/rust-toolchain` uses in `ci.yml` and
`release.yml` with `rustup toolchain install --no-self-update`, run
after checkout so the file is honored. No version literal in the
workflows.
- Components and targets stay job-specific: `clippy` in the lint job,
`wasm32-unknown-unknown` where `trunk build` runs, the macOS release
targets on macOS only.
- Docs: Rust is pinned by `rust-toolchain.toml`; developers add
`clippy`/`rustfmt` themselves.

## Behavior of the removed action

- `CARGO_INCREMENTAL=0`: still set by `Swatinem/rust-cache` in every job
that uses it; release builds are not incremental.
- `rustup default`, `CARGO_HOME`, rustup bootstrap, sparse-registry and
curl workarounds: unnecessary on current runners (rustup 1.29.x
preinstalled on ubuntu-22.04, Windows 2025 and macOS 26).
- `CARGO_TERM_COLOR=always`: cosmetic only, dropped.

## Not in this PR

No `rust-version` in `Cargo.toml` (this is a toolchain pin, not an
MSRV), no `#[allow(clippy::double_must_use)]`, no move to 1.99. A later
bump should target the first stable release containing the Clippy fix
and address its new warnings (1.100 beta reports four unused-dependency
warnings).

## Validation

With Rust 1.98.1 selected only by the file: the exact CI Clippy command,
the acceptance-harness Clippy command and the CI test commands pass.
Rust 1.99.0 fails the Clippy command on unchanged `main`; 1.98.1 passes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[double_must_use] False positives from macro expansion?

4 participants