Unresolved import for platform specific modules #6038

GrayJack · 2020-09-19T04:33:49Z

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;

The text was updated successfully, but these errors were encountered:

jonas-schievink · 2020-09-19T15:05:11Z

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

jonas-schievink · 2020-09-20T12:23:34Z

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 · 2020-09-21T20:56:09Z

I'm also seeing this issue for

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

in the 2020-09-21 release.

ttzztztz · 2020-09-24T08:14:06Z

Same issue.

iulianR · 2020-09-27T17:43:43Z

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 · 2020-09-27T18:29:07Z

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

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

leshow · 2020-10-04T21:03:39Z

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 · 2020-10-04T21:10:30Z

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 · 2020-10-05T18:18:07Z

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

flodiebold · 2020-10-05T18:21:03Z

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 · 2020-10-05T18:42:56Z

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

thomcc · 2020-10-06T12:39:29Z

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 · 2020-10-06T12:44:46Z

Oh, turns out the experimental ones are on by default

cameron-rowe · 2020-10-12T23:59:35Z

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 · 2020-10-14T01:20:37Z

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 · 2020-10-14T05:26:45Z

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 · 2020-10-14T18:20:52Z

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

The proper fix I think is: * move rust-lang/rust library crates to a separate workspace * when packaging rust-src component, vendor sources of external deps

6294: Add a hacky remidy for #6038 r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>

matklad · 2020-10-20T10:43:33Z

#6294 papers over this issue

The proper fix I think is: * move rust-lang/rust library crates to a separate workspace * when packaging rust-src component, vendor sources of external deps

bjorn3 · 2021-02-07T06:38:37Z

core::arch not resolving is a different issue. This one is due to #[path = "..."] mod arch; not working when the path is not part of any directory assumed to be part of a crate in the crate graph based on the output of cargo metadata.

thomcc · 2021-02-09T21:06:45Z

core::arch not resolving is a different issue. This one is due to #[path = "..."] mod arch; not working when the path is not part of any directory assumed to be part of a crate in the crate graph based on the output of cargo metadata.

Oh. Well. Is there a separate bug for that? How tractable is it to fix in r-a?

If it's very hard to fix in r-a I could do a patch to change stdarch itself to not use #[path] in the name of simplifying things for tooling probably, since usually the alternative there is just a slightly more complex mod/use setup.

…imulacrum Avoid `cfg_if` in `std::os` rust-analyzer cannot currently load the `cfg_if` crate, which means that rust-analyzer is unable to see `std::os::{unix, windows, linux}` here. This works around that by avoiding `cfg_if`; the `#[cfg]` expressions are simple enough to reasonably write by hand. Fixes rust-lang/rust-analyzer#6038

lnicola · 2021-02-24T15:40:10Z

@jonas-schievink this doesn't seem to work for me even after rust-lang/rust#81969:

lnicola · 2021-02-24T15:41:10Z

Oh, there's plenty more in lib/rustlib/src/rust/library/std/src/sys/mod.rs

jonas-schievink · 2021-02-24T15:48:46Z

Ugh, how annoying

elinorbgr · 2021-03-14T11:09:09Z

Has something happened? I was successfully using the "add cfg-if in your dependency tree" method, but since today it no longer works, I again get unresolved import errors in vscode for std::os::unix::*.

Version 0.2.513 of the vscode rust-analyzer extension, and rustc 1.52.0-nightly (acca81892 2021-03-13)

nico-abram · 2021-03-27T21:03:54Z

I'm encountering this issue when doing use std::os::windows::ffi::OsStrExt; (With no conditional compilation attributes, it's a toy project that will only run in my machine). I don't have cfg_if in my dep tree

Move all `sys::ext` modules to `os` This PR moves all `sys::ext` modules to `os`, centralizing the location of all `os` code and simplifying the dependencies between `os` and `sys`. Because this also removes all uses `cfg_if!` on publicly exported items, where after rust-lang#81969 there were still a few left, this should properly work around rust-lang/rust-analyzer#6038. `@rustbot` label: +T-libs-impl

