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

Discussion:
I'm sorry, I haven't reduced this at all, and I'm sure the code is awful, but the error message said you'd appreciate a bug report. I tried this code: jeremyBanks/0dmg using I expected to see this happen: my program would run, or the compiler would give one of its typical helpful error messages! Instead, this happened: I am using the Windows Linux Subsystem thing with Debian or Ubuntu, I think. : : Backtrace:
If I use cargo doc I get a different stack trace:
The crash stopped occurring in my code when I fixed an invalid import: see jeremyBanks/0dmg
I'm pretty certain this is caused by being directly indexed without being checked here: But, really, it'd be nice to have a reduced test case so we can confirm the bug is fixed afterwards.
Makes sense. I'll try to pare it down to something useful.
I'm failing to reproduce this crash without using multiple crates, so I can't figure out how to put it in a Playground example or doc test, but here's a reduced example ().
Okay, I've got the failure occurring in a compiler test at jeremyBanks/rust Result: If I understand correctly, it will be possible to turn this into a regression test by annotating it with the desired non-panic output, once this issue has been fixed and we know what the fixed output looks like. But since we're not sure what the will look like, there'd be no point trying to get this merged yet.
now that is merged and should be in the next Nightly, could you check your test-case again to see whether it's fixed? I didn't have time to add your test case before it was merged. Thanks!
I think it's fixed. My stand-alone test case produces the same initial error message of "no type-dependent def for method call", but it no longer displays any panic; it seems to exit cleanly. Using built from : Using : (Now running in a normal Debian VM. Sorry for the constantly-changing platform. :P)
Sorry! I didn't mean to submit the post yet, or close the issue, but I mis-clicked. I'm still trying to figure out the appropriate annotations to make this pass as a test.

If I get the test working behaving properly, would it be useful to send a PR to add my regression test, or is this too small of an issue to warrant one?
yes, a regression test would be useful here. Actually, I don't think the behaviour is even correct here — it shouldn't be displaying that error at all, even if it's not actually crashing.
Did a test ever get here?

Compiling this code results in: There is no backtrace. If I disable specialization feature, rustc reports an error: ` Rustc details:
This seems to compile as of the most recent nightly.
Good to hear that! Would it make sense to add this example to the test suite to prevent regressions in the future?