Change:
<ins> error[E0425]: cannot find value `Foo` in this scope --> $DIR/crate-in-paths.rs:20:5 | LL |     Foo; |     ^^^ not found in this scope help: possible candidate is found in another module, you can import it into scope | LL | use crate::bar::Foo; | error: aborting due to previous error For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
UPDATE: There has been some progress on this issue. prefixes now work, but you still don't get suggestions from other crates except when you write an explicit . When you get name resolution suggestions from resolve after an error, they should use prefixes where appropriate. Example (): gives but I want to see suggested.
It looks like the suggestions are issued here: The behavior I think we want is this: The function that prepares those suggestions appears to be this one: Here is an example of checking for whether the feature is enabled:
expressed some interest in tackling this.
Hmm, now i'm worried that this will apply even when it shouldn't. Consider this testcase: This currently prints: and I think we do not want it to print . I think this suggests an alternative fix to what I recommended before (and what did in ) -- but I'd like to get opinion. Before I suggested changing how the values are printed out, but now I think we should change them at the source: Right now, this works by walking through the crate and finding candidates. I suspect (but we should test) that this means it will not work when the option is enabled and no explicit exists, because there is nothing to walk over. Therefore, the change I propose is as follows: the function to (if is enabled) to push a at the front of the import suggestions it is currently creating. This is because all of them are found by trawling the crate source. , if is enabled, add a loop that executes first. This would go over all of the crates that are available from the command line, load them up, and search for the item within (basically the same as the existing search, but beginning from the crate directly). In this case, we would not prepend to the resulting path, but instead the name of the crate we are searching. One flaw I can see here is that it may be that the crate is locally shadowed. I suspect we can overlook that possibility for now.
do the above notes seem ok?
Looks reasonable.
To get a bit more detailed in how to make this modification, ultimately I envision we'll have a helper like this: This will be roughly the same as the existing , except that instead of starting from , it will seed the worklist with : Then, later, when it finds a suggestion: It will check if and the feature is enabled.

In that case, it adds to the start of the suggestion. This is step 1. Step 2 in a second. =)
OK, so step 2... The basic idea was to iterate over each of the "available" crates. For each crate, we would load the crate (if not already loaded), and then use the fn to walk and make a suggestion. So the first question is where we find that list of available crates and how to load it. Here are some pointers. For example, here is where we find the set of things in the prelude: which ends up in the Resolver struct. And this is where we resolve paths that rely on external prelude: It seems sort of like this is the snippet of code to "load a crate if needed": I think the idea would be to refactor that last snippet of code into a helper fn, and then invoke it from . So would look something like: OK, there is a slight flaw -- I think that should take not a ("in root") but rather a with the crate name to prepend (which would be in the case of the root module). I've modified the code above accordingly.