document that t-lang does not need involvement for unobservable intrisics - #161675
document that t-lang does not need involvement for unobservable intrisics#161675RalfJung wants to merge 1 commit into
Conversation
|
cc @rust-lang/wg-const-eval
cc @rust-lang/miri Any special-casing of Miri in the standard library requires review. cc @rust-lang/miri Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter |
|
|
e04e762 to
453be15
Compare
This comment has been minimized.
This comment has been minimized.
453be15 to
93c8b74
Compare
| //! Intrinsics don't need a body. However, they optionally can have a body, which we call the | ||
| //! "fallback body". This will be used by codegen backends that do not have a dedicated | ||
| //! implementation of the intrinsic, making it easier to add new intrinsics for specific operations | ||
| //! without having to implement them in each codegen backend. The fallback body obviously has to be | ||
| //! a valid implementation of the documented specification of the intrinsic. In some cases, the | ||
| //! fallback body will be *equivalent* to the specification. Note that this is a strong requirement: | ||
| //! if the spec says "UB if input `x` is even", then a valid implementation can just ignore this and | ||
| //! do whatever it wants in that case; an *equivalent* implementation needs to actually check this | ||
| //! condition and trigger UB in that case (e.g. by using `hint::assert_unchecked()`). Similar, if | ||
| //! the spec says "returns `x` or `y` non-deterministically", then an *equivalent* implementation | ||
| //! must actually do non-deterministic choice and return either value (e.g. by invoking some other | ||
| //! language operation that has the same non-determinism). Intrinsics with such a fallback body that | ||
| //! is equivalent to the spec may be marked with `#[miri::intrinsic_fallback_is_spec]`; the fallback | ||
| //! body will then also be used by Miri for UB checking. When in doubt, do not use this attribute or | ||
| //! ask the Miri maintainers for advice. | ||
| //! | ||
| //! Intrinsics are, in general, language extensions. Therefore, t-lang should be involved whenever a | ||
| //! new intrinsic is exposed to stable code. However, if an intrinsic is marked | ||
| //! `#[miri::intrinsic_fallback_is_spec]` with a fallback body that only uses stable features (or if | ||
| //! such a fallback body could be written, but for one reason or another the actual fallback body is | ||
| //! different), and if it also does not make other promises that go beyond observable program | ||
| //! behavior (such as steering the optimizer in a particular direction), then an intrinsic may be | ||
| //! used without t-lang involvement. |
There was a problem hiding this comment.
Just a remark on my side, no need to do anything about it. This is quite a lot a word to say that if a intrinsic does something new (language wise, ie not using existing language features) it should be validated by T-lang, and everything else just need T-compiler approval.
There was a problem hiding this comment.
The first paragraph explains a lot more than that. It explains the intrinsic_fallback_is_spec which is non-trivial, that's why I used so many words for it.
The second paragraph explains what you summarized. Happy to make it shorter if you have suggestions for how to concretely do that. It's non-trivial to say precisely what "something new" means.
This turns the FCP about intrinsics that could already be written on stable into documentation.
Also use this opportunity to document
miri::intrinsic_fallback_is_spec.r? @tgross35
Cc @rust-lang/lang
Should only land once the FCP completes!