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>
10103: fix: make "find references" multi-token mapping aware r=jonas-schievink a=jonas-schievink
Part of https://github.com/rust-analyzer/rust-analyzer/issues/10070
I was hoping that this would fix "find references" on salsa queries, but salsa emits multiple defs sharing the same span (the trait method, and an impl of that trait).
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9954: feat: Show try operator propogated types on ranged hover r=matklad a=Veykril
Basically this just shows the type of the inner expression of the `?` expression as well as the type of the expression that the `?` returns from:
Unless both of these types are `core::result::Result` in which case we show the error types only.
If both types are `core::option::Option` with different type params we do not show this special hover either as it would be pointless(instead fallback to default type hover)
Very much open to changes to the hover text here(I suppose we also want to show the actual type of the `?` expression, that is its output type?).
Fixes#9931
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
