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>
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
