-
Notifications
You must be signed in to change notification settings - Fork 224
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
rust-project check TARGET
#767
base: main
Are you sure you want to change the base?
rust-project check TARGET
#767
Conversation
By fixing & removing the workaround for missing JSON output that swallowed all the BXL errors too.
This became necessary when I was debugging a sysroot that by mistake did not have rust-src due to being a "minimal" rustup toolchain. I figure that might be a common mistake.
My feeling is that we should move over to |
Only problem is there are other buck users that are adopting rust-project and using saved file. Maybe it's still few enough people that we can break the CLI. |
@@ -11,4 +11,4 @@ | |||
|
|||
# @rustc_version: rustc 1.80.0-nightly (804421dff 2024-06-07) | |||
channel = "nightly-2024-06-08" | |||
components = ["llvm-tools-preview","rustc-dev","rust-src"] | |||
components = ["llvm-tools-preview","rustc-dev","rust-src", "rust-analyzer"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is for neovim support, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For any support -- you need this component to have the proc macro server even if you're using a custom build of rust analyzer, IIRC. Just generally very difficult to contribute without it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah! despite being on the rust-analyzer team, I didn't know that rust-analyzer
implies the proc macro server as well.
/// It also claims that `${sysroot}/lib/rustlib/src/rust/library` is the | ||
/// default value. But it fails to add `std` and `core` as dependencies | ||
/// if you do not provide a value. So we will always provide one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if that's inaccurate documentation or an intentional change: Rust-for-Linux/linux@fe99216. I'll try to clarify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#756 did the same thing. I was just carrying this patch for a while and documented it a little. I kinda think it is a bug in RA.
@@ -485,6 +550,24 @@ impl Buck { | |||
cmd | |||
} | |||
|
|||
/// Return the absolute path of the CELL root for a given buck target label |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Return the absolute path of the CELL root for a given buck target label | |
/// Return the absolute path of the cell root for a given target. |
runnables: vec![ | ||
let mut runnables = vec![ | ||
Runnable { | ||
kind: RunnableKind::Flycheck, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops, i thought i called this check
. we should probably resolve this in rust-analyzer, but i'm not sure in favor of what.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think check should, in VSCode, open the terminal with the text rendered diagnostics from cargo/buck etc. Very often the inline diagnostics from LSP do not live up to the standard set by rustc's text renderer and you need to see it in the terminal to understand what rustc is honking about. Flycheck should be for the JSON output.
The existing "check" runnable just runs buck2 build, which is what I'm describing already.
}) | ||
} | ||
|
||
fn validate(sysroot_src: &Path) -> Result<(), anyhow::Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
naive question: how would you feel about reducing this to a rustup component list
and scanning for a rust-src
? rustup doesn't really have machine-readable output, but that might simplify this a bit...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't work if you use Nix without rustup. Which I do. This way works for all methods including, for example, a custom sysroot built by buck.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, gotcha. I need to remind myself of what rust-analyzer does to handle sysroots
, but checking whether core
gives me some slight unease: I think if $SYSROOT/lib/rustlib/src/rust/library
exists, I'm not sure how useful it'd be to check that $SYSROOT/lib/rustlib/src/rust/library/core
also exists: something with the packaging has already gone terribly wrong if core
(or any other path!) doesn't exist in the sysroot_src
directory.
Stepping back, I'll also check how stable the directory layout of sysroot_src
is and figure out when/how we might need to change it in rust-project and rust-analyzer. My personal feeling is that I'm fine if it's not stable, but I'd prefer to only make the change in one spot—rust-analyzer, not rust-analyzer and rust-project. I'd like to have that solved for every user of rust-analyzer, not just the somewhat nice minority who use buck2 and rust-analyzer. There's also substantial logistical benefits: a change in rust-lang/rust
could also immediately update rust-analyzer's logic in a single PR.
(For context, I use two workflows: rustup install nightly
for Cargo-based projects + a Buck-managed sysroot for Buck stuff.)
Gotcha! I think we should keep the For what it's worth, I always viewed the |
Context: relies on the as-yet unmerged rust-lang/rust-analyzer#18043, which adds
{label}
interpolation in rust-analyzer flycheck commands and allowsrust-project develop-json
to supply the flycheck commands.Previously rust-project worked with the
$saved_file
interpolation in rust-analyzer. This PR makes it work with a target label, substituted as{label}
instead. So it's not really backwards compatible, but we could make it so. Submitting this now to get feedback.We also now emit flycheck runnables that configure rust-analyzer to do flychecks using
rust-project check
.Also:
rust-project develop-json --use-clippy false
rust-src
component. This was an undocumented requirement and rust-analyzer just doesn't work without it, so we should fail as early as possible.buck2 test
runnables, the new ones work with the rustc_test harness and OSS buck2.Attn @davidbarsky