-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 6 pull requests #126679
Rollup of 6 pull requests #126679
Conversation
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 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)
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 5978f35330 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (3186d17): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary -2.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 691.592s -> 690.996s (-0.09%) |
Successful merges:
src/tools/rust-demangler
#125880 (Removesrc/tools/rust-demangler
)wasm32-wasi
#126662 (Unconditionally warn on usage ofwasm32-wasi
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup