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>
10152: feat: Add completion for raw identifiers r=matklad a=nabakin
Adds support for valid Rust completion of raw identifiers.
Previously, code completion of fields made via raw identifiers would not re-insert those raw identifiers, resulting in invalid Rust code. Now, code completion of fields made via raw identifiers do re-insert those raw identifiers, resulting in valid Rust code.
The same is true for all code completion instances for fields and compatible Rust identifiers.
Co-authored-by: Blake Wyatt <894305+nabakin@users.noreply.github.com>
10157: Add section on configuring compilation errors when using `rust-project.json` r=matklad a=dozzman
When using `rust-project.json` to specify the project workspace, flychecks are disabled. It is not mentioned that they can be re-enabled by specifying a custom checking command using the `checkOnSave.overrideCommand` configuration. This additional section makes it clear that using `rust-project.json` disables flychecks and how to enable them either using `cargo check` (as an example) or (more likely) a custom command which emits json error messages.
Further information can be found at this forum thread:
https://users.rust-lang.org/t/rust-analyzer-doesnt-show-cargo-check-compilation-errors-warnings-when-using-rust-project-json/64412
Co-authored-by: Dorian Peake <dozzman@hotmail.co.uk>
10154: feat: Complete `#![recursion_limit = "N"]` instead of `#![recursion_limit = N]` r=lnicola a=hkmatsumoto
Currently ra emits `#![recursion_limit = 128]`, but this should rather be `#![recursion_limit = "128"]`
Co-authored-by: Hirochika Matsumoto <git@hkmatsumoto.com>
10162: feat: enable completions inside macros after `.` r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/8158
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10039
This issue was not caused by us not being able to expand the macro (we can do that just fine). Instead, body lowering deliberately aborted lowering of a statement macro expansion when the expansion causes errors, citing some hygiene-related issue with recovery (`@edwin0cheng` if you remember what exactly the issue was I'd be happy to take a look).
Simply removing that code path doesn't cause any tests to fail, and makes completions in macros work better ("completion after `.`" is not the only thing that now works better, we also get better highlighting in incomplete macro calls).
Just to be sure, lets merge this after tomorrow's release.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10161: Don't dump `DefMap`s to build the panic context r=matklad a=matklad
internal: remove accidental code re-use
FragmentKind played two roles:
* entry point to the parser
* syntactic category of a macro call
These are different use-cases, and warrant different types. For example,
macro can't expand to visibility, but we have such fragment today.
This PR introduces `ExpandsTo` enum to separate this two use-cases.
I suspect we might further split `FragmentKind` into `$x:specifier` enum
specific to MBE, and a general parser entry point, but that's for
another PR!
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
FragmentKind played two roles:
* entry point to the parser
* syntactic category of a macro call
These are different use-cases, and warrant different types. For example,
macro can't expand to visibility, but we have such fragment today.
This PR introduces `ExpandsTo` enum to separate this two use-cases.
I suspect we might further split `FragmentKind` into `$x:specifier` enum
specific to MBE, and a general parser entry point, but that's for
another PR!
