Unresolved import for platform specific modules

[GrayJack]

I tried to search if it was reported but didn't found anything.

When importing the platform specific modules in std::os rust-analyzer gives me the following error:
unresolved import. Also those modules don't show up for auto-complete.

When the module is used outside use statement, there is no error, but the semantic token are of the type unresolvedReference.

RA version

Latest master branch

Example

use std::os::unix;

[jonas-schievink]

We seem to have trouble finding/expanding the cfg_if! invocation

[jonas-schievink]

Oh, it's because we don't load the sysroot correctly. We just add a bunch of hard-coded path dependencies to libstd without looking at its Cargo.toml.

[jfcha]

I'm also seeing this issue for

use std::os::windows::ffi::{OsStrExt, OsStringExt};

in the 2020-09-21 release.

[ttzztztz]

Same issue.

[iulianR]

Hello, it's a bit spammy in VSCode (using Code Lens extension) because it looks like a hard error, making you think the code won't compile:

It is possible to change it somehow it so it shows in a similar way to an {unknown} error (when ra is unable to determine type for example)? I think that was the previous behaviour before the 21-09-2020 release.
Thanks!

[lnicola]

@iulianR you can disable that warning in the preferences (the experimental diagnostics key).

EDIT: "rust-analyzer.diagnostics.disabled": ["unresolved-import"]

[leshow]

I am running into this too, if I use the above disable though, won't that disable all unresolved import errors?

That doesn't seem to be desirable. Is there any other options? I assume it happens because rust-analyzer is set to build for all targets, and the import isn't available on some targets

[jonas-schievink]

No, it happens because

we don't load the sysroot correctly. We just add a bunch of hard-coded path dependencies to libstd without looking at its Cargo.toml.

You can only disable the unresolved import diagnostic entirely (although check-on-save will still display rustc's unresolved import messages, regardless of how r-a diagnostics are configured)

[thomcc]

This is (unsurprisingly) also broken for {core,std}::arch::*. I'm certain this used to work too... :(

[flodiebold]

It "used to work" in the sense that this diagnostic didn't show up, because the diagnostic wasn't implemented yet. You can make it not show up again with the setting mentioned above; you'll still get unresolved import errors from rustc. But at least we're now aware that rust-analyzer can't actually resolve these imports.

[jonas-schievink]

The diagnostic is already marked as experimental fwiw, so unless you opt into the experimental ones this shouldn't show up.

[thomcc]

It "used to work" in the sense that this diagnostic didn't show up

I guess I'll take your word for it that it never worked, but I was pretty sure I had autocomplete for some parts of core::arch in the past. Huh.

The diagnostic is already marked as experimental fwiw, so unless you opt into the experimental ones this shouldn't show up.

Hrm, I don't remember opting into experimental diagnostics anywhere.

[jonas-schievink]

Oh, turns out the experimental ones are on by default