std: reorganize pipe implementations
Currently, there are two distinct types called `AnonPipe` in `std`:
* The one used to implement `io::pipe` (in `sys::anonymous_pipe`)
* The one used to implement `Stdin`/`Stdout`/`Stderr` (in `sys::pal::pipe`)
On Windows, these actually have different semantics, as one of the handles returned by the `sys::pal::pipe` version is opened for asynchronous operation in order to support `read2`, whereas the `sys::anonymous_pipe` version does not do so. Thus the naming is extremely confusing.
To fix this, this PR renames the `sys::anonymous_pipe` version of `AnonPipe` to simply `Pipe`, whereas the `sys::pal::pipe` version is now called `ChildPipe`. Additionally,
* `sys::anonymous_pipe` is now also just called `sys::pipe`.
* On Windows, `sys::pal::pipe` has been moved to `sys::process` and is now called `sys::process::child_pipe`.
* On non-Windows platforms, pipe creation is now exclusively handled by `sys::pipe` and `ChildPipe` is defined as a type alias to `Pipe` within `sys::process`.
And lastly, the `read2` function (originally in `sys::pal::pipe`) is now called `read_output` and defined by `sys::process`, as (at least on Windows) it is only usable with `ChildPipe`.
Includes rust-lang/rust#146639 for convenience.
Update to mdbook 0.5
This updates to mdbook 0.5.2 from mdbook 0.4.52. A primary aspect of this change is that it splits the `mdbook` crate into multiple crates, and various API changes and cleanup.
There's full release notes and a migration guide at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-050.
This also includes submodule updates:
## book
1 commits in 8c0eacd5c4acbb650497454f3a58c9e8083202a4..9c9104e8a82430f97f42e738051bda718919211c
2025-11-18 10:36:41 -0500 to 2025-12-10 11:33:49 -0500
- Update to mdbook 0.5
## edition-guide
1 commits in 9cf5443d632673c4d41edad5e8ed8be86eeb3b8f..c3c0f0b3da26610138b7ba7663f60cd2c68cf184
2025-11-15 21:51:11 +0000 to 2025-11-28 18:54:18 +0000
- Update to mdbook 0.5 (rust-lang/edition-guide#381)
## nomicon
2 commits in 0fe83ab28985b99aba36a1f0dbde3e08286fefda..9fe8fa599ad228dda74f240cc32b54bc5c1aa3e6
2025-11-15 00:03:14 +0000 to 2025-12-03 11:54:04 +0000
- Remove references to outdated unsafe code guidelines (rust-lang/nomicon#512)
- Update to mdbook 0.5 (rust-lang/nomicon#511)
## reference
5 commits in b14b4e40f53ca468beaf2f5d0dfb4f4c4ba6bc7b..50c5de90487b68d429a30cc9466dc8f5b410128f
2025-12-02 21:17:44 +0000 to 2025-12-09 22:19:05 +0000
- UB: update the extra clause for provenance UB during const evaluation (rust-lang/reference#2091)
- Remove `[no-mentions]` handler in our triagebot config (rust-lang/reference#2102)
- Clarify that omitting `nostack` is a promise from the compiler to the programmer (rust-lang/reference#1999)
- Specify that range patterns must be nonempty. (rust-lang/reference#2093)
- Update to mdbook 0.5 (rust-lang/reference#2096)
## rust-by-example
1 commits in 111cfae2f9c3a43f7b0ff8fa68c51cc8f930637c..7d21279e40e8f0e91c2a22c5148dd2d745aef8b6
2025-11-27 17:16:42 -0300 to 2025-12-01 15:02:09 -0300
- Update to mdbook 0.5 (rust-lang/rust-by-example#1977)
fix va_list test by adding a llvmir signext check
s390x has no option to directly pass 32bit values therefor i32 parameters need an optional llvmir signext attribute.
Add SystemTime::{MIN, MAX}
Accepted ACP: <https://github.com/rust-lang/libs-team/issues/692>
Tracking Issue: <https://github.com/rust-lang/rust/issues/149067>
---
This merge request introduces two new constants to `SystemTime`: `MIN` and `MAX`, whose values represent the maximum values for the respective data type, depending upon the platform.
Technically, this value is already obtainable during runtime with the following algorithm:
Use `SystemTime::UNIX_EPOCH` and call `checked_add` (or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it returns None.
Mathematically speaking, this algorithm will terminate after a finite amount of steps, yet it is impractical to run it, as it takes practically forever.
Besides, this commit also adds a unit test to verify those values represent the respective minimum and maximum, by letting a `checked_add` and `checked_sub` on it fail.
In the future, the hope of the authors lies within the creation of a `SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar to the functions already present in `std::time::Duration`.
However, for those, these constants are crucially required, thereby this should be seen as the initial step towards this direction.
With this change, implementing these functions oneself outside the standard library becomes feasible in a portable manner for the first time.
This feature (and a related saturating version of `checked_{add, sub}` has been requested multiple times over the course of the past few years, most notably:
* rust-lang/rust#100141
* rust-lang/rust#133525
* rust-lang/rust#105762
* rust-lang/rust#71224
* rust-lang/rust#45448
* rust-lang/rust#52555
Constify `DropGuard::dismiss` and trait impls
Feature: `drop_guard` (rust-lang/rust#144426), `const_convert` (rust-lang/rust#143773), `const_drop_guard` (no tracking issue yet)
Constifies `DropGuard::dismiss` and trait impls.
I reused `const_convert` (rust-lang/rust#143773) for the `Deref*` impls.
Don't leak sysroot crates through dependencies
Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates.
Should fix https://github.com/rust-lang/rust/issues/147966
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
Overhaul filename handling for cross-compiler consistency
This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`).
This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang/rust#148328).
In order to achieved consistency multiple steps are being taken by this PR:
- by making `RealFileName` immutable
- by only having `SourceMap::to_real_filename` create `RealFileName`
- currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue
- by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes
- this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename
In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed.
This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes.
Unblocks https://github.com/rust-lang/rust/pull/147611
Fixes https://github.com/rust-lang/rust/issues/148328
The Windows implementation of `SystemTime::checked_sub` contains a bug,
namely that it does not return `None` on values below 1601.
This bug stems from the fact that internally, the time gets converted to
an i64, with zero representing the anchor in 1601. Of course,
performing checked subtraction on a signed integer generally works fine.
However, the resulting value delivers undefined behavior on Windows
systems.
To mitigate this issue, we try to convert the resulting i64 to an u64
because a negative value should obviously fail there.
Run main rust-analyzer tests in rust-lang/rust CI
Part of rust-lang/rust#147370.
MCP: https://github.com/rust-lang/compiler-team/issues/923
This PR prepares `rust-analyzer` crates with `in-rust-tree` cargo featues where needed, and and updates bootstrap to run the main `rust-analyzer` tests in rust-lang/rust CI, not just the `proc-macro-srv` crate tests.
This supersedes the earlier attempt at https://github.com/rust-lang/rust/pull/136779. I was honestly expecting more failures in this PR, but looking back at the previous attempt, that makes sense because we no longer run `i686-mingw` (32-bit windows-gnu) which had a _bunch_ of these failures. In the earlier attempt I also disabled the `i686-mingw`-related failures for `i686-msvc` since I didn't feel like digging into 32-bit msvc at the time. Try results from this PR shows that it's most likely limited to 32-bit windows-gnu specifically.
### `rust-analyzer` test remarks
- I actually had to _remove_ the `CARGO_WORKSPACE_DIR` `expect-test`-hack in order for `expect-test` to be able to find the test expectation HTML files (for `syntax_highlighting` tests in `ide`). When I added the hack, ironically, it made `expect-test` unable to find the expectation files. I think this was because previously the path was of the `proc-macro-srv` crate specifically, now we point to the root r-a workspace?
- The `cfg`-related differences on `aarch64-apple-darwin` might've been fixed? I can't tell, but we don't seem to be observing the differences now.
- I'm not sure why `config::{generate_config_documentation, generate_package_json_config}` no longer fails. Perhaps they were fixed to no longer try to write to source directory?
### Review remarks
- Commit 1 updates r-a crates that are involved in tests needing artifacts from `rustc_private` compiler crates to use the `in-rust-tree` cargo feature. I briefly tried to use a plain `--cfg=in_rust_tree`, but quickly realized it was very hacky, and needed invasive bootstrap changes. The cargo feature approach seems most "natural"/well-supported to both bootstrap and cargo.
- Commit 2 updates bootstrap to not only run the `proc-macro-srv` tests, but the whole r-a tests.
- Commit 3 restricts r-a main tests to non-32-bit targets we test in CI, since (1) r-a repo does not run tests against 32-bit platforms, and (2) there are some target pointer width sensitive hash differences causing tests to fail. Notably, this means that we also no longer run r-a `proc-macro-srv` tests against 32-bit targets, but we don't expect that crate to be have target pointer width differences. Discussed this in [#t-compiler/rust-analyzer > 32-bit tests?](https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/32-bit.20tests.3F/with/563145736).
---
// try-job: aarch64-gnu
// try-job: aarch64-apple
// try-job: x86_64-mingw-1
// try-job: i686-msvc-1
// try-job: x86_64-msvc-1
// try-job: aarch64-msvc-1
There is a slight edge case when adding and subtracting a `Duration`
from a `SystemTime`, namely when the duration itself is finer/smaller
than the time precision on the operating systems.
On most (if not all non-Windows) operating systems, the precision of
`Duration` aligns with the `SystemTime`, both being one nanosecond.
However, on Windows, this time precision is 100ns, meaning that adding
or subtracting a `Duration` whose value is `< Duration::new(0, 100)`
will result in that method behaving like an addition/subtracting of
`Duration::ZERO`, due to the `Duration` getting rounded-down to the zero
value.
`declare_lint_pass` for `INLINE_ALWAYS_MISMATCHING_TARGET_FEATURES`
The `INLINE_ALWAYS_MISMATCHING_TARGET_FEATURES` lint was missing from this causing it to be an unknown lint when attempting to allow it.
r? ``@davidtwco``
Add a sanity check in case of any duplicate nodes
A simple check in case compiler tries to encode a dep node twice like in rust-lang/rust#141540.
Also if we'd try to mark a red node as green as it may then create a bad `DepNodeIndex` like in rust-lang/rust#148295.
If it prevents rust-lang/rust#141540 from emitting a faulty `dep-graph.bin` file via panic then it means you will be able to temporarily fix it by simply restarting cargo or rust-analyzer without cleaning up incremental cache.
bootstrap: Don't pass an unused `--color` to compiletest
- Follow-up to https://github.com/rust-lang/rust/pull/149850
---
This flag was an artifact of compiletest's old libtest-based test executor, and currently doesn't influence compiletest's output at all.
A follow-up commit also inlines `force_coloring_in_ci` into its only remaining caller, and updates its comment.
Weak for Arc pointer is marked as DynSend/DynSync
`std::sync::Weak` (weak pointer for Arc) added to DynSend and DynSync (looks like it was missed to add there when implemented).
Fix: Prevent macro-expanded extern crates from shadowing extern arguments
prevents an ICE by fixing a logic bug in `build_reduced_graph.rs`.
the bug caused the compiler to correctly detect and report a shadowing error for a macro-expanded `extern crate` but then continue processing the invalid item, corrupting the resolver's internal state (`extern_prelude`) and leading to a crash in later resolution passes the fix adds an early return after the shadowing error is reported to ensure the invalid item is not added to the resolution graph.
Fixesrust-lang/rust#149821
Add proper suggestion for associated function with unknown field
Fixesrust-lang/rust#149038
The first commit is changing the old suggestion to verbose,
the second commit is a new added suggestion.
r? ``@estebank``
Update `rustc_codegen_gcc` rotate operation document
## Description
This PR resolves a TODO comment in the `rustc_codegen_gcc` backend by documenting that the rotate operations (`rotate_left` and `rotate_right`) already implement the optimized branchless algorithm from comment.
The existing implementation already uses the optimal branchless rotation pattern:
- For left rotation: `(x << n) | (x >> (-n & (width-1)))`
- For right rotation: `(x >> n) | (x << (-n & (width-1)))`
This pattern avoids branches and generates efficient machine code across different platforms, which was the goal mentioned in the original TODO.
## Changes
- Removed the TODO comment that suggested implementing the algorithm from https://blog.regehr.org/archives/1063
MGCA: Syntactically distinguish anon const const args
r? oli-obk
tracking issue: rust-lang/rust#132980
This PR requires that when `feature(min_generic_const_args)` is enabled, anon const const args are *syntactically* distinguishable from other kinds of args. We use `const { ... }` in const argument position to denote an anon const:
```rust
#![feature(min_generic_const_args)]
// no longer allowed as `1 + 1` is represented via an anon const and
// there is no syntactic marker
type Foo = [(); 1 + 1];
// allowed, `const { ... }` indicates an anon const representation
type Foo = [(); const { 1 + 1 }];
```
This restriction is only placed when mgca is enabled. There should be no effect on stable. This restriction is not enforced for unbraced literals which we continue to implicitly wrap in an anon const: `tests/ui/const-generics/mgca/explicit_anon_consts_literals_hack.rs`
This restriction allows us to create `DefId`s for anon consts only when actually required. When it is syntactically ambiguous whether a const argument is an anon const or not we are forced to conservatively create a `DefId` for every const argument even if it doesn't wind up needing one.
This works fine on stable but under `mgca` we can wind up with anon consts nested inside non-anon-const const arguments resulting in a broken `DefId` tree. See rust-lang/rust#148838 where an anon const arg inside of a path arg winds up with a parent of a conservatively created `DefId` that doesn't actually correspond to an anon const, resulting in an ICE.
With rust-lang/rust#149114 every field initialiser in a const argument would become a place where there could *possibly* be an anon const. This would also get worse once we support tuple constructors- now every function argument is a place where there could possibly be an anon const.
We introduce this restriction to avoid creating massive amounts of unused `DefId`s that make the parent tree significantly more complicated, and to avoid having to paper over this issue in things like `generics_of`.
Fixesrust-lang/rust#148838
It also must be syntactically clear from context whether `'_` means an inference lifetime or an elided lifetime parameter. This restriction will allow us to properly resolve `'_` in const arguments in mgca. This PR doesn't actually fix handle this, but we could do so trivially after this lands.
If there are too many suggestions for malformed attribute, do not suggest them
Part of https://github.com/rust-lang/rust/issues/149865.
This not only covers for doc attributes but for all attributes, so don't hesitate to tell me if you want it to be limited to only doc attributes (although I think it's actually a nice improvement overall).
Also, I picked 3 as the maximum number of suggestions before it becomes noise, but it's very much open to debate.
r? `@JonathanBrouwer`
This updates to mdbook 0.5.2 from mdbook 0.4.52. A primary aspect of
this change is that it splits the `mdbook` crate into multiple crates,
and various API changes and cleanup.
There's full release notes and a migration guide at
https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-050.
This also includes submodule updates:
## book
2 commits in 8c0eacd5c4acbb650497454f3a58c9e8083202a4..39aeceaa3aeab845bc4517e7a44e48727d3b9dbe
2025-11-18 10:36:41 -0500 to 2025-12-12 11:02:27 -0500
- Synchronize TrplNote name
- Update to mdbook 0.5
## edition-guide
1 commits in 9cf5443d632673c4d41edad5e8ed8be86eeb3b8f..c3c0f0b3da26610138b7ba7663f60cd2c68cf184
2025-11-15 21:51:11 +0000 to 2025-11-28 18:54:18 +0000
- Update to mdbook 0.5 (rust-lang/edition-guide#381)
## nomicon
2 commits in 0fe83ab28985b99aba36a1f0dbde3e08286fefda..9fe8fa599ad228dda74f240cc32b54bc5c1aa3e6
2025-11-15 00:03:14 +0000 to 2025-12-03 11:54:04 +0000
- Remove references to outdated unsafe code guidelines (rust-lang/nomicon#512)
- Update to mdbook 0.5 (rust-lang/nomicon#511)
## reference
5 commits in b14b4e40f53ca468beaf2f5d0dfb4f4c4ba6bc7b..50c5de90487b68d429a30cc9466dc8f5b410128f
2025-12-02 21:17:44 +0000 to 2025-12-09 22:19:05 +0000
- UB: update the extra clause for provenance UB during const evaluation (rust-lang/reference#2091)
- Remove `[no-mentions]` handler in our triagebot config (rust-lang/reference#2102)
- Clarify that omitting `nostack` is a promise from the compiler to the programmer (rust-lang/reference#1999)
- Specify that range patterns must be nonempty. (rust-lang/reference#2093)
- Update to mdbook 0.5 (rust-lang/reference#2096)
## rust-by-example
1 commits in 111cfae2f9c3a43f7b0ff8fa68c51cc8f930637c..7d21279e40e8f0e91c2a22c5148dd2d745aef8b6
2025-11-27 17:16:42 -0300 to 2025-12-01 15:02:09 -0300
- Update to mdbook 0.5 (rust-lang/rust-by-example#1977)
