-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Show interior mutability chain in mutable_key_type
#13496
Conversation
r? @Alexendoo rustbot has assigned @Alexendoo. Use |
6d8812b
to
19d1358
Compare
span_lint_and_then(cx, MUTABLE_KEY_TYPE, span, "mutable key type", |diag| { | ||
for ty in chain.iter().rev() { | ||
diag.note(with_forced_trimmed_paths!(format!( | ||
"... because it contains `{ty}`, which has interior mutability" |
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.
Since type names can be quite long sometimes, wouldn't it be best to use …
instead of ...
here? In monospace font the difference would be two characters wide:
... because it contains `UnsafeCell<usize>`, which has interior mutability
… because it contains `UnsafeCell<usize>`, which has interior mutability
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.
I went with the three dots because I think it's much more common in diagnostics (in fact, I think I've never actually seen a non-ASCII character like that in a diagnostic - rust-lang/rust#126597 adds unicode block drawing but it requires an extra --error-format=human-unicode
).
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.
There is a "…" in a diagnostic issued by clippy_lints/src/methods/or_then_unwrap.rs
:
clippy_lints/src/methods/or_then_unwrap.rs
25: title = "found `.or(Some(…)).unwrap()`";
32: title = "found `.or(Ok(…)).unwrap()`";
👍
@bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Fixes #10619
Just ran into this myself and I definitely agree it's not very nice to have to manually go through all the types involved to figure out why this happens and to evaluate if this is really a problem (knowing if the field of a struct is something that a hash impl relies on), so this changes the lint to emit notes for each step involved.
changelog: none