rustfmt: Import sorting does not handle uppercase/lowercase consistently
This may be related to https://github.com/rust-lang/rustfmt/issues/4648 , but I don’t know if it’s the same issue.
rustfmt sorts imports, and braced groups within imports, in the following order:
use a;
use aA;
use aa;
use Aa;
use WoRD;
use Word;
use A;
use AA;
use WORD;
use brace_group_sort_test::{a, aA, aa, Aa, WoRD, Word, A, AA, WORD};
This isn’t alphabetical, ASCIIbetical, or any other sort order that I can identify.
The style guide says to sort ascii-betically here, in both cases (top-level and within braced lists).
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 18 (13 by maintainers)
@calebcartwright I do understand that rustfmt has to be cautious about introducing changes that will cause churn. If rustfmt were sorting in a plausible order that just disagreed with the style guide, I would absolutely suggest we keep that until an edition boundary or similar, to avoid churn. However, in this case, it seems like this is producing an unpredictable order that people can’t easily replicate, and I think this may be close enough to a bugfix to be worth considering.
(That’s separate from any future changes to do version-sorting or similar, which I’d love to see but which does seem like 2.0 material.)
This won’t arise in every import list, and in the ones where it does arise, I think the inconsistency and inability for a human to produce the same order as rustfmt before running rustfmt provide a sufficiently compelling motivation for this change.
That said, I also acknowledge that any such change will incur a cost, even if we think that cost is worthwhile. And whether or not this can be fixed in rustfmt 1, I’d still like to see it fixed in the next generation.
I’m marking this as a p-high, as I’d really like to get
imports_granularitystabilized, with at least a few of the variants stabilized (IIRC one or two may not be ready due to bugs/relative nascency).@yaahc - this could potentially be a pretty gnarly one, but also potentially a decent one if you wanted to hack on the rustfmt codebase a little.
Subsequent to some of my prior comments, @ytmimi has developed some really sweet automation that we can use to evaluate changes for idempotency across multiple codebases (kinda like our own mini formatting crater run) that helps reduce the review burden of having to mentally conjure potential formatting impacts
It looks like #1785 was the PR that introduced this change.
Thanks for the report!
Confirming that I’m able to reproduce this on
rustfmt 1.4.38-nightly (b4de150d 2022-03-12). I’ll try to set aside some time later to look a little deeper into this.