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 12 pull requests #137789

Closed
wants to merge 36 commits into from
Closed

Conversation

jieyouxu
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Shunpoco and others added 30 commits January 4, 2025 12:53
From rust-lang#123067, this test should ensure that there is no duplicated basic block against or-patterns.

Signed-off-by: Shunpoco <tkngsnsk313320@gmail.com>
This was left to only warn in the current crate to give users
a chance to update their code. Now for 1.86 we also warn users
depending on those crates.
Otherwise this test will include a future incompatibility warning
on some targets but not others.
minicore makes it much easier to add new language items to all of the
existing `no_core` tests.
If we use a С/С++ compiler as linker, then Posix-style escaping should be used.
instead, we can just import the intrinsics from core
…DianQK

Add FileCheck annotations to mir-opt/issues

This resolves a part of rust-lang#116971 .

The directory `tests/mir-opt/issues` has only one test issue_75439.rs which should add FileCheck annotations.

Originally it was introduced in rust-lang#75580 to confirm that there were duplicated basic blocks against or-patterns, but in rust-lang#123067 the duplication was resolved. So FileCheck should ensure that there is no such duplication any more.
…in-deps, r=compiler-errors

Future incompatibility warning `unsupported_fn_ptr_calling_conventions`: Also warn in dependencies

Tracking issue: rust-lang#130260

As discussed [in the previous PR](https://github.com/rust-lang/rust/pull/128784/files#r1752533758) now the future incompatibility warning is enabled in dependencies.

The warning was added in 1.83, while this change will get into stable in 1.86, which gives crate authors three versions to fix the warning.

r? compiler-errors
… r=BoxyUwU

Pattern types: Avoid having to handle an Option for range ends in the type system or the HIR

Instead,

1. during hir_ty_lowering, we now generate constants for the min/max when the range doesn't have a start/end specified.
2. in a later commit we generate those constants during ast lowering, simplifying everything further by not having to handle the range end inclusivity anymore in the type system (and thus avoiding any issues of `0..5` being different from `0..=4`

I think it makes all the type system code simpler, and the cost of the extra `ConstKind::Value` processing seems negligible.

r? ``@BoxyUwU``

cc ``@joshtriplett`` ``@scottmcm``
…li-obk

Don't error when adding a staticlib with bitcode files compiled by newer LLVM

cc rust-lang#128955 (comment)
Update some comparison codegen tests now that they pass in LLVM20

Fixes rust-lang#106107

Needed one tweak to the default `PartialOrd::le` to get the test to pass.  Everything but the derived 2-field `le` test passes even without the change to the defaults in the trait.
…directives, r=notriddle

Fix (more) test directives that were accidentally ignored

Continuation of rust-lang#137099 , caught by rust-lang#137103 (and needed to unblock that one).
These test directives were accidentally using the old (`// `@`)` syntax
… r=RalfJung

import `simd_` intrinsics

In most cases, we can import the simd intrinsics rather than redeclare them. Apparently, most of these tests were written before `std::intrinsics::simd` existed.

There are a couple of exceptions where we can't yet import:

- the intrinsics are not declared as `const fn` in the standard library, causing issues in the `const-eval` tests
- the `simd_shuffle_generic` function is not exposed from `std::intrinsics`
- the `simd_fpow` and `simd_fpowi` functions are not exposed from `std::intrinsics` (removed in rust-lang#137595)
- some tests use `no_core`, and therefore cannot use `std::intrinsics`

r? `@RalfJung`

cc `@workingjubilee` do you have context on why some intrinsics are not exposed?
…youxu

tests: use minicore more

minicore makes it much easier to add new language items to all of the existing `no_core` tests.

Most of the remaining tests that *could* use minicore either fail because..

1. LLVM IR output changes and doesn't pass the test as written. I didn't look into these further.
2. The test has revisions w/ different compilation flags, expecting some to fail, and when using minicore, minicore is compiled with those flags and fails in the expected way because of the flags rather than the test, and that's considered a failure.

But these tests can be changed and make adding new language items a lot easier.

r? `@jieyouxu`
…lnay

Fix Windows `Command` search path bug

Currently `Command::new` on Windows works differently depending on whether any environment variable is set. For example,

```rust
// Searches for "myapp" in the application and system paths first (aka Windows native behaviour).
Command::new("myapp").spawn();

// Search for "myapp" in `PATH` first
Command::new("myapp").env("a", "b").spawn();
```

This is a bug because the search path should only change if `PATH` is changed for the child (i.e. `.env("PATH", "...")`).

This was discussed in a libs-api meeting where the exact semantics of `Command::new` was not decided but there seemed to be broad agreement that this particular thing is just a bug that can be fixed.

r? libs-api
linker: Fix escaping style for response files on Windows

If we use a С/С++ compiler as linker, then Posix-style escaping should be used.

Also temporarily fixup rustbuild to not fail at least in common scenarios, until the bootstrap compiler is updated.

Fixes rust-lang#137498
…,GuillaumeGomez

Re-enable `--generate-link-to-defintion` for tools internal rustdoc

~~These were removed because they used to break the build: rust-lang#122066 (comment), but testing locally it seems to work now.~~

This was re enabled in rust-lang#136589, but only for rustc, not tools.

The FIXME that prompted removing this is still present. Do we have an issue with an MCVE for this? CC `@GuillaumeGomez`

https://github.com/rust-lang/rust/blob/ac91805f3179fc2225c60e8ccf5a1daa09d43f3d/src/librustdoc/html/render/span_map.rs#L178-L182

try-job: aarch64-apple
…d-crit, r=oli-obk

Fix sized constraint for unsafe binder

Fixes rust-lang#137705
r? oli-obk
@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc O-windows Operating system: Windows PG-exploit-mitigations Project group: Exploit mitigations 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-libs Relevant to the library 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. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. rollup A PR which is a rollup labels Feb 28, 2025
@jieyouxu
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 28, 2025

📌 Commit e5ca055 has been approved by jieyouxu

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 Feb 28, 2025
@rust-log-analyzer
Copy link
Collaborator

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

Click to see the possible cause of the failure (guessed by this bot)
   Compiling compiler_builtins v0.1.148
error: const stability on the impl does not match the const stability on the trait
  --> library/core/src/pat.rs:44:13
   |
41 | /  macro_rules! impl_range_pat {
42 | |      ($($ty:ty,)*) => {
43 | |          $(
44 | |/             impl const RangePattern for $ty {
45 | ||                 const MIN: $ty = <$ty>::MIN;
46 | ||                 const MAX: $ty = <$ty>::MAX;
47 | ||                 fn sub_one(self) -> Self {
50 | ||             }
   | ||_____________^
...  |
53 | |  }
---
57 |  |     u8, u16, u32, u64, u128, usize,
58 |  | }
   |  |_- in this macro invocation
   |
note: this impl is (implicitly) stable...
   |
41 | /  macro_rules! impl_range_pat {
41 | /  macro_rules! impl_range_pat {
42 | |      ($($ty:ty,)*) => {
43 | |          $(
44 | |/             impl const RangePattern for $ty {
45 | ||                 const MIN: $ty = <$ty>::MIN;
46 | ||                 const MAX: $ty = <$ty>::MAX;
47 | ||                 fn sub_one(self) -> Self {
50 | ||             }
   | ||_____________^
...  |
53 | |  }
---

error: const stability on the impl does not match the const stability on the trait
  --> library/core/src/pat.rs:60:1
   |
60 | / impl const RangePattern for char {
61 | |     const MIN: Self = char::MIN;
62 | |
63 | |     const MAX: Self = char::MAX;
71 | | }
   | |_^
   |
   |
note: this impl is (implicitly) stable...
   |
60 | / impl const RangePattern for char {
60 | / impl const RangePattern for char {
61 | |     const MIN: Self = char::MIN;
62 | |
63 | |     const MAX: Self = char::MAX;
71 | | }
   | |_^
note: ...but the trait is unstable
  --> library/core/src/pat.rs:26:11

@jieyouxu
Copy link
Member Author

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 28, 2025
@jieyouxu jieyouxu closed this Feb 28, 2025
@jieyouxu jieyouxu deleted the rollup-9n5mmq0 branch February 28, 2025 13:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs A-testsuite Area: The testsuite used to check the correctness of rustc O-windows Operating system: Windows PG-exploit-mitigations Project group: Exploit mitigations rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. 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-libs Relevant to the library 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. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.
Projects
None yet
Development

Successfully merging this pull request may close these issues.