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
`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
forward linker option to lint-docs
This fixes an error found when building the doc for a cross-built toolchain.
```
warning: the code example in lint `unstable_syntax_pre_expansion` in /buildroots/chenx97/rustc-1.80.1-src/compiler/rustc_lint_defs/src/builtin.rs failed to generate the expected output: did not find lint `unstable_syntax_p
re_expansion` in output of example, got:
error: linking with `cc` failed: exit status: 1
...
```
Closes: #129956
copy rustc rustlib artifacts from ci-rustc
We recently (since https://github.com/rust-lang/rust/pull/129311) had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast") when building tools that rely on rustc. This patch fixes that by copying those files as required.
r? Kobzol
Blocker for https://github.com/rust-lang/rust/pull/122709
explain why Rvalue::Len still exists
I just spent a bit of time trying to remove this until I realized why that's non-trivial. Let's document that for the next person. :)
bootstrap: Try to track down why `initial_libdir` sometimes fails
When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this:
```text
thread 'main' panicked at src/lib.rs:341:14:
called `Result::unwrap()` on an `Err` value: StripPrefixError(())
```
It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs.
Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have.
So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
fix ICE when `asm_const` and `const_refs_to_static` are combined
fixes https://github.com/rust-lang/rust/issues/129462fixes#126896fixes#124164
I think this is a case that was missed in the fix for https://github.com/rust-lang/rust/pull/125558, which inserts a type error in the case of an invalid (that is, non-integer) type being passed to an asm `const` operand.
I'm not 100% sure that `span_mirbug_and_err` is the right macro here, but it is used earlier with `builtin_deref` and seems to do the trick.
r? ``@lcnr``
Add an internal lint that warns when accessing untracked data
Some methods access data that is not tracked by the query system and should be used with caution. As suggested in https://github.com/rust-lang/rust/pull/128815#issuecomment-2275488683, in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions.
I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough.
r? ``@oli-obk``
feat: Suggest name in completion for let_stmt and fn_param
fix#17780
1. Refactor: move `ide_assist::utils::suggest_name` to `ide-db::syntax_helpers::suggest_name` for reuse.
2. When completing `IdentPat`, detecte if the current node is a `let_stmt` or `fn_param`, and suggesting a new name based on the context.
