Code change:
I have two crates: Notice that the implementation of contains an . Something is not happy about that. This currently affects Serde trait impls that use a private helper type with a Serde derive, which is a common pattern. The following script reproduces the issue as of rustc 1.31.0-beta.4 ( 2018-11-01) as well as rustc 1.32.0-nightly ( 2018-11-07).
Mentioning who seems to know about extern_prelude.
The issue is caused by entering infinite recursion when trying to print the impl path. If returns and finishes , then this issue should be fixed as well.
(Also, the issue reproduces on 2015 edition as well.)
I'm hitting this on stable 1.32.0 with a , and I confirmed that replacing it with a manual impl works. Is there any other workaround?
Just ran into this on with the serde helper pattern.
Copying <kbdI-nominated</kbdfrom .
pre-triage: P-high. Leaving nominated for discussion at compiler triage meeting tomorrow.
From what I can tell, this was fixed sometime between nightly-2020-01-04 and nightly-2020-01-05. Here's what landed during that time:
I just discovered a detail about this bug that I did not previously appreciate: It needed the invocation (or some similar call to e.g. ) to replicate. The bug as described here ended up being fixed by PR . I suspect that's due to that rollup PR's inclusion of PR , but I have not yet verified this. The question I have remaining: Is the bug here really fixed, or is it merely masked by the changes from PR ? E.g. PR makes heavy revisions to the expansion of ; can one manually write code that emulates the previous expansion, and then replicate the original bug atop that? Anyway, even if the bug here is truly fixed, we should add the code from the description here as a regression test.
It's not fixed, the repro at the top still overflows rustc's stack as of 1.42.0-nightly ( 2020-01-09). We would need to minimize again to get a different minimal repro post-.
Okay I've got a new reproduction now, thanks for the pointer
removing nomination tag since I do not think this needs explicit discussion. However, it should get assignment. I'm not yet sure if I will take it on myself or try to get someone else to investigate it.
For posterity, here's the current backtrace (since the module no longer exists):
The issue is here Removing the check makes the repro case compile successfully, but it degrades some existing test output: an example of the changes: I'll see what can be done.
Just checking, did you see this? I don't remember all the details but I found that comment after looking at the context around the code you linked, which seemed vaguely familiar.
I'd seen that comment, but didn't grok the full meaning of it until I looked at this in more detail. Is there any reason not to change the to be ? is precisely as a way to avoid the problem at hand of unconditional recursion for other cases.
I found this separately in Workaround: add an (or whichever crate) at the root of your crate.
triage: nominating for discussion as part of attempt to burn down set of unassigned P-high issues at an otherwise light triage meeting.
discussed at . Assigning to
just ran into this bug in their GSoC project when adding a trybuild test (). EDIT: Rest of the comment was probably nonsense.
Just to confirm, still there in 1.46.0 (same repro with serde as posted above).
Didn't see this when it was posted, my bad, but I wanted to reply because it's not that simple because that recursion tracking is limited to , but currently, gets in between that, so that you have many independent sets, none of them containing the of the item.
I ran into this as well with while trying to delete based on the status here.

Related discussion:
text: match self.tcx().extern_crate(def_id) { Some(&ExternCrate { src, dependency_of, span, .. }) => match (src, dependency_of) { (ExternCrateSource::Extern(def_id), LOCAL_CRATE) => { <del> debug!("try_print_visible_def_path: def_id={:?}", def_id); return Ok(( if !span.is_dummy() { self.print_def_path(def_id, &[])? } else { self.path_crate(cnum)? }, true, )); </del> <ins> // NOTE(eddyb) the only reason `span` might be dummy, // that we're aware of, is that it's the `std`/`core` // `extern crate` injected by default. // FIXME(eddyb) find something better to key this on, // or avoid ending up with `ExternCrateSource::Extern`, // for the injected `std`/`core`. if span.is_dummy() { return Ok((self.path_crate(cnum)?, true)); } // Disable `try_print_trimmed_def_path` behavior within // the `print_def_path` call, to avoid infinite recursion // in cases where the `extern crate foo` has non-trivial // parents, e.g. it's nested in `impl foo::Trait for Bar` // (see also issues #55779 and #87932). self = with_no_visible_paths(|| self.print_def_path(def_id, &[]))?; return Ok((self, true)); </ins> } (ExternCrateSource::Path, LOCAL_CRATE) => { <del> debug!("try_print_visible_def_path: def_id={:?}", def_id); </del> return Ok((self.path_crate(cnum)?, true)); } _ => {}