-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
feature: teach rust-analyzer to discover linked_projects
#17246
feature: teach rust-analyzer to discover linked_projects
#17246
Conversation
378ef57
to
e62932f
Compare
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.
Haven't looked at the main_loop.rs and reload.rs changes yet, will do that tomorrow
crates/rust-analyzer/src/reload.rs
Outdated
if self.config.linked_or_discovered_projects() != old_config.linked_or_discovered_projects() | ||
{ | ||
self.fetch_workspaces_queue.request_op("discovered projects changed".to_owned(), false) | ||
self.fetch_workspaces_queue.request_op("discovered projects changed".to_owned(), true) |
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.
Seeing this we should probably make this an enum (I'm at fault for introducing a bool here and being lazy)
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 can change this to an enum, since I'm doing a bunch of surgery here anyways: would something like (bad namesincoming!) ReloadBehavior { Force, Done }
be a decent starting point?
The flycheck crate is a mess now (at least name wise) anyways as it also does stuff for the test explorer, so that doesn't really make things a lot worse now... |
ace6d7d
to
1003808
Compare
☔ The latest upstream changes (presumably #17287) made this pull request unmergeable. Please resolve the merge conflicts. |
1003808
to
57fa458
Compare
☔ The latest upstream changes (presumably #17275) made this pull request unmergeable. Please resolve the merge conflicts. |
57fa458
to
1404d02
Compare
1404d02
to
ce2c55c
Compare
☔ The latest upstream changes (presumably #17278) made this pull request unmergeable. Please resolve the merge conflicts. |
ce2c55c
to
be92e74
Compare
For "reload rust-analyzer reasons when a |
Summary: To support rust-lang/rust-analyzer#17246, I've added an argument for logging using JSON to that rust-analyzer can use these fields for progress reporting. Reviewed By: Wilfred Differential Revision: D57924551 fbshipit-source-id: 992e9e096fdea1eefe2b199d8dd84be7b247a732
☔ The latest upstream changes (presumably #17346) made this pull request unmergeable. Please resolve the merge conflicts. |
93e6138
to
7d6408a
Compare
☔ The latest upstream changes (presumably #17374) made this pull request unmergeable. Please resolve the merge conflicts. |
7d6408a
to
651983d
Compare
f4fe143
to
2f44eb0
Compare
crates/flycheck/src/project_json.rs
Outdated
|
||
#[derive(PartialEq, Clone, Debug, Serialize, Deserialize)] | ||
#[serde(rename_all = "camelCase")] | ||
pub enum Arguments { |
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.
Suggest DiscoverArgument
or similar. This gets used below as project_json::Arguments
which is not entirely self-explanatory. And since this is the interface that other build systems will program their project discovery tools against, needs some docs -- what does RA want them to do, roughly, for Path vs 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.
yeah, i'll add those docs today. thanks!
(the tl;dr is that it assumes a somewhat expansive client like Buck's rust-project
because the smarts can't live in rust-analyzer.)
acf5f3c
to
f3ee31f
Compare
f3ee31f
to
db43a5a
Compare
☀️ Test successful - checks-actions |
…ification, r=Veykril chore: remove `UnindexinedProject` notification This PR is split out from #17246 (and contains its changes, which is a little annoying from a review perspective...). I'd like to land this change a week or so after #17246 lands in order to give any users of the unindexed project notification time to adopt migrate.
…oject-notification, r=Veykril chore: remove `UnindexinedProject` notification This PR is split out from rust-lang/rust-analyzer#17246 (and contains its changes, which is a little annoying from a review perspective...). I'd like to land this change a week or so after rust-lang#17246 lands in order to give any users of the unindexed project notification time to adopt migrate.
…oject-notification, r=Veykril chore: remove `UnindexinedProject` notification This PR is split out from rust-lang/rust-analyzer#17246 (and contains its changes, which is a little annoying from a review perspective...). I'd like to land this change a week or so after rust-lang#17246 lands in order to give any users of the unindexed project notification time to adopt migrate.
`linkedProjects` is owned by the user's configuration, so when users update this setting, `linkedProjects` is reset. This is problematic when `linkedProjects` also contains projects discovered with `discoverCommand`. The buggy behaviour occurred when: (1) The user configures `discoverCommand` and loads a Rust project. (2) The user changes any setting in VS Code, so rust-analyzer receives `workspace/didChangeConfiguration`. (3) `handle_did_change_configuration` ultimately calls `Client::apply_change_with_sink()`, which updates `config.user_config` and discards any items we added in `linkedProjects`. Instead, separate out `discovered_projects_from_filesystem` and `discovered_projects_from_command` from user configuration, so user settings cannot affect any type of discovered project. This fixes the subtle issue mentioned here: rust-lang#17246 (comment)
`linkedProjects` is owned by the user's configuration, so when users update this setting, `linkedProjects` is reset. This is problematic when `linkedProjects` also contains projects discovered with `discoverCommand`. The buggy behaviour occurred when: (1) The user configures `discoverCommand` and loads a Rust project. (2) The user changes any setting in VS Code, so rust-analyzer receives `workspace/didChangeConfiguration`. (3) `handle_did_change_configuration` ultimately calls `Client::apply_change_with_sink()`, which updates `config.user_config` and discards any items we added in `linkedProjects`. Instead, separate out `discovered_projects_from_filesystem` and `discovered_projects_from_command` from user configuration, so user settings cannot affect any type of discovered project. This fixes the subtle issue mentioned here: rust-lang#17246 (comment)
`linkedProjects` is owned by the user's configuration, so when users update this setting, `linkedProjects` is reset. This is problematic when `linkedProjects` also contains projects discovered with `discoverCommand`. The buggy behaviour occurred when: (1) The user configures `discoverCommand` and loads a Rust project. (2) The user changes any setting in VS Code, so rust-analyzer receives `workspace/didChangeConfiguration`. (3) `handle_did_change_configuration` ultimately calls `Client::apply_change_with_sink()`, which updates `config.user_config` and discards any items we added in `linkedProjects`. Instead, separate out `discovered_projects_from_filesystem` and `discovered_projects_from_command` from user configuration, so user settings cannot affect any type of discovered project. This fixes the subtle issue mentioned here: rust-lang#17246 (comment)
fix: Updating settings should not clobber discovered projects `linkedProjects` is owned by the user's configuration, so when users update this setting, `linkedProjects` is reset. This is problematic when `linkedProjects` also contains projects discovered with `discoverCommand`. The buggy behaviour occurred when: (1) The user configures `discoverCommand` and loads a Rust project. (2) The user changes any setting in VS Code, so rust-analyzer receives `workspace/didChangeConfiguration`. (3) `handle_did_change_configuration` ultimately calls `Client::apply_change_with_sink()`, which updates `config.user_config` and discards any items we added in `linkedProjects`. Instead, separate out `discovered_projects_from_filesystem` and `discovered_projects_from_command` from user configuration, so user settings cannot affect any type of discovered project. This fixes the subtle issue mentioned here: #17246 (comment)
`linkedProjects` is owned by the user's configuration, so when users update this setting, `linkedProjects` is reset. This is problematic when `linkedProjects` also contains projects discovered with `discoverCommand`. The buggy behaviour occurred when: (1) The user configures `discoverCommand` and loads a Rust project. (2) The user changes any setting in VS Code, so rust-analyzer receives `workspace/didChangeConfiguration`. (3) `handle_did_change_configuration` ultimately calls `Client::apply_change_with_sink()`, which updates `config.user_config` and discards any items we added in `linkedProjects`. Instead, separate out `discovered_projects_from_filesystem` and `discovered_projects_from_command` from user configuration, so user settings cannot affect any type of discovered project. This fixes the subtle issue mentioned here: rust-lang/rust-analyzer#17246 (comment)
fix: Updating settings should not clobber discovered projects `linkedProjects` is owned by the user's configuration, so when users update this setting, `linkedProjects` is reset. This is problematic when `linkedProjects` also contains projects discovered with `discoverCommand`. The buggy behaviour occurred when: (1) The user configures `discoverCommand` and loads a Rust project. (2) The user changes any setting in VS Code, so rust-analyzer receives `workspace/didChangeConfiguration`. (3) `handle_did_change_configuration` ultimately calls `Client::apply_change_with_sink()`, which updates `config.user_config` and discards any items we added in `linkedProjects`. Instead, separate out `discovered_projects_from_filesystem` and `discovered_projects_from_command` from user configuration, so user settings cannot affect any type of discovered project. This fixes the subtle issue mentioned here: rust-lang/rust-analyzer#17246 (comment)
This PR's been a long-time coming, but like the title says, it introduces server-side project discovery and removes the extension hooks I previously introduced. I don't think this PR is ready to land, but here are the things I'm feeling squishy about:
cargo-metadata
command-but-for-everything-else in theflycheck
module, but the progress reporting infrastructure was too convenient to pass up. Happy to move it elsewhere.Here are the things I know I need to change:
serde_json::Value
that corresponds totracing_subsciber::fmt::Layer
's JSON output. I'd like to make this a bit more structured/documented than the current nonsense I wrote.Anyway, here's a video of rust-analyzer discovering a Buck target.
rust-project.mov