Resolve `core` types

[Matthias247]

rust-analyzer works great if I use std types. However for their core equivalents I typically get neither auto-completion nor goto definition. This a bit inconvenient when working on a no-std project.

I mostly work around it by typing std things and then remaining them. But it would be better if core types would be directly supported.

[matklad]

Some code pointers:

• adding dependency on std crate happens here:

https://github.com/rust-analyzer/rust-analyzer/blob/9d786ea221b27fbdf7c7f7beea0290db448e0611/crates/ra_project_model/src/lib.rs#L202

• extern crates are plugged in name resolution here:

https://github.com/rust-analyzer/rust-analyzer/blob/9d786ea221b27fbdf7c7f7beea0290db448e0611/crates/ra_hir_def/src/nameres.rs#L88

My guess would be that adding dependency on core to all crates around the first bullet point should be enough. If that doesn't work, some more digging around the second bullet point is required. This is a guess because I don't exactly remember how core is treated by name resolution.

[Matthias247]

Thanks for the hints! I looked at it - mostly through text search for "std" - and also arrived at the first file. I now added the additional dependencies on core and it is indeed able to resolve core types now.

However it might have added an issue with std types: While it can still resolve things that are explicitely prefixed with std, it seems to have issues with prelude types (like Vec and String). Any idea?

What also is a bit mysterious to me is how the std types could have been resolved before - since they forwarded to core. Is that because RA starts at std, and then goto definition follows the all the re-exports until it arrives at core?

[Matthias247]

Is this going wrong now, with the additional dependency?

https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/ra_hir_def/src/nameres/collector.rs#L38-L44

[matklad]

Hm, my guess about prelude is that both core and std have (different) prelude, and, with an added dependency on core, we now always pick its prelude.

The best way to debug it is to create a test, which replicates the structure of std and prelude modules, and see what goes wrong. Note that it’s impossible to use real std in tests (bc it’s slow and brittle)

The std types know about core because we explicitly add std->core dependency (see sysroot.rs)

[matklad]

The relevant test is here: https://github.com/rust-analyzer/rust-analyzer/blob/4fd742d6bc23e2f61d0980e15234f09d7e715b76/crates/ra_hir_def/src/nameres/tests.rs#L222

If my hypothesis about std vs core prelude is correct, we might actually need to look at the no_std attribute, and that is slightly more involved. Attributes are handled by raw.rs

[Matthias247]

The std types know about core because we explicitly add std->core dependency (see sysroot.rs)

Ah ok. I found that. Does the dependency adding in ra_project_model add another dependency from std to core - or does the project model only cover user crates?

The relevant test is here:

That test actually still succeeds

If my hypothesis about std vs core prelude is correct, we might actually need to look at the no_std attribute, and that is slightly more involved.

You mean a different prelude needs to be included depending on whether it's a std or nostd crate? That's probably more correct, yes. But likely even just always picking the std prelude would be fine in the first iteration. People would get more completions than really available and compiler errors later on, but it's still a bit better than getting no completions.

[Matthias247]

Can you give me a hint how the test is supposed to work? It doesn't refer to any std type directly. Does it emulate a virtual std with prelude? If yes then I guess we would need to add a virtual "core". However I don't see how the names are mapped.

Regarding the fix: I guess we would need to implement one of:

• If std is a dependency, then the prelude of this overwrites the prelude of core
• If std is a dependency, remove the prelude from core
• Unconditionally remove the prelude from core

I guess the first solution might be the most correct one, since it allows to have a mix of crates which are either no-std and std, and all have their preludes correctly set.

[Matthias247]

I know published a CR for the first approach. That seems to yield the expected behavior for me.

[matklad]

The tests only have the code that is explicitly specified, so you need to add mock std/core directly in the test. I think one day we’ll add “standard” mocked core and std, with predefined lang items, but so far this wasn’t necessary.

The test in the PR looks right!