It feels wrong using the database in this part of the code, but this was the only way to figure out whether a file belongs to a proc-macro that I could think of.
For `-gnu` triples, use 20.04, the current LTS. This upgrades the
required version of glibc. For musl, just use `latest` as, presumably,
we don't care about glibc version in that case.
Aleksey Kladov [Sun, 31 Oct 2021 10:05:40 +0000 (13:05 +0300)]
feat: upgrade ubuntu builders
For `-gnu` triples, use 20.04, the current LTS. This upgrades the
required version of glibc. For musl, just use `latest` as, presumably,
we don't care about glibc version in that case.
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] [Tue, 26 Oct 2021 18:55:42 +0000 (18:55 +0000)]
Merge #10642
10642: minor: Add dummy impls for `trace_macros` and `log_syntax` r=Veykril a=Veykril
Both of these are macros for debugging macros and as such don't really need an implementation for us.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/2212
bors r+
improve https://github.com/rust-analyzer/rust-analyzer/pull/10637/ by always returning `Some(potentially_empty_vec)` instead of `None` in the empty case
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.
projects / rust.git / log