about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp
diff options
context:
space:
mode:
authorDylan DPC <99973273+Dylan-DPC@users.noreply.github.com>2022-04-05 22:58:56 +0200
committerGitHub <noreply@github.com>2022-04-05 22:58:56 +0200
commite597d06144f356f58cf16a15ac7f21bc0d4d3628 (patch)
treef8f6f6b58e219036edef778c0c9bdac65e6e34a3 /compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp
parentc5e7e952925be74fc7dd6a2fac8e16df9e2044f6 (diff)
parentdd85a7682cf17103ec72eb1606fabf04bbf52971 (diff)
downloadrust-e597d06144f356f58cf16a15ac7f21bc0d4d3628.tar.gz
rust-e597d06144f356f58cf16a15ac7f21bc0d4d3628.zip
Rollup merge of #95547 - RalfJung:ptr-int-transmutes, r=scottmcm
caution against ptr-to-int transmutes

I don't know how strong of a statement we want to make here, but I am very concerned that the current docs could be interpreted as saying that ptr-to-int transmutes are just as okay as transmuting `*mut T` into an `&mut T`.

Examples [like this](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-1085144431) show that ptr-to-int transmutes are deeply suspicious -- they are either UB, or they don't round-trip properly, or we have to basically say that `transmute` will actively look for pointers and do all the things a ptr-to-int cast does (which includes a global side-effect of marking the pointed-to allocation as 'exposed').

Another alternative might be to simply not talk about them... but we *do* want people to use casts rather than transmutes for this.

Cc `@rust-lang/lang`
Diffstat (limited to 'compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp')
0 files changed, 0 insertions, 0 deletions