-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Put "checks that detect UB" under their own flag below debug_assertions
#725
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:
Concerns can be lifted with:
See documentation at https://forge.rust-lang.org cc @rust-lang/compiler @rust-lang/compiler-contributors |
@rustbot second for adding it unstably with the plan to stabilize it |
This has been seconded more than 10 days ago, does that mean it got accepted? |
the mark-as-accepted process is still manual, but seems ok |
… r=<try> refactor check_{lang,library}_ub: use a single intrinsics This enacts the plan I laid out [here](rust-lang#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
… r=<try> refactor check_{lang,library}_ub: use a single intrinsics This enacts the plan I laid out [here](rust-lang#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
… r=<try> refactor check_{lang,library}_ub: use a single intrinsics This enacts the plan I laid out [here](rust-lang#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
… r=<try> refactor check_{lang,library}_ub: use a single intrinsic This enacts the plan I laid out [here](rust-lang#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
… r=saethlin refactor check_{lang,library}_ub: use a single intrinsic This enacts the plan I laid out [here](rust-lang#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
… r=saethlin refactor check_{lang,library}_ub: use a single intrinsic This enacts the plan I laid out [here](rust-lang#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
refactor check_{lang,library}_ub: use a single intrinsic This enacts the plan I laid out [here](rust-lang/rust#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang/rust#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
… r=saethlin refactor check_{lang,library}_ub: use a single intrinsic This enacts the plan I laid out [here](rust-lang#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
refactor check_{lang,library}_ub: use a single intrinsic This enacts the plan I laid out [here](rust-lang/rust#122282 (comment)): use a single intrinsic, called `ub_checks` (in aniticpation of rust-lang/compiler-team#725), that just exposes the value of `debug_assertions` (consistently implemented in both codegen and the interpreter). Put the language vs library UB logic into the library. This makes it easier to do something like rust-lang/rust#122282 in the future: that just slightly alters the semantics of `ub_checks` (making it more approximating when crates built with different flags are mixed), but it no longer affects whether these checks can happen in Miri or compile-time. The first commit just moves things around; I don't think these macros and functions belong into `intrinsics.rs` as they are not intrinsics. r? `@saethlin`
Put checks that detect UB under their own flag below debug_assertions Implementation of rust-lang/compiler-team#725
Put checks that detect UB under their own flag below debug_assertions Implementation of rust-lang/compiler-team#725
Rollup merge of rust-lang#123411 - saethlin:ub-checks, r=Urgau,RalfJung Put checks that detect UB under their own flag below debug_assertions Implementation of rust-lang/compiler-team#725
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20240701183625.665574-13-ojeda@kernel.org
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: Benno Lossin <benno.lossin@proton.me>
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20240701183625.665574-13-ojeda@kernel.org
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Reviewed-by: Finn Behrens <me@kloenk.dev> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Reviewed-by: Finn Behrens <me@kloenk.dev> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/r/20240709160615.998336-13-ojeda@kernel.org
Rust 1.79.0 has introduced a new codegen flag, `-Zub-checks` [1], to allow to independently configure (from `-Cdebug-assertions`) whether the extra runtime checks for UB are emitted, in a similar fashion to `-Coverflow-checks`. This allows to configure the kernel with only the UB checks enabled, but not the `debug_assert!`s; or vice versa, e.g. [2]. It also showcases how `RUSTC_VERSION` and the Kbuild macros, introduced in the previous commit, can be used. Link: rust-lang/compiler-team#725 [1] Link: https://godbolt.org/z/jY69ezx5K [2] Reviewed-by: Finn Behrens <me@kloenk.dev> Tested-by: Benno Lossin <benno.lossin@proton.me> Tested-by: Andreas Hindborg <a.hindborg@samsung.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Proposal
@saethlin has been working on adding more and more checks to rustc and the standard library that can detect widespread uses of UB. Currently, they are all controlled by
-Cdebug-assertions
/cfg(debug_assertions)
. I would argue that similar to the existing-Coverflow-checks
/cfg(overflow_checks)
, it is worth having a knob that can separately control them. While they generally have fairly little overhead, in some cases they can hurt a lot. And vice versa, maybe someone wants to turn on just these checks but not all the checks for more "harmless" bugs.So I suggest we add a new flag,
-Cub-checks
/cfg(ub_checks)
, that behaves likeoverflow_checks
: it defaults to matchdebug_assertions
but can be overwritten separately. Initially it would be unstable as-Zub-checks
, andcfg(ub_checks)
would not be stabilized beforecfg(overflow_checks)
.When this was discussed previously, a lot was talked about whether this should be grouped with the sanitizers. However, currently this is controlled entirely by
-Cdebug-assertions
, so just splitting up that flag in the established way seems to make most sense to me. In the end, sanitizers are not the only way we can detect UB -- we also have Miri, and now these checks. It would probably be confusing to people familiar with sanitizers if these kinds of debug assertions were mixed up with ubsan/msan and friends.Mentors or Reviewers
Myself, and possibly @saethlin ?
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
The text was updated successfully, but these errors were encountered: