-
Notifications
You must be signed in to change notification settings - Fork 893
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
repair Ord for UseSegment #6375
Conversation
@ajewellamz Thanks for looking into this! Can you briefly explain how your fix addresses the issue? |
In the example above, the problem was that (A, C) was compared with the special case logic, but (A,B) and (B,C) were not. This is why the comparison operator was not transitive. That is, segments that began with a character that was neither Said another way, A was CamelCase when compared to C but snake_case when compared to B. Switching from |
So it was mostly an issue with special characters like |
If all segments start with a letter, then there is no change. If there is a segment that does not start with a letter, then the current behavior is indeterminate, and often results in a panic! (because Ord is not transitive) so we need a change. Yes, it has the potential to change the current sort behavior, but with the current code, running rustfmt in a slightly different context also has potential to change the current sort behavior. |
So.... is there something more I can do? |
Could you elaborate on which cases would potentially be changed? Also, what do you mean when you say running rustfmt in different contexts could change things?
Adding a test case would be great. Especially if you can think of cases where the new sort behavior differs from what we used to have. You can add a new test case by creating a |
If there are segments that don't begin with a letter, the current behavior is undefined, because the comparator is not transitive. This is what I mean by "could change", and why rustfmt will panic on some input, like that in #6333 I haven't found a case where rustfmt produces unexpected results but doesn't crash. I've added tests/target/issue-6333.rs, but I might be confused about something, because |
You may need to add a config comment to the top of your test file to specify |
We changed the sort order in |
Even with |
Can you try running |
Thanks. With |
tests/target/issue-6333.rs
Outdated
@@ -0,0 +1,22 @@ | |||
pub use crate::r#_StructUtil_Compile::CanonCryptoItem; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would probably be useful to add the // rustfmt-style_edition: 2015
comment to the start of the file. Also, it might be useful to include a separate test for // rustfmt-style_edition: 2024
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
Fixes #6333
Ord for UseSegment was not Transitive, causing
user-provided comparison function does not correctly implement a total order
panic.e.g. for
let A = DafnyType
let B = _System
let C = truncate
A < B
B < C
but
A > C