-
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
Collapse invocationLocation and invocationStrategy into a single setting #17848
Comments
+1 for keeping To add context, these settings were generally never meant to stick around, they were only an escape hatch for rustc's |
So the best way to go about this is to remove the one config half here rust-analyzer/crates/rust-analyzer/src/config.rs Lines 83 to 95 in 56f63df
rust-analyzer/crates/rust-analyzer/src/config.rs Lines 185 to 198 in 56f63df
In the build scripts part changes are simply, the branch here can be dropped for picking rust-analyzer/crates/project-model/src/build_dependencies.rs Lines 66 to 69 in 56f63df
and the branch here can be dropped, we will always use root here rust-analyzer/crates/project-model/src/build_dependencies.rs Lines 92 to 100 in 56f63df
For flycheck you'll have to drop the outer match here https://github.com/veykril/rust-analyzer/blob/56f63dfd8aeebf80e3fc87894fa3d5a40f98a329/crates/rust-analyzer/src/flycheck.rs#L434-L449 and change the |
@rustbot claim |
These options were added to explore how RA can best work with repos like rustc and Miri that need special non-cargo invocations (
./x.py ...
/./miri ...
). The consensus that generally has emerged is that these scripts should be invoked exactly once, in the root, and they will emit all the diagnostics for all parts of the project with paths relative to the root. There were ideas of having RA pass--manifest-path
or so, with template magic available inoverrideCommand
to control where to put that flag; I don't think any more that those are promising.If there are no other usecases being covered by these flags then most of the freedom provided by having two independent settings, invocationLocation and invocationStrategy, isn't actually needed. A possible simplification here might be to only have invocationLocation, and if it is set to "root" then that also implies running it only once (since it seems kind of pointless to run the same command in the same location multiple times). invocationStrategy could then be removed. Or conversely,
invocationStrategy
is preserved and setting it toonce
means "run it once, in the root".The text was updated successfully, but these errors were encountered: