Put "checks that detect UB" under their own flag below `debug_assertions`

[RalfJung]

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 like overflow_checks: it defaults to match debug_assertions but can be overwritten separately. Initially it would be unstable as -Zub-checks, and cfg(ub_checks) would not be stabilized before cfg(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:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

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.

[rustbot]

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:

@rustbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rustbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler @rust-lang/compiler-contributors

[Noratrieb]

@rustbot second for adding it unstably with the plan to stabilize it

[RalfJung]

This has been seconded more than 10 days ago, does that mean it got accepted?

[Noratrieb]

the mark-as-accepted process is still manual, but seems ok