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

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>