Commit Graph

1105 Commits

Author SHA1 Message Date
bors
251206c27b Auto merge of #135268 - pietroalbini:pa-bump-stage0, r=Mark-Simulacrum
Master bootstrap update

Part of the release process.

r? `@Mark-Simulacrum`
2025-01-09 13:33:16 +00:00
Pietro Albini
2af3ba9a8a
update cfg(bootstrap) 2025-01-08 21:26:39 +01:00
Oli Scherer
4a8773a3af Rename PatKind::Lit to Expr 2025-01-08 07:34:59 +00:00
Manuel Drehwald
d753cbf779 upstream rustc_codegen_llvm changes for enzyme/autodiff 2025-01-01 21:42:45 +01:00
Matthias Krüger
0c94f631d8
Rollup merge of #134956 - compiler-errors:format-args-hidden-chars, r=jieyouxu
Account for C string literals and `format_args` in `HiddenUnicodeCodepoints` lint

This is stacked on #134955, and either that can land first or both of them can land together here. I split this out because this is a bit more involved of an impl.

Fixes #94945
2024-12-31 14:30:44 +01:00
Michael Goulet
ea291e5b5f Account for format_args in HiddenUnicodeCodepoints lint 2024-12-31 05:03:22 +00:00
Michael Goulet
aea2a6f836 Convert some Into impls into From impls 2024-12-31 01:56:33 +00:00
Esteban Küber
1f82b45b6a Use #[derive(Default)] instead of manually implementing it 2024-12-23 03:01:29 +00:00
David Tolnay
fe65e886f3
Change comparison operators to have Fixity::None 2024-12-20 20:12:22 -08:00
Matthias Krüger
f3b19f54fa
Rollup merge of #133782 - dtolnay:closuresjumps, r=spastorino,traviscross
Precedence improvements: closures and jumps

This PR fixes some cases where rustc's pretty printers would redundantly parenthesize expressions that didn't need it.

<table>
<tr><th>Before</th><th>After</th></tr>
<tr><td><code>return (|x: i32| x)</code></td><td><code>return |x: i32| x</code></td></tr>
<tr><td><code>(|| -> &mut () { std::process::abort() }).clone()</code></td><td><code>|| -> &mut () { std::process::abort() }.clone()</code></td></tr>
<tr><td><code>(continue) + 1</code></td><td><code>continue + 1</code></td></tr>
</table>

Tested by `echo "fn main() { let _ = $AFTER; }" | rustc -Zunpretty=expanded /dev/stdin`.

The pretty-printer aims to render the syntax tree as it actually exists in rustc, as faithfully as possible, in Rust syntax. It can insert parentheses where forced by Rust's grammar in order to preserve the meaning of a macro-generated syntax tree, for example in the case of `a * $rhs` where $rhs is `b + c`. But for any expression parsed from source code, without a macro involved, there should never be a reason for inserting additional parentheses not present in the original.

For closures and jumps (return, break, continue, yield, do yeet, become) the unneeded parentheses came from the precedence of some of these expressions being misidentified. In the same order as the table above:

