Skip to content
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

make unaligned_references future-incompat lint warn-by-default #82525

Merged
merged 1 commit into from
Mar 27, 2021

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Feb 25, 2021

and also remove the safe_packed_borrows lint that it replaces.

std::ptr::addr_of! has hit beta now and will hit stable in a month, so I propose we start fixing #27060 for real: creating a reference to a field of a packed struct needs to eventually become a hard error; this PR makes it a warn-by-default future-incompat lint. (The lint already existed, this just raises its default level.) At the same time I removed the corresponding code from unsafety checking; really there's no reason an unsafe block should make any difference here.

For references to packed fields outside unsafe blocks, this means unaligned_refereces replaces the previous safe_packed_borrows warning with a link to #82523 (and no more talk about unsafe blocks making any difference). So behavior barely changes, the warning is just worded differently. For references to packed fields inside unsafe blocks, this PR shows a new future-incompat warning.

Closes #46043 because that lint no longer exists.

@rust-highfive
Copy link
Collaborator

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 25, 2021
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@digama0
Copy link
Contributor

digama0 commented Feb 25, 2021

Why is it okay to make it not unsafe anymore? Doesn't this cause a soundness issue, at least in versions that don't give the hard error (i.e. the current version)?

@RalfJung
Copy link
Member Author

RalfJung commented Feb 26, 2021

Why is it okay to make it not unsafe anymore? Doesn't this cause a soundness issue, at least in versions that don't give the hard error (i.e. the current version)?

Instead of making it unsafe, we will forbid it entirely. This is always UB, which is not allowed even in unsafe blocks. Also note that it wasn't a hard unsafety error before either, it was a future-incompat warning.

Previously, outside unsafe blocks, it just caused a warning -- that was silenced by adding an unsafe block. That makes little sense, given that it is still UB. So the behavior does not change for what happens when you do this outside an unsafe block: both before and after this PR, you get a warning, saying "this will be a hard error eventually". This PR only changes behavior for doing this inside an unsafe block.

