Stream: t-compiler/rust-analyzer

Topic: `panic!` doesn't work anymore


Jonas Schievink [he/him] (Apr 02 2021 at 23:05, on Zulip):

The definition of panic! was changed, so now it's broken in rust-analyzer:

#[rustc_builtin_macro = "std_panic"]
#[stable(feature = "rust1", since = "1.0.0")]
#[allow_internal_unstable(edition_panic)]
#[cfg_attr(not(test), rustc_diagnostic_item = "std_panic_macro")]
macro_rules! panic {
    // Expands to either `$crate::panic::panic_2015` or `$crate::panic::panic_2021`
    // depending on the edition of the caller.
    ($($arg:tt)*) => {
        /* compiler built-in */
    };
}

This is the only use of #[rustc_builtin_macro = "std_panic"] with a string argument, for some reason.

Jonas Schievink [he/him] (Apr 02 2021 at 23:05, on Zulip):

Ah, that's because in libcore it uses core_panic instead

Jonas Schievink [he/him] (Apr 03 2021 at 00:00, on Zulip):

Doesn't seem hard to implement, I'll work on this

Jonas Schievink [he/him] (Apr 03 2021 at 00:25, on Zulip):

We seem to have problems parsing (?) this macro though:

pub macro panic_2015 {
    () => (
        $crate::panicking::panic("explicit panic")
    ),
    ($msg:literal $(,)?) => (
        $crate::panicking::panic($msg)
    ),
    ($msg:expr $(,)?) => (
        $crate::panicking::panic_str($msg)
    ),
    ($fmt:expr, $($arg:tt)+) => (
        $crate::panicking::panic_fmt($crate::format_args!($fmt, $($arg)+))
    ),
}

fn main() {
    panic_2015!();
}

Do we support macro 2.0 with multiple branches?

Mario Carneiro (Apr 03 2021 at 00:43, on Zulip):

The code says yes

Jonas Schievink [he/him] (Apr 03 2021 at 00:54, on Zulip):

Ah, it expects ; to separate the rules, not ,

Jonas Schievink [he/him] (Apr 03 2021 at 00:55, on Zulip):

we really need to report better errors for malformed macro definitions, the parser has them

Jonas Schievink [he/him] (Apr 03 2021 at 01:28, on Zulip):

Landed everything in https://github.com/rust-analyzer/rust-analyzer/pull/8304

Last update: Jul 28 2021 at 03:30UTC