The new flag has been described in the Major Change Proposal at
rust-lang/compiler-team#707

…more projections.

This makes it possible for two nodes/edges in the coverage graph to share the
same counter, without causing the instrumentor to inject unwanted duplicate
counter-increment statements.

Co-authored-by: Ralf Jung <post@ralfj.de>

When encountering an `if let` tail expression without an `else` arm for an
enum with a single variant, suggest writing an irrefutable `let` binding
instead.

```
error[E0317]: `if` may be missing an `else` clause
  --> $DIR/irrefutable-if-let-without-else.rs:8:5
   |
LL |   fn foo(x: Enum) -> i32 {
   |                      --- expected `i32` because of this return type
LL | /     if let Enum::Variant(value) = x {
LL | |         value
LL | |     }
   | |_____^ expected `i32`, found `()`
   |
   = note: `if` expressions without `else` evaluate to `()`
   = help: consider adding an `else` block that evaluates to the expected type
help: consider using an irrefutable `let` binding instead
   |
LL ~     let Enum::Variant(value) = x;
LL ~         value
   |
```

Fix rust-lang#61788.

Ignoring unused bindings should be a determination made by a human, `rustfix` shouldn't auto-apply the suggested change.

Fix rust-lang#54196.

It's never used.

When `download-ci-llvm` is enabled, `llvm_out` ends up with the
error below due to an incorrect path on cross-compilations. This change fixes that.

```
failed to execute command: "/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--version"
ERROR: No such file or directory (os error 2)
```

Signed-off-by: onur-ozkan <work@onurozkan.dev>

Signed-off-by: onur-ozkan <work@onurozkan.dev>

When `catch_fatal_errors` catches a `FatalErrorMarker`, it returns an
`ErrorGuaranteed` that is conjured out of thin air with
`unchecked_claim_error_was_emitted`. But that `ErrorGuaranteed` is never
used.

This commit changes it to instead conjure a `FatalError` out of thin
air. (A non-deprecated action!) This makes more sense because
`FatalError` and `FatalErrorMarker` are a natural pairing -- a
`FatalErrorMarker` is created by calling `FatalError::raise`, so this is
effectively getting back the original `FatalError`.

This requires a tiny change in `catch_with_exit_code`. The old result of
the `catch_fatal_errors` call there was
`Result<Result<(), ErrorGuaranteed>, ErrorGuaranteed>` which could be
`flatten`ed into `Result<(), ErrorGuaranteed>`. The new result of the
`catch_fatal_errors` calls is
`Result<Result<(), ErrorGuaranteed>, FatalError>`, which can't be
`flatten`ed but is still easily matched for the success case.

By making non-unicode arguments a fatal error instead of a warning, we
don't need to handle what comes after, which avoids the need for an
`unchecked_claim_error_was_emitted` call.

`main_args` calls `from_matches`, which does lots of initialization. If
anything goes wrong, `from_matches` emits an error message and returns
`Err(1)` (or `Err(3)`). `main_args` then turns the `Err(1)` into
`Err(ErrorGuaranteed)`, because that's what `catch_with_exit_code`
requires on error. But `catch_with_exit_code` doesn't do anything with
the `ErrorGuaranteed`, it just exits with `EXIT_FAILURE`.

We can avoid the creation of the `ErrorGuaranteed` (which requires
an undesirable `unchecked_claim_error_was_emitted` call), by changing
`from_matches` to instead eagerly abort if anything goes wrong. The
behaviour from the user's point of view is the same: an early abort with
an `EXIT_FAILURE` exit code.

And we can also simplify `from_matches` to return an `Option` instead of
a `Result`:
- Old `Err(0)` case --> `None`
- Old `Err(_)` case --> fatal error.

This requires similar changes to `ScrapeExamplesOptions::new` and
`load_call_locations`.

- In `emit_producing_error_guaranteed`, only allow `Level::Error`.
- In `emit_diagnostic`, only produce `ErrorGuaranteed` for `Level` and
  `DelayedBug`. (Not `Bug` or `Fatal`. They don't need it, because the
  relevant `emit` methods abort.)
- Add/update various comments.

…teed`.

It's more to-the-point.

Add armv8r-none-eabihf target for the Cortex-R52.

…, r=petrochenkov

Add unstable `-Z direct-access-external-data` cmdline flag for `rustc`

The new flag has been described in the Major Change Proposal at rust-lang/compiler-team#707

Fixes rust-lang#118053

…alfJung

various const interning cleanups

After rust-lang#119044 I noticed that some things can be simplified and refactored.

This is also a requirement for rust-lang#116564 as there we'll need to treat the base allocation differently from the others

r? ```@RalfJung```

…illot

 Add FileCheck annotations to MIR-opt SROA tests

Part of rust-lang#116971, adds FileCheck annotations to SROA MIR-opt tests in `tests/mir-opt/sroa` and a few uncategorized files.

r? cjgillot

…rrors

Mark "unused binding" suggestion as maybe incorrect

Ignoring unused bindings should be a determination made by a human, `rustfix` shouldn't auto-apply the suggested change.

Fix rust-lang#54196.

Suggest turning `if let` into irrefutable `let` if appropriate

When encountering an `if let` tail expression without an `else` arm for an enum with a single variant, suggest writing an irrefutable `let` binding instead.

```
error[E0317]: `if` may be missing an `else` clause
  --> $DIR/irrefutable-if-let-without-else.rs:8:5
   |
LL |   fn foo(x: Enum) -> i32 {
   |                      --- expected `i32` because of this return type
LL | /     if let Enum::Variant(value) = x {
LL | |         value
LL | |     }
   | |_____^ expected `i32`, found `()`
   |
   = note: `if` expressions without `else` evaluate to `()`
   = help: consider adding an `else` block that evaluates to the expected type
help: consider using an irrefutable `let` binding instead
   |
LL ~     let Enum::Variant(value) = x;
LL ~         value
   |
```

Fix rust-lang#61788.

coverage: Split out counter increment sites from BCB node/edge counters

This makes it possible for two nodes/edges in the coverage graph to share the same counter, without causing the instrumentor to inject unwanted duplicate counter-increment statements.

---

```@rustbot``` label +A-code-coverage

…rrors

pattern_analysis: gather up place-relevant info

We track 3 things about each place during exhaustiveness: its type, its (data) validity, and whether it's the scrutinee place. This PR gathers all three into a single struct.

r? ````@compiler-errors````

…rcote

Add parallel rustc ui tests

Updates rust-lang#118698

Add some ui tests for parallel rustc front end

This is a relatively large feature so I think it's worth creating a new entity in tests/ui folder, so we need to modify the limit in tidy.

…cross-target, r=albertlarsan68

fix `llvm_out` to use the correct LLVM root

When `download-ci-llvm` is enabled, `llvm_out` ends up with the
error below due to an incorrect path on cross-compilations. This change fixes that.

```sh
failed to execute command: "/rust/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--version"
ERROR: No such file or directory (os error 2)
```

…crum

Don't use bashism in checktools.sh

`if [[` doesn't work because this is a `/bin/sh` script. We were never running the success side of this `if` at all.

MirPass: make name more const

Continues rust-lang#120161, this time applied to `MirPass` instead of `MirLint`, locally shaves few (very few) instructions off.

r? `@cjgillot`

…ms, r=oli-obk

Remove some `unchecked_claim_error_was_emitted` calls

We want to drive the number of these calls down as much as possible. This PR gets rid of a bunch of them.

r? `@oli-obk`