@@ -336,6 +336,7 @@ fn register_builtins(store: &mut LintStore, no_interleave_lints: bool) {
store.register_renamed("redundant_semicolon", "redundant_semicolons");
store.register_renamed("intra_doc_link_resolution_failure", "broken_intra_doc_links");
store.register_renamed("overlapping_patterns", "overlapping_range_endpoints");
store.register_renamed("safe_packed_borrows", "unaligned_references");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I called this a "rename" now because the lints are fairly similar... but maybe "remove" would be more appropriate?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No opinion, seems fine as is.

@RalfJung
Copy link
Member Author

FWIW, I don't know what our policy is wrt how long we wait before shipping such things -- std::ptr::addr_of! is available on beta and nightly, but not yet on stable. So maybe we want to wait until it hits stable to ensure that people can properly fix this warning while remaining stable-compatible. But in case there need to be FCPs or so I wanted to already get the ball rolling here.

@RalfJung RalfJung added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Feb 26, 2021
@RalfJung RalfJung changed the title make unaligned_refereces future-incompat lint warn-by-default make unaligned_references future-incompat lint warn-by-default Feb 26, 2021
@DemiMarie
Copy link
Contributor

In the future, I would like to see a type that wraps a (possibly unaligned) pointer that is guaranteed to be safe to dereference.

@petrochenkov
Copy link
Contributor

I think it's useful to land this even if std::ptr::addr_of is not yet stable, since the most common correct fix is to copy the field rather than to take a raw reference to it.
The old lint is not good, I've personally seen people wrongly silencing the warning by adding an unsafe block instead of copying the value.

@petrochenkov
Copy link
Contributor

r=me with the doc tweaked (#82525 (comment)).

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 28, 2021
@RalfJung
Copy link
Member Author

RalfJung commented Mar 1, 2021

I think it's useful to land this even if std::ptr::addr_of is not yet stable, since the most common correct fix is to copy the field rather than to take a raw reference to it.

My concern here is that people will silence the lint if they cannot fix the error because addr_of is not yet stable.

Let's see what @rust-lang/lang says.

@petrochenkov petrochenkov added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 1, 2021
@nikomatsakis
Copy link
Contributor

We discussed this in the @rust-lang/lang meeting and we would approve merging the PR. I'm happy to do any review necessary.

@petrochenkov petrochenkov added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Mar 23, 2021
@rust-log-analyzer

This comment has been minimized.

@petrochenkov
Copy link
Contributor

r=me with commits squashed.

…move the safe_packed_borrows lint that it replaces
@RalfJung
Copy link
Member Author

@bors r=petrochenkov

@bors
Copy link
Contributor

bors commented Mar 27, 2021

📌 Commit fb4f48e has been approved by petrochenkov

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 27, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 27, 2021
Rollup of 8 pull requests

Successful merges:

 - rust-lang#81351 (combine: stop eagerly evaluating consts)
 - rust-lang#82525 (make unaligned_references future-incompat lint warn-by-default)
 - rust-lang#82626 (update array missing `IntoIterator` msg)
 - rust-lang#82917 (Add function core::iter::zip)
 - rust-lang#82993 (rustdoc: Use diagnostics for error when including sources)
 - rust-lang#83522 (Improve fs error open_from unix)
 - rust-lang#83548 (Always preserve `None`-delimited groups in a captured `TokenStream`)
 - rust-lang#83555 (Add #[inline] to io::Error methods)

Failed merges:

 - rust-lang#83130 (escape_ascii take 2)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit a900677 into rust-lang:master Mar 27, 2021
@rustbot rustbot added this to the 1.53.0 milestone Mar 27, 2021
@RalfJung RalfJung deleted the unaligned-ref-warn branch March 28, 2021 09:29
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request May 18, 2021
…safeck, r=RalfJung

Clean up remnants of BorrowOfPackedField

cc rust-lang#82525 which removed `BorrowOfPackedField` from unsafety-checking
r? `@RalfJung`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Apr 16, 2022
…i-obk

make unaligned_references lint deny-by-default

This lint has been warn-by-default for a year now (since rust-lang#82525), so I think it is time to crank it up a bit. Code that triggers the lint causes UB (without `unsafe`) when executed, so we really don't want people to write code like this.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Apr 16, 2022
…i-obk

make unaligned_references lint deny-by-default

This lint has been warn-by-default for a year now (since rust-lang#82525), so I think it is time to crank it up a bit. Code that triggers the lint causes UB (without `unsafe`) when executed, so we really don't want people to write code like this.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Oct 23, 2022
…ce, r=cjgillot

make unaligned_reference a hard error

The `unaligned_references` lint has been warn-by-default since Rust 1.53 (rust-lang#82525) and deny-by-default with mention in cargo future-incompat reports since Rust 1.62 (rust-lang#95372). Current nightly will become Rust 1.66, so (unless major surprises show up with crater) I think it is time we make this a hard error, and close this old soundness gap in the language.

Fixes rust-lang#82523.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 31, 2023
…, r=cjgillot,scottmcm

make unaligned_reference a hard error

The `unaligned_references` lint has been warn-by-default since Rust 1.53 (rust-lang#82525) and deny-by-default with mention in cargo future-incompat reports since Rust 1.62 (rust-lang#95372). Current nightly will become Rust 1.66, so (unless major surprises show up with crater) I think it is time we make this a hard error, and close this old soundness gap in the language.

EDIT: Turns out this will only land for Rust 1.67, so there is another 6 weeks of time here for crates to adjust.

Fixes rust-lang#82523.
RalfJung pushed a commit to RalfJung/miri that referenced this pull request Feb 1, 2023
…lot,scottmcm

make unaligned_reference a hard error

The `unaligned_references` lint has been warn-by-default since Rust 1.53 (rust-lang/rust#82525) and deny-by-default with mention in cargo future-incompat reports since Rust 1.62 (rust-lang/rust#95372). Current nightly will become Rust 1.66, so (unless major surprises show up with crater) I think it is time we make this a hard error, and close this old soundness gap in the language.

EDIT: Turns out this will only land for Rust 1.67, so there is another 6 weeks of time here for crates to adjust.

Fixes rust-lang/rust#82523.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking issue for safe_packed_borrows compatibility lint