Rollup of 9 pull requests #109252
Closed
Rollup of 9 pull requests #109252
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This test was failing under new-symbol-mangling = true. Adapt pattern to work in both cases. Related to rust-lang#106002 from December.
…ed type's param-env
I went over the cases where sort_by is used and in these two, one can use sort_by_key instead.
…r-errors Remove box expressions from HIR After rust-lang#108516, `#[rustc_box]` is used at HIR->THIR lowering and this is no longer emitted, so it can be removed. This is based on top of rust-lang#108471 to help with conflicts, so 43490488ccacd1a822e9c621f5ed6fca99959a0b is the only relevant commit (sorry for all the duplicated pings!) ```@rustbot``` label +S-blocked
…r=jyn514 Prevent stable `libtest` from supporting `-Zunstable-options` Took a while for me to get around to this but seems trivial (unless I'm missing some reason this will break all our tests). Fixes rust-lang#75526 Basically `libtest` already tries to handle this in https://github.com/rust-lang/rust/blob/501ad021b9a4fb2cd6a39e0302d22f169f6166b0/library/test/src/cli.rs#L310-L318 But that env var was not passed. I'm guessing at one point [this code](https://github.com/rust-lang/rust/blob/501ad021b9a4fb2cd6a39e0302d22f169f6166b0/src/bootstrap/compile.rs#L842-L844) (or a common ancestor) was used to compile the standard library/libtest, but that is no longer the case (or perhaps it never worked, I don't have time to go digging). I don't love that this is a "allow unstable by default" situation, as it means things like [`rustc-build-sysroot`](https://github.com/RalfJung/rustc-build-sysroot) could accidentally get unstable (CC ```@RalfJung)``` even if this is fixed here, but it's consistent with what happens in `rustc_feature`, so... yeah. This is user-facing after all, even if it's hard to imagine the outcome of that conversation being "lets continue allowing use of `-Zunstable-features` from stable rust" (especially since a `RUSTC_BOOTSTRAP=1`-shaped loophole remains)... I think it probably should get a vibe check in the t-libs meeting (and plausibly a relnote along the lines of "hey `cargo test -- -Zunstable-options --some --unstable --stuff=here` used to work on stable, that's been fixed, sorry"). I'll nominate it for that after CI comes up green (I've done a smoke check but don't know what (if anything) will need `bootstrap` to enable `RUSTC_BOOTSTRAP=1` when running tests) r? ```@jyn514```
…arget, r=tmandry Fix riscv64 fuchsia LLVM target name Currently, riscv64gc-unknown-fuchsia (added in rust-lang#108722) sets riscv64*gc*-unknown-fuchsia as the LLVM target. https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/compiler/rustc_target/src/spec/riscv64gc_unknown_fuchsia.rs#L5 However, riscv64*gc*-\* is not a valid LLVM target and causes the following error. ```console $ rustc --print cfg --target riscv64gc-unknown-fuchsia error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia" ``` As with other RISC-V targets, the LLVM target should use riscv64-\*, not riscv64*gc*-\*. https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/compiler/rustc_target/src/spec/riscv64gc_unknown_freebsd.rs#L5 https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/compiler/rustc_target/src/spec/riscv64gc_unknown_linux_gnu.rs#L5 I confirmed that riscv64-unknown-fuchsia is recognized as a valid LLVM target by using custom targets. ```console # create a custom target with `"llvm-target": "riscv64-unknown-fuchsia" from no-std riscv64gc target. $ rustc --print target-spec-json -Z unstable-options --target riscv64gc-unknown-none-elf | grep -v is-builtin | sed 's/"llvm-target".*/"llvm-target": "riscv64-unknown-fuchsia",/' > riscv64gc-unknown-fuchsia.json $ rustc --print cfg --target riscv64gc-unknown-fuchsia.json debug_assertions panic="abort" target_abi="" target_arch="riscv64" target_endian="little" target_env="" target_feature="a" target_feature="c" target_feature="d" target_feature="f" target_feature="m" ... $ cat riscv64gc-unknown-fuchsia.json { "arch": "riscv64", "code-model": "medium", "cpu": "generic-rv64", "data-layout": "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128", "eh-frame-header": false, "emit-debug-gdb-scripts": false, "features": "+m,+a,+f,+d,+c", "linker": "rust-lld", "linker-flavor": "ld.lld", "llvm-abiname": "lp64d", "llvm-target": "riscv64-unknown-fuchsia", "max-atomic-width": 64, "panic-strategy": "abort", "relocation-model": "static", "supported-sanitizers": [ "kernel-address" ], "target-pointer-width": "64" } # Check the current master's LLVM target name causes an error $ sed -i 's/riscv64-unknown-fuchsia/riscv64gc-unknown-fuchsia/' riscv64gc-unknown-fuchsia.json $ rustc --print cfg --target riscv64gc-unknown-fuchsia.json error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia" ``` r? ```@tmandry```
…henkov Fix linker detection for clang with prefix rust-lang#106489 removed check for clang with prefix. It says: > Also remove the check for -clang, since there are no architecture specific variants of clang (to my knowledge). However, when doing cross-compilation, a wrapper script for clang with the target name as a prefix is sometimes used. https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L62 https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/src/ci/docker/scripts/freebsd-toolchain.sh#L76-L80 https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L40 https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/compiler/rustc_target/src/spec/aarch64_pc_windows_gnullvm.rs#L7 It seems the regression did not occur on the targets mentioned above because the default linker flavor is gcc, but it did occur on targets where the default linker flavor is not gcc (taiki-e/setup-cross-toolchain-action@fd352f3). r? ```@petrochenkov```
…, r=Nilstrieb inherit_overflow: adapt pattern to also work with v0 mangling This test was failing under new-symbol-mangling = true. Adapt pattern to work in both cases. Related to rust-lang#106002 from December.
…-body, r=spastorino Install projection from RPITIT to default trait method opaque correctly 1. For new lowering strategy `-Zlower-impl-trait-in-trait-to-assoc-ty`, install the correct default trait method projection predicates (RPITIT -> opaque). This makes default trait body tests pass! 2. Fix two WF-checking bugs -- first, we want to make sure that we're always looking for an opaque type in `check_return_position_impl_trait_in_trait_bounds`. That's because the RPITIT projections are normalized to opaques during wfcheck. Second, fix RPITIT's param-envs by not adding the projection predicates that we install on trait methods to make default RPITITs work -- I left a comment why. 3. Also, just a small drive-by for `rustc_on_unimplemented`. Not sure if it affects any tests, but can't hurt. r? ```@spastorino,``` based off of rust-lang#109140
Use sort_by_key instead of sort_by I went over the cases where sort_by is used and in these two, one can use sort_by_key instead.
…ddle Fix invalid markdown link references Fixes invalid link references in librustdoc's template documentation. `[text](link)` was interpreted as a relative path to the file, making the link invalid, while `[text][label]` references a label defined in the file itself: <https://www.markdownguide.org/basic-syntax/#reference-style-links>
…er-errors Fix generics mismatch errors for RPITITs on -Zlower-impl-trait-in-trait-to-assoc-ty This PR stops reporting errors due to different count of generics on the new synthesized associated types for RPITITs. Those were already reported when we compare the function on the triat with the function on the impl. r? `@compiler-errors`
rustbot
added
S-waiting-on-review
rustbot
added
T-rustdoc
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
libtestfrom supporting-Zunstable-options#109044 (Prevent stablelibtestfrom supporting-Zunstable-options)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup