Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading 2020-09-14 -> 2020-09-21 broke #![feature(rustc_private)] #6057

Closed
khyperia opened this issue Sep 22, 2020 · 3 comments
Closed

Upgrading 2020-09-14 -> 2020-09-21 broke #![feature(rustc_private)] #6057

khyperia opened this issue Sep 22, 2020 · 3 comments

Comments

@khyperia
Copy link

khyperia commented Sep 22, 2020

Setup

Cargo.toml:

[package]
name = "nightlytest"
version = "0.1.0"
authors = ["khyperia <github@khyperia.com>"]
edition = "2018"

[lib]
crate-type = ["dylib"]

[dependencies]

rust-toolchain:

nightly

src/lib.rs:

#![feature(rustc_private)]

extern crate rustc_ast;

Expected behavior, behavior on rust-analyzer 2020-09-14

No error

Actual behavior on rust-analyzer 2020-09-21

Red squiggles on the extern crate, with popup unresolved extern crate. cargo build etc. still works fine.

@kiljacken
Copy link
Contributor

Just for context: I don't believe it's as much us breaking rustc_private, but introducing a diagnostic for unresolved imports in rust-analyzer instead of depending on cargo check. So this is very likely #6016.

You should be able to silence the diagnostic by adding the following to your vscode config:

"rust-analyzer.diagnostics.disabled": ["unresolved-extern-crate"]

@khyperia
Copy link
Author

Aah gotcha, thanks, that is indeed what's happening (diagnostics for things in rustc crates still work, e.g. use rustc_ast::asdf errors but use rustc_ast::[valid item] doesn't), sorry for the silly bug report! Should have investigated a little bit more and figured that out.

@kiljacken
Copy link
Contributor

kiljacken commented Sep 22, 2020

No worries! Rather an extraneous bug report than a missed issue :)

EDIT: Also, the false positive should go away once #3517 is fixed, which seemed to have just been unblocked by an upstream update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants