The new C++ standard, C++26, defined a new category of program bugs, called erroneous behavior and defined as well-defined behavior that the compiler is recommended to diagnose. The example of erroneous behavior in C++ is reading an erroneous value (a primitive-type value that has not been initialized and has not been marked [[indeterminate]]).
The Rust standard library documentations defines a similar kind of bugs called logic errors, that can cause undesirable but not undefined behavior. The examples of such are:
Non-compliant (not conforming to expectations of standard library) or inconsistent (giving different results depending on the method called) of PartialEq, PartialOrd and Ord
Implementation of Eq for types that can be not equal to itself
Using types that can change their ordering, equality or hash as key types for HashMap or BTreeMap or item types for HashSet, BTreeSet or BinaryHeap
Calling poll() on a future after the last call returned Poll::Ready()
Calling resume() on a coroutine after the last call returned CoroutineState::Complete()
upd: more precise wording about C++26 changing previously undefined behavior to erroneous behavior
I don't think this is a meaningful comparison. Unlike erroneous behaviour according to the C++ standard, logic bugs in Rust are implementation mistakes that can't be caught by the compiler at compile time. The Rust equivalent of trying to read an uninitialized variable is a compile time error. The C++ standard leaves it up to the C++ implementation to decide what it wants to do in the face of erroneous behaviour. It could for example stop compilation with an error (same as Rust does) or emit a warning or panic at runtime in the face of erroneous behaviour:
If the execution contains an operation specified as having erroneous behavior, the implementation is permitted and recommended to issue a diagnostic, and is permitted to terminate the execution at an unspecified time after that operation.
C++ erroneouss behavior are a language concept, they represent bugs that can be detected at compile time.
rust logic errors are library contract violations, and cannot be checked at compile time. some (not all) of the logic errors can (and do) be checked at runtime though, but it's a decision of the library author about how to handle them (e.g. they can report an error, panic, or silently produce wrong results if unchecked, but they cannot cause UB in safe APIs).
in fact, C++ also has had the concept of "logic error" for ages, which represents precondition violations, just like the rust counter part:
rust logic errors are library contract violations, and cannot be checked at compile time.
to be precise you cannot check all logic errors at compile time with perfect accuracy (as doing so would solve the halting problem),
but you can have a check that has false positives, false negatives, or both.
While it's phrased in a funny way, and I appreciate the joke, it is actually a pretty nice change since before these things were left as undefined behavior!
Reading an undefined value is only one example, there's a variety of "this shouldn't be a big enough mistake to nuke the whole compile" mistakes. Theoretically Rust could add a similar concept for some unsafe code, but it would depend on what the overlap is, I guess (I'd assume not much if any)
