-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
Uplift temporary-cstring-as-ptr lint from clippy into rustc
#75671
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
Conversation
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion |
|
⌛ Trying commit f7da096488c6fd9d4be7c480affa26d9f7b80a02 with merge ca7ac508d257828878fb0e7cade1ad46381056f8... |
|
Sgtm, modulo CI passing, perf being clean and we'll need an MCP so the entire compiler team is informed about this. Can you open an MCP? It just needs a sentence or two and maybe an example on what is now being linted. |
f7da096 to
bb1759b
Compare
src/librustc_lint/methods.rs
Outdated
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'll need a crater run to check the fallout from this (but it should still be deny by default unless we break some foundational crate, 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.
dependencies get their lints capped anyway, so it will only break building that crate 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.
I feel that it shouldn't be deny by default as long as it considers func(CString::new("...").unwrap().as_ptr()); to be erroneous (since in typical situations this would be a false positive).
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.
+1 for making this Warn, and not Deny (though I don't know if we have other similar deny-by-default lints).
I think we also should add a regression test for func(CString::new("...").unwrap().as_ptr());. I wouldn't personally call it as a false-positive though: it's not UB, but still sufficiently obscure style worth linting against.
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 agree on the Warn by default, since the lint covers cases that aren't incorrect. That's reflected in the PR now.
Sure thing! Filed rust-lang/compiler-team#346. |
2337d68 to
6d43d7f
Compare
|
☔ The latest upstream changes (presumably #73084) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I think rust-lang/rust-clippy#5838 should be fixed before making this deny-by-default. Warn-by-default is fine if fixing the false positive is too difficult and we want to get this in soon. |
|
I feel moderately strongly that rust-lang/rust-clippy#5838 is not a false positive. it is false-positive for "this code is UB", as it is not UB. But it absolutely is a true positive for "this code is confusing, because you need to be a language lawyer to understand why it is not UB". |
Then it should say that. Instead it currently says
Which is not true. It will be invalid outside the statement, which encompasses both the |
|
Also I think it would be nice for it to link to https://doc.rust-lang.org/reference/destructors.html, but I won't block on that. |
6d43d7f to
ab8b582
Compare
jyn514
left a comment
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 think this should add a test case for rust-lang/rust-clippy#5838. If the behavior there is intentional, then it should be tested; it shouldn't slip in by accident. If it's not intentional, the lint should be fixed.
ab8b582 to
42d91b3
Compare
@bors retry |
|
☀️ Test successful - checks-actions |
|
Uh, can we have a policy that the Clippy team is pinged for major changes to Clippy in rustc, such as uplifting lints. Even though the lint was removed, it wasn't deprecated properly (which is a lengthy process by design). Luckily @ebroto caught that in the rustup. But with a ping to the Clippy team we can avoid pull requests, like this "emergency sync": #78505 |
The general consensus seems to be that this lint covers a common enough mistake to warrant inclusion in rustc.
The diagnostic message might need some tweaking, as I'm not sure the use of second-person perspective matches the rest of rustc, but I'd like to hear others' thoughts on that.
(cc #53224).
r? @oli-obk