CDirkx · 2021-05-05T21:14:42Z

rust-lang/rust#84200 just got merged, which also removed more cfg_if in publicly exported items. I believe this should make everything in std::os usable, without needing to add cfg-if to your dependency tree. Can anyone confirm if this is the case?

jonas-schievink · 2021-05-05T21:24:17Z

Looks like this block still causes problems with std::os::unix: https:/rust-lang/rust/blob/bacf770f2983a52f31e3537db5f0fe1ef2eaa874/library/std/src/sys/mod.rs#L27-L50

However, std::os::linux seems to work fine now 🎉

Move all `sys::ext` modules to `os` This PR moves all `sys::ext` modules to `os`, centralizing the location of all `os` code and simplifying the dependencies between `os` and `sys`. Because this also removes all uses `cfg_if!` on publicly exported items, where after #81969 there were still a few left, this should properly work around rust-lang/rust-analyzer#6038. `@rustbot` label: +T-libs-impl

noproto · 2021-06-18T01:58:27Z

I'm no longer seeing any errors! (latest toolchain Rust 1.53, nightly rust-analyzer) 🥳🥳🥳

Meister1593 · 2021-06-20T12:27:50Z

Works for me only with git rust-analyzer (pretty much current nightly) and nightly rust 1.55 (nightly-x86_64-unknown-linux-gnu, 1.53 stable didn't work)
rustc 1.55.0-nightly (150fad30e 2021-06-19)
rust-analyzer 3843bd02a 2021-06-20 dev

jonas-schievink · 2021-06-20T16:23:40Z

Cool, looks like we can close this then. The more general problem on the r-a side is tracked in #7637.

xanderio · 2021-08-08T17:08:11Z

I'm still having this issue on my FreeBSD box with std::os::unix::ffi::OsStringExt.
rustc 1.54.0 (a178d0322 2021-07-26)
rust-analyzer bc084a6ee 2021-08-08 dev

jonas-schievink added the A-macro macro expansion label Sep 19, 2020

jonas-schievink removed the A-macro macro expansion label Sep 20, 2020

lnicola mentioned this issue Oct 14, 2020

False unresolved import error #6223

Closed

matklad added E-hard S-unactionable Issue requires feedback, design decisions or is blocked on other work labels Oct 15, 2020

bjorn3 mentioned this issue Oct 16, 2020

Misreport of unresolved import #6249

Closed

tigregalis mentioned this issue Oct 19, 2020

"unresolved import" #6278

Closed

matklad added a commit to matklad/rust-analyzer that referenced this issue Oct 20, 2020

Add a hacky remidy for rust-lang#6038

7a21e93

The proper fix I think is: * move rust-lang/rust library crates to a separate workspace * when packaging rust-src component, vendor sources of external deps

bors bot added a commit that referenced this issue Oct 20, 2020

Merge #6294

be762cc

6294: Add a hacky remidy for #6038 r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>

bnjjj pushed a commit to bnjjj/rust-analyzer that referenced this issue Oct 20, 2020

Add a hacky remidy for rust-lang#6038

d5ae193

The proper fix I think is: * move rust-lang/rust library crates to a separate workspace * when packaging rust-src component, vendor sources of external deps

bjorn3 mentioned this issue Oct 25, 2020

unresolved import: thiserror::Error #6053

Closed

bjorn3 mentioned this issue Nov 3, 2020

Incorrect "unresolved import" in std #6449

Closed

This was referenced Feb 10, 2021

Avoid cfg_if in std::os rust-lang/rust#81969

Merged

Load crates.io dependencies of the standard library #7637

Closed

CDirkx mentioned this issue Apr 14, 2021

Move all sys::ext modules to os rust-lang/rust#84200

Merged

cryptoquick mentioned this issue Jun 9, 2021

[Audit fixes] FOR-16: Unnecessary Extensive Permissions for Private Keys ChainSafe/forest#1151

Merged

jonas-schievink closed this as completed Jun 20, 2021

lnicola mentioned this issue Jul 2, 2021

unresolved import for use std::os::unix::net::{UnixListener, UnixStream}; #9459

Closed

patbecich mentioned this issue Jul 15, 2021

rust-analyzer on WSL cannot find sysroot, VSCode 1.49.2 #6106

Closed

GuillaumeGomez mentioned this issue Sep 3, 2021

Remove cfg(doc) from std::os module reexports to fix rustdoc linking issues rust-lang/rust#88619

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unresolved import for platform specific modules #6038

Unresolved import for platform specific modules #6038

GrayJack commented Sep 19, 2020

jonas-schievink commented Sep 19, 2020

jonas-schievink commented Sep 20, 2020

jfcha commented Sep 21, 2020

ttzztztz commented Sep 24, 2020

iulianR commented Sep 27, 2020

lnicola commented Sep 27, 2020 •

edited

Loading

leshow commented Oct 4, 2020 •

edited

Loading

jonas-schievink commented Oct 4, 2020

thomcc commented Oct 5, 2020

flodiebold commented Oct 5, 2020 •

edited

Loading

jonas-schievink commented Oct 5, 2020

thomcc commented Oct 6, 2020 •

edited

Loading

jonas-schievink commented Oct 6, 2020

cameron-rowe commented Oct 12, 2020

blinsay commented Oct 14, 2020

lnicola commented Oct 14, 2020

matklad commented Oct 14, 2020

matklad commented Oct 20, 2020

bjorn3 commented Feb 7, 2021

thomcc commented Feb 9, 2021

lnicola commented Feb 24, 2021

lnicola commented Feb 24, 2021

jonas-schievink commented Feb 24, 2021

elinorbgr commented Mar 14, 2021

nico-abram commented Mar 27, 2021

CDirkx commented May 5, 2021

jonas-schievink commented May 5, 2021

noproto commented Jun 18, 2021

Meister1593 commented Jun 20, 2021 •

edited

Loading

jonas-schievink commented Jun 20, 2021

xanderio commented Aug 8, 2021 •

edited

Loading

Unresolved import for platform specific modules #6038

Unresolved import for platform specific modules #6038

Comments

GrayJack commented Sep 19, 2020

RA version

Example

jonas-schievink commented Sep 19, 2020

jonas-schievink commented Sep 20, 2020

jfcha commented Sep 21, 2020

ttzztztz commented Sep 24, 2020

iulianR commented Sep 27, 2020

lnicola commented Sep 27, 2020 • edited Loading

leshow commented Oct 4, 2020 • edited Loading

jonas-schievink commented Oct 4, 2020

thomcc commented Oct 5, 2020

flodiebold commented Oct 5, 2020 • edited Loading

jonas-schievink commented Oct 5, 2020

thomcc commented Oct 6, 2020 • edited Loading

jonas-schievink commented Oct 6, 2020

cameron-rowe commented Oct 12, 2020

blinsay commented Oct 14, 2020

lnicola commented Oct 14, 2020

matklad commented Oct 14, 2020

matklad commented Oct 20, 2020

bjorn3 commented Feb 7, 2021

thomcc commented Feb 9, 2021

lnicola commented Feb 24, 2021

lnicola commented Feb 24, 2021

jonas-schievink commented Feb 24, 2021

elinorbgr commented Mar 14, 2021

nico-abram commented Mar 27, 2021

CDirkx commented May 5, 2021

jonas-schievink commented May 5, 2021

noproto commented Jun 18, 2021

Meister1593 commented Jun 20, 2021 • edited Loading

jonas-schievink commented Jun 20, 2021

xanderio commented Aug 8, 2021 • edited Loading

lnicola commented Sep 27, 2020 •

edited

Loading

leshow commented Oct 4, 2020 •

edited

Loading

flodiebold commented Oct 5, 2020 •

edited

Loading

thomcc commented Oct 6, 2020 •

edited

Loading

Meister1593 commented Jun 20, 2021 •

edited

Loading

xanderio commented Aug 8, 2021 •

edited

Loading