Code change:
I've been working on a branch where I've made some refactoring changes and I'm working through cargo check errors/warnings/etc. now. Unexpectedly, one of the errors was from rustc mentioning "overflowed the stack": To reproduce: out the branch the patch listed below (uncomment a single line) <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --Backtrace N/A.
Your compiler is "very" (3 versions behind) old. There should be no reason to pin to such an old compiler, unless you're using a very specific nightly version, which you aren't. This error however does also occur on latest stable (1.54.0) as well as nightly. So, ... modify labels: regression-from-stable-to-stable I-crash -I-ICE Stable and nightly outputs are different though: (See for explanation) <details<summarystable</summary</details<details<summarynightly</summary</details
This is causing the overflow: Trying to get rid of serde ~and bisecting~ right now. Bisecting shows that even a 2018-06-01 (1.28.0-nightly) will overflow. This is a edition2018 specific bug, because there's no need for anymore. If I add that to the outer scope, the overflow will go away. For reference, here's a code that a user would write, therefore I think this should be P-High The workaround is to move the to the outer scope.
Please don't respond to issues in this way. There are plenty of reasons to pin compiler versions like that, it's not a good idea to presume that someone has no reason to do a thing, and in the case of this issue it seems extraneous. The reduced testcase is appreciated, however!
note that adding the use declaration is not the source of the bug; the use declaration uncovers the bug because without the the compiler fails earlier in the pipeline. reduced testcase also runs on the if needed, btw!
cc
For reference: The small error went away with , which seems fine and dandy because that's whats the PR is supposed to do. So there's nothing wrong with the different outputs of stable and nightly :)
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I believe I managed to hit this specific crash while working on ( is the WIP commit where I first encountered that crash), however, this project does not depend on Serde. I investigated further, and managed to make a complete , here's the gist of it (in ) : This cannot be reproduced solely in the playground without Serde, as it requires a multiple-crate setup. This project has a main crate and a single dependency. The points for reproducing the issue in a project are the following: As pointed out by the title of this issue, there needs to be an declaration inside of a trait implementation, which references the same crate the trait is coming from. There also needs an exposed function referencing a type from that same crate, i.e. either returning it, or receiving it as a parameter (either directly, or through a reference or pointer). The exposed function can be either a function, or a private function marked with the attribute (the attribute is how I encountered the crash at first). The common denominator with Serde here is the in "hack" to make proc macros as hygienic as possible, first suggested in , which I discovered through the explanation in . I had just tried to use this same trick, as we've had , and that's when the compiler crashed with the stack overflow: And here's my : I know nothing about 's internals, but here are a few additional observations I made while making this test case: Unlike what's described in the first message, both Rust-LV2 and my test project only reproduce the crash by actually building the project using (in either debug or release mode). Using on those projects did not crash. This is also corroborated by the fact that introducing a type error in the exposed function does not result in a crash either — the type error stops the rustc before it actually builds anything. The exposed function can be either in the same module as the trait implementations, or in a submodule, as long as it is either public or the function is (which, in a way, bypasses module visibility). If the function is either private, or marked but in a private module, the compiler does not crash. The "exposed function" part of the crash does not apply to all exposed items: replacing the function with e.g. does not trigger a crash. If a second declaration is in the implementation of another trait (here demonstrated with ) then the crash does not happen anymore. Having it only in the impl does not trigger the crash either. It behaves like there is a cache of some sort on these 'extern crate' declarations, and having a cache miss inside of the trait impl referenced by that crate causes the crash. Hope this helps! :slightlysmiling_face:
I remember this, it is an old issue -
If returns and finishes , then this issue should be fixed as well. Narrator: eddyb never returned.
Ah, right, that got lost in the chaos of Rust 2018 + all the changes. Fingers crossed that code hasn't gotten crazier since.
A different reproducer (one above will stop working soon; probably).
Finally found some time for this, some notes: had been superseded by work, seems to be correct, so there's not really anything to do by trying to rebase that PR is what never happened, and should be relatively simple by comparison right now we prioritize over "Rust 2018 paths to " (whether in or elsewhere), as the "source of ", but I'm not sure the latter ends up being used with -introduced names, so I'm hoping flipping that priority direction is enough to get better results
Also, I don't recall seeing - seems like that would be the correct fix for the stack overflow, whereas the priority thing is more of an "aesthetic" fix. EDIT: this turns out not to be that simple, see

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)); } _ => {}