Hello everyone!
The C++ standard defines certain programming mistakes (such as defining a function more than one time) to cause a program to be "ill-formed, no diagnostic required", which means if the program is compiled, it will have undefined behavior from the start of execution (not when non-compliant part is reached). I wonder, is there anything similar in Rust?
I suppose that what you describe amounts to "undefined behavior which the compiler can prove happens on all possible executions of the program", thereby granting the compiler permission to do whatever it wants, since you gave it a program which isn't valid at all. I think I'd count "undefined behavior which occurs at compile time" as a subset of this case. It doesn't seem unreasonable to count the "execution of the program" as starting with the compile-time evaluated parts of it, including linking. (Maybe there's more appropriate jargon I'm unaware of, though.)
I don't think I've seen such a category be special-cased in Rust, though, it's just more UB.
#[unsafe(no_mangle)] can certainly have that effect on many platforms by having you overwrite mechanism from libc with bogus implementations, affecting symbol resolution, .. affecting anything from startup to the binary loading before startup (or for a library how it is linked to others). Rust does not make any difference to other forms here as far as I'm aware, it's all called unsound.
Yes and no.
Yes: Rust has unsafe, which has the power to create problems that mess up the program (ill-formed) which the compiler can't reasonably detect (to emit a diagnostic).
Unmangled extern symbols are supported in Rust, and can cause the same mess as C++ ODR violations.
No: Rust doesn't phrase it that way. Rust has one leading implementation, so the design, spec, and implementation mostly blend into one project.
There isn't a negotiation between a spec committee and multiple vendors happening between the lines of a spec. That phrase in the C++ spec sounds like one side wanted to forbid this, but some vendors said they can't control this, so the spec is phrased to forbid this without actually forcing the vendors to do it.
Rust implements what it can without being so formal about it. Whether something has a diagnostic or not may be a matter making a pull request adding it. The language reference is more of a documentation of what Rust does rather than requirements for what it should do.
For ODR, Rust chose to have orphan rules that statically prevent the problem and are strongly enforced. Rust chose to have more opinions on how it's built and use extra metadata for libraries (rlib/rmeta) to detect more ABI problems without having to throw hands into the air and declare that linkers suck and it can't be fixed (but linkers still suck and unmangled symbols and non-rlibs still cause problems Rust can't fix).
What is ill-formed and should/or not be allowed in Rust is also a bit simpler thanks to the memory safety goal and unsafe keyword. If you can break memory safety without an unsafe keyword somewhere, that's a problem for Rust to fix. There are two loopholes to this that would probably get a documented excuse like that in a Rust spec (programs modifying their memory via external OS facilities like /proc/mem or debuggers, and build scripts linking in arbitrary libraries that change behavior of functions or OS APIs that Rust relies on), but most cases are self-evident.