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
Reverse the order of returned lint attributes for a `SyntaxNode` to
match rustc's behavior.
When multiple lint attributes are present, rustc overrides earlier ones
with the last defined attribute. The previous iteration order was
incorrect, causing earlier attributes to override the later ones.
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
error: Potential incomplete link
┌─ fuzzing.md:41:122
│
41 │ > error: internal compiler error: compiler/rustc_middle/src/ty/normalize_erasing_regions.rs:195:90: Failed to normalize <[closure@src/main.rs:36:25: 36:28] as std::ops::FnOnce<(Emplacable<()>,)>>::Output, maybe try to call `try_normalize_erasing_regions` instead
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Did you forget to define a URL for `closure@src/main.rs:36:25: 36:28`?
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
