Skip to content
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 8 pull requests #109242

Closed
wants to merge 32 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

thomcc and others added 30 commits March 12, 2023 00:23
Hide invalid proc-macro suggestions and track spans
coming from proc-macros pointing at attribute.

Effectively, unless the proc-macro keeps user spans,
suggestions will not be produced for the code they
produce.

Account for desugaring when checking if a span can be used for suggestions

Fix rust-lang#106720.
This test was failing under new-symbol-mangling = true. Adapt pattern to
work in both cases.

Related to rust-lang#106002 from December.
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``
Do not provide suggestions when the spans come from expanded code that doesn't point at user code

Hide invalid proc-macro suggestions and track spans
coming from proc-macros pointing at attribute.

Effectively, unless the proc-macro keeps user spans,
suggestions will not be produced for the code they
produce.

r? ``@ghost``

Fix rust-lang#107113, fix rust-lang#107976, fix rust-lang#107977, fix rust-lang#108748, fix rust-lang#106720, fix rust-lang#90557.

Could potentially address rust-lang#50141, rust-lang#67373, rust-lang#55146, rust-lang#78862, rust-lang#74043, rust-lang#88514, rust-lang#83320, rust-lang#91520, rust-lang#104071. CC rust-lang#50122, rust-lang#76360.
…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.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Mar 17, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Mar 17, 2023

📌 Commit 2026095 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 17, 2023
@bors
Copy link
Contributor

bors commented Mar 17, 2023

⌛ Testing commit 2026095 with merge ce9737aa47037575acb72703e49f292fb6af46c8...

@rust-log-analyzer
Copy link
Collaborator

The job dist-x86_64-mingw failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[2523/3025] Building CXX object lib/XRay/CMakeFiles/LLVMXRay.dir/InstrumentationMap.cpp.obj
[2524/3025] Linking CXX static library lib\libLLVMInterfaceStub.a
[2525/3025] Building CXX object lib/XRay/CMakeFiles/LLVMXRay.dir/FDRTraceWriter.cpp.obj
[2526/3025] Linking CXX static library lib\libLLVMDebugInfoPDB.a
FAILED: lib/libLLVMDebugInfoPDB.a 
cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E rm -f lib\libLLVMDebugInfoPDB.a && D:\a\rust\rust\mingw64\bin\ar.exe qc lib\libLLVMDebugInfoPDB.a  @CMakeFiles\LLVMDebugInfoPDB.rsp && D:\a\rust\rust\mingw64\bin\ranlib.exe lib\libLLVMDebugInfoPDB.a && cd ."
D:\a\rust\rust\mingw64\bin\ar.exe: could not create temporary file whilst writing archive: no more archived files
[2527/3025] Building CXX object lib/XRay/CMakeFiles/LLVMXRay.dir/FDRRecords.cpp.obj
[2528/3025] Building CXX object lib/XRay/CMakeFiles/LLVMXRay.dir/FDRTraceExpander.cpp.obj
[2529/3025] Linking CXX static library lib\libLLVMDebugInfoDWARF.a
[2530/3025] Linking CXX static library lib\libLLVMObjCopy.a
[2530/3025] Linking CXX static library lib\libLLVMObjCopy.a
[2531/3025] Building CXX object lib/XRay/CMakeFiles/LLVMXRay.dir/FileHeaderReader.cpp.obj
[2532/3025] Linking CXX static library lib\libLLVMObjectYAML.a
[2533/3025] Building CXX object lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.obj
ninja: build stopped: subcommand failed.
command did not execute successfully, got: exit code: 1


build script failed, must exit now', C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\cmake-0.1.48\src\lib.rs:975:5
 finished in 251.549 seconds
Build completed unsuccessfully in 0:07:15

@bors
Copy link
Contributor

bors commented Mar 17, 2023

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 17, 2023
@oli-obk oli-obk closed this Mar 17, 2023
@oli-obk
Copy link
Contributor

oli-obk commented Mar 17, 2023

#109082 is a perf regression

@matthiaskrgr matthiaskrgr deleted the rollup-o5g4yn6 branch March 16, 2024 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.