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!
10148: docs: make dev docs more discoverable r=matklad a=matklad
I *think* people might try to debug ra by using only the troubleshooting
section. Might make sense to point them to dev docs then!
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
10146: fix: use placeholder as default type in `Generate function` and `Extract into function`. r=matklad a=iDawer
Closes#10123
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
10139: Fix replacing for loops over ranges with for_each. r=yotamofek a=yotamofek
Previously, the assist would turn this:
```rust
for x in 0..92 {
...
}
```
into the syntactically incorrect code below:
```rust
0..92.for_each(|x| ...)
```
This fixes the assist by parenthesizing range expressions.
Co-authored-by: Yotam Ofek <yotam.ofek@gmail.com>
10132: docs(logging): use `tracing` for logging r=matklad a=dzvon
Currently, we're using `tracing` for logging, but the doc is lagging, so update it.
#9274
Co-authored-by: Dezhi Wu <wu543065657@163.com>
10127: fix: When descending tokens don't bail on failed macro call expansions r=Veykril a=Veykril
(with `#[test]` expansion enabled)
The problem was pretty simple, since we go through the ancestors we first try to expand the macro call node we are in since in attributed items these are valid syntaxnodes instead of TokenTrees, we then fail the expansion since the expansion only exists in the attribute expanded file and therefor skip the attribute expansion due to returning immediately. So instead of breaking out we just continue looking up the ancestors.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10115
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
