-
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
new lint: manual_c_str_literals
#11919
Conversation
r? @xFrednet (rustbot has picked a reviewer for you, use r? to override) |
6e25e10
to
4be054f
Compare
4be054f
to
d66b5ae
Compare
This PR is still marked as being a draft. Let me know when it's ready or if you have any questions, of course. |
Alright, I think it should be ready for review now. It now also lints bare This still needs |
Did a lintcheck run on the top 300 crates and the only warnings are from the openssl-sys crate. They all look legitimate and |
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 good to me, a few small nits, but they should hopefully be simple to fix :)
Do you think that we should wait with merging until |
6a0998d
to
b394a90
Compare
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.
Tiny nit, and then everything should be good to go
That's a good idea, can you ping me after the next release? Then I can r+ this :) |
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.
LGTM, now we're just waiting for the next release :)
Wouldn't we have to wait until 1.76, which is in two releases, since that's when If we merge when 1.75 gets released, we'd still have the problem that stable cannot yet use that syntax and nightly users likely don't want this lint because they still want their project to build on stable, right? It's possible that I have the release cycle mixed up though |
☔ The latest upstream changes (presumably #11977) made this pull request unmergeable. Please resolve the merge conflicts. |
Going to hold off fixing conflicts since we're gonna need to wait a bit anyway |
I'm a bit undecided on this one. It would be cool, to have a lint that suggests the new Actually, thinking about it, users can just set the minimal rust version, if they want to prevent the lint from triggering on nightly. With that config, I would actually say it's safe to merge it as is. |
Looks like there's an ongoing discussion in the T-lang zulip for reverting the stabilization of c string literals, at least for 1.76 I think if it does end up being reverted, we should probably really wait, since then the MSRV is also wrong. But I do agree with your last point, that if the MSRV is correct, users can set that to not get the lint |
So, C-String literals will be stable in 1.77 and 1.76 will be stable in a few days. Do you think we should try to get this merged soon, or wait? |
Let's merge this soon, if we merge it now, it should be on stable in 1.78. For some context:
|
4fb28b0
to
1e3e96a
Compare
Squashed the commits and rebased on to master |
clippy_config/src/msrvs.rs
Outdated
@@ -17,7 +17,7 @@ macro_rules! msrv_aliases { | |||
|
|||
// names may refer to stabilized feature flags or library items | |||
msrv_aliases! { | |||
1,76,0 { PTR_FROM_REF } | |||
1,76,0 { PTR_FROM_REF, C_STR_LITERALS } |
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.
It looks like they're planning to stabilize it in 1.77:
We discussed this in the triage call today and agreed, given that rust-lang/rust#119172 has landed, that we were happy to see this restabilize in Rust 1.77
On nightly these strings already seem to work, so I think it's safe to merge this, once the version is 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.
oh right, oops, of course 😅
1e3e96a
to
7f80b44
Compare
Perfect, looks good to me, thank you for all the work you put into this. Let's get this on to master: @bors r+ |
new lint: `manual_c_str_literals` With rust-lang/rust#117472 merged and `c""` syntax stabilized, I think it'd be nice to have a lint for using `CStr::from_ptr` (and similar constructors) with a string literal as an argument. We can probably also lint `"foo\0".as_ptr()` and suggest `c"foo".as_ptr()`. I might add that to this PR tomorrow if I find the time. The byte string literal to c string literal rewriting is ugly but oh well. changelog: new lint: `manual_c_str_literals`
💔 Test failed - checks-action_test |
new lint: `manual_c_str_literals` With rust-lang/rust#117472 merged and `c""` syntax stabilized, I think it'd be nice to have a lint for using `CStr::from_ptr` (and similar constructors) with a string literal as an argument. We can probably also lint `"foo\0".as_ptr()` and suggest `c"foo".as_ptr()`. I might add that to this PR tomorrow if I find the time. The byte string literal to c string literal rewriting is ugly but oh well. changelog: new lint: `manual_c_str_literals` [#11919](#11919)
💔 Test failed - checks-action_test |
@bors retry Please 🙏 |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
With rust-lang/rust#117472 merged and
c""
syntax stabilized, I think it'd be nice to have a lint for usingCStr::from_ptr
(and similar constructors) with a string literal as an argument.We can probably also lint
"foo\0".as_ptr()
and suggestc"foo".as_ptr()
. I might add that to this PR tomorrow if I find the time.The byte string literal to c string literal rewriting is ugly but oh well.
changelog: new lint:
manual_c_str_literals
#11919