Signed-off-by: onur-ozkan <[email protected]>

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

Signed-off-by: onur-ozkan <[email protected]>

This commit is a continuation of the work originally proposed in
rust-lang/compiler-team#607 and later amended in
rust-lang/compiler-team#695. The end goal is to rename `wasm32-wasi` to
`wasm32-wasip1` to reflect WASI's development and distinguish the
preexisting target from the `wasm32-wasip2` target that WASI is now
developing. Work for this transition began in rust-lang#120468 which landed in
Rust 1.78 which became stable on 2024-05-02.

This implements the next phase of the transition plan to warn on usage
of `wasm32-wasi`. This is intended to help alert users that a removal is
pending and all release channels have the replacement available as well.
This will reach stable on 2024-09-05. The next stage of the plan is to
remove the `wasm32-wasi` target some time in October 2024 which means
that the removal will reach stable on 2025-01-09. For reference a full
schedule of this transition is listed [here].

Currently this implementation is a simple unconditional warning whenever
`rustc --target wasm32-wasi` is invoked. As-implemented there's no way
to turn off the warning other than to switch to the `wasm32-wasip1`
target.

[here]: rust-lang#120468 (comment)

Condition coverage extends branch coverage to treat the specific case
of last operands of boolean decisions not involved in control flow.
This is ultimately made for MCDC to be exhaustive on all boolean expressions.

This patch adds a call to `visit_branch_coverage_operation` to track the
top-level operand of the said decisions, and changes
`visit_coverage_standalone_condition` so MCDC branch registration is called
when enabled on these _last RHS_ cases.

…-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.

…l, r=nnethercote

MCDC Coverage: instrument last boolean RHS operands from condition coverage

Fresh PR from rust-lang#124652

--

This PR ensures that the top-level boolean expressions that are not part of the control flow are correctly instrumented thanks to condition coverage.

See discussion on rust-lang#124120.
Depends on `@Zalathar` 's condition coverage implementation rust-lang#125756.

Remove `src/tools/rust-demangler`

`rust-demangler` is a small binary that reads a list of mangled symbols from stdin, demangles them (using the `rustc-demangle` library crate), and prints the demangled symbols to stdout.

It was added as part of the initial implementation of coverage instrumentation in 2020/2021, so that coverage tests could pass it to `llvm-cov --Xdemangler` when generating coverage reports. It has been largely untouched since then.

As of rust-lang#125816 it is no longer used by coverage tests, and has no remaining in-tree uses.

There is code in bootstrap to build and package the demangler, but it's unclear where the resulting binaries actually end up, or whether there's any reasonable way for `rustup` users to obtain them.

---

For users needing a command-line demangler, `rustfilt` exists and is more actively maintained. It's also quite easy to use the `rustc-demangle` library to build a custom command-line demangler if necessary, with only a few lines of code.

The tool's name (`rust-demangler`) is easily confused with the name of the library crate `rustc-demangle`, so removing the tool will eliminate that confusion. There also doesn't appear to be much reason to use `rust-demangler` over `rustfilt`.

---

This PR therefore removes the tool, and removes all of its associated code from bootstrap.

MCP filed: rust-lang/compiler-team#754

…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

…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=michaelwoerister

Unconditionally warn on usage of `wasm32-wasi`

This commit is a continuation of the work originally proposed in rust-lang/compiler-team#607 and later amended in
rust-lang/compiler-team#695. The end goal is to rename `wasm32-wasi` to `wasm32-wasip1` to reflect WASI's development and distinguish the preexisting target from the `wasm32-wasip2` target that WASI is now developing. Work for this transition began in rust-lang#120468 which landed in Rust 1.78 which became stable on 2024-05-02.

This implements the next phase of the transition plan to warn on usage of `wasm32-wasi`. This is intended to help alert users that a removal is pending and all release channels have the replacement available as well. This will reach stable on 2024-09-05. The next stage of the plan is to remove the `wasm32-wasi` target some time in October 2024 which means that the removal will reach stable on 2025-01-09. For reference a full schedule of this transition is listed [here].

Currently this implementation is a simple unconditional warning whenever `rustc --target wasm32-wasi` is invoked. As-implemented there's no way to turn off the warning other than to switch to the `wasm32-wasip1` target.

[here]: rust-lang#120468 (comment)