Rust-analyzer: 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

[cameron-rowe]

Oh, turns out the experimental ones are on by default

Disabling that caused the error to go away for me. This works as a temporary workaround. Thanks.

[blinsay]

Is there documentation on disabling diagnostics in editors that aren't VSCode? I can't tell from this thread if rust-analyzer.diagnostics.disabled is a VSCode option or a rust-analyzer option.

Thanks for rust-analyzer, it's wonderful.

[lnicola]

It's a rust-analyzer option, but configuring it is client-dependant. If you're using coc.vim, you can use the same setting, otherwise it might be called diagnostics/enabled, without the program name.

If you figure it out and have the time, we'll probably accept client-specific documentation pull requests.

[matklad]

Some discussion here: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Where.20are.20third.20party.20crates.20in.20rustc-src.3F

[matklad]

https://github.com/rust-analyzer/rust-analyzer/pull/6294 papers over this issue

[jonas-schievink]

This still seems to happen, despite the workaround. Or does that only work if something else pulls in a cfg_if dependency?

[matklad]

Yeah, cfg_if should be in dep tree somewhere

[iamwwc]

Still showing this problem when I use use std::os::unix::io::{AsRawFd, RawFd}; :(
Please fix it, think you :)

[iamwwc]

Mio seems works in WSL2

But my project doesn't show docs and hint.

[talk2drys]

same issue. even though it works

[danfo]

In my projects I have unresolved imports reported on files deep in ~/.rustup/. Sounds like it could be this known issue?

[AXIM0S]

Same issue when using std::os::unix::fs::symlink.