rust/compiler/rustc_parse, branch 1.71.0

Rollup merge of #111181 - bvanjoi:fix-issue-111148, r=davidtwco

2023-05-27T18:40:28+00:00

fix(parse): return unpected when current token is EOF close https://github.com/rust-lang/rust/issues/111148 #111148 panic occurred because [FatalError.raise()](https://github.com/bvanjoi/rust/blob/master/compiler/rustc_parse/src/parser/mod.rs#LL540C3-L540C3) was encountered which caused by `Eof` and `Pound`(the last token) had same span, when parsing `#` in `fn a<#`. There are a few ways to solve this problem: - Change the action assign for [self.last_unexpected_token_span](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/diagnostics.rs#L592), for example, if current token is `Eof`, then return Error directly. - Avoid triggering the `FatalError` when the current token is `Eof`. I have chosen the second option because executing `expected_one_of_not_found` when the token is `Eof` but not in `ediable` seems reasonable.

Ensure Fluent messages are in alphabetical order

2023-05-25T23:49:35+00:00

Use `is_some_and`/`is_ok_and` in less obvious spots

2023-05-24T14:33:43+00:00

Use `Option::is_some_and` and `Result::is_ok_and` in the compiler

2023-05-24T14:20:41+00:00

Rollup merge of #111708 - jyn514:delay-span-bug-msg, r=compiler-errors

2023-05-20T06:51:00+00:00

Give a more useful location for where a span_bug was delayed Before: ``` = note: delayed at 0: ::emit_diagnostic at ./compiler/rustc_errors/src/lib.rs:1335:29 1: ::emit_diagnostic at ./compiler/rustc_errors/src/lib.rs:1124:9 ... ``` After: ``` = note: delayed at compiler/rustc_parse/src/parser/diagnostics.rs:2158:28 0: ::emit_diagnostic at ./compiler/rustc_errors/src/lib.rs:1335:29 1: ::emit_diagnostic at ./compiler/rustc_errors/src/lib.rs:1124:9 ... ``` This both makes the relevant frame easier to find without having to dig through diagnostic internals, and avoids the weird-looking formatting for the first frame. Found while working on https://github.com/rust-lang/rust/issues/111529.

Rollup merge of #111054 - cjgillot:cfg-eval-recover, r=b-naber

2023-05-18T12:07:08+00:00

Do not recover when parsing stmt in cfg-eval. `parse_stmt` does recovery on its own. When parsing the statement fails, we always get `Ok(None)` instead of an `Err` variant with the diagnostic that we can emit. To avoid this behaviour, we need to opt-out of recovery for cfg_eval. Fixes https://github.com/rust-lang/rust/issues/105228

Rollup merge of #111633 - nnethercote:avoid-ref-format, r=WaffleLapkin

2023-05-18T05:22:35+00:00

Avoid `&format("...")` calls in error message code. Some error message cleanups. Best reviewed one commit at a time. r? `@davidtwco`

Give a more useful location for where a span_bug was delayed

2023-05-18T04:15:22+00:00

Before: ``` = note: delayed at 0: ::emit_diagnostic at ./compiler/rustc_errors/src/lib.rs:1335:29 1: ::emit_diagnostic at ./compiler/rustc_errors/src/lib.rs:1124:9 ... ``` After: ``` = note: delayed at compiler/rustc_parse/src/parser/diagnostics.rs:2158:28 0: ::emit_diagnostic at ./compiler/rustc_errors/src/lib.rs:1335:29 1: ::emit_diagnostic at ./compiler/rustc_errors/src/lib.rs:1124:9 ``` This both makes the relevant frame easier to find without having to dig through diagnostic internals, and avoids the weird-looking formatting for the first frame.

Avoid `&format("...")` calls in error message code.

2023-05-16T07:59:56+00:00

Error message all end up passing into a function as an `impl Into<{D,Subd}iagnosticMessage>`. If an error message is creatd as `&format("...")` that means we allocate a string (in the `format!` call), then take a reference, and then clone (allocating again) the reference to produce the `{D,Subd}iagnosticMessage`, which is silly. This commit removes the leading `&` from a lot of these cases. This means the original `String` is moved into the `{D,Subd}iagnosticMessage`, avoiding the double allocations. This requires changing some function argument types from `&str` to `String` (when all arguments are `String`) or `impl Into<{D,Subd}iagnosticMessage>` (when some arguments are `String` and some are `&str`).

Recover `impl` correctly

2023-05-15T17:14:59+00:00