Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10243, I couldn't reproduce the panic with the given snippet, but this change should still guard against it.
bors r+
The way rustc solves this is rather ad-hoc. In rustc, token trees are
allowed to include whole AST fragments, so 1+2 is passed through macro
expansion as a single unit. This is a significant violation of token
tree model.
In rust-analyzer, we intended to handle this in a more elegant way,
using token trees with "invisible" delimiters. The idea was is that we
introduce a new kind of parenthesis, "left $"/"right $", and let the
parser intelligently handle this.
The idea was inspired by the relevant comment in the proc_macro crate:
> An implicit delimiter, that may, for example, appear around tokens
> coming from a “macro variable” $var. It is important to preserve
> operator priorities in cases like $var * 3 where $var is 1 + 2.
> Implicit delimiters might not survive roundtrip of a token stream
> through a string.
Now that we are older and wiser, we conclude that the idea doesn't work.
_First_, the comment in the proc-macro crate is wishful thinking. Rustc
currently completely ignores none delimiters. It solves the (1 + 2) * 3
problem by having magical token trees which can't be duplicated:
_Second_, it's not like our implementation in rust-analyzer works. We
special-case expressions (as opposed to treating all kinds of $var
captures the same) and we don't know how parser error recovery should
work with these dollar-parenthesis.
So, in this PR we simplify the whole thing away by not pretending that
we are doing something proper and instead just explicitly special-casing
expressions by wrapping them into real `()`.
In the future, to maintain bug-parity with `rustc` what we are going to
do is probably adding an explicit `CAPTURED_EXPR` *token* which we can
explicitly account for in the parser.
If/when rustc starts handling delimiter=none properly, we'll port that
logic as well, in addition to special handling.
bors[bot] [Sat, 23 Oct 2021 13:30:32 +0000 (13:30 +0000)]
Merge #10617
10617: Set MSRV r=Veykril a=lnicola
Set the MSRV to `1.56` since we're already on the 2021 edition and building with older version fails.
From now on, there'll be a change in behavior: `xtask install` used to warn on old toolchains, but now the user will get an error. This isn't so bad because:
- the check in `xtask install` wasn't always working (because sometimes `xtask` itself required a newer toolchain)
- we generally bump the required version for a reason (when using a newer feature). We might forget to bump it, but when we do, older toolchains won't work
bors[bot] [Wed, 20 Oct 2021 21:02:46 +0000 (21:02 +0000)]
Merge #10563
10563: feat: Make "Generate getter" assist use semantic info r=agluszak a=agluszak
This PR makes "Generate getter" assist use semantic info instead of dealing with types encoded as strings.
Getters for types which are:
- `Copy` no longer return references
- `AsRef<str>` (i.e. `String`) return `&str` (instead of `&String`)
- `AsRef<[T]>` (i.e. `Vec<T>`) return `&[T]` (instead of `&Vec<T>`)
- `AsRef<T>` (i.e. `Box<T>`) return `&T` (instead of `&Box<T>`)
- `Option<T>` return `Option<&T>` (instead of `&Option<T>`)
- `Result<T, E>` return `Result<&T, &E>` (instead of `&Result<T, E>`)
String, Vec, Box and Option were previously handled as special cases.
Closes #10295
Co-authored-by: Andrzej Głuszak <gluszak.andrzej@gmail.com>
bors[bot] [Wed, 20 Oct 2021 20:54:36 +0000 (20:54 +0000)]
Merge #10387
10387: Move `IdxRange` into la-arena r=Veykril a=arzg
Currently, `IdxRange` (named `IdRange`) is located in `hir_def::item_tree`, when really it isn’t specific to `hir_def` and could become part of la-arena. The rename from `IdRange` to `IdxRange` is to maintain consistency with the naming convention used throughout la-arena (`Idx` instead of `Id`, `RawIdx` instead of `RawId`). This PR also adds a few new APIs to la-arena on top of `IdxRange` for convenience, namely:
- indexing into an `Arena` by an `IdxRange` and getting a slice of values back
- creating an `IdxRange` from an inclusive range
Currently this PR also exposes a new `Arena::next_idx` method to make constructing inclusive`IdxRange`s using `IdxRange::new` easier; however, it would in my opinion be better to remove this as it allows for easy creation of out-of-bounds `Idx`s, when `IdxRange::new_inclusive` mostly covers the same use-case while being less error-prone.
I decided to bump the la-arena version to 0.3.0 from 0.2.0 because adding a new `Index` impl for `Arena` turned out to be a breaking change: I had to add a type hint in `crates/hir_def/src/body/scope.rs` when one wasn’t necessary before, since rustc couldn’t work out the type of a closure parameter now that there are multiple `Index` impls. I’m not sure whether this is the right decision, though.
bors[bot] [Mon, 18 Oct 2021 12:56:33 +0000 (12:56 +0000)]
Merge #10578
10578: Fix partialord codegen take 2 r=lnicola a=yoshuawuyts
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10576. This reverts "generate `PartialOrd` to our previous match-based design, and in turn uses that to correctly take references for multi-value comparisons. This is a bit more verbose, but it should be more readable and easier to edit by end-users than multiple nested layers of borrows. I also manually verified every example in the Rust playground to ensure it works. Thanks!
bors[bot] [Sat, 16 Oct 2021 10:28:46 +0000 (10:28 +0000)]
Merge #10542
10542: Use workspace cargo to fetch rust source's metadata r=lnicola a=Alexendoo
Previously the detected cargo is the global one, as it uses the
directory of the rust source which doesn't pick up the local override
This fixes the case in clippy where the local rust toolchain is a recent
nightly that has a 2021 edition Cargo.toml. The global (stable) cargo
returns an error attempting to parse it