10218: minor: Don't spam the manual with warnings r=lnicola a=lnicola
A single warning on the first line should™ be enough. Currently we put that warning on every section, while also breaking the table of contents in the process:
10215: Use correct file syntax node for decl_access computation in find_all_refs r=Veykril a=Veykril
Defs and refs of locals only ever life in one file, this isn't true for fields though.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10201
10212: fix: Avoid type inference panic on bitslice methods r=flodiebold a=flodiebold
Should fix #10090, fix #10046, and fix #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.
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.
This adds implicit `: Sized` bound to type parameters at lowering step.
Hovering on type parameter does not show it's `: Sized` bound be it set explicitly or implicitly. This is because it doesn't track that the bound was set implicitly.
10193: fix: fix type mismatches with `panic!()` on Rust 1.55.0 r=jonas-schievink a=jonas-schievink
This addresses the regression mentioned in https://github.com/rust-analyzer/rust-analyzer/issues/8961#issuecomment-916332702
(no test because https://github.com/rust-analyzer/rust-analyzer/issues/10192 makes that rather hard, but I've checked that the analysis-stats are back to normal)
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
The new bracket pair colorization feature of vscode colorizes all brackets no matter the language. In the context of rust colorizing the '<' and '>' brackets doesn't make sense most of the time, especially in match statements with math like the following screenshot.
Currently this configuration is only possible on a language server level which is why this PR is necessary.
See https://github.com/microsoft/vscode/issues/132175 and https://github.com/microsoft/vscode/issues/132476 for more information on the issue in vscode
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.
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.
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.
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:
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>
10155: Minor: replace old name `CrateDefMap` in comments r=jonas-schievink a=toyboot4e
This PR replaces the old name `CrateDefMap` in comments with the new name `DefMap`. The renaming was done in [57a82fb0](https://github.com/rust-analyzer/rust-analyzer/commit/57a82fb0) (Jan 2021).
I didn't touch the working code ([CrateDefMapQueryQuery][QQ]). Thank you.
projects / rust.git / log