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

Do not dereference uninhabited types refs in Clone implementations #3456

Merged
merged 1 commit into from Nov 30, 2023

Conversation

samueltardieu
Copy link
Contributor

A reference to an uninhabited type should never be dereferenced: this is UB. Copy should not be implemented on such a type, and an upcoming Clippy lint (uninhabited_reference) may flag such
dereferences as suspicious.

Since those types are not structs, they do not need to get Copy and Clone implementations. A missing! macro limits code duplication.

A reference to an uninhabited type should never be dereferenced:
this is UB. `Copy` should not be implemented on such a type, and
an upcoming Clippy lint (`uninhabited_reference`) may flag such
dereferences as suspicious.

Since those types are not structs, they do not need to get `Copy`
and `Clone` implementations. A `missing!` macro limits code
duplication.
@rustbot
Copy link
Collaborator

rustbot commented Nov 28, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@JohnTitor
Copy link
Member

Thanks! @bors r+

@bors
Copy link
Contributor

bors commented Nov 30, 2023

📌 Commit a693257 has been approved by JohnTitor

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Nov 30, 2023

⌛ Testing commit a693257 with merge b4686c6...

@bors
Copy link
Contributor

bors commented Nov 30, 2023

☀️ Test successful - checks-actions, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13, checks-cirrus-freebsd-14
Approved by: JohnTitor
Pushing b4686c6 to main...

@bors bors merged commit b4686c6 into rust-lang:main Nov 30, 2023
11 checks passed
@Nadrieril
Copy link
Member

A reference to an uninhabited type should never be dereferenced: this is UB

This is not quite correct: if the &! is safe, then the code can't be reached so dereferencing it is ok. In other words, the Clone impl is sound because it can assume that &self obeys its safety invariant (which means that clone will never be called). A different way to see why this is not UB is that this does not require an unsafe {} block.

Now, this Clone impl could trigger UB if it was passed a &self that breaks the safety invariant. But that's the responsibility of the caller, not the impl.

@samueltardieu
Copy link
Contributor Author

A reference to an uninhabited type should never be dereferenced: this is UB

This is not quite correct: if the &! is safe, then the code can't be reached so dereferencing it is ok. In other words, the Clone impl is sound because it can assume that &self obeys its safety invariant (which means that clone will never be called). A different way to see why this is not UB is that this does not require an unsafe {} block.

Now, this Clone impl could trigger UB if it was passed a &self that breaks the safety invariant. But that's the responsibility of the caller, not the impl.

I agree. However, in the context of libc which necessarily deals with a lot of unsafe, obtaining such a reference (for example a &mut FILE from a *mut FILE) is quite easy and a user could shoot themselves in the foot by calling .clone() on them. This is why I think that removing those Clone implementations was the best think to do anyway.

@Nadrieril
Copy link
Member

Oh I see! Then I totally agree, having these impls is a big footgun. Well the whole thing is quite footgunny but that too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants