Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:

 1. enums that uninhabited
 2. enums for which all but one variant is uninhabited
 3. enums with multiple inhabited variants

This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:

    enum Uninhabited { A(!, u128) }

...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in rust-lang#126460.

In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:

    enum Uninhabited { A(!, !), B(!) }

The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:

    enum Uninhabited { A(!, u128) }

...which represent their variants with `Variants::Single`.

Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:

    enum Uninhabited { A(u8, !), B(!, u32) }

...which represent their variants with `Variants::Multiple`.

This PR also adds a comment requested by RalfJung in his review of rust-lang#126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.

Fixes rust-lang#126460

Apparently MIR borrowck cares about at least one of these for checking variance.

In runtime MIR, though, there's no need for them as `PtrToPtr` does the same thing.

(Banning them simplifies passes like GVN that no longer need to handle multiple cast possibilities.)

We can't mix them with candidates below them, but we can mix them with
candidates above.

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

This is already handled at the config parsing level, so we can simplify it.

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

This synchronizes the fuchsia test running code with the clang test
runner. This brings with it:

* Improved logging
* Uses the fuchsia image from the SDK version
* Caches the product bundle across test runs
* Strips the binaries to reduce the data sent to the emulator

Fixes rust-lang#126573

Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de>

Edit from rust-lang#126631 to revert changes on ui tests

…compatible lifetimes

…ram" note

- Avoid "caller chooses ty for type param" note if the found type a.k.a.
  the return expression type *contains* the type parameter, because e.g.
  `&T` will always be different from `T` (i.e. "well duh").
- Rename `note_caller_chooses_ty_for_ty_param` to
  `try_note_caller_chooses_ty_for_ty_param` because the note is not
  always made.

Issue: rust-lang#126547

…r-errors

Test that opaque types can't have themselves as a hidden type with incompatible lifetimes

fixes rust-lang#122876

This PR used to add extra logic to prevent those cases, but after rust-lang#113169 this is implicitly rejected, because such usages are not defining.

delegation: Implement glob delegation

Support delegating to all trait methods in one go.
Overriding globs with explicit definitions is also supported.

The implementation is generally based on the design from rust-lang/rfcs#3530 (comment), but unlike with list delegation in rust-lang#123413 we cannot expand glob delegation eagerly.
We have to enqueue it into the queue of unexpanded macros (most other macros are processed this way too), and then a glob delegation waits in that queue until its trait path is resolved, and enough code expands to generate the identifier list produced from the glob.

Glob delegation is only allowed in impls, and can only point to traits.
Supporting it in other places gives very little practical benefit, but significantly raises the implementation complexity.

Part of rust-lang#118212.

…field, r=jackh726

Suggest removing unused tuple fields if they are the last fields

Fixes rust-lang#124556

We now check if dead/unused fields are the last fields of the tuple and suggest their removal instead of suggesting them to be changed to `()`.

…errors

fix: break inside async closure has incorrect span for enclosing closure

Fixes rust-lang#124496

…fetime, r=estebank,davidtwco

Place tail expression behind terminating scope

This PR implements rust-lang#123739 so that we can do further experiments in nightly.

A little rewrite has been applied to `for await` lowering. It was previously `unsafe { Pin::unchecked_new(into_async_iter(..)) }`. Under the edition 2024 rule, however, `into_async_iter` gets dropped at the end of the `unsafe` block. This presumably the first Edition 2024 migration rule goes by hoisting `into_async_iter(..)` into `match` one level above, so it now looks like the following.
```rust
match into_async_iter($iter_expr) {
  ref mut iter => match unsafe { Pin::unchecked_new(iter) } {
    ...
  }
}
```

…-errors

Allow constraining opaque types during subtyping in the trait system

Previous attempt: rust-lang#123979

Sometimes we don't immediately perform subtyping, but instead register a subtyping obligation and solve that obligation when its inference variables become resolved. Unlike immediate subtyping, we currently do not allow registering hidden types for opaque types. This PR also allows that.

…=jieyouxu

Migrate `bin-emit-no-symbols` `run-make` test to `rmake`

Part of rust-lang#121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

try-job: x86_64-msvc
try-job: armhf-gnu

…trait, r=compiler-errors

improve tip for inaccessible traits

Improve the tips when the candidate method is from an inaccessible trait.

For example:

```rs
mod m {
  trait Trait {
    fn f() {}
  }
  impl<T> Trait for T {}
}

fn main() {
  struct S;
  S::f();
}
```

The difference between before and now is:

```diff
error[E0599]: no function or associated item named `f` found for struct `S` in the current scope
  --> ./src/main.rs:88:6
   |
LL |   struct S;
   |   -------- function or associated item `f` not found for this struct
LL |   S::f();
   |      ^ function or associated item not found in `S`
   |
   = help: items from traits can only be used if the trait is implemented and in scope
- help: trait `Trait` which provides `f` is implemented but not in scope; perhaps you want to import it
+ help: trait `crate::m::Trait` which provides `f` is implemented but not reachable
   |
- LL + use crate::m::Trait;
   |
```

…errors

StorageLive: refresh storage (instead of UB) when local is already live

Blocked on [this FCP](rust-lang#99160 (comment)), which also contains the motivation.

Fixes rust-lang#99160
Fixes rust-lang#98896 (by declaring it not-a-bug)
Fixes rust-lang#119366
Fixes rust-lang/unsafe-code-guidelines#129

…thlin

Ban `ArrayToPointer` and `MutToConstPointer` from runtime MIR

Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/CastKind.3A.3APointerCoercion.20in.20Runtime.20MIR/near/443955195>

Apparently MIR borrowck cares about at least one of these for checking variance.

In runtime MIR, though, there's no need for them as `PtrToPtr` does the same thing.

(Banning them simplifies passes like GVN that no longer need to handle multiple cast possibilities.)

r? mir

…r=fmease

Suggest using a standalone doctest for non-local impl defs

This PR tweaks the lint output of the `non_local_definitions` lint to suggest using a standalone doctest instead of a moving the `impl` def to an impossible place as was already done with `macro_rules!` case in rust-lang#124568.

Fixes rust-lang#126339
r? ``@fmease``

safe transmute: support non-ZST, variantful, uninhabited enums

Previously, `Tree::from_enum`'s implementation branched into three disjoint cases:

 1. enums that uninhabited
 2. enums for which all but one variant is uninhabited
 3. enums with multiple variants

This branching (incorrectly) did not differentiate between variantful and variantless uninhabited enums. In both cases, we assumed (and asserted) that uninhabited enums are zero-sized types. This assumption is false for enums like:

    enum Uninhabited { A(!, u128) }

...which, currently, has the same size as `u128`. This faulty assumption manifested as the ICE reported in rust-lang#126460.

In this PR, we revise the first case of `Tree::from_enum` to consider only the narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts are described with `Variants::Single { index }`, are special in their layouts otherwise resemble the `!` type and cannot be descended into like typical enums. This first case captures uninhabited enums like:

    enum Uninhabited { A(!, !), B(!) }

The second case is revised to consider the broader category of "enums that defer their layout to one of their variants"; i.e., enums whose layouts are described with `Variants::Single { index }` and that do have a variant at `index`. This second case captures uninhabited enums that are not ZSTs, like:

    enum Uninhabited { A(!, u128) }

...which represent their variants with `Variants::Single`.

Finally, the third case is revised to cover the broader category of "enums with multiple variants", which captures uninhabited enums like:

    enum Uninhabited { A(u8, !), B(!, u32) }

...which represent their variants with `Variants::Multiple`.

This PR also adds a comment requested by ```@RalfJung``` in his review of rust-lang#126358 to `compiler/rustc_const_eval/src/interpret/discriminant.rs`.

Fixes rust-lang#126460

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

Sync fuchsia test runner with clang test runner

This synchronizes the fuchsia test running code with the clang test runner. This brings with it:

* Improved logging
* Uses the fuchsia image from the SDK version
* Caches the product bundle across test runs
* Strips the binaries to reduce the data sent to the emulator

r? `@tmandry`

…, r=matthewjasper

match lowering: expand or-candidates mixed with candidates above

This PR tweaks match lowering of or-patterns. Consider this:
```rust
match (x, y) {
    (1, true) => 1,
    (2, false) => 2,
    (1 | 2, true | false) => 3,
    (3 | 4, true | false) => 4,
    _ => 5,
}
```
One might hope that this can be compiled to a single `SwitchInt` on `x` followed by some boolean checks. Before this PR, we compile this to 3 `SwitchInt`s on `x`, because an arm that contains more than one or-pattern was compiled on its own. This PR groups branch `3` with the two branches above, getting us down to 2 `SwitchInt`s on `x`.

We can't in general expand or-patterns freely, because this interacts poorly with another optimization we do: or-pattern simplification. When an or-pattern doesn't involve bindings, we branch the success paths of all its alternatives to the same block. The drawback is that in a case like:
```rust
match (1, true) {
    (1 | 2, false) => unreachable!(),
    (2, _) => unreachable!(),
    _ => {}
}
```
if we used a single `SwitchInt`, by the time we test `false` we don't know whether we came from the `1` case or the `2` case, so we don't know where to go if `false` doesn't match.

Hence the limitation: we can process or-pattern alternatives alongside candidates that precede it, but not candidates that follow it. (Unless the or-pattern is the only remaining match pair of its candidate, in which case we can process it alongside whatever).

This PR allows the processing of or-pattern alternatives alongside candidates that precede it. One benefit is that we now process or-patterns in a single place in `mod.rs`.

r? `@matthewjasper`

hir_typeck: be more conservative in making "note caller chooses ty param" note

In rust-lang#122195 I added a "caller chooses ty for type param" note for when the return expression type a.k.a. found type does not match the expected return type.

rust-lang#126547 found that this note was confusing when the found return type *contains* the expected type, e.g.

```rs
fn f<T>(t: &T) -> T {
    t
}
```

because the found return type `&T` will *always* be different from the expected return type `T`, so the note was needlessly redundant and confusing.

This PR addresses that by not making the note if the found return type contains the expected return type.

r? `@fmease` (since you reviewed the original PR)

Fixes rust-lang#126547

…by789

override user defined channel when using precompiled rustc

We need to override `rust.channel` if it's manually specified when using the CI rustc. This is because if the compiler uses a different channel than the one specified in config.toml, tests may fail due to using a different channel than the one used by the compiler during tests.

For more context, see rust-lang#122709 (comment).

…r=Nilstrieb

Add @badboy and @BlackHoleFox as Mac Catalyst maintainers

Assented in rust-lang/compiler-team#761 (comment) and https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Promote.20Mac.20Catalyst.20targets.20to.20Tier.202.20compiler-team.23761/near/444590303.

…drop-glue, r=oli-obk

Make async drop code more consistent with regular drop code

Fixes rust-lang#126573

Relates to rust-lang#126482

r? ``@petrochenkov``

…-errors

Add `rustc-ice*` to `.gitignore`

I am a bit surprised this wasn't already here but there doesn't seem to be any reason not to add it. This will be nice to cut down on `git {add, diff, etc}` noise when debugging crashes.

…-v2, r=Nilstrieb

Replace `move||` with `move ||`

Edit from rust-lang#126631 to revert changes in `tests/ui`.

There are 18 instances of `move||` across 6 files in the repo:
- `compiler/rustc_hir_typeck/src/typeck_root_ctxt.rs`
- `library/core/src/sync/atomic.rs`
- `library/std/src/sync/condvar.rs`
- `library/std/src/sync/mpsc/mod.rs`
- `library/std/src/sync/barrier.rs`
- `library/std/src/thread/local.rs`

I have replaced all such instances with `move ||` instead as it better adheres to modern formatting standards.

Ideally, we would have this automated by rustfmt or some other tool, but I do not have the time to implement such a feature or tool.
Nonetheless, I would encourage any effort invested into such a tool or feature.