presence of lint attributes changes const block formatting
Open
Nobody has claimed this yet.
A-attributes
A-const-blocks
C-bug
- Dominant language
- Rust
- Stars
- 7k
- Forks
- 1.1k
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 24
Description
If I ask cargo fmt from 1.81.0 to format this code, I get:
const COUNT: u8 = 5;
pub struct Thing;
impl Thing {
pub fn set() {
#[allow(clippy::assertions_on_constants)]
const {
assert!(COUNT == 5)
};
}
}
Under 1.80.0 I get:
const COUNT: u8 = 5;
pub struct Thing;
impl Thing {
pub fn set() {
#[allow(clippy::assertions_on_constants)]
const { assert!(COUNT == 5) };
}
}
Weirdly, if I remove the lint attribute, then both 1.81.0 and 1.80.0 format the const block on a single line.
I'm on Ubuntu 22.04, with no rustfmt.toml and the rustfmt versions are:
$ .rustup/toolchains/1.80.0-x86_64-unknown-linux-gnu/bin/rustfmt -V
rustfmt 1.7.0-stable (0514789 2024-07-21)
$ .rustup/toolchains/1.81.0-x86_64-unknown-linux-gnu/bin/rustfmt -V
rustfmt 1.7.1-stable (eeb90cd 2024-09-04)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the example with rustfmt 1.7.0 and 1.7.1 on the provided Rust code, comparing output with and without the lint attribute. Trace the formatting path for attributed const blocks and add a regression test showing the expected stable formatting across these cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100