Tracking Issue for "unsafe blocks in unsafe fn" (RFC #2585)

[nikomatsakis]

This is a tracking issue for the RFC "unsafe blocks in unsafe fn" (rust-lang/rfcs#2585).
The lint unsafe_block_in_unsafe_fn is stable, but the RFC proposes some further things we might want to do.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Introduce an opt-in lint that, when enabled, causes unsafe blocks in unsafe functions to be considered required, and warns if they are absent when an unsafe operation is performed.
• Stabilization PR in Rust 1.52.0 (Stabilize unsafe_op_in_unsafe_fn lint #79208)
• Include a suggestion with the lint that can insert required unsafe blocks. This could be as simple as adding a block across the entire function, though more granular insertion is probably better. (Add MVP suggestion for unsafe_op_in_unsafe_fn #112017)
• Adjust documentation to describe the (somewhat unusual) effect of the lint, and to describe the possibility that the lint will be enabled default (see instructions on rustc-dev-guide)
• Write a blog post describing the change, perhaps?

Unresolved Questions

• What is the timeline for adding the lint, and cranking up its default level?
• Should the default level depend on the edition?
• Should we ever make this deny-by-default or even a hard error, in a future edition?
• Should we require cargo fix to be able to do something about this warning before making it even warn-by-default? And how precise should it be?

Implementation history

• Implemented in Implement RFC 2585: unsafe blocks in unsafe fn #71862
• Stabilized in Stabilize unsafe_op_in_unsafe_fn lint #79208
• Fixable suggestion added in Add MVP suggestion for unsafe_op_in_unsafe_fn #112017
• Made warn-by-default for 2024 edition in Change unsafe_op_in_unsafe_fn to be warn-by-default from edition 2024 #112038

[nikomatsakis]

cc @RalfJung

[nikomatsakis]

A relevant note towards the implementation:

• Clippy has a helper function for testing whether a lint is enabled.

[LeSeulArtichaut]

I'll try to work on the implementation!

[RalfJung]

If I understand https://boats.gitlab.io/blog/post/ringbahn/ correctly, that API would also benefit greatly from not treating the body of an unsafe fn as unsafe {}: there is a trait with an unsafe fn, and

It’s important to understand what an unsafe methods means: unsafe methods are unsafe to call - meaning that callers must guarantee additional invariants when calling them. However, they are safe to implement (as long as you don’t do anything unsafe inside of them). So when a user implements the Event trait, they are given additional guarantees about how this method will be called that normally they could not assume.

@withoutboats did I understand this correctly?

[withoutboats]

@RalfJung I don't think its a particularly new situation. Basically, the guarantee that you are getting from it being unsafe are the guarantees you need to be able to call these unsafe methods in the SubmissionQueueEvent that is passed as an argument.

In other words, an Event implementation is going to use probably 1 unsafe operation (calling one of these methods), which it can prove is correct based on the invariant that trait requires the caller to maintain. This isn't really different from any other unsafe code.

What I'm trying to say with the blog post is that the Event trait hasn't introduced a new invariant for you to maintain, its introduced a new invariant that I maintain so its easier for you to call that unsafe method you need to call to get any work done.

This is just how unsafe trait methods work in general, so its nothing new. But I agree that unsafe trait methods (where the invariant contract is specified separately from the implementer) are a compelling example of where unsafe blocks in unsafe fns seem beneficial.