-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add rust-analyzer-proc-macro-srv
binary, use it if found in sysroot
#12858
Changes from 1 commit
5f54ec0
fba6adf
fd1b64e
4364531
dadb832
74a2fad
6967751
2c2520f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -305,8 +305,34 @@ impl GlobalState { | |||
|
||||
if self.proc_macro_clients.is_empty() { | ||||
if let Some((path, args)) = self.config.proc_macro_srv() { | ||||
self.proc_macro_clients = (0..self.workspaces.len()) | ||||
.map(|_| { | ||||
self.proc_macro_clients = self | ||||
.workspaces | ||||
.iter() | ||||
.map(|ws| { | ||||
let mut path = path.clone(); | ||||
if let ProjectWorkspace::Cargo { sysroot, .. } = ws { | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So at this point in time, we don't have any support for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did proc-macros ever work for project.json workspaces actually? From the looks of it we never even build build scripts for them since we can't really do that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, proc macros should work with project.json workspaces. We have a field that allows specifying the path of the compiled proc macro. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you point me to where the proc-macro-srv is spawned for ProjectWorkspace::Json workspaces? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @woody77 that match is definitely missing an arm I forgot to add when I added the additional field to rust-project.json's schema. I also didn't have any projects to test it with. I encourage you to open the small PR to fix it! |
||||
tracing::info!("Found a cargo workspace..."); | ||||
if let Some(sysroot) = sysroot.as_ref() { | ||||
tracing::info!("Found a cargo workspace with a sysroot..."); | ||||
let server_path = sysroot | ||||
.root() | ||||
.join("libexec") | ||||
.join("rust-analyzer-proc-macro-srv"); | ||||
if std::fs::metadata(&server_path).is_ok() { | ||||
tracing::info!( | ||||
"And the server exists at {}", | ||||
server_path.display() | ||||
); | ||||
path = server_path; | ||||
} else { | ||||
tracing::info!( | ||||
"And the server does not exist at {}", | ||||
server_path.display() | ||||
); | ||||
} | ||||
} | ||||
} | ||||
|
||||
ProcMacroServer::spawn(path.clone(), args.clone()).map_err(|err| { | ||||
let error = format!( | ||||
"Failed to run proc_macro_srv from path {}, 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.
I think the names of this and
root
should be swapped. Also it did be nice ifpath/to/sysroot/lib/rustlib/src/rust
could be derived frompath/to/sysroot
if the former is not given.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.
oh I got my comments mixed up, hang on
(I already did the name swap - thankfully
ProjectJson
already had the proper naming)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.
Okay, comments fixed in 6967751
We never have a case where
root
is given butsrc_root
is missing: previously,Sysroot
could only be built when passingsrc_root
. And simply joininglib/rustlib/src/rust
is not a great idea. We already have a method for that (discover_sysroot_src_dir
) and it respectsRUST_SRC_PATH
.I considered making it so that building a
Sysroot
always takesroot
and an optionalsrc_root
(and ifsrc_root
is missing, we use the "discover" method), but decided against it, since:src_root
(it doesn't reproduce the directory structure of a real sysroot). We could fix that test case, no big deal, but...rust-project.json
, which up until now only allowed asysroot_src
field, not asysroot
field.And going from
sysroot_src
tosysroot
seems like a bad idea - it would involve checking that the last few path components are["lib", "rustlib", "src", "rust]
, and removing them. I don't feel great about that.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 we should allow only giving the
sysroot
field and skippingsysroot_src
.Why not?
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.
Because non-cargo projects (
ProjectWorkspace::Json
) might have "libstd sources" somewhere but not a "sysroot" like we expect for cargo projects, maybe? I'm not sure.The question is where?
For cargo projects, we already call
discover_*
functions for bothroot
andsrc_root
. Those respectRUST_SRC_PATH
for example.For
ProjectWorkspace::Json
projects, I'm not sure who sets the standard (maybe RA does?), but therust-project.json
format currently only has asysroot_src
field. Is that the case where you want to allow passingsysroot
and "guess"sysroot_src
?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.
Using sysroot + lib/rustlib/src/rust as fallback for sysroot_src would work fine in that case, 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.
No, they specify the
lib/rustlib/src/rust
- we can't get what we need by joining additional path segments, we need to strip some, and that feels really iffy (but we can do it if we want)There's zero codepaths where we have
sysroot
but notsysroot_src
.sysroot
is a directory withsrc/
,lib/
,libexec/
,etc/
, etc.sysroot_src
is a deeper path with libstd sources (sorry about the initial confusion, my comments were swapped).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.
You don't have sysroot_src if the user didn't specify one. I think the behavior should be:
if user specifies sysroot_src => use it, else use sysroot + lib/rustlib/src/rust
Or to put it another way:
sysroot_src is not specified by the user, set it to sysroot + lib/rustlib/src/rust
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, right. But right now no one is specifying
sysroot
either. That would require bazel (or other build systems that generaterust-project.json
files) to set that field.We should really discuss the
Cargo
/Json
cases separately 😂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 implemented what I think you and @jyn514 asked for in 2c2520f