Change:
<ins> error[E0599]: no function or associated item named `deserialize` found for struct `A` in the current scope --> $DIR/issue-87932.rs:13:8 | LL | pub struct A {} | ------------ function or associated item `deserialize` not found for this ... LL |     A::deserialize(); |        ^^^^^^^^^^^ function or associated item not found in `A` | = help: items from traits can only be used if the trait is in scope help: the following trait is implemented but not in scope; perhaps add a `use` for it: | LL | use <crate::A as issue_87932_a::Deserialize>::deserialize::_a::Deserialize; | error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>

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

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.