-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
internal: Implement invocation strategy config #13128
Conversation
@Veykril the "OnceInRoot" strategy looks like exactly what we want :) I'd love to see this merged, is there any way I can help out? Maybe test this locally on rust-lang/rust for you? Not sure how to do that but I'm happy to try. |
There is nothing specific blocking this PR aside from me finishing iirc in regards to build scripts. For Because of the problem with cargo actually, none of the modes other than what r-a currently does works with cargo emitted diagnostics by default, rust-lang/cargo#11007 |
Testing it would be great as well though (I don't really know the workspace setup in rustc to reliable know how to check this right now). In theory to test that, all you need to do is set the |
f32ea38
to
c104f0e
Compare
Okay, the PR is basically done now, but checkOnSave while implemented, won't work without changes to x.py or cargo. The build script stuff should just work assuming x.py emits all the metadata for the workspaces when building with proper paths (this is an assumption, we'd need to test that). checkOnSave will not work as is though, cargo emits paths in diagnostics relative to the workspace root, that means if x.py forwards the diagnostics as is to r-a, r-a won't know what files to associate these with, because it now gets diagnostics with workspace relative paths for all workspaces without the corresponding workspaces, so either x.py has to fix these paths up (as it should know from what workspaces the diagnostics come) or we need to fix rust-lang/cargo#11007 assuming x.py uses that under the hood. rust-lang/cargo#11007 needs to be fixed nevertheless for |
So you decided against adding interpolation for this? That seemed like the more general thing.
In "per workspace in the project root" mode, we could declare that RA interprets diagnostics paths relative to the folder containing the workspace toml file -- that should work, right? "once in the project root" indeed cannot currently work due to rust-lang/cargo#11007 (unless we teach bootstrap to translate the paths it receives from cargo). |
Not strictly, this was just simpler to implement for now. I wanted to get the general thing working first, it probably makes sense to switch this to intepolation before finalizing the PR.
Right, that mode actually works fine as is, not sure why I thought differently, there is no problem here since we still know the workspaces. |
☔ The latest upstream changes (presumably #13058) made this pull request unmergeable. Please resolve the merge conflicts. |
Great :) how can I use this build of rust-analyzer with rust-lang/rust? I see https://github.com/rust-lang/rust-analyzer/tree/master/docs/dev#launching-rust-analyzer, but I tried |
Hmm, odd, that should be enough. You could also try building via |
81e9571
to
5bd7d26
Compare
☔ The latest upstream changes (presumably #13259) made this pull request unmergeable. Please resolve the merge conflicts. |
5bd7d26
to
18cbf41
Compare
☔ The latest upstream changes (presumably #13268) made this pull request unmergeable. Please resolve the merge conflicts. |
1f983d2
to
aba8ad7
Compare
aba8ad7
to
a3549dd
Compare
Alright this is now ready (the interpolation implemented here is just a replacement of There is basically only the question of naming left, what should the configs be called, current names are More important is the name for the interpolation var I also tested that |
Miri is fine even without this PR, since we introduced a But rustc needs something like this PR -- specifically Not sure how much sense that makes but it could work. I am just not sure if |
Ye, tying the working directory to the interpolation var seems rather odd, I realized this as well now. Will probably split the
Ye, the diagnostics/checkOnSave stuff the bootstrap people will probably have to figure out, but this PR should give them all the tools needed for that then with the last changes I just mentioned if I see this right. Thanks for dropping the valuable information here :) |
per_workspace_from_root without interpolation is a bit odd though since it means the script has no way to know which project even needs to be built. Granted, x.py can't (currently) make use of that information, but in general it seems like that would be good to have... |
Well, it would be certainly great if x.py could make use of the manifest-path arg, because a check right now is more expensive than it needs to be I think. At least from a quick test running x.py check takes a long time even if I'm only interested in one workspace (though I have almost no experience with the rustc codebase). I'm a bit split now though, you are right that |
It should. We run cargo under the hood, which will replay its diagnostic cache. |
☔ The latest upstream changes (presumably #13385) made this pull request unmergeable. Please resolve the merge conflicts. |
crates/flycheck/src/lib.rs
Outdated
with_manifest_path = true; | ||
cmd.arg(arg.replace( | ||
"$manifest_path", | ||
&self.root.join("Cargo.toml").display().to_string(), |
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.
There should be a check for rust-project.json
here, I think (and of course placing rust-project.json
when it's being used instead)
Note that due to how cargo works, none of the modes currently work for r-a
bb57ffe
to
448d34b
Compare
I removed the simplistic interpolation from this, as I'll rather do that properly with a bit more thought behind. The PR itself is good to go though and the rustc repo at least benefits from the |
@bors r+ |
Implement invocation strategy config Fixes #10793 This allows to change how we run build scripts (and `checkOnSave`), exposing two configs: - `once`: run the specified command once in the project root (the working dir of the server) - `per_workspace`: run the specified command per workspace in the corresponding workspace This also applies to `checkOnSave` likewise, though `once_in_root` is useless there currently, due to rust-lang/cargo#11007
448d34b
to
4673236
Compare
@bors r+ |
☀️ Test successful - checks-actions |
Implement invocation location config This allows setting the working directory for build-scripts on flycheck Complements #13128 This will be followed up by one more PR that adds a few simple interpolation vars for `overrideCommand`, with that we should cover the needs for most build systems I believe.
Could someone clarify what these settings do exactly? the descriptions are pretty vague imo and I don't understand them. |
cc #10793
This allows to change how we run build scripts (and
checkOnSave
), exposing two configs:once
: run the specified command once in the project root (the working dir of the server)per_workspace
: run the specified command per workspace in the corresponding workspaceThis also applies to
checkOnSave
likewise, thoughonce_in_root
is useless there currently, due to rust-lang/cargo#11007