Skip to content

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented May 4, 2024

Resolves #34117 by declaring it to be "working as intended" until someone RFCs it or whatever other lang proposal would be required. It seems a bit of a footgun, but perhaps there are strong reasons to allow it anyways. Seeing as how I often have to be mindful to not allow a pointer to coerce the wrong way in my FFI work, I am inclined to think not, but perhaps it's fine in some use-case and that's actually more common?

@rustbot
Copy link
Collaborator

rustbot commented May 4, 2024

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 4, 2024
@workingjubilee workingjubilee force-pushed the document-no-double-pointer-coercion-happens branch from 4911a8c to a27c897 Compare May 4, 2024 03:09
@rust-log-analyzer

This comment has been minimized.

@workingjubilee workingjubilee force-pushed the document-no-double-pointer-coercion-happens branch from a27c897 to e404e7a Compare May 4, 2024 03:18
Copy link
Member

@compiler-errors compiler-errors left a comment

Choose a reason for hiding this comment

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

This is definitely not supported via any current coercion rules, and I don't expect it happening any time soon.

@compiler-errors
Copy link
Member

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented May 4, 2024

📌 Commit e404e7a has been approved by compiler-errors

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 May 4, 2024
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request May 4, 2024
…pointer-coercion-happens, r=compiler-errors

We do not coerce `&mut &mut T -> *mut mut T`

Resolves rust-lang#34117 by declaring it to be "working as intended" until someone RFCs it or whatever other lang proposal would be required. It seems a bit of a footgun, but perhaps there are strong reasons to allow it anyways. Seeing as how I often have to be mindful to not allow a pointer to coerce the wrong way in my FFI work, I am inclined to think not, but perhaps it's fine in some use-case and that's actually more common?
bors added a commit to rust-lang-ci/rust that referenced this pull request May 4, 2024
…iaskrgr

Rollup of 6 pull requests

Successful merges:

 - rust-lang#123356 (Reduce code size of `thread::set_current`)
 - rust-lang#124159 (Move thread parking to `sys::sync`)
 - rust-lang#124293 (Let miri and const eval execute intrinsics' fallback bodies)
 - rust-lang#124500 (lldb-formatters: Use StdSliceSyntheticProvider for &str)
 - rust-lang#124677 (Set non-leaf frame pointers on Fuchsia targets)
 - rust-lang#124692 (We do not coerce `&mut &mut T -> *mut mut T`)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request May 4, 2024
…iaskrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#123356 (Reduce code size of `thread::set_current`)
 - rust-lang#124159 (Move thread parking to `sys::sync`)
 - rust-lang#124293 (Let miri and const eval execute intrinsics' fallback bodies)
 - rust-lang#124677 (Set non-leaf frame pointers on Fuchsia targets)
 - rust-lang#124692 (We do not coerce `&mut &mut T -> *mut mut T`)
 - rust-lang#124698 (Rewrite `rustdoc-determinism` test in Rust)
 - rust-lang#124700 (Remove an unnecessary cast)
 - rust-lang#124701 (Docs: suggest `uN::checked_sub` instead of check-then-unchecked)

r? `@ghost`
`@rustbot` modify labels: rollup
@RalfJung
Copy link
Member

RalfJung commented May 4, 2024

This seems awfully specific as we generally don't coerce below references (coercions only apply top-level). But sure, why not 🤷

@bors bors merged commit b0715b4 into rust-lang:master May 4, 2024
@rustbot rustbot added this to the 1.80.0 milestone May 4, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 4, 2024
Rollup merge of rust-lang#124692 - workingjubilee:document-no-double-pointer-coercion-happens, r=compiler-errors

We do not coerce `&mut &mut T -> *mut mut T`

Resolves rust-lang#34117 by declaring it to be "working as intended" until someone RFCs it or whatever other lang proposal would be required. It seems a bit of a footgun, but perhaps there are strong reasons to allow it anyways. Seeing as how I often have to be mindful to not allow a pointer to coerce the wrong way in my FFI work, I am inclined to think not, but perhaps it's fine in some use-case and that's actually more common?
@workingjubilee workingjubilee deleted the document-no-double-pointer-coercion-happens branch May 5, 2024 02:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

Can't coerce &mut &mut T to *mut *mut T
7 participants