Change:
rustc crashes ungracefully when given the following input (found by ): I'm seeing this behavior on stable, beta, and nightly.
cc
Interesting: I'm not familiar with but that's where we are aborting:
cc
If I change the body of to this: then the compiler aborts how you would expect. I caught the panic in gdb (with ). It is coming from . Here's the stack trace: So it seems like this is a "legitimate" panic from the parser that the compiler would normally catch gracefully somewhere... except that assumes the closure it calls never panics and just aborts immediately if so. 's current implementation arose out of . any thoughts on how could let the panic pass through in a memory-safe manner? Or is that not possible?
I think there’s no magic trick here. Afaik the only safe way to do this is to mem::replace t with a dummy value, apply f, and swap the result back, but that requires that t has a dummy value. Does the code break if you add T: Default bound? Also, when suggesting that change I was 80% sure that it’s pure pedantry because, clearly, we don’t panic anywhere :) I am fascinated by how conspicuous and shallow such “benign” problems become in rust!
cc re:macros/ being ky.
Yes. Unfortunately, lots of the involved types lack a bound, and adding one doesn't make sense. wants the commit that introduced to be reverted anyway. Perhaps that's the best path forward, even though it'll be a perf hit. If I'd stuck with the original code that didn't handle panics it would have been a double-free without warning. One of those " is trickier than you might think" moments.
Or we just accept the current behaviour, because it's a benign abort on a very obscure case, and is being phased out anyway...
What's the plan post-? Benign to , but it will kill RLS or any other long lived tool. (Not that I disagree that we can live with this in the medium term.)
Just in case it's useful: here is a variation that causes (what I assume is) the same abort with only the macro:
I am unable to reproduce this crash on the latest releases. I was curious what fixed it, so I tried bisecting with nightlies. The crash still happens on but no longer happens on . Unfortunately, it looks like nightlies are not available in between those two. In any case, as far as I'm concerned, this issue may be closed now.
Let's close this with a PR containing these repro cases as regression tests.

Discussion:
<ins> // Regression test for #63952, shouldn't hang. use std::usize; #[repr(C)] #[derive(Copy, Clone)] struct SliceRepr { ptr: *const u8, len: usize, } union SliceTransmute { repr: SliceRepr, slice: &'static [u8], } // bad slice: length too big to even exist anywhere const SLICE_WAY_TOO_LONG: &[u8] = unsafe { //~ ERROR: it is undefined behavior to use this value SliceTransmute { repr: SliceRepr { ptr: &42, len: usize::MAX, }, } .slice }; fn main() {} </ins>

<ins> error[E0080]: it is undefined behavior to use this value --> $DIR/issue-63952.rs:18:1 | LL | / const SLICE_WAY_TOO_LONG: &[u8] = unsafe { LL | |     SliceTransmute { LL | |         repr: SliceRepr { LL | |             ptr: &42, ...  | LL | |     .slice LL | | }; | |__^ invalid slice: total size is bigger than largest supported object | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </ins>

<ins> // A regression test for #68653, which was fixed by #68938. // check-pass #![allow(incomplete_features)] #![feature(generic_associated_types)] trait Fun { type F<'a: 'a>; } impl <T> Fun for T { type F<'a> = Self; } fn main() {} </ins>

<ins> #![crate_type = "lib"] pub fn vec() -> Vec<u8> { vec![] } </ins>

<ins> // edition:2018 // aux-build:issue-51798.rs // check-pass extern crate issue_51798; mod server { fn f() { let mut v = issue_51798::vec(); v.clear(); } } fn main() {} </ins>

<ins> // Regression test for #62894, shouldn't crash. // error-pattern: this file contains an unclosed delimiter // error-pattern: expected one of `(`, `[`, or `{`, found keyword `fn` fn f() { assert_eq!(f(), (), assert_eq!(assert_eq! fn main() {} </ins>

<ins> error: this file contains an unclosed delimiter --> $DIR/issue-62894.rs:7:14 | LL | fn f() { assert_eq!(f(), (), assert_eq!(assert_eq! |        -           -                   - unclosed delimiter |        |           | |        |           unclosed delimiter |        unclosed delimiter LL | LL | fn main() {} |              ^ error: this file contains an unclosed delimiter --> $DIR/issue-62894.rs:7:14 | LL | fn f() { assert_eq!(f(), (), assert_eq!(assert_eq! |        -           -                   - unclosed delimiter |        |           | |        |           unclosed delimiter |        unclosed delimiter LL | LL | fn main() {} |              ^ error: this file contains an unclosed delimiter --> $DIR/issue-62894.rs:7:14 | LL | fn f() { assert_eq!(f(), (), assert_eq!(assert_eq! |        -           -                   - unclosed delimiter |        |           | |        |           unclosed delimiter |        unclosed delimiter LL | LL | fn main() {} |              ^ error: expected one of `(`, `[`, or `{`, found keyword `fn` --> $DIR/issue-62894.rs:7:1 | LL | fn f() { assert_eq!(f(), (), assert_eq!(assert_eq! |                                                   - expected one of `(`, `[`, or `{` LL | LL | fn main() {} | ^^ unexpected token error: aborting due to 4 previous errors </ins>

<ins> // Regression test for #39618, shouldn't crash. // FIXME(JohnTitor): Centril pointed out this looks suspicions, we should revisit here. // More context: https://github.com/rust-lang/rust/pull/69192#discussion_r379846796 // check-pass #![feature(specialization)] trait Foo { fn foo(&self); } trait Bar { fn bar(&self); } impl<T> Bar for T where T: Foo { fn bar(&self) {} } impl<T> Foo for T where T: Bar { fn foo(&self) {} } impl Foo for u64 {} fn main() {} </ins>