Should fix#10090, #10046, #10179.
This is only a workaround, but the proper fix requires some bigger
refactoring (also related to fixing #10058), and this at least prevents
the crash.
10177: fix: Treat path dependencies like workspace members r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/9070
Fixes diagnostics not showing up in path dependencies.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10093: fix: Remove incorrectly filtering VS Code cargo task execution resolution by scope r=oeed a=oeed
This fixes#9093 introduced by #8995.
A filter was present on the function that adds the execution definition to Cargo tasks. This would mean Cargo tasks defined in workspaces (i.e. `.code-workspace` files) would not be given an execution, leading to a `There is no task provider registered for tasks of type "cargo".` error as descibed in #9093. I have made a minimum reproduction setup [here](https://github.com/oeed/ra-workspace).
This PR essentially removes that check. The `if (scope) { ... }` is to handle the case where `task.scope === undefined` using a deprecated constructor. I'm not sure if that is ever likely to occur and can remove if not needed.
There is some discussion about whether it's necessary to filter the tasks before building them. From my understanding, it shouldn't be needed as we should provide an execution for all `cargo` tasks; but I'm not overly familiar with VS Code internals so I could be wrong. For more info please see [the discussion](https://github.com/rust-analyzer/rust-analyzer/pull/8995#issuecomment-908920395) on #8995
Co-authored-by: Oliver Cooper <oliver.cooper@me.com>
10180: Fix resolution for inherent array methods r=flodiebold a=yotamofek
My second attempt at fixing #9992 , previous attempt was here: #10017 , but the logic was broken.
I know that this is not an ideal solution.... that would require, IIUC, a pretty big overhaul of the const generics handling in `rust-analyzer`. But, given that some of the array methods were/are being stabilized (e.g. https://github.com/rust-lang/rust/pull/87174 ), I think it'll be very beneficial to `rust-analyzer` users to have some preliminary support for them. (I know it's something I've been running into quite a lot lately :) )
As far as my limited understanding of this project's architecture goes, I think this isn't the worst hack in the world, and shouldn't be too much of a hassle to undo if/when const generics become better supported. If the maintainers deem this approach viable, I'll want to add some comments, emphasizing the purpose of this code, and that it should be removed at some point in the future.
Co-authored-by: Yotam Ofek <yotam.ofek@gmail.com>
10165: update to tracing-tree 0.1.10, which does not pull in syn r=matklad a=davidbarsky
I've updated tracing-tree to 0.1.10, which does not pull in syn and proc-macro2 (thanks for [the PR](https://github.com/davidbarsky/tracing-tree/pull/32), `@matklad!).`
It took a little bit more work than I expected to land https://github.com/davidbarsky/tracing-tree/issues/33, but I should get that done this week. However, I didn't want to keep y'all waiting, so here's _some_ of the changes that should hopefully improve your compile times.
Co-authored-by: David Barsky <me@davidbarsky.com>
