Skip to content

Conversation

ytmimi
Copy link
Contributor

@ytmimi ytmimi commented Jan 2, 2025

Bumping the toolchain version as part of a git subtree push

current toolchain (nightly-2024-12-02):

  • 1.85.0-nightly (5e1440ae5 2024-12-01)

latest toolchain (nightly-2025-01-02):

  • 1.85.0-nightly (45d11e51b 2025-01-01)

max-niederman and others added 20 commits November 24, 2024 19:42
And pass this to the individual emitters when necessary.
Parse guard patterns

This implements the parsing of [RFC3637 Guard Patterns](https://rust-lang.github.io/rfcs/3637-guard-patterns.html) (see also [tracking issue](rust-lang/rust#129967)). This PR is extracted from rust-lang/rust#129996 with minor modifications.

cc `@max-niederman`
Rollup of 7 pull requests

Successful merges:

 - #133567 (A bunch of cleanups)
 - #133789 (Add doc alias 'then_with' for `then` method on `bool`)
 - #133880 (Expand home_dir docs)
 - #134036 (crash tests: use individual mir opts instead of mir-opt-level where easily possible)
 - #134045 (Fix some triagebot mentions paths)
 - #134046 (Remove ignored tests for hangs w/ new solver)
 - #134050 (Miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
…r paths involving them

When we expand a `mod foo;` and parse `foo.rs`, we now track whether that file had an unrecovered parse error that reached the end of the file. If so, we keep that information around. When resolving a path like `foo::bar`, we do not emit any errors for "`bar` not found in `foo`", as we know that the parse error might have caused `bar` to not be parsed and accounted for.

When this happens in an existing project, every path referencing `foo` would be an irrelevant compile error. Instead, we now skip emitting anything until `foo.rs` is fixed. Tellingly enough, we didn't have any test for errors caused by `mod` expansion.

Fix #97734.
Add AST support for unsafe binders

I'm splitting up #130514 into pieces. It's impossible for me to keep up with a huge PR like that. I'll land type system support for this next, probably w/o MIR lowering, which will come later.

r? `@oli-obk`
cc `@BoxyUwU` and `@lcnr` who also may want to look at this, though this PR doesn't do too much yet
As it happens, lookahead values of 0, 1, and 2 all work fine here, due
to the structure of the code. (Values or 3 or greater cause test
failures.) This commit changes the lookahead to zero because that will
facilitate cleanups in subsequent commits.
It's only ever used with a lookahead of 0, so this commit removes the
lookahead and renames it `peek`.
Because `TokenStreamIter` is a much better name for a `TokenStream`
iterator. Also rename the `TokenStream::trees` method as
`TokenStream::iter`, and some local variables.
`rustc_symbol` is the source of truth for keywords.

rustdoc has its own implicit definition of keywords, via the
`is_doc_keyword`. It (presumably) intends to include all keywords, but
it omits `yeet`.

rustfmt has its own explicit list of Rust keywords. It also (presumably)
intends to include all keywords, but it omits `await`, `builtin`, `gen`,
`macro_rules`, `raw`, `reuse`, `safe`, and `yeet`. Also, it does linear
searches through this list, which is inefficient.

This commit fixes all of the above problems by introducing a new
predicate `is_any_keyword` in rustc and using it in rustdoc and rustfmt.
It documents that it's not the right predicate in most cases.
Overhaul keyword handling

The compiler's list of keywords has some problems.
- It contains several items that aren't keywords.
- The order isn't quite right in a couple of places.
- Some of the names of predicates relating to keywords are confusing.
- rustdoc and rustfmt have their own (incorrect) versions of the keyword list.
- `AllKeywords` is unnecessarily complex.

r? ```@jieyouxu```
The parser pushes a `TokenType` to `Parser::expected_token_types` on
every call to the various `check`/`eat` methods, and clears it on every
call to `bump`. Some of those `TokenType` values are full tokens that
require cloning and dropping. This is a *lot* of work for something
that is only used in error messages and it accounts for a significant
fraction of parsing execution time.

This commit overhauls `TokenType` so that `Parser::expected_token_types`
can be implemented as a bitset. This requires changing `TokenType` to a
C-style parameterless enum, and adding `TokenTypeSet` which uses a
`u128` for the bits. (The new `TokenType` has 105 variants.)

The new types `ExpTokenPair` and `ExpKeywordPair` are now arguments to
the `check`/`eat` methods. This is for maximum speed. The elements in
the pairs are always statically known; e.g. a
`token::BinOp(token::Star)` is always paired with a `TokenType::Star`.
So we now compute `TokenType`s in advance and pass them in to
`check`/`eat` rather than the current approach of constructing them on
insertion into `expected_token_types`.

Values of these pair types can be produced by the new `exp!` macro,
which is used at every `check`/`eat` call site. The macro is for
convenience, allowing any pair to be generated from a single identifier.

The ident/keyword filtering in `expected_one_of_not_found` is no longer
necessary. It was there to account for some sloppiness in
`TokenKind`/`TokenType` comparisons.

The existing `TokenType` is moved to a new file `token_type.rs`, and all
its new infrastructure is added to that file. There is more boilerplate
code than I would like, but I can't see how to make it shorter.
Bumping the toolchain version as part of a git subtree push

current toolchain (nightly-2024-12-02):
  - 1.85.0-nightly (5e1440ae5 2024-12-01)

latest toolchain (nightly-2025-01-02):
  - 1.85.0-nightly (45d11e51b 2025-01-01)
@ytmimi
Copy link
Contributor Author

ytmimi commented Jan 2, 2025

Link to the Diff-Check Job

Edit: Job failed ❌

@ytmimi
Copy link
Contributor Author

ytmimi commented Jan 2, 2025

There were formatting difference in the diff-check related to nightly formatting implemented in the compiler.

#![feature(unsafe_binders)] 68a558c

Tracking issue: rust-lang/rust#130516

Details

Input

fn foo() -> unsafe<'a>
&'a () {}

struct Foo {
    x: unsafe<'a>
&'a (),
}

struct Bar(unsafe<'a> &'a ());

impl Trait for unsafe<'a> &'a () {}

Output rustfmt (master)
Parse error.

error: expected type, found keyword `unsafe`
 --> <stdin>:1:13
  |
1 | fn foo() -> unsafe<'a>
  |             ^^^^^^ expected type


Output rustfmt (subtree-push-nightly-2025-01-02)

fn foo() -> unsafe<'a> &'a () {}

struct Foo {
    x: unsafe<'a> &'a (),
}

struct Bar(unsafe<'a> &'a ());

impl Trait for unsafe<'a> &'a () {}

@ytmimi ytmimi merged commit d97c4fb into rust-lang:master Jan 14, 2025
30 checks passed
@ytmimi ytmimi added release-notes Needs an associated changelog entry and removed pr-not-reviewed labels Jun 21, 2025
@ytmimi ytmimi deleted the subtree-push-nightly-2025-01-02 branch June 21, 2025 17:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-notes Needs an associated changelog entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.