Skip to content

Rollup of 10 pull requests #142490

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

Closed
wants to merge 42 commits into from
Closed

Conversation

jhpratt
Copy link
Member

@jhpratt jhpratt commented Jun 14, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

cberner and others added 30 commits May 28, 2025 21:01
The unexpected configs are now unused or known to `rustc` in our CI.
This allows UTF-8 characters to be printed without escapes, rather than
just ASCII.
Replace `build.rs` Rust generation with macros, using the unstable
`${concat(...)}`.

Fixes: rust-lang/compiler-builtins#947
After adding tests, the current implementation for fminimum fails when
provided a negative zero and NaN as inputs:

    ---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64 stdout ----

    thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13:
    fmaximum_num(-0x0p+0, NaN)
    l: NaN (0x7ff8000000000000)
    r: -0.0 (0x8000000000000000)

    ---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32 stdout ----

    thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13:
    fmaximum_num(-0x0p+0, NaN)
    l: NaN (0x7fc00000)
    r: -0.0 (0x80000000)

Add more thorough spec tests for these functions and correct the
implementations.

Canonicalization is also moved to a trait method to centralize
documentation about what it does and doesn't do.
Use a consistent ordering for top-level manifest keys, and remove those
that are now redundant (`homapage` isn't supposed to be the same as
`repository`, and `documentation` automatically points to docs.rs now).
Now that this repository is a subtree, we have no need to continue
publishing `compiler-builtins`.
Signed-off-by: Jonathan Brouwer <[email protected]>
The config file is not needed anymore since compiler-builtins is no
longer published. Removing it will resolve a CI failure.
To prepare for merging from rust-lang/rust, set the version file to:

    d087f11 Auto merge of rust-lang#134841 - estebank:serde-attr-4, r=wesleywiser
tgross35 and others added 11 commits June 14, 2025 06:56
Out-of-tree testing is broken with the most recent update from
rust-lang/rust because it makes `compiler-builtins` depend on `core` by
path, which isn't usually available. In order to enable testing outside
of rust-lang/rust, add a new crate `builtins-shim` that uses the same
source as `compiler-builtins` but drops the `core` dependency. This has
replaced `compiler-builtins` as the workspace member and entrypoint for
tests.
Temporary lifetime extension through tuple struct and tuple variant constructors

This makes temporary lifetime extension work for tuple struct and tuple variant constructors, such as `Some()`.

