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

Add MVP suggestion for unsafe_op_in_unsafe_fn #112017

Merged
merged 5 commits into from
Jun 13, 2023

Conversation

Nemo157
Copy link
Member

@Nemo157 Nemo157 commented May 27, 2023

Rebase of #99827

cc tracking issue #71668

No real changes since the original PR, just migrated the new suggestion to use fluent messages and added a couple more testcases, AFAICT from the discussion there were no outstanding changes requested.

@rustbot
Copy link
Collaborator

rustbot commented May 27, 2023

r? @eholk

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 27, 2023
@rustbot
Copy link
Collaborator

rustbot commented May 27, 2023

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@@ -10,6 +10,14 @@ note: the lint level is defined here
|
LL | #![deny(unsafe_op_in_unsafe_fn)]
| ^^^^^^^^^^^^^^^^^^^^^^
help: consider wrapping the function in an unsafe block
Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, there was one outstanding point:

I'm not sure that this help text is useful -- I assume it's not necessary for the suggestion to be emitted for us to show it to humans too?

I feel like something more human-applicable here would be better, along the lines of "help: an unsafe function restricts callers, but it's body is safe by default". But I'm struggling with something succinct here.

It's probably a good idea to update the text in E0133 with some more expansive commentary on the effects of unsafe_op_in_unsafe_fn in any case, since it currently says nothing about that case.

@Mark-Simulacrum#99827 (comment)

Any suggestions on whether to remove the message completely, or a better message to replace it with?

Copy link
Member

Choose a reason for hiding this comment

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

The existing suggestion I gave: not providing a in-code suggestion and instead provide just the help text, e.g., "help: an unsafe function restricts callers, but it's body is safe by default".

@rust-log-analyzer

This comment was marked as outdated.

@rust-log-analyzer

This comment was marked as outdated.

Copy link
Contributor

@eholk eholk left a comment

Choose a reason for hiding this comment

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

Looks good. I made a few minor suggestions, which you can take or leave at your discretion. Feel free to r=me once you're ready.

@@ -55,6 +55,8 @@ mir_transform_unaligned_packed_ref = reference to packed field is unaligned
mir_transform_union_access_label = access to union field
mir_transform_union_access_note = the field may not be properly initialized: using uninitialized data will cause undefined behavior
mir_transform_unsafe_op_in_unsafe_fn = {$details} is unsafe and requires unsafe block (error E0133)
.suggestion = consider wrapping the function in an unsafe block
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
.suggestion = consider wrapping the function in an unsafe block
.suggestion = consider wrapping the function body in an unsafe block

To me wrapping the function in an unsafe block would mean something like this, even though it's nonsensical.

unsafe {
    unsafe fn foo() { ... }
}

@@ -130,6 +131,7 @@ impl RequiresUnsafeDetail {

pub(crate) struct UnsafeOpInUnsafeFn {
pub details: RequiresUnsafeDetail,
pub suggest_unsafe_block: Option<(Span, Span, Span)>,
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe add a doc comment describing what each of the three spans means?

@Nemo157
Copy link
Member Author

Nemo157 commented Jun 13, 2023

@bors r=eholk

@bors
Copy link
Contributor

bors commented Jun 13, 2023

📌 Commit 802c1d5 has been approved by eholk

It is now in the queue for this repository.

@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-review Status: Awaiting review from the assignee but also interested parties. labels Jun 13, 2023
@bors
Copy link
Contributor

bors commented Jun 13, 2023

⌛ Testing commit 802c1d5 with merge 5683791...

@bors
Copy link
Contributor

bors commented Jun 13, 2023

☀️ Test successful - checks-actions
Approved by: eholk
Pushing 5683791 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 13, 2023
@bors bors merged commit 5683791 into rust-lang:master Jun 13, 2023
@rustbot rustbot added this to the 1.72.0 milestone Jun 13, 2023
@Nemo157 Nemo157 deleted the unsafe-block-rustfix branch June 13, 2023 19:44
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (5683791): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.2% [1.2%, 1.2%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This 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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.3% [-2.3%, -2.3%] 1
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 647.795s -> 648.13s (0.05%)

bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 14, 2023
…safe_fn, r=RalfJung

Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024

This was previously FCPed: rust-lang#71668 (comment)

There were two blocking requirements:
* Fix the `unused_unsafe` lint, done in rust-lang#100081
* Have `cargo fix` able to fix the lint, done in rust-lang#112017
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Sep 15, 2023
…r=RalfJung

Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024

This was previously FCPed: rust-lang/rust#71668 (comment)

There were two blocking requirements:
* Fix the `unused_unsafe` lint, done in rust-lang/rust#100081
* Have `cargo fix` able to fix the lint, done in rust-lang/rust#112017
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Apr 7, 2024
…r=RalfJung

Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024

This was previously FCPed: rust-lang/rust#71668 (comment)

There were two blocking requirements:
* Fix the `unused_unsafe` lint, done in rust-lang/rust#100081
* Have `cargo fix` able to fix the lint, done in rust-lang/rust#112017
RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request Apr 27, 2024
…r=RalfJung

Change `unsafe_op_in_unsafe_fn` to be `warn`-by-default from edition 2024

This was previously FCPed: rust-lang/rust#71668 (comment)

There were two blocking requirements:
* Fix the `unused_unsafe` lint, done in rust-lang/rust#100081
* Have `cargo fix` able to fix the lint, done in rust-lang/rust#112017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-edition-2024 Area: The 2024 edition merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants