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
patterns: reject raw pointers that are not just integers #116930
Conversation
r? @davidtwco (rustbot has picked a reviewer for you, use r? to override) |
pub POINTER_STRUCTURAL_MATCH, | ||
Allow, |
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 didn't realize this lint is still allow-by-default oO. Seems high time we make it warn-by-default?
The 2nd commit makes this forbid-by-default so we can crater it. |
patterns: reject raw pointers that are not just integers Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not. Cc `@oli-obk` `@lcnr`
Due to #116929 this lint still has a big gap, it'll only find bad raw pointers "at the root". I wonder if with this change to valtree construction, we can make it so that some lint always fires when a const is used as a pattern and valtree construction fails? I do think those cases should all become hard errors eventually... |
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
Let's see how much fallout we're getting from this weak form of the lint. |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
0787e62
to
a91227c
Compare
Some changes might have occurred in exhaustiveness checking cc @Nadrieril |
a91227c
to
41ab7f7
Compare
This comment has been minimized.
This comment has been minimized.
Lol, the doctest for |
2e70736
to
35b0255
Compare
@@ -247,6 +247,7 @@ marker_impls! { | |||
/// | |||
/// const CFN: Wrap<fn(&())> = Wrap(higher_order); | |||
/// | |||
/// #[allow(pointer_structural_match)] |
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.
FWIW these entire trait docs are outdated; that's tracked in #115881.
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
@craterbot run mode=check-only crates=https://crater-reports.s3.amazonaws.com/pr-116930/retry-regressed-list.txt |
This comment was marked as outdated.
This comment was marked as outdated.
5ab33a9
to
70a8e15
Compare
Those seem to be 3 legit regressions:
In particular, none of them is matching on a raw pointer that was not derived from an integer. So IMO we should land this PR to make sure people don't start doing that. |
@rust-lang/lang this PR does three things:
We haven't reached a proper conclusion in the recent "match on const" meeting, but the general direction seems to have been towards "it should still work like a pattern" (and not like sugar for Crater found only 3 cases where the warning triggers, in the entire ecosystem. All of them would already warn on stable if they enabled the lint; the new cases covered by this PR were not detected at all by crater. |
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.
Implementation changes look good to me, r=me after decisions from t-lang.
); | ||
} | ||
_ => {} | ||
if !have_valtree { |
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.
nit: could be part of the condition on the previous line
I'm in favor of this. (I also have thoughts on the semantics of matching on constants -- tl;dr I think I'm ready to accept "match is not an extensible mechanism" and hence will not act the same as |
T-lang meeting consensus: let's do this, no FCP needed. |
@bors r=davidtwco |
☀️ Test successful - checks-actions |
Finished benchmarking commit (fdaaaf9): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 662.394s -> 663.159s (0.12%) |
patterns: reject raw pointers that are not just integers Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not. This extends the existing check against function pointers and wide pointers: we now uniformly reject all these pointer types during valtree construction, and then later lint because of that. See [here](rust-lang/rust#116930 (comment)) for some more explanation and context. Also fixes rust-lang/rust#116929. Cc `@oli-obk` `@lcnr`
patterns: reject raw pointers that are not just integers Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not. This extends the existing check against function pointers and wide pointers: we now uniformly reject all these pointer types during valtree construction, and then later lint because of that. See [here](rust-lang/rust#116930 (comment)) for some more explanation and context. Also fixes rust-lang/rust#116929. Cc `@oli-obk` `@lcnr`
patterns: reject raw pointers that are not just integers Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not. This extends the existing check against function pointers and wide pointers: we now uniformly reject all these pointer types during valtree construction, and then later lint because of that. See [here](rust-lang/rust#116930 (comment)) for some more explanation and context. Also fixes rust-lang/rust#116929. Cc `@oli-obk` `@lcnr`
Matching against
0 as *const i32
is fine, matching against&42 as *const i32
is not.This extends the existing check against function pointers and wide pointers: we now uniformly reject all these pointer types during valtree construction, and then later lint because of that. See here for some more explanation and context.
Also fixes #116929.
Cc @oli-obk @lcnr