Before:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Not extended :(
let a = Some { 0: &temp() }; // Extended
```

After:
```rust
let a = &temp(); // Extended
let a = Some(&temp()); // Extended
let a = Some { 0: &temp() }; // Extended
```

So, with this change, this works:

```rust
let a = Some(&String::from("hello")); // New: String lifetime now extended!

println!("{a:?}");
```

Until now, we did not extend through tuple struct/variant constructors (like `Some`), because they are function calls syntactically, and we do not want to extend the String lifetime in:

```rust
let a = some_function(&String::from("hello")); // String not extended!
```

However, it turns out to be very easy to distinguish between regular functions and constructors at the point where we do lifetime extension.

In practice, constructors nearly always use UpperCamelCase while regular functions use lower_snake_case, so it should still be easy to for a human programmer at the call site to see whether something qualifies for lifetime extension or not.

This needs a lang fcp.

---

More examples of what will work after this change:

```rust
let x = Person {
    name: "Ferris",
    job: Some(&Job { // `Job` now extended!
        title: "Chief Rustacean",
        organisation: "Acme Ltd.",
    }),
};

dbg!(x);
```

```rust
let file = if use_stdout {
    None
} else {
    Some(&File::create("asdf")?) // `File` now extended!
};

set_logger(file);
```

```rust
use std::path::Component;

let c = Component::Normal(&OsString::from(format!("test-{num}"))); // OsString now extended!

assert_eq!(path.components.first().unwrap(), c);
```
…r=aDotInTheVoid

[rustdoc] Give more information into extracted doctest information

Follow-up of rust-lang#134531.

This update fragment the doctest code into its sub-parts to give more control to the end users on how they want to use it.

The new JSON looks like this:

```json
{
  "format_version":2,
  "doctests":[
    {
      "file":"$DIR/extract-doctests-result.rs",
      "line":8,
      "doctest_attributes":{
        "original":"",
        "should_panic":false,
        "no_run":false,
        "ignore":"None",
        "rust":true,
        "test_harness":false,
        "compile_fail":false,
        "standalone_crate":false,
        "error_codes":[],
        "edition":null,
        "added_css_classes":[],
        "unknown":[]
      },
      "original_code":"let x = 12;\nOk(())",
      "doctest_code":{
        "crate_level":"#![allow(unused)]\n",
        "code":"let x = 12;\nOk(())",
        "wrapper":{
          "before":"fn main() { fn _inner() -> core::result::Result<(), impl core::fmt::Debug> {\n",
          "after":"\n} _inner().unwrap() }",
          "returns_result":true
        }
      },
      "name":"$DIR/extract-doctests-result.rs - (line 8)"
    }
  ]
}
```

for this doctest:

```rust
let x = 12;
Ok(())
```

With this, I think it matches what you need `@ojeda?` If so, once merged I'll update the patch I sent to RfL.

r? `@aDotInTheVoid`
…riplett

Delegate `<SocketAddr as Debug>` to `ByteStr`

This allows UTF-8 characters to be printed without escapes, rather than
just ASCII.

r? `@joshtriplett`
Unimplement unsized_locals

Implements rust-lang/compiler-team#630

Tracking issue here: rust-lang#111942

Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.

There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas

cc `@JakobDegen` `@oli-obk` `@Noratrieb` `@programmerjake` `@bjorn3`

`@rustbot` label F-unsized_locals

Fixes rust-lang#79409
…enton

Stabilize "file_lock" feature

Closes rust-lang#130994

r? `@joshtriplett`
float tests: deduplicate min, max, and rounding tests

Part of rust-lang#141726

Best reviewed commit-by-commit.

- Use `assert_biteq!` in the `mod.rs` tests. This requires some trickery to make shadowing macros with imports work.
- The min, max, minimum, maximum tests in `tests/floats/f*.rs` are entirely subsumed by what we already have in `tests/float/mod.rs`, so I just removed them.
- The rounding tests (floor etc) in `f*.rs` had more test points, so I copied them over. They didn't have `0.5` and `-0.5` though which seem like interesting points in particular regarding the sign of the resulting zero if that's what it sounds to, and they didn't max min/max/inf/nan tests, so this was really a merger of both tests.

r? `@tgross35`
…workingjubilee

variadic functions: remove list of supported ABIs from error

I think this list is problematic for multiple reasons:
- It is bound to go out-of-date as it is in a very different place from where we actually define which functions support varagrs (`fn supports_varargs`).
- Many of the ABIs we list only work on some targets; it makes no sense to mention "aapcs" as a possible ABI when building for x86_64. (This led to a lot of confusion in rust-lang#110505 where the author thought they should use "cdecl" and then were promptly told that "cdecl" is not a legal ABI on their target.)
- Typically, when the programmer wrote `extern "foobar"`, it is because they need the "foobar" ABI. It is of little use to tell them that there are other ABIs with which varargs would work.

Cc `@workingjubilee`
…ggestion, r=WaffleLapkin

Fix incorrect suggestion when calling an associated type with a type anchor

`sugg_span` here is the span of the call expression.
That span here is the `<Self>::Assoc`, which is exactly what we need here (even though I would expect it to include the arguments, but I guess it doesn't)

r? `@WaffleLapkin`
One commit with failing tests and one that fixes it for reviewability

closes rust-lang#142473
Remove unneeded lifetime bound from signature of BTreeSet::extract_if

One way to observe the difference between these signatures, using 0 explicit lifetimes and 0 contrived where-clauses:

```rust
use std::collections::btree_set::{BTreeSet, ExtractIf};
use std::ops::RangeFull;

fn repro(
    set: &mut BTreeSet<i32>,
    predicate: impl Fn(i32) -> bool,
) -> ExtractIf<i32, RangeFull, impl FnMut(&i32) -> bool> {
    set.extract_if(.., move |x| predicate(*x))
}
```

**Before:**

```console
error[E0311]: the parameter type `impl Fn(i32) -> bool` may not live long enough
 --> src/lib.rs:8:5
  |
5 |     set: &mut BTreeSet<i32>,
  |          ------------------ the parameter type `impl Fn(i32) -> bool` must be valid for the anonymous lifetime defined here...
...
8 |     set.extract_if(.., move |x| predicate(*x))
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `impl Fn(i32) -> bool` will meet its required lifetime bounds
  |
help: consider adding an explicit lifetime bound
  |
4 ~ fn repro<'a>(
5 ~     set: &'a mut BTreeSet<i32>,
6 ~     predicate: impl Fn(i32) -> bool + 'a,
7 ~ ) -> ExtractIf<'a, i32, RangeFull, impl FnMut(&i32) -> bool> {
  |
```

**After:** compiles success.

- Tracking issue: rust-lang#70530
Update the `compiler-builtins` subtree

Update the Josh subtree to rust-lang/compiler-builtins@7c46e921c117.

r? `@ghost`
@rustbot rustbot added A-compiler-builtins Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins) A-rustc-dev-guide Area: rustc-dev-guide A-tidy Area: The tidy tool O-unix Operating system: Unix-like 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 Jun 14, 2025
@jhpratt
Copy link
Member Author

jhpratt commented Jun 14, 2025

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jun 14, 2025

📌 Commit 08dc3b0 has been approved by jhpratt

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

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

Click to see the possible cause of the failure (guessed by this bot)

@jhpratt jhpratt deleted the rollup-e2gk8r5 branch June 14, 2025 09:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiler-builtins Area: compiler-builtins (https://github.com/rust-lang/compiler-builtins) A-rustc-dev-guide Area: rustc-dev-guide A-tidy Area: The tidy tool O-unix Operating system: Unix-like rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.