feat: invisible character help string
I was playing around with zero width spaces in different programming languages and thought that this error message could be more helpful. Hopefully it's a good first contribution! :)
Remove mentions of debootstrap and chroots from the m68k-unknown-none-elf platform support doc
I left the mentions of qemu-user-static as it's one of the only easily accessible emulators for m68k, even though you would have to write your own `_start` and such. The C toolchain that is mentioned is also the easiest way I've found so far to get a linker, which is still needed unless I'm missing something.
closesrust-lang/rust#150414
r? @Noratrieb
resolve: Use `Macros20NormalizedIdent` in more interfaces
It allows to avoid expensive double normalization in some cases.
This is an attempt to fix the perf regressions from https://github.com/rust-lang/rust/pull/149681.
Update cargo submodule
5 commits in 8c133afcd5e0d69932fe11f5907683723f8d361d..6d1bd93c47f059ec1344cb31e68a2fb284cbc6b1
2026-01-09 03:50:15 +0000 to 2026-01-10 12:53:59 +0000
- fix: preserve `dep_name` for build script metadata (rust-lang/cargo#16494)
- refactor(toml): clarify `to_dependency` for config patch (rust-lang/cargo#16492)
- Add `--id` flag to `cargo report timings` and `cargo report rebuilds` (rust-lang/cargo#16490)
- Display lockfile path in very verbose mode when blocking (rust-lang/cargo#16491)
- fix(info): resolve underscore vs hyphen mismatch in schema lookup (rust-lang/cargo#16455)
---
An extra submodule update right after <https://github.com/rust-lang/rust/pull/150739> due to a relatively impactful nightly regression <https://github.com/rust-lang/cargo/issues/16493>
Port `#[rustc_has_incoherent_inherent_impls]` to attribute parser
Tracking issue: rust-lang/rust#131229
no tests changed here at all, so maybe we should add some but would like to know what kind of tests would be good to add
r? @JonathanBrouwer
llvm: Update `reliable_f16` configuration for LLVM22
Since yesterday, the LLVM `main` branch should have working `f16` on all platforms that Rust supports; this will be LLVM version 22, so update how `cfg(target_has_reliable_f16)` is set to reflect this.
Within the rust-lang organization, this currently has no effect. The goal is to start catching problems as early as possible in external CI that runs top-of-tree rust against top-of-tree LLVM, and once testing for the rust-lang bump to LLVM 22 starts. Hopefully this will mean that we can fix any problems that show up before the bump actually happens, meaning `f16` will be about ready for stabilization at that point (with some considerations for the GCC patch at [1] propagating).
References:
* 919021b0df
* 054ee2f870
* db26ce5c55
* 549d7c4f35
* 4903c6260c
[1]: 8b6a18ecaf
Reenable GCC CI download
Now that we have the `gcc-dev` artifacts on CI. However, I forgot to bump download-ci-gcc-stamp before 🤦 So I will also have to bump it for this PR.
std: sys: fs: uefi: Implement File::flush
- Also forward fsync and datasync to flush. UEFI does not have anything separate for metadata sync.
@rustbot label +O-UEFI
Use `rand` crate more idiomatically
Small cleanup, found while working on something else.
We were using `rand` un-idiomatically in a couple of places, and it was bugging me...
Fix the connect_error test on FreeBSD 15+
On FreeBSD 15, the error code returned in this situation changed. It's now ENETUNREACH. I think that error code is reasonable, and it's documented for connect(2), so we should expect that it might be returned.
Reword the collect() docs
Update the `Iterator::collect` docs so they explain that the return type, not the iterator itself, determines which collection is built.
Follow up on rust-lang/rust#121140
adding Ordering enum to minicore.rs, importing minicore in "tests/assembly-llvm/rust-abi-arg-attr.rs" test file
this adds the `Ordering` enum to `minicore.rs`.
consequently, this updates `tests/assembly-llvm/rust-abi-arg-attr.rs` to import `minicore` directly. previously, this test file contained traits like `Copy` `Clone` `PointeeSized`, which were giving a duplicate lang item error, so replace those by importing `minicore` completely.
stabilize `Peekable::next_if_map` (`#![feature(peekable_next_if_map)]`)
# Stabilization report
## Summary
`#![feature(peekable_next_if_map)]` is a variation of `next_if` on peekable iterators that can transform the peeked item. This creates a way to take ownership of the next item in an iterator when some condition holds, but put the item back when the condition doesn't hold. This pattern would otherwise have needed unwraps in many cases.
[Tracking issue](https://github.com/rust-lang/rust/issues/143702)
### What is stabilized
```rust
impl<I: Iterator> Peekable<I> {
pub fn next_if_map<R>(
&mut self,
f: impl FnOnce(I::Item) -> Result<R, I::Item>,
) -> Option<R> {
..
}
pub fn next_if_map_mut<R>(
&mut self,
f: impl FnOnce(&mut I::Item) -> Option<R>,
) -> Option<R> {
..
}
}
```
Example usage adapted from the ACP:
```rust
let mut it = Peekable::new("123".chars());
while let Some(digit) = it.next_if_map(|c| c.to_digit(10).ok_or(c)) {
codepoint = codepoint * 10 + digit;
}
```
or with `next_if_map_mut`:
```rust
let mut it = Peekable::new("123".chars());
while let Some(digit) = iter.next_if_map_mut(|c| c.to_digit(10)) {
line_num = line_num * 10 + digit;
}
```
Note that the major difference here is that `next_if_map_mut` does not get owned items from the iterator, but mutable references. With that api, the closure can return an `Option` which avoids an `ok_or`. This may require cloning or copying the iterator elements, so if that is expensive, the owned version, `next_if_map`, may be preferable.
### Nightly use
At the moment, this feature is barely used in nightly, though I've found multiple good uses for it in my own projects, hence my pushing for stabilization. It makes the kind of patterns used in recursive descent parsing super concise and maybe with its stabilization it will find more use.
### Test coverage
Besides a quite comprehensive doctest, this feature is tested (including panicking in the closure) here:
c880acdd31/library/coretests/tests/iter/adapters/peekable.rs (L275-L359)
## History
- ACP: https://github.com/rust-lang/libs-team/issues/613 accepted with https://github.com/rust-lang/libs-team/issues/613#issuecomment-3049844223
- implementation: https://github.com/rust-lang/rust/pull/143725 with tests, and no issues reported since july.
## Acknowledgments
ACP, implementation and tracking issue for this feature all by @kennytm <3
Also hash spans inside the same file as relative (V2)
Hashes spans relatively to their parent, even if they are not contained inside their parent.
Fixes https://github.com/rust-lang/rust/issues/150400
Closes https://github.com/rust-lang/rust/pull/143882, as this is a successor PR
This PR is very closely based on that PR with a few minor changes, so to give proper credit I made @cjgillot coauthor of the commit.
compiler: Forward attributes to eii-expanded macros
Since https://github.com/rust-lang/rust/pull/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:
- https://github.com/rust-lang/rust/issues/125418
- https://github.com/rust-lang/rust/issues/150588
### What about a test?
https://github.com/rust-lang/rust/pull/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.
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](https://github.com/rust-lang/stdarch/issues/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=`
Fix ICE: can't type-check body of DefId for issue #148729
This commit fixes https://github.com/rust-lang/rust/issues/148729 for min_const_generic_args https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/issues/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
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 dso_local for external statics with linkage
Tracking issue of the feature: rust-lang/rust#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.
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/rust#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.
```
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#150269 (Remove inactive nvptx maintainer)
- rust-lang/rust#150713 (mgca: Type-check fields of struct expr const args)
- rust-lang/rust#150765 (rustc_parse_format: improve error for missing `:` before `?` in format args)
- rust-lang/rust#150847 (Fix broken documentation links to SipHash)
- rust-lang/rust#150867 (rustdoc_json: Remove one call to `std::mem::take` in `after_krate`)
- rust-lang/rust#150872 (Fix some loop block coercion diagnostics)
- rust-lang/rust#150874 (Ignore `rustc-src-gpl` in fast try builds)
- rust-lang/rust#150875 (Refactor artifact keep mode in bootstrap)
- rust-lang/rust#150876 (Mention that `rustc_codegen_gcc` is a subtree in `rustc-dev-guide`)
- rust-lang/rust#150882 (Supress unused_parens lint for guard patterns)
- rust-lang/rust#150884 (Update bors email in CI postprocessing step)
Failed merges:
- rust-lang/rust#150869 (Emit error instead of delayed bug when meeting mismatch type for const tuple)
r? @ghost
Reflection MVP
I am opening this PR for discussion about the general design we should start out with, as there are various options (that are not too hard to transition between each other, so we should totally just pick one and go with it and reiterate later)
r? @scottmcm and @joshtriplett
project goal issue: https://github.com/rust-lang/rust-project-goals/issues/406
tracking issue: https://github.com/rust-lang/rust/issues/146922
The design currently implemented by this PR is
* `TypeId::info` (method, usually used as `id.info()` returns a `Type` struct
* the `Type` struct has fields that contain information about the type
* the most notable field is `kind`, which is a non-exhaustive enum over all possible type kinds and their specific information. So it has a `Tuple(Tuple)` variant, where the only field is a `Tuple` struct type that contains more information (The list of type ids that make up the tuple).
* To get nested type information (like the type of fields) you need to call `TypeId::info` again.
* There is only one language intrinsic to go from `TypeId` to `Type`, and it does all the work
An alternative design could be
* Lots of small methods (each backed by an intrinsic) on `TypeId` that return all the individual information pieces (size, align, number of fields, number of variants, ...)
* This is how C++ does it (see https://lemire.me/blog/2025/06/22/c26-will-include-compile-time-reflection-why-should-you-care/ and https://isocpp.org/files/papers/P2996R13.html#member-queries)
* Advantage: you only get the information you ask for, so it's probably cheaper if you get just one piece of information for lots of types (e.g. reimplementing size_of in terms of `TypeId::info` is likely expensive and wasteful)
* Disadvantage: lots of method calling (and `Option` return types, or "general" methods like `num_fields` returning 0 for primitives) instead of matching and field accesses
* a crates.io crate could implement `TypeId::info` in terms of this design
The backing implementation is modular enough that switching from one to the other is probably not an issue, and the alternative design could be easier for the CTFE engine's implementation, just not as nice to use for end users (without crates wrapping the logic)
One wart of this design that I'm fixing in separate branches is that `TypeId::info` will panic if used at runtime, while it should be uncallable
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
