| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Refactor: Rename `db` locals to `diag`
https://github.com/rust-lang/rust/pull/64272 replaced `DiagnosticBuilder` with `Diagnostic` in some places. This PR just renames the db variable from `db` to `diag` where it wasn't renamed.
r? @Mark-Simulacrum
|
|
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
|
|
syntax: misc extractions
Part of https://github.com/rust-lang/rust/pull/65324.
r? @petrochenkov
|
|
|
|
|
|
|
|
|
|
|
|
https://github.com/rust-lang/rust/pull/64272 replaced
`DiagnosticBuilder` with `Diagnostic` in some places. This commit just
renames the DB variable from `db` to `diag` where it wasn't renamed.
|
|
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
|
|
Bring attention to suggestions when the only difference is capitalization
CC #65386.
|
|
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
|
|
|
|
This avoids some unnecessary creation of empty token streams.
|
|
|
|
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.
|
|
|
|
Split non-CAS atomic support off into target_has_atomic_load_store
This PR implements my proposed changes in https://github.com/rust-lang/rust/issues/32976#issuecomment-518542029 by removing `target_has_atomic = "cas"` and splitting `target_has_atomic` into two separate `cfg`s:
* `target_has_atomic = 8/16/32/64/128`: This indicates the largest width that the target can atomically CAS (which implies support for all atomic operations).
* ` target_has_atomic_load_store = 8/16/32/64/128`: This indicates the largest width that the target can support loading or storing atomically (but may not support CAS).
cc #32976
r? @alexcrichton
|
|
|
|
mbe: reduce panictry! uses.
Extracted from https://github.com/rust-lang/rust/pull/65324.
r? @petrochenkov
|
|
simplify integer_lit
Extracted from https://github.com/rust-lang/rust/pull/65324.
r? @davidtwco
|
|
simplify maybe_stage_features
Extracted from https://github.com/rust-lang/rust/pull/65324.
r? @estebank
|
|
r=davidtwco
syntax: simplify maybe_annotate_with_ascription
Split out from https://github.com/rust-lang/rust/pull/65324.
r? @estebank
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize mem::take (mem_take)
Tracking issue: https://github.com/rust-lang/rust/issues/61129
r? @matklad
|
|
Speed up `TokenStream` concatenation
This PR fixes the quadratic behaviour identified in #65080.
r? @Mark-Simulacrum
|
|
`#[track_caller]` feature gate (RFC 2091 1/N)
RFC text: https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md
Tracking issue: https://github.com/rust-lang/rust/issues/47809
I started with @ayosec's commit to add the feature gate with tests and rebased it onto current master. I fixed up some tidy lints and added a test.
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/61129
|
|
Warn if include macro fails to include entire file
This currently introduces an error, mainly because that was just simpler, and I'm not entirely certain if we can introduce a lint without an RFC and such.
This is primarily to get feedback on the approach and overall aim -- in particular, do we think this is helpful? If so, we probably will need lang-team sign off and decide if it should be an error (as currently introduced by this PR), a lint, or a warning.
r? @petrochenkov
cc https://github.com/rust-lang/rust/issues/35560
|
|
|
|
Add long error explanation for E0551
Part of #61137
|