Skip to content

Conversation

@matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Jan 10, 2026

Successful merges:

r? @ghost

Create a similar rollup

asder8215 and others added 30 commits December 13, 2025 19:18
This test currently doesn't fulfill its purpose, as `external dso_local`
can still match `external {{.*}}`. Fix this by using CHECK-NOT directives.

Also, this test is expanded to all platforms where it makes sense, instead
of restricting to loongarch.
The current code applies `dso_local` to the internal generated symbols
instead of the actually-externally one.
They were introduced back when std_detect was a standalone crate
published to crates.io. The motivation for std_detect_dlsym_getauxval
was to allow using getauxval without dlopen when statically linking
musl, which we now unconditionally do for musl. And for
std_detect_file_io to allow no_std usage, which std_detect now supports
even with that feature enabled as it directly uses libc. This also
prevents accidentally disabling runtime feature detection when using
cargo build -Zbuild-std -Zbuild-std-features=
It is no longer a part of the stdarch repo and the rest is not necessary
anymore due to no longer publishing to crates.io.
This will allow extra data to be attached to the `Pat` before it is returned.
… a body.

Handling for inherent associated consts is missing elsewhere, remove so it can be handled later in that handling.

Diagnostic not always be emitted on associated constant

Add a test case and Fix for a different ICE I encountered.

I noticed when trying various permuations of the test case code to see if I could find anymore ICEs. I did, but not one that I expected. So in the instances of the a named const not having any args, insantiate it directly. Since it is likely an inherent assocaiated const.

Added tests.

Centralize the is_type_const() logic.

I also noticed basically the exact same check in other part the code.

Const blocks can't be a type_const, therefore this check is uneeded.

Fix comment spelling error.

get_all_attrs is not valid to call for all DefIds it seems.

Make sure that if the type is omitted for a type_const that we don't ICE.

Co-Authored-By: Boxy <[email protected]>
Tested using OVMF on QEMU.

Signed-off-by: Ayush Singh <[email protected]>
Otherwise you get errors like these if you have an Externally
Implementable Item defined in std:

    error: attribute macro has missing stability attribute
        --> library/std/src/io/mod.rs:2269:1
         |
    2269 | #[eii(on_broken_pipe)]
         | ^^^^^^^^^^^^^^^^^^^^--
         | |
         | in this attribute macro expansion
         |
        ::: library/core/src/macros/mod.rs:1899:5
         |
    1899 |     pub macro eii($item:item) {
         |     ------------- in this expansion of `#[eii]`

Or (fatal) warnings like these:

    warning: missing documentation for an attribute macro
        --> library/std/src/io/mod.rs:2269:1
…=Mark-Simulacrum,jhpratt

Implement create_dir_all() to operate iteratively instead of recursively

The current implementation of `create_dir_all(...)` in std::fs operates recursively. As mentioned in rust-lang#124309, this could run into a stack overflow with big paths. To avoid this stack overflow issue, this PR implements the method in an iterative manner, preserving the documented behavior of:
```
Recursively create a directory and all of its parent components if they are missing.
This function is not atomic. If it returns an error, any parent components it was able to create will remain.
If the empty path is passed to this function, it always succeeds without creating any directories.
```
 Fix dso_local for external statics with linkage

Tracking issue of the feature: rust-lang#127488

DSO local attributes are not correctly applied to extern statics with `#[linkage = "foo"]` as we generate an internal global for such statics, and the we evaluate (and apply) DSO attributes on the internal one instead.

Fix this by applying DSO local attributes on the actually extern ones, too.
THIR patterns: Replace `AscribeUserType` and `ExpandedConstant` wrappers with per-node data

This PR removes the `AscribeUserType` and `ExpandedConstant` variants from `thir::PatKind`, and replaces them with an `Option<Box<PatExtra>>` field attached to every `thir::Pat`.

### Why remove these variants?

Unlike other THIR pattern kinds, these variants are mere “wrappers” that exist to attach some additional information to an underlying pattern node.

There are several places where code that consumes THIR patterns needs to carefully “unpeel” any wrapper nodes, in order to match on the underlying pattern. This is clunky, and easy to forget to do, especially since it's not always obvious where the wrapper nodes can and can't appear.

Attaching the data to an optional per-node field makes it easier for consuming code to simply ignore the extra data when it is not relevant.

(One downside is that it is now easier to accidentally ignore the extra data when it *is* relevant, but I think that's generally a favourable tradeoff.)

### Impact

After this change, THIR pattern trees should be “logically identical” to the previous THIR pattern trees, in the sense that information that was carried by wrapper nodes should now be directly attached to the non-wrapper nodes that were being wrapped. Types and spans associated with THIR pattern nodes should (hopefully!) still be accurate.

There should be no change to the output of THIR-based checks or MIR building.
Fix ICE: can't type-check body of DefId  for issue rust-lang#148729

This commit fixes the issue rust-lang#148729 for min_const_generic_args rust-lang#132980.

It's pretty small PR. The first commit makes sure that the `type_const`s are made into normal consts in const expressions.

The next one just handles the case rust-lang#148729 of where the type of the const was omitted at which point it was trying to treat a `type_const` again as a regular const. That obviously will fail since a type_const does not have a body.

@rustbot label +F-associated_const_equality +F-min_generic_const_args +I-ICE
Remove std_detect_file_io and std_detect_dlsym_getauxval features

They were introduced back when std_detect was a standalone crate published to crates.io. The [motivation](rust-lang/stdarch#655) for `std_detect_dlsym_getauxval` was to allow using `getauxval` without `dlopen` when statically linking musl, which we now unconditionally do for musl. And for `std_detect_file_io` to allow `no_std` usage, which std_detect now supports even with that feature enabled as it directly uses libc. This also prevents accidentally disabling runtime feature detection when using `cargo build -Zbuild-std -Zbuild-std-features=`
std: sys: fs: uefi: Implement File::write

Tested using OVMF on QEMU.

@rustbot label +O-UEFI
Use f64 NaN in documentation instead of sqrt(-1.0)
Emit an error for linking staticlibs on BPF

Rather than panicking. Also a drive-by diagnostic type visibility reduction.

Fixes rust-lang#149432
Add missing documentation for globs feature

Fixes FIXME by documenting that globs enables wildcard imports (use module::*;).
compiler: Forward attributes to eii-expanded macros

Since rust-lang#150592 is quite complicated to reason about I figured it would be good to split it up in smaller pieces that are easier to digest. Here is the attribute fix in isolation.

## The Problem

With this eii in **library/std/src/io/mod.rs**:
```rs
/// Foo
#[eii(on_broken_pipe)]
#[unstable(feature = "on_broken_pipe", issue = "150588")]
pub fn on_broken_pipe() -> OnBrokenPipe {
    OnBrokenPipe::BackwardsCompatible
}
```

you currently get this compilation error:

```
error: attribute macro has missing stability attribute
    --> library/std/src/io/mod.rs:2269:1
     |
2269 | #[eii(on_broken_pipe)]
     | ^^^^^^^^^^^^^^^^^^^^--
     | |
     | in this attribute macro expansion
     |
    ::: library/core/src/macros/mod.rs:1899:5
     |
1899 |     pub macro eii($item:item) {
     |     ------------- in this expansion of `#[eii]`
```

because with ` MAGIC_EXTRA_RUSTFLAGS=-Zunpretty=expanded ./x build library/std` we can see that a pub item in the expanded code is indeed missing that attribute:

```rs
const _: () =
    {
        #[on_broken_pipe]
        fn on_broken_pipe() -> OnBrokenPipe {
            OnBrokenPipe::BackwardsCompatible
        }
    };
unsafe extern "Rust" {
    /// Foo
    #[unstable(feature = "on_broken_pipe", issue = "150588")]
    #[rustc_eii_extern_item]
    pub safe fn on_broken_pipe()
    -> OnBrokenPipe;
}
#[rustc_builtin_macro(eii_shared_macro)]
#[eii_extern_target(on_broken_pipe)]
pub macro on_broken_pipe { () => {} }
```

## The Solution

With the fix, that error goes away because we get this expanded code instead:

```rs
const _: () =
    {
        #[on_broken_pipe]
        fn on_broken_pipe() -> OnBrokenPipe {
            OnBrokenPipe::BackwardsCompatible
        }
    };
unsafe extern "Rust" {
    /// Foo
    #[unstable(feature = "on_broken_pipe", issue = "150588")]
    #[rustc_eii_extern_item]
    pub safe fn on_broken_pipe()
    -> OnBrokenPipe;
}
/// Foo
#[unstable(feature = "on_broken_pipe", issue = "150588")]
#[rustc_builtin_macro(eii_shared_macro)]
#[eii_extern_target(on_broken_pipe)]
pub macro on_broken_pipe { () => {} }
```

Note that we also need to forward the docs, otherwise get get (fatal) warnings like these:

```
warning: missing documentation for an attribute macro
    --> library/std/src/io/mod.rs:2269:1
```

r? @jdonszelmann

Tracking issues:
- rust-lang#125418
- rust-lang#150588

### What about a test?

rust-lang#150591 will prevent regressions once it lands since it does not build without this fix. I think it is overkill to add a temporary eii to std before that.
Once again, reorganize the EII tests a bit

Some tests in the root of tests/ui/eii actually kind of belonged in the subfolders we made earlier
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Jan 10, 2026
@rustbot rustbot added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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. labels Jan 10, 2026
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@rust-bors rust-bors bot 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 Jan 10, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 10, 2026

📌 Commit f094066 has been approved by matthiaskrgr

It is now in the queue for this repository.

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 11, 2026

⌛ Testing commit f094066 with merge c8a0819...

Workflow: https://github.com/rust-lang/rust/actions/runs/20888506472

rust-bors bot added a commit that referenced this pull request Jan 11, 2026
Rollup of 11 pull requests

Successful merges:

 - #148196 (Implement create_dir_all() to operate iteratively instead of recursively)
 - #150494 ( Fix dso_local for external statics with linkage)
 - #150788 (THIR patterns: Replace `AscribeUserType` and `ExpandedConstant` wrappers with per-node data)
 - #150799 (Fix ICE: can't type-check body of DefId  for issue #148729)
 - #150804 (Remove std_detect_file_io and std_detect_dlsym_getauxval features)
 - #150852 (std: sys: fs: uefi: Implement File::write)
 - #150871 (Use f64 NaN in documentation instead of sqrt(-1.0))
 - #150878 (Emit an error for linking staticlibs on BPF)
 - #150911 (Add missing documentation for globs feature)
 - #150913 (compiler: Forward attributes to eii-expanded macros)
 - #150916 (Once again, reorganize the EII tests a bit)

r? @ghost
@Zalathar
Copy link
Member

Because this rollup only just started, I'm going to re-make it to incorporate #150947, which should reduce CI duration from ~4 hours back to the usual ~3 hours.

@Zalathar
Copy link
Member

Yielding to #150951, which is this rollup plus the CI duration fixes in #150947.

@bors r- retry

@rust-bors rust-bors bot 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 Jan 11, 2026
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 11, 2026

Commit f094066 has been unapproved.

Auto build cancelled due to unapproval. Cancelled workflows:

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jan 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. rollup A PR which is a rollup 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.