Change:
<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>

Discussion:
I wanted to test our handling of slices that are "too big" (bigger than the largest possible allocation), so I wrote: I expected an ICE or so, but I got a timeout. On nightly, here's what a stacktrace looks like: looks like the interning could do with a fast path for integer slices similar to what validation does? And maybe it could also check that the reference is dereferencable before walking it, that would avoid finding out later that we are going to produce an error anyway.
This now finishes in milliseconds with an error:

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.