| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Add test for rejecting `trait A: B1 = B2;`.
Also test rejection of `trait A: = B;`.
|
|
refactor and move `maybe_append`
|
|
|
|
Clarify diagnostics when using `~` as a unary op
It seems we prefer `bitwise not` to `bitwise negation`.
Fixes #57239
r? @estebank
|
|
|
|
Because most of the call sites have an easier time working with a
`TokenTree` instead of a `TokenStream`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 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
|
|
|
|
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.
|
|
Account for macro invocation in `let mut $pat` diagnostic.
Fixes https://github.com/rust-lang/rust/issues/65122.
r? @estebank
|
|
|
|
|
|
|
|
This works just as you might expect - an 'extern const fn' is a 'const
fn' that is callable from foreign code.
Currently, panicking is not allowed in consts. When RFC 2345 is
stabilized, then panicking in an 'extern const 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.
|
|
syntax: cleanup param, method, and misc parsing
Do some misc cleanup of the parser:
- Method and parameter parsing is refactored.
- A parser for `const | mut` is introduced that https://github.com/rust-lang/rust/pull/64588 can reuse.
- Some other misc parsing.
Next up in a different PR:
- ~Implementing https://github.com/rust-lang/rust/issues/64252.~ -- maybe some other time...
- Heavily restructuring up `item.rs` which is a mess (hopefully, no promises ^^).
r? @petrochenkov
|
|
syntax: recover trailing `|` in or-patterns
Fixes https://github.com/rust-lang/rust/issues/64879.
For example (this also shows that we are sensitive to the typo `||`):
```
error: a trailing `|` is not allowed in an or-pattern
--> $DIR/remove-leading-vert.rs:33:11
|
LL | A || => {}
| - ^^ help: remove the `||`
| |
| while parsing this or-pattern starting here
|
= note: alternatives in or-patterns are separated with `|`, not `||`
```
r? @estebank
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|