Implement Rust 2021 panic

[m-ou-se]

This implements the Rust 2021 versions of panic!(). See #80162 and rust-lang/rfcs#3007.

It does so by replacing {std, core}::panic!() by a bulitin macro that expands to either $crate::panic::panic_2015!(..) or $crate::panic::panic_2021!(..) depending on the edition of the caller.

This does not yet make std's panic an alias for core's panic on Rust 2021 as the RFC proposes. That will be a separate change: c5273bd That change is blocked on figuring out what to do with #80846 first.

[Aaron1011]

I don't think this will require any Miri changes - all of the Miri panic logic/hooks occur much deeper into the panic code.

[m-ou-se]

@bors try @rust-timer queue

[rust-timer]

Finished benchmarking try commit (18bbe6416d2f0b96850a82cf214a118ca792bc4c): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[m-ou-se]

Not sure who would be the right reviewer for this. Pinging some people whose names I saw in related git blame outputs: r? @Mark-Simulacrum @petrochenkov @SimonSapin @RalfJung

[petrochenkov]

@bors r+

[bors]

📌 Commit 5b11a97 has been approved by petrochenkov

[bors]

⌛ Testing commit 5b11a97 with merge e5451054558902869b7121a3c2f0c1cc180283ad...

[JohnTitor]

@bors retry yielding

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

⌛ Testing commit 5b11a97 with merge e0d9f79...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing e0d9f79 to master...

[Aurel300]

This is a minor point but we can no longer tell apart panic!() and assert!(false, "msg") in the macro_backtrace(), because both result in ["std::panic::panic_2015", "std::panic"].

[m-ou-se]

@Aurel300 On Rust 2015 and 2018, nothing should've changed there other than an extra panic_2015 at the end, I think? Why doesn't the assert result in ["std::panic::panic_2015", "std::panic", "core::assert"]?

[Aurel300]

I would have expected it to, yes, but maybe it is inlined somehow? The macro_backtrace() of the two is identical (except for call location of course).

macro_backtrace: [
    ExpnData {
        kind: Macro(
            Bang,
            "$crate::panic::panic_2015",
        ),
        parent: ExpnId(
            2,
        ),
        call_site: prusti-tests/tests/verify/fail/no-annotations/panic-reason.rs:2:5: 2:14 (#6),
        def_site: /rustc/5fa22fe6f821ac3801d05f624b123dda25fde32c/library/std/src/panic.rs:26:1: 36:2 (#0),
        allow_internal_unstable: Some(
            [
                "libstd_sys_internals",
            ],
        ),
        allow_internal_unsafe: false,
        local_inner_macros: false,
        edition: Edition2018,
        macro_def_id: Some(
            DefId(1:4000 ~ std[a906]::panic::panic_2015),
        ),
        krate: crate0,
        orig_id: Some(
            21,
        ),
        disambiguator: 0,
    },
    ExpnData {
        kind: Macro(
            Bang,
            "panic",
        ),
        parent: ExpnId(
            0,
        ),
        call_site: prusti-tests/tests/verify/fail/no-annotations/panic-reason.rs:2:5: 2:14 (#0),
        def_site: /rustc/5fa22fe6f821ac3801d05f624b123dda25fde32c/library/std/src/macros.rs:28:1: 34:2 (#0),
        allow_internal_unstable: Some(
            [
                "edition_panic",
            ],
        ),
        allow_internal_unsafe: false,
        local_inner_macros: false,
        edition: Edition2018,
        macro_def_id: Some(
            DefId(1:9 ~ std[a906]::macros::panic),
        ),
        krate: crate0,
        orig_id: Some(
            2,
        ),
        disambiguator: 0,
    },
]

Edit: even with assert!(unimplemented_bool_call(), "msg") the backtrace is the same, so not inlining.

[m-ou-se]

Can you open a new issue for this? Comments on an already merged PR tend to get lost easily.