-
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
Add missing_transmute_annotations
lint
#12239
Add missing_transmute_annotations
lint
#12239
Conversation
b1980d1
to
72d7430
Compare
missing_transmute_annotation
lintmissing_transmute_annotations
lint
And as usual I discover that there is already a |
#715?? Guillaume, that issue was open 8 years ago. Really going on a journey back inntime |
There's also #11047 for basically an identical lint, it's inactive though |
Which also provides type suggestions. Maybe I should add that. |
72d7430
to
6374508
Compare
Told you I was going through issues. :p I generally pick a random page and start taking a look there.
Didn't see that one. ^^' Oh well, since it's inactive I think it's fine. I added suggestions as well. |
I'll have to reroll this one, we are at Feb. 9 and I have practically no progress on performance (which is kinda really important), I've also set myself on vacation for this exact reason (I'd love to not have my busyness status in version control D:). r? rust-lang/clippy |
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.
Looks like a really nice lint to have! Implementation looks pretty good already. Not sure about the category and if we want to have it be warn-by-default though - that might deserve discussion :)
8a5b75a
to
e55f017
Compare
Applied suggestions. |
☔ The latest upstream changes (presumably #12040) made this pull request unmergeable. Please resolve the merge conflicts. |
f40a339
to
235c9f3
Compare
Updated, cleaned up the commit history as well and implemented the two limitations:
|
Anything else to be done here? |
last.ident.span.with_hi(path.span.hi()), | ||
"transmute used without annotations", | ||
"consider adding missing annotations", | ||
format!("{}::<{from_ty}, {to_ty}>", last.ident.as_str()), |
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.
If one/more of the types can be left inferred, can we keep it like that here? e.g., let _: T
.
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'd rather not.
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.
Why not? Is it because it'd require rewriting it? I don't see why this shouldn't be 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.
Maybe I misunderstood what you meant but this lint is about making it explicit what the transmute
types are (both input and output). So if we provide annotation for one of the two, better provide for both directly.
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.
What I meant was that, if it's within a let
statement for example, we could keep Dst
as _
. If it's better to provide both directly, and this is still an issue with let
, then we shouldn't special case let
at all, no?
I see what you mean that providing them is better, but special-casing it then not suggesting it is a bit contradictory.
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.
The idea behind my position is that if you ever remove the let
binding or change the type annotation, if we originally suggested both types, it'll prevent compilation and require user to check that the code is still valid. I think it's pretty important considering how easy it is to have unexpected behaviours with transmute
.
|
||
macro_rules! local_bad_transmute { | ||
($e:expr) => { | ||
std::mem::transmute($e) |
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.
Can you special case _
here in all macros? The type can't always be specified like this automatically
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.
In such cases, I think it means the macro should be rewritten instead of us dropping the level of detection.
if !missing_generic { | ||
return false; | ||
} | ||
// If it's being set as a local variable value... |
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.
We should include closures here imo, if they have type annotations. This could include the parameter if it's specified as well, but not something like:
// i64 is known, but [i32; 2] is never specified
|x: i32, y: i32| -> i64 unsafe { transmute::<[i32; 2], _>([x, y]) };
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 don't think we should special case closures either. It adds a lot of complexity to detect such cases for a very marginal gain imo.
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.
Not really. The return type part is easy, and the parameter is too - Get the Res
from the QPath
, the HirId
of the local, then the parent's parent should include the types in FnDecl
.
I wouldn't block it on this so if it's not done I can add it after, eventually.
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.
Not in this sense. I meant, for the same reason we want to enforce having type annotations when transmute
is used as return expr, we want to enforce for it for closures as well.
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 don't agree with that as closures are usually private and not public. It's more akin to let
than functions. I don't think you can fold a closure either in IDEs.
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 don't see why closures being private or public changes anything. If you want to bring this back to debate, let's continue on zulip. ;)
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'll bring up my current points on zulip sometime.
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 an open thread already, don't hesitate to comment there directly. ;)
235c9f3
to
e2376e5
Compare
I added check for With this I think I didn't forget anything? |
e2376e5
to
1ad95f1
Compare
And updated ui test. |
☔ The latest upstream changes (presumably #12386) made this pull request unmergeable. Please resolve the merge conflicts. |
1ad95f1
to
b016af5
Compare
b016af5
to
9fbabde
Compare
As discussed on zulip, if the Anything else to be done? |
Updated! |
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.
Looks fine to me. The implementation seems more lax now (e.g. it allows a tail transmute expression in a function no matter how many other statements there are), but that's fine by me and should also make it less controversial.
It would probably be useful to have an optional configuration variable for disallowing inferred transmute node args everywhere if a user specifically wants that behavior, but I don't want to block the (initial) PR adding it for too much longer. It could always be improved separately
if let Some(local) = get_parent_local_binding_ty(cx, expr_hir_id) { | ||
// ... which does have type annotations. | ||
if let Some(ty) = local.ty | ||
// If this is a `let x: _ =`, we shouldn't lint. |
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.
// If this is a `let x: _ =`, we shouldn't lint. | |
// If this is a `let x: _ =`, we should lint. |
?
Otherwise this comment is a bit confusing, because the opposite happens: we do lint specifically let x: _
because of the !matches!(ty.kind, TyKind::Infer)
below
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.
Forgot to update the comment, good catch!
The history here is a bit "convoluted", I tried cleaning it up a little bit by resolving my previous comments, but I don't know about @Centri3 's comments. Some of them aren't implemented, but I'm also not sure if you both agreed that its okay to not do it or if there's something left from your side? |
Fixed comment.
Please open an issue and assign me to it so it's not forgotten. 😉 |
I think it was resolved based on their comment in the zulip conversation. EDIT: It would still be worth confirming with @Centri3 though. |
I didn't bring up anything, though I don't think it's worth it to block on anything. It was mostly supposed to be about allowing some edge cases (like closures) which don't need to be added, but my rationale behind them. Everything else is good. |
Thanks for confirming! @y21 time for r+? :3 |
Sounds good, can you squash the commits? @bors delegate+ |
✌️ @GuillaumeGomez, you can now approve this pull request! If @y21 told you to " |
…r: _ = transmute`
… the only expr in the function
e52a7dd
to
ee25582
Compare
@bors r=y21 |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Fixes #715.
r? @blyxyas
changelog: Add
missing_transmute_annotations
lint