Add intrinsic for Option::Some(_) offset#109095
Add intrinsic for Option::Some(_) offset#109095llogiq wants to merge 1 commit intorust-lang:masterfrom
Conversation
|
r? @scottmcm (rustbot has picked a reviewer for you, use r? to override) |
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
library/core/src/intrinsics.rs
Outdated
There was a problem hiding this comment.
Please re-add the FIXME from the hacky libstd impl here, so we remember to nuke this intrinsic in the future
library/core/src/option.rs
Outdated
There was a problem hiding this comment.
0 should be the safest choice here.
|
I'm a bit confused about the error. I had included the const-unstable feature in |
if the intrinsic is used from stable code, then yes, you need to make it stable. |
library/core/src/intrinsics.rs
Outdated
There was a problem hiding this comment.
Can you add the intrinsics to the main extern "rust-intrinsic" block instead and just cfg the fn directly?
da1a88c to
86bc827
Compare
There was a problem hiding this comment.
Why not use variant.fields.offset(0)? I am not sure if the bug! here is truly unreachable. Layouts can take very surprising shapes sometimes.
There was a problem hiding this comment.
I think this will ICE on Option<!>.
There was a problem hiding this comment.
Oh, a test for Option<Never> would be a good add, regardless of implementation 👍
There was a problem hiding this comment.
I think we should avoid duplicating this code.
There was a problem hiding this comment.
Ok, where to put it then?
Const stability checking is fully recursive, unlike the usual library stability checking. We want to avoid accidentally stably exposing the behavior of some unstable function / intrinsic at compile time. |
86bc827 to
a5ac44e
Compare
scottmcm
left a comment
There was a problem hiding this comment.
I think this probably needs some updates before it can land, but I'm usually just a libs reviewer, so this should go to someone better equipped to evaluate the right way to do this in the compiler.
r? compiler
|
Closing this in favor of a |
…ce, r=eholk move Option::as_slice to intrinsic `@scottmcm` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc `@nikic` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
…ce, r=eholk move Option::as_slice to intrinsic ``@scottmcm`` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc ``@nikic`` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
…ce, r=eholk move Option::as_slice to intrinsic ```@scottmcm``` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc ```@nikic``` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
…ce, r=eholk move Option::as_slice to intrinsic ````@scottmcm```` suggested on rust-lang#109095 I use a direct approach of unpacking the operation in MIR lowering, so here's the implementation. cc ````@nikic```` as this should hopefully unblock rust-lang#107224 (though perhaps other changes to the prior implementation, which I left for bootstrapping, are needed).
This replaces the prior hacky calculation with an
option_some_offsetintrinsic that directly gets the offset from the type layout.cc @scottmcm #108545