10375: minor: Use SmallVec<[_; 1]> in `descend_into_macros_impl` r=Veykril a=Veykril
A lot of descends don't actually descend in which case we don't wanna allocate
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10374: fix: Make `stringify!` insert/collapse whitespace when needed r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10365
Unlike rustc, we don't insert newlines, but that should be fine.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
10353: Remove `GenericParams::new` r=SkiFire13 a=SkiFire13
Helps with #10305
I made the implementations of `HasChildSource<_>` and `ChildBySource` for `GenericDefId` use their own logic instead of relying on `GenericParams::new`. This in turn means that `GenericParams::new` is unused and can be removed. `SourceMap` becomes also unused because all the rest of the code does is insert into it, so it can be removed too.
This also helps avoid creating a completly new `GenericParams` when `GenericDefId::child_source` and `GenericDefId::child_by_source_to` are called, and also creating a `SourceMap` in `item_tree::lower::Ctx::lower_generic_params`.
Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
Consider these expples
{ 92 }
async { 92 }
'a: { 92 }
#[a] { 92 }
Previously the tree for them were
BLOCK_EXPR
{ ... }
EFFECT_EXPR
async
BLOCK_EXPR
{ ... }
EFFECT_EXPR
'a:
BLOCK_EXPR
{ ... }
BLOCK_EXPR
#[a]
{ ... }
As you see, it gets progressively worse :) The last two items are
especially odd. The last one even violates the balanced curleys
invariant we have (#10357) The new approach is to say that the stuff in
`{}` is stmt_list, and the block is stmt_list + optional modifiers
BLOCK_EXPR
STMT_LIST
{ ... }
BLOCK_EXPR
async
STMT_LIST
{ ... }
BLOCK_EXPR
'a:
STMT_LIST
{ ... }
BLOCK_EXPR
#[a]
STMT_LIST
{ ... }
10357: internal: fix and force-disable block validation ;-( r=matklad a=matklad
Originally we tried to maintain the invariant that `{}` always match.
That is, that in the parse tree the pair of corresponding `{}` is always
first and last tokens of some nodes.
We had the code to validate that, but apparently it's been broken for
**years** since we introduced tokens/nodes split. Fixing it now makes
some tests fail.
It's unclear if we want to keep this invariant: there's a strong
motivation for breaking it in the following case:
```
use std::{ // unclosed paren
fn main() {
}
} // don't actually want to pair up this with the one from `use`
```
So let's fix the code, but disable it for the time being
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Originally we tried to maintain the invariant that `{}` always match.
That is, that in the parse tree the pair of corresponding `{}` is always
first and last tokens of some nodes.
We had the code to validate that, but apparently it's been broken for
**years** since we introduced tokens/nodes split. Fixing it now makes
some tests fail.
It's unclear if we want to keep this invariant: there's a strong
motivation for breaking it in the following case:
```
use std::{ // unclosed paren
fn main() {
}
} // don't actually want to pair up this with the one from `use`
```
So let's fix the code, but disable it for the time being
