| Age | Commit message (Collapse) | Author | Lines |
|
Clarify diagnostics when using `~` as a unary op
It seems we prefer `bitwise not` to `bitwise negation`.
Fixes #57239
r? @estebank
|
|
nnethercote:avoid-unnecessary-TokenTree-to-TokenStream-conversions, r=petrochenkov
Avoid unnecessary `TokenTree` to `TokenStream` conversions
A `TokenStream` contains any number of `TokenTrees`. Therefore, a single `TokenTree` can be promoted to a `TokenStream`. But doing so costs two allocations: one for the single-element `Vec`, and one for the `Lrc`. (An `IsJoint` value also must be added; the default is `NonJoint`.)
The current code converts `TokenTree`s to `TokenStream`s unnecessarily in a few places. This PR removes some of these unnecessary conversions, both simplifying the code and speeding it up.
r? @petrochenkov
|
|
Collect occurrences of empty blocks for mismatched braces diagnostic
Fix #63904
|
|
|
|
Because most of the call sites have an easier time working with a
`TokenTree` instead of a `TokenStream`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Change-Id: I20ba0b62308370ee961141fa1aefc4b9c9f0cb3a
|
|
nnethercote:rm-custom-LocalInternedString-PartialEq-impls, r=petrochenkov
Remove custom `PartialEq` impls for `LocalInternedString`.
This is on-trend with the recent changes simplifying
`LocalInternedString` and reducing its use.
r? @petrochenkov
|
|
|
|
|
|
|
|
|
|
This is on-trend with the recent changes simplifying
`LocalInternedString` and reducing its use.
|
|
syntax: add parser recovery for intersection- / and-patterns `p1 @ p2`
Fixes https://github.com/rust-lang/rust/issues/65400.
The recovery comes in two flavors:
1. We know that `p2` is a binding so we can invert as `p2 @ p1`:
```rust
error: pattern on wrong side of `@`
--> $DIR/intersection-patterns.rs:13:9
|
LL | Some(x) @ y => {}
| -------^^^-
| | |
| | binding on the right, should be to the left
| pattern on the left, should be to the right
| help: switch the order: `y @ Some(x)`
```
2. Otherwise we emit a generic diagnostic for the lack of support for intersection patterns:
```rust
error: left-hand side of `@` must be a binding
--> $DIR/intersection-patterns.rs:23:9
|
LL | Some(x) @ Some(y) => {}
| -------^^^-------
| | |
| | also a pattern
| interpreted as a pattern, not a binding
|
= note: bindings are `x`, `mut x`, `ref x`, and `ref mut x`
```
For more on and-patterns, see e.g. https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/pattern-matching#and-pattern.
r? @davidtwco
cc @varkor @lzutao
|
|
Remove `Option` from `TokenStream`
A code simplification.
r? @petrochenkov
|
|
|
|
|
|
|
|
Move `Nonterminal::to_tokenstream` to parser & don't rely directly on parser in lowering
Split out from https://github.com/rust-lang/rust/pull/65324.
r? @petrochenkov
|
|
Remove implicit dependencies on syntax::pprust
Part of https://github.com/rust-lang/rust/pull/65324.
The main goal here is to facilitate the eventual move of pprust out from libsyntax and because an AST definition typically should not depend on its pretty printer.
r? @estebank
|
|
syntax: consolidate function parsing in item.rs
Extracted from https://github.com/rust-lang/rust/pull/65324.
r? @estebank
|
|
|
|
It means an allocation is required to create an empty `TokenStream`, but
all other operations are simpler and marginally faster due to not having
to check for `None`. Overall it simplifies the code for a negligible
performance effect.
The commit also removes `TokenStream::empty` by implementing `Default`,
which is now possible.
|
|
|
|
|
|
simplify integer_lit
Extracted from https://github.com/rust-lang/rust/pull/65324.
r? @davidtwco
|
|
Change-Id: I20ba0b62308370ee961141fa1aefc4b9c9f0cb3a
|
|
Change-Id: I20ba0b62308370ee961141fa1aefc4b9c9f0cb3a
|
|
Instead just use `pprust::path_to_string(..)` where needed.
This has two benefits:
a) The AST definition is now independent of printing it.
(Therefore we get closer to extracting a data-crate.)
b) Debugging should be easier as program flow is clearer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add support for `const unsafe? extern fn`
This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code.
Currently, panicking is not allowed in `const`s. When https://github.com/rust-lang/rfcs/pull/2345 (https://github.com/rust-lang/rust/issues/51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime.
Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary.
This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well.
Tracking issue: https://github.com/rust-lang/rust/issues/64926.
|