You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are obviously workarounds, but these are examples that are safe where the type-checker gets in the way. It is also unfortunate that the code is marked as "unsafe", yet the compiler rejects the code.
"unsafe" doesn't mean "anything goes". You can't call methods on types which have no method with that name, for example, or create a trait object out of a type which doens't implement the trait. This is a deliberate result of #14859 and #12898, closing as wontfix.
IRC: "okay then, then I think the core team needs to re-consider what they want with the language. in essence, things like this will send the message that "the compiler knows better", which will result in c/c++ people to not use the language."
This exposed a more important issue: we don't emphasize enough that unsafe shouldn't be required for performance in many cases, and that premature micro-optimization should be avoided.
I am glad for this change, as it removes many misuses of transmute.
Just to point out how bad transmuting can be, I've done a comparison, for this specific example.
Even with --opt-level=3, it's still inferior to the safe code (the only remaining difference being the tail modifier on the call to memcpy.
I have to admit, the Plane<T> ←→ Vec4<T> case does seem unfortunate.
#12898 did explicitly say that the plan would be to only permit transmutes of generics "through pointers" (which I interpret to mean "TypeExpr can only be transmuted behind a * or &"). Still, it seems like we could be more aggressive about recognizing that the two types have the same structure given that they are both applied to the same type T.
Closing, as has been noted many times in this thread, this was an explicit decision and this is working as-is today.
I believe it is too soon (this only landed 3 days ago) to start revisiting our initial decision. With this patch we have achieved the point where it is impossible to fail in codegen due to upstream crates. It is only possible to fail for a deterministically known issue in the local crate.
It would be possible to extend the language with a compiler-defined trait that signifies that two type parameters T and U are the same size, but this is part of the revisiting which can happen at a later date.
If there is a legitimate bug in the new transmute restrictions, then that is definitely something that should be dealt with. I would recommend opening a separate issue about perhaps adding a case of transmuting between the same type parameter, which is guaranteed to have the same size.
Activity
emberian commentedon Jun 14, 2014
"unsafe" doesn't mean "anything goes". You can't call methods on types which have no method with that name, for example, or create a trait object out of a type which doens't implement the trait. This is a deliberate result of #14859 and #12898, closing as wontfix.
emberian commentedon Jun 14, 2014
(Sorry)
emberian commentedon Jun 14, 2014
IRC: "okay then, then I think the core team needs to re-consider what they want with the language. in essence, things like this will send the message that "the compiler knows better", which will result in c/c++ people to not use the language."
emberian commentedon Jun 14, 2014
Reopening for discussion at a meeting, but I recommend wontfix/notabug.
emberian commentedon Jun 14, 2014
In particular, this just revolves around the new restriction on the
transmute
intrinsic.emberian commentedon Jun 14, 2014
A function which does the same thing as the old
transmute
, although doesn't care about same-sizedness:huonw commentedon Jun 14, 2014
(You can use
ptr::read
rather than explicitcopy_memory
too.)eddyb commentedon Jun 14, 2014
This exposed a more important issue: we don't emphasize enough that
unsafe
shouldn't be required for performance in many cases, and that premature micro-optimization should be avoided.I am glad for this change, as it removes many misuses of
transmute
.Just to point out how bad transmuting can be, I've done a comparison, for this specific example.
Even with
--opt-level=3
, it's still inferior to the safe code (the only remaining difference being thetail
modifier on the call tomemcpy
.engstad commentedon Jun 15, 2014
Here's another example that now fails, in gl-rs. It was fixed by this commit: rust-windowing/gl-rs@b01df8e
The idea here is to trampoline to the C-function if it exists, and to call the fail function if it doesn't.
eddyb commentedon Jun 15, 2014
In that case,
FnPtr
is too generic, under VG it would be:A better (short term) solution would be to expand
FnPtr::new
for eachload_with
:pnkfelix commentedon Jun 15, 2014
I have to admit, the
Plane<T>
←→Vec4<T>
case does seem unfortunate.#12898 did explicitly say that the plan would be to only permit transmutes of generics "through pointers" (which I interpret to mean "TypeExpr can only be transmuted behind a
*
or&
"). Still, it seems like we could be more aggressive about recognizing that the two types have the same structure given that they are both applied to the same typeT
.bluss commentedon Jun 15, 2014
If you are talking workarounds,
transmute_copy
already exists, maybe it is good enough for this use case.alexcrichton commentedon Jun 16, 2014
Closing, as has been noted many times in this thread, this was an explicit decision and this is working as-is today.
I believe it is too soon (this only landed 3 days ago) to start revisiting our initial decision. With this patch we have achieved the point where it is impossible to fail in codegen due to upstream crates. It is only possible to fail for a deterministically known issue in the local crate.
It would be possible to extend the language with a compiler-defined trait that signifies that two type parameters
T
andU
are the same size, but this is part of the revisiting which can happen at a later date.If there is a legitimate bug in the new transmute restrictions, then that is definitely something that should be dealt with. I would recommend opening a separate issue about perhaps adding a case of transmuting between the same type parameter, which is guaranteed to have the same size.