- Jumps and closures are supposed to have equal precedence. The [Rust Reference](https://doc.rust-lang.org/1.83.0/reference/expressions.html#expression-precedence) says so, and in Syn they do. There is no Rust syntax that would require making a precedence distinction between jumps and closures. But in rustc these were previously 2 distinct levels with the closure being lower, hence the parentheses around a closure inside a jump (but not a jump inside a closure).

- When a closure is written with an explicit return type, the grammar [requires](https://doc.rust-lang.org/1.83.0/reference/expressions/closure-expr.html) that the closure body consists of exactly one block expression, not any other arbitrary expression as usual for closures. Parsing of the closure body does not continue after the block expression. So in `|| { 0 }.clone()` the clone is inside the closure body and applies to `{ 0 }`, whereas in `|| -> _ { 0 }.clone()` the clone is outside and applies to the closure as a whole.

- Continue never needs parentheses. It was previously marked as having the lowest possible precedence but it should have been the highest, next to paths and loops and function calls, not next to jumps.
2024-12-21 01:30:15 +01:00
许杰友 Jieyou Xu (Joe)
0a2d708c31
Rollup merge of #134253 - nnethercote:overhaul-keywords, r=petrochenkov
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```
2024-12-18 22:56:53 +08:00
许杰友 Jieyou Xu (Joe)
477f222b02
Rollup merge of #134161 - nnethercote:overhaul-token-cursors, r=spastorino
Overhaul token cursors

Some nice cleanups here.

r? `````@davidtwco`````
2024-12-18 22:56:53 +08:00
Nicholas Nethercote
1564318482 Only have one source of truth for keywords.
`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.
2024-12-18 20:21:03 +11:00
Nicholas Nethercote
2620eb42d7 Re-export more rustc_span::symbol things from rustc_span.
`rustc_span::symbol` defines some things that are re-exported from
`rustc_span`, such as `Symbol` and `sym`. But it doesn't re-export some
closely related things such as `Ident` and `kw`. So you can do `use
rustc_span::{Symbol, sym}` but you have to do `use
rustc_span::symbol::{Ident, kw}`, which is inconsistent for no good
reason.

This commit re-exports `Ident`, `kw`, and `MacroRulesNormalizedIdent`,
and changes many `rustc_span::symbol::` qualifiers in `compiler/` to
`rustc_span::`. This is a 200+ net line of code reduction, mostly
because many files with two `use rustc_span` items can be reduced to
one.
2024-12-18 13:38:53 +11:00
Nicholas Nethercote
2903356b2e Overhaul TokenTreeCursor.
- Move it to `rustc_parse`, which is the only crate that uses it. This
  lets us remove all the `pub` markers from it.

- Change `next_ref` and `look_ahead` to `get` and `bump`, which work
  better for the `rustc_parse` uses.

- This requires adding a `TokenStream::get` method, which is simple.

- In `TokenCursor`, we currently duplicate the
  `DelimSpan`/`DelimSpacing`/`Delimiter` from the surrounding
  `TokenTree::Delimited` in the stack. This isn't necessary so long as
  we don't prematurely move past the `Delimited`, and is a small perf
  win on a very hot code path.

- In `parse_token_tree`, we clone the relevant `TokenTree::Delimited`
  instead of constructing an identical one from pieces.
2024-12-18 12:50:22 +11:00
Nicholas Nethercote
c82d5865f2 Remove Peekable<TokenStreamIter> uses.
Currently there are two ways to peek at a `TokenStreamIter`.
- Wrap it in a `Peekable` and use that traits `peek` method.
- Use `TokenStreamIter`'s inherent `peek` method.

Some code uses one, some use the other. This commit converts all places
to the inherent method. This eliminates mixing of `TokenStreamIter` and
`Peekable<TokenStreamIter>` and some use of `impl Iterator` and `dyn
Iterator`.
2024-12-18 10:43:28 +11:00
Nicholas Nethercote
809975c94a Rename RefTokenTreeCursor.
Because `TokenStreamIter` is a much better name for a `TokenStream`
iterator. Also rename the `TokenStream::trees` method as
`TokenStream::iter`, and some local variables.
2024-12-18 10:39:07 +11:00
Nicholas Nethercote
3575e7943b Simplify RefTokenTreeCursor::look_ahead.
It's only ever used with a lookahead of 0, so this commit removes the
lookahead and renames it `peek`.
2024-12-18 10:31:39 +11:00
Matthias Krüger
86db97e2b3
Rollup merge of #134284 - estebank:issue-74863, r=lcnr
Keep track of patterns that could have introduced a binding, but didn't

When we recover from a pattern parse error, or a pattern uses `..`, we keep track of that and affect resolution error for missing bindings that could have been provided by that pattern. We differentiate between `..` and parse recovery. We silence resolution errors likely caused by the pattern parse error.

```
error[E0425]: cannot find value `title` in this scope
  --> $DIR/struct-pattern-with-missing-fields-resolve-error.rs:18:30
   |
LL |     if let Website { url, .. } = website {
   |            ------------------- this pattern doesn't include `title`, which is available in `Website`
LL |         println!("[{}]({})", title, url);
   |                              ^^^^^ not found in this scope
```

Fix #74863.
2024-12-16 20:00:22 +01:00
Jonathan Dönszelmann
1d5ec2cd6a
Remove some leftover dead code 2024-12-15 19:18:46 +01:00
Jonathan Dönszelmann
d50c0a5480
Add hir::Attribute 2024-12-15 19:18:46 +01:00
Oli Scherer
53b2c7cc95 Rename value field to expr to simplify later commits' diffs 2024-12-15 18:47:45 +01:00
Esteban Küber
0f82cfffda Keep track of patterns that could have introduced a binding, but didn't
When we recover from a pattern parse error, or a pattern uses `..`, we keep track of that and affect resolution error for missing bindings that could have been provided by that pattern. We differentiate between `..` and parse recovery. We silence resolution errors likely caused by the pattern parse error.

```
error[E0425]: cannot find value `title` in this scope
  --> $DIR/struct-pattern-with-missing-fields-resolve-error.rs:19:30
   |
LL |         println!("[{}]({})", title, url);
   |                              ^^^^^ not found in this scope
   |
note: `Website` has a field `title` which could have been included in this pattern, but it wasn't
  --> $DIR/struct-pattern-with-missing-fields-resolve-error.rs:17:12
   |
LL | / struct Website {
LL | |     url: String,
LL | |     title: Option<String> ,
   | |     ----- defined here
LL | | }
   | |_-
...
LL |       if let Website { url, .. } = website {
   |              ^^^^^^^^^^^^^^^^^^^ this pattern doesn't include `title`, which is available in `Website`
```

Fix #74863.
2024-12-13 21:51:33 +00:00
Matthias Krüger
5c9b227a3d
Rollup merge of #134140 - compiler-errors:unsafe-binders-ast, r=oli-obk
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
2024-12-13 17:25:31 +01:00
Matthias Krüger
c1810269e9
Rollup merge of #133937 - estebank:silence-resolve-errors-from-mod-with-parse-errors, r=davidtwco
Keep track of parse errors in `mod`s and don't emit resolve errors for 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 in the HIR and mark its `DefId` in the `Resolver`. 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 expansion of `mod`s with parse errors.

Fix https://github.com/rust-lang/rust/issues/97734.
2024-12-13 17:25:28 +01:00
Michael Goulet
3f97c6be8d Add unwrap_unsafe_binder and wrap_unsafe_binder macro operators 2024-12-12 16:29:40 +00:00
Michael Goulet
3b1adfa94b Parsing unsafe binders 2024-12-12 16:29:39 +00:00
onur-ozkan
f11edf7611 allow symbol_intern_string_literal lint in test modules
Signed-off-by: onur-ozkan <work@onurozkan.dev>
2024-12-11 20:38:55 +03:00
Esteban Küber
69fb612608 Keep track of parse errors in mods and don't emit resolve errors for 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.
2024-12-10 18:17:24 +00:00
Esteban Küber
9ac95c10c0 Introduce default_field_values feature
Initial implementation of `#[feature(default_field_values]`, proposed in https://github.com/rust-lang/rfcs/pull/3681.

Support default fields in enum struct variant

Allow default values in an enum struct variant definition:

```rust
pub enum Bar {
    Foo {
        bar: S = S,
        baz: i32 = 42 + 3,
    }
}
```

Allow using `..` without a base on an enum struct variant

```rust
Bar::Foo { .. }
```

`#[derive(Default)]` doesn't account for these as it is still gating `#[default]` only being allowed on unit variants.

Support `#[derive(Default)]` on enum struct variants with all defaulted fields

```rust
pub enum Bar {
    #[default]
    Foo {
        bar: S = S,
        baz: i32 = 42 + 3,
    }
}
```

Check for missing fields in typeck instead of mir_build.

Expand test with `const` param case (needs `generic_const_exprs` enabled).

Properly instantiate MIR const

The following works:

```rust
struct S<A> {
    a: Vec<A> = Vec::new(),
}
S::<i32> { .. }
```

Add lint for default fields that will always fail const-eval

We *allow* this to happen for API writers that might want to rely on users'
getting a compile error when using the default field, different to the error
that they would get when the field isn't default. We could change this to
*always* error instead of being a lint, if we wanted.

This will *not* catch errors for partially evaluated consts, like when the
expression relies on a const parameter.

Suggestions when encountering `Foo { .. }` without `#[feature(default_field_values)]`:

 - Suggest adding a base expression if there are missing fields.
 - Suggest enabling the feature if all the missing fields have optional values.
 - Suggest removing `..` if there are no missing fields.
2024-12-09 21:55:01 +00:00
Matthias Krüger
1868c8f66f
Rollup merge of #133424 - Nadrieril:guard-patterns-parsing, r=fee1-dead
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](https://github.com/rust-lang/rust/issues/129967)). This PR is extracted from https://github.com/rust-lang/rust/pull/129996 with minor modifications.

cc `@max-niederman`
2024-12-08 17:18:50 +01:00
Michael Goulet
05c34cc5ed Fix suggestion when shorthand self has erroneous type 2024-12-04 19:52:53 +00:00
Matthias Krüger
45088fdf68
Rollup merge of #133784 - dtolnay:visitspans, r=compiler-errors
Fix MutVisitor's default implementations to visit Stmt's and BinOp's spans

The `Stmt` case is a bug introduced almost certainly unintentionally by https://github.com/rust-lang/rust/pull/126993. The code _used_ to visit and mutate `span` correctly, but got changed as follows by that PR. Notice how `span` is **copied** into the output by `|kind| Stmt { id, kind, span }` which happens after the mutation in the correct code (red) and before the mutation in the incorrect code (green).

```diff
  pub fn noop_flat_map_stmt<T: MutVisitor>(
      Stmt { kind, mut span, mut id }: Stmt,
      vis: &mut T,
  ) -> SmallVec<[Stmt; 1]> {
      vis.visit_id(&mut id);
-     vis.visit_span(&mut span);
      let stmts: SmallVec<_> = noop_flat_map_stmt_kind(kind, vis)
          .into_iter()
          .map(|kind| Stmt { id, kind, span })
          .collect();
      if stmts.len() > 1 {
          panic!(...);
      }
+     vis.visit_span(&mut span);
      stmts
  }
```
2024-12-04 05:42:08 +01:00
David Tolnay
a3cfe2fd08
Visit Stmt span in MutVisitor::flat_map_stmt 2024-12-03 07:03:26 -08:00
David Tolnay
a2eca35c15
Visit BinOp span in MutVisitor::visit_expr 2024-12-03 07:03:26 -08:00
David Tolnay
fe06c5dce1
Never parenthesize continue 2024-12-02 17:50:12 -08:00
David Tolnay
72ac961616
Raise precedence of closure that has explicit return type 2024-12-02 17:48:16 -08:00
David Tolnay
193d82797c
Squash closures and jumps into a single precedence level 2024-12-02 17:33:20 -08:00
Guillaume Gomez
6f9f17fc08
Rollup merge of #133746 - oli-obk:push-xwyrylxmrtvq, r=jieyouxu
Change `AttrArgs::Eq` to a struct variant

Cleanups for simplifying https://github.com/rust-lang/rust/pull/131808

Basically changes `AttrArgs::Eq` to a struct variant and then avoids several matches on `AttrArgsEq` in favor of methods on it. This will make future refactorings simpler, as they can either keep methods or switch to field accesses without having to restructure code
2024-12-02 23:08:58 +01:00
Oli Scherer
da182b6d95 Deduplicate some matches that always panic in one arm 2024-12-02 11:04:57 +00:00
Oli Scherer
c0b532277b Add a helper method for extracting spans from AttrArgsEq 2024-12-02 11:04:57 +00:00
Oli Scherer
778321d155 Change AttrArgs::Eq into a struct variant 2024-12-02 10:28:58 +00:00
David Tolnay
7ced18f329
Eliminate magic numbers from expression precedence 2024-11-30 17:53:40 -08:00
David Tolnay
ca8f47439e
Eliminate PREC_FORCE_PAREN 2024-11-30 17:53:39 -08:00
lcnr
94131bd0a8 always create DefIds when lowering anon-consts 2024-11-28 12:22:02 +00:00
Michael Goulet
6e5bac19d0
Rollup merge of #133140 - dtolnay:precedence, r=fmease
Inline ExprPrecedence::order into Expr::precedence

The representation of expression precedence in rustc_ast has been an obstacle to further improvements in the pretty-printer (continuing from #119105 and #119427).

Previously the operation of *"does this expression have lower precedence than that one"* (relevant for parenthesis insertion in macro-generated syntax trees) consisted of 3 steps:

1. Convert `Expr` to `ExprPrecedence` using `.precedence()`
2. Convert `ExprPrecedence` to `i8` using `.order()`
3. Compare using `<`

As far as I can guess, the reason for the separation between `precedence()` and `order()` was so that both `rustc_ast::Expr` and `rustc_hir::Expr` could convert as straightforwardly as possible to the same `ExprPrecedence` enum, and then the more finicky logic performed by `order` could be present just once.

The mapping between `Expr` and `ExprPrecedence` was intended to be as straightforward as possible:

```rust
match self.kind {
    ExprKind::Closure(..) => ExprPrecedence::Closure,
    ...
}
```

although there were exceptions of both many-to-one, and one-to-many:

```rust
    ExprKind::Underscore => ExprPrecedence::Path,
    ExprKind::Path(..) => ExprPrecedence::Path,
    ...
    ExprKind::Match(_, _, MatchKind::Prefix) => ExprPrecedence::Match,
    ExprKind::Match(_, _, MatchKind::Postfix) => ExprPrecedence::PostfixMatch,
```

Where the nature of `ExprPrecedence` becomes problematic is when a single expression kind might be associated with multiple different precedence levels depending on context (outside the expression) and contents (inside the expression). For example consider what is the precedence of an ExprKind::Closure `$closure`. Well, on the left-hand side of a binary operator it would need parentheses in order to avoid the trailing binary operator being absorbed into the closure body: `($closure) + Rhs`, so the precedence is something lower than that of `+`. But on the right-hand side of a binary operator, a closure is just a straightforward prefix expression like a unary op, which is a relatively high precedence level, higher than binops but lower than method calls: `Lhs + $closure` is fine without parens but `($closure).method()` needs them. But as a third case, if the closure contains an explicit return type, then the precedence is an even higher level than that, never needing parenthesization even in a binop left-hand side or method call: `|| -> bool { false } + Rhs` or `|| -> bool { false }.method()`.

You can see that trying to capture all of this resolution about expressions into `ExprPrecedence` violates the intention of `ExprPrecedence` being a straightforward one-to-one correspondence from each AST and HIR `ExprKind` variant. It would be possible to attempt that by doing stuff like `ExprPrecedence::Closure(Side::Leading, ReturnType::No)`, but I don't foresee the original envisioned benefit of the `precedence()`/`order()` distinction being retained in this approach. Instead I want to move toward a model that Syn has been using successfully. In Syn, there is a Precedence enum but it differs from rustc in the following ways:

- There are [relatively few variants](https://github.com/dtolnay/syn/blob/2.0.87/src/precedence.rs#L11-L47) compared to rustc's `ExprPrecedence`. For example there is no distinction at the precedence level between returns and closures, or between loops and method calls.

- We distinguish between [leading](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L293) and [trailing](https://github.com/dtolnay/syn/blob/2.0.87/src/fixup.rs#L309) precedence, taking into account an expression's context such as what token follows it (for various syntactic bail-outs in Rust's grammar, like ambiguities around break-with-value) and how it relates to operators from the surrounding syntax tree.

- There are no hardcoded mysterious integer quantities like rustc's `PREC_CLOSURE = -40`. All precedence comparisons are performed via PartialOrd on a C-like enum.

This PR is just a first step in these changes. As you can tell from Syn, I definitely think there is value in having a dedicated type to represent precedence, instead of what `order()` is doing with `i8`. But that is a whole separate adventure because rustc_ast doesn't even agree consistently on `i8` being the type for precedence order; `AssocOp::precedence` instead uses `usize` and there are casts in both directions. It is likely that a type called `ExprPrecedence` will re-appear, but it will look substantially different from the one that existed before this PR.
2024-11-26 12:03:41 -05:00
Frank King
161221da9e Refactor where predicates, and reserve for attributes support 2024-11-25 16:38:35 +08:00
Max Niederman
9b8bfed73b add guard pattern AST node 2024-11-24 18:08:20 +01:00
Luca Versari
9022bb2d6f Implement the unsafe-fields RFC.
Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>
2024-11-21 19:32:07 +01:00
bors
717f5df2c3 Auto merge of #132629 - nnethercote:124141-preliminaries, r=petrochenkov
#124141 preliminaries

Preliminary changes required to start removing `Nonterminal` (https://github.com/rust-lang/rust/pull/124141).

r? `@petrochenkov`
2024-11-21 10:57:22 +00:00