diff options
| author | bors <bors@rust-lang.org> | 2024-09-06 06:04:03 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2024-09-06 06:04:03 +0000 |
| commit | ecd835de15e14891d70529a9e64a1cc705f10470 (patch) | |
| tree | 73e95611323a3aea55c4a4152b61d2097dacff22 /compiler/rustc_codegen_llvm/src | |
| parent | a3be86666893ab0b79e53c301f34fd29d9550447 (diff) | |
| parent | 06c86a106915b5875391a7abdd749f1708dc3b50 (diff) | |
| download | rust-ecd835de15e14891d70529a9e64a1cc705f10470.tar.gz rust-ecd835de15e14891d70529a9e64a1cc705f10470.zip | |
Auto merge of #18059 - Wilfred:config_cleanups, r=Veykril
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: https://github.com/rust-lang/rust-analyzer/pull/17246#issuecomment-2185259122
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions