Commit Graph

1837 Commits

Author SHA1 Message Date
Nicholas Nethercote
29e6e2859b Remove low-value comments.
The first one is out-of-date -- there are no longer functions expr,
item, stmt. And I don't know what a "HOF" is.

The second one doesn't really tell you anything.
2024-06-05 10:38:02 +10:00
Nicholas Nethercote
af13b48927 Improve panictry_buffer!.
- Convert it from a macro to a function, which is nicer.
- Rename it as `unwrap_or_emit_fatal`, which is clearer.
- Fix the comment. In particular, `panictry!` no longer exists.
- Remove the unnecessary `use` declaration.
2024-06-05 10:38:02 +10:00
Nicholas Nethercote
3c321b9ea8 Remove stream_to_parser.
It's a zero-value wrapper of `Parser::new`.
2024-06-05 10:37:59 +10:00
Nicholas Nethercote
769ca3f661 Rename maybe_file_to_stream as maybe_source_file_to_stream.
Because it takes an `Lrc<SourceFile>`, and for consistency with
`source_file_to_stream`.
2024-06-05 10:29:16 +10:00
Nicholas Nethercote
f6576249ab Inline and remove error_malformed_cfg_attr_missing.
It has a single call site.

This also means `CFG_ATTR_{GRAMMAR_HELP,NOTE_REF}` can be moved into
`parse_cfg_attr`, now that it's the only function that uses them.
And the commit removes the line break in the URL.
2024-06-05 10:29:16 +10:00
Nicholas Nethercote
d1215da26e Don't use the word "parse" for lexing operations.
Lexing converts source text into a token stream. Parsing converts a
token stream into AST fragments. This commit renames several lexing
operations that have "parse" in the name. I think these names have been
subtly confusing me for years.

This is just a `s/parse/lex/` on function names, with one exception:
`parse_stream_from_source_str` becomes `source_str_to_stream`, to make
it consistent with the existing `source_file_to_stream`. The commit also
moves that function's location in the file to be just above
`source_file_to_stream`.

The commit also cleans up a few comments along the way.
2024-06-05 10:29:16 +10:00
Nicholas Nethercote
e1ae0fa055 UNICODE_ARRAY and ASCII_ARRAY fixes.
- Avoid unnecessary escaping of single quotes within string literals.
- Add a missing blank line between two `UNICODE_ARRAY` sections.
2024-06-05 10:29:16 +10:00
Vincenzo Palazzo
36d5fc9a64
Avoid checking the edition as much as possible
Inside #123865, we are adding support for the new semantics
for expr2024, but we have noted a performance issue.

We realized there is a redundant check for each
token regarding an edition. This commit moves the edition
check to the end, avoiding some extra checks that
can slow down compilation time.

Link: https://github.com/rust-lang/rust/pull/123865
Co-Developed-by: @eholk
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2024-06-02 09:42:21 +02:00
bors
f67a1acc04 Auto merge of #125863 - fmease:rej-CVarArgs-in-parse_ty_for_where_clause, r=compiler-errors
Reject `CVarArgs` in `parse_ty_for_where_clause`

Fixes #125847. This regressed in #77035 where the `parse_ty` inside `parse_ty_where_predicate` was replaced with the at the time new `parse_ty_for_where_clause` which incorrectly stated it would permit CVarArgs (maybe a copy/paste error).

r? parser
2024-06-01 21:13:52 +00:00
León Orell Valerian Liehr
89386092f1
Reject CVarArgs in parse_ty_for_where_clause 2024-06-01 20:57:15 +02:00
Matthias Krüger
379233242b
Rollup merge of #125635 - fmease:mv-type-binding-assoc-item-constraint, r=compiler-errors
Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup

Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.

Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.

---

Old terminology (HIR, rustdoc):

```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
    ├── `Ty`: (associated) type binding
    └── `Const`: associated const equality (constraint)
```

Old terminology (AST, abbrev.):

```
`AssocConstraint`
├── `Bound`
└── `Equality`
    ├── `Ty`
    └── `Const`
```

New terminology (AST, HIR, rustdoc):

```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
    ├── `Ty`: associated type equality constraint OR associated type binding (for short)
    └── `Const`: associated const equality constraint OR associated const binding (for short)
```

r? compiler-errors
2024-05-31 08:50:22 +02:00
León Orell Valerian Liehr
34c56c45cf
Rename HIR TypeBinding to AssocItemConstraint and related cleanup 2024-05-30 22:52:33 +02:00
Oli Scherer
ddc5f9b6c1 Create const block DefIds in typeck instead of ast lowering 2024-05-28 13:38:43 +00:00
Nicholas Nethercote
bb364fe950 Remove #[macro_use] extern crate tracing from rustc_parse. 2024-05-23 18:02:40 +10:00
León Orell Valerian Liehr
5b485f04de
Rollup merge of #125049 - dtolnay:castbrace, r=compiler-errors
Disallow cast with trailing braced macro in let-else

This fixes an edge case I noticed while porting #118880 and #119062 to syn.

Previously, rustc incorrectly accepted code such as:

```rust
let foo = &std::ptr::null as &'static dyn std::ops::Fn() -> *const primitive! {
    8
} else {
    return;
};
```

even though a right curl brace `}` directly before `else` in a `let...else` statement is not supposed to be valid syntax.
2024-05-22 19:04:44 +02:00
bors
791adf759c Auto merge of #124417 - Xiretza:translate-early-lints, r=fmease
Make early lints translatable

<del>Requires https://github.com/projectfluent/fluent-rs/pull/353.</del> 5134a04eaa

r? diagnostics
2024-05-21 21:36:09 +00:00
Xiretza
98dd6c7e8f Rename buffer_lint_with_diagnostic to buffer_lint 2024-05-21 20:16:39 +00:00
Xiretza
b7abf014ec Convert uses of BuiltinLintDiag::Normal to custom variants
This ensures all diagnostic messages are created at diagnostic emission
time, making them translatable.
2024-05-21 20:16:39 +00:00
Xiretza
c227f35a9c Generate lint diagnostic message from BuiltinLintDiag
Translation of the lint message happens when the actual diagnostic is
created, not when the lint is buffered. Generating the message from
BuiltinLintDiag ensures that all required data to construct the message
is preserved in the LintBuffer, eventually allowing the messages to be
moved to fluent.

Remove the `msg` field from BufferedEarlyLint, it is either generated
from the data in the BuiltinLintDiag or stored inside
BuiltinLintDiag::Normal.
2024-05-21 20:16:39 +00:00
ardi
972633f530 Fix parsing of erroneously placed semicolons 2024-05-20 21:36:20 +02:00
bors
eb1a5c9bb3 Auto merge of #125077 - spastorino:add-new-fnsafety-enum2, r=jackh726
Rename Unsafe to Safety

Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.

This leaves us today with:

```rust
enum ast::Safety {
    Unsafe(Span),
    Default,
    // Safe (going to be added for unsafe extern blocks)
}

enum hir::Safety {
    Unsafe,
    Safe,
}
```

We would convert from `ast::Safety::Default` into the right Safety level according the context.
2024-05-18 19:35:24 +00:00
Matthias Krüger
f9bf759e83
Rollup merge of #125117 - dev-ardi:improve-parser, r=wesleywiser,fmease
Improve parser

Fixes #124935.

- Add a few more help diagnostics to incorrect semicolons
- Overall improved that function
- Addded a few comments
- Renamed diff_marker fns to git_diff_marker
2024-05-18 18:44:14 +02:00
bors
9b75a43881 Auto merge of #123865 - eholk:expr_2021, r=fmease
Update `expr` matcher for Edition 2024 and add `expr_2021` nonterminal

This commit adds a new nonterminal `expr_2021` in macro patterns, and `expr_fragment_specifier_2024` feature flag.

This change also updates `expr` so that on Edition 2024 it will also match `const { ... }` blocks, while `expr_2021` preserves the current behavior of `expr`, matching expressions without `const` blocks.

Joint work with `@vincenzopalazzo.`

Issue #123742
2024-05-17 21:54:14 +00:00
Santiago Pastorino
6b46a919e1
Rename Unsafe to Safety 2024-05-17 18:33:37 -03:00
Eric Holk
3986ea0ea5
Update compiler/rustc_parse/src/parser/nonterminal.rs
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
2024-05-17 11:55:38 -07:00
ardi
f8433a82b4 use signature name for arg 2024-05-17 15:47:24 +02:00
ardi
db5a616405 s/(Ident, ItemKind)/ItemInfo/ 2024-05-17 15:47:21 +02:00
ardi
1f6d271527 Clarify that the diff_marker is talking about version control system
conflicts specifically and a few more improvements.
2024-05-17 15:45:50 +02:00
Vadim Petrochenkov
c30b41012d delegation: Implement list delegation
```rust
reuse prefix::{a, b, c}
```
2024-05-15 02:32:59 +03:00
ardi
8dc6a5d145 improve maybe_consume_incorrect_semicolon 2024-05-14 23:07:40 +02:00
Michael Goulet
1529c661e4 Warn against redundant use<...> 2024-05-13 23:57:56 -04:00
Nicholas Nethercote
95e519ecbf Remove NtIdent and NtLifetime.
The extra span is now recorded in the new `TokenKind::NtIdent` and
`TokenKind::NtLifetime`. These both consist of a single token, and so
there's no operator precedence problems with inserting them directly
into the token stream.

The other way to do this would be to wrap the ident/lifetime in invisible
delimiters, but there's a lot of code that assumes an interpolated
ident/lifetime fits in a single token, and changing all that code to work with
invisible delimiters would have been a pain. (Maybe it could be done in a
follow-up.)

This change might not seem like much of a win, but it's a first step toward the
much bigger and long-desired removal of `Nonterminal` and
`TokenKind::Interpolated`. That change is big and complex enough that it's
worth doing this piece separately. (Indeed, this commit is based on part of a
late commit in #114647, a prior attempt at that big and complex change.)
2024-05-14 08:19:58 +10:00
Vincenzo Palazzo
a55d06323a
Macros: match const { ... } with expr nonterminal in edition 2024
Co-authored-by: Eric Holk <eric@theincredibleholk.org>
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
2024-05-13 11:55:26 -07:00
Eric Holk
ef6478ba5f
Add expr_2021 nonterminal and feature flag
This commit adds a new nonterminal `expr_2021` in macro patterns, and
`expr_fragment_specifier_2024` feature flag. For now, `expr` and
`expr_2021` are treated the same, but in future PRs we will update
`expr` to match to new grammar.

Co-authored-by: Vincezo Palazzo <vincenzopalazzodev@gmail.com>
2024-05-13 11:27:26 -07:00
David Tolnay
a36b94d088
Disallow cast with trailing braced macro in let-else 2024-05-12 21:50:14 -07:00
Nicholas Nethercote
9a63a42cb7 Remove a Span from TokenKind::Interpolated.
This span records the declaration of the metavariable in the LHS of the macro.
It's used in a couple of error messages. Unfortunately, it gets in the way of
the long-term goal of removing `TokenKind::Interpolated`. So this commit
removes it, which degrades a couple of (obscure) error messages but makes
things simpler and enables the next commit.
2024-05-13 10:30:30 +10:00
David Tolnay
10227eaee7
Add classify::expr_is_complete 2024-05-11 18:18:20 -07:00
David Tolnay
53521faf06
Remove MacCall special cases from Parser::parse_full_stmt
It is impossible for expr here to be a braced macro call. Expr comes
from `parse_stmt_without_recovery`, in which macro calls are parsed by
`parse_stmt_mac`. See this part:

    let kind = if (style == MacStmtStyle::Braces
        && self.token != token::Dot
        && self.token != token::Question)
        || self.token == token::Semi
        || self.token == token::Eof
    {
        StmtKind::MacCall(P(MacCallStmt { mac, style, attrs, tokens: None }))
    } else {
        // Since none of the above applied, this is an expression statement macro.
        let e = self.mk_expr(lo.to(hi), ExprKind::MacCall(mac));
        let e = self.maybe_recover_from_bad_qpath(e)?;
        let e = self.parse_expr_dot_or_call_with(e, lo, attrs)?;
        let e = self.parse_expr_assoc_with(
            0,
            LhsExpr::AlreadyParsed { expr: e, starts_statement: false },
        )?;
        StmtKind::Expr(e)
    };

A braced macro call at the head of a statement is always either extended
into ExprKind::Field / MethodCall / Await / Try / Binary, or else
returned as StmtKind::MacCall. We can never get a StmtKind::Expr
containing ExprKind::MacCall containing brace delimiter.
2024-05-11 15:49:51 -07:00
David Tolnay
aedc1b6ad4
Remove MacCall special case from recovery after missing 'if' after 'else'
The change to the test is a little goofy because the compiler was
guessing "correctly" before that `falsy! {}` is the condition as opposed
to the else body. But I believe this change is fundamentally correct.
Braced macro invocations in statement position are most often item-like
(`thread_local! {...}`) as opposed to parenthesized macro invocations
which are condition-like (`cfg!(...)`).
2024-05-11 15:49:51 -07:00
David Tolnay
728e117166
Document MacCall special case in Parser::parse_arm 2024-05-11 15:49:51 -07:00
David Tolnay
9dbe33d256
Document MacCall special case in Parser::expr_is_complete 2024-05-11 15:49:51 -07:00
David Tolnay
8adcaf5df2
Mark Parser::expr_is_complete call sites 2024-05-11 15:49:51 -07:00
David Tolnay
9e1cf2098d
Macro call with braces does not require semicolon to be statement
This commit by itself is supposed to have no effect on behavior. All of
the call sites are updated to preserve their previous behavior.

The behavior changes are in the commits that follow.
2024-05-11 15:48:59 -07:00
David Tolnay
cbb8714a3f
Mark expr_requires_semi_to_be_stmt call sites
For each of these, we need to decide whether they need to be using
`expr_requires_semi_to_be_stmt`, or `expr_requires_comma_to_be_match_arm`,
which are supposed to be 2 different behaviors. Previously they were
conflated into one, causing either too much or too little
parenthesization.
2024-05-11 15:48:58 -07:00
许杰友 Jieyou Xu (Joe)
e7bb090d0a
Rollup merge of #124930 - compiler-errors:consume-arg, r=petrochenkov
Make sure we consume a generic arg when checking mistyped turbofish

When recovering un-turbofish-ed args in expr position (e.g. `let x = a<T, U>();` in `check_mistyped_turbofish_with_multiple_type_params`, we used `parse_seq_to_before_end` to parse the fake generic args; however, it used `parse_generic_arg` which *optionally* parses a generic arg. If it doesn't end up parsing an arg, it returns `Ok(None)` and consumes no tokens. If we don't find a delimiter after this (`,`), we try parsing *another* element. In this case, we just infinitely loop looking for a subsequent element.

We can fix this by making sure that we either parse a generic arg or error in `parse_seq_to_before_end`'s callback.

Fixes #124897
2024-05-11 01:15:10 +01:00
许杰友 Jieyou Xu (Joe)
69122f1da4
Rollup merge of #124318 - bvanjoi:fix-123911, r=petrochenkov
ignore generics args in attribute paths

Fixes #97006
Fixes #123911
Fixes #123912

This patch ensures that we no longer have to handle invalid generic arguments in attribute paths.

r? `@petrochenkov`
2024-05-11 01:15:08 +01:00
bohan
f70f900036 ignore generics args in attribute paths 2024-05-11 00:13:27 +08:00
Matthias Krüger
f605174ea7
Rollup merge of #124778 - fmease:fix-diag-msg-parse-meta-item, r=nnethercote
Fix parse error message for meta items

Addresses https://github.com/rust-lang/rust/issues/122796#issuecomment-2010803906, cc [``@]Thomasdezeeuw.``

For attrs inside of a macro like `#[doc(alias = $ident)]` or `#[cfg(feature = $ident)]` where `$ident` is a macro metavariable of fragment kind `ident`, we used to say the following when expanded (with `$ident` ⟼ `ident`):

```
error: expected unsuffixed literal or identifier, found `ident`
  --> weird.rs:6:19
   |
6  |      #[cfg(feature = $ident)]
   |                      ^^^^^^
...
11 | m!(id);
   | ------ in this macro invocation
   |
   = note: this error originates in the macro `m` (in Nightly builds, run with -Z macro-backtrace for more info)
```

This was incorrect and caused confusion, justifiably so (see #122796).

In this position, we only accept/expect *unsuffixed literals* which consist of numeric & string literals as well as the boolean literals / the keywords / the reserved identifiers `false` & `true` **but not** arbitrary identifiers.

Furthermore, we used to suggest garbage when encountering unexpected non-identifier tokens:

```
error: expected unsuffixed literal, found `-`
  --> weird.rs:16:17
   |
16 | #[cfg(feature = -1)]
   |                 ^
   |
help: surround the identifier with quotation marks to parse it as a string
   |
16 | #[cfg(feature =" "-1)]
   |                + +
```

Now we no longer do.
2024-05-10 16:10:45 +02:00
León Orell Valerian Liehr
0ad3c5da72
Fix parse error message for meta items 2024-05-10 09:16:27 +02:00
Michael Goulet
dbdef68ddf Make sure we consume a generic arg when checking mistyped turbofish 2024-05-09 10:47:14 -04:00