Automatic Rustup #4680
Merged
Automatic Rustup #4680
+167
−173
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update LLVM to 21.1.5 Includes some fixes for BPF.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 8401398e1f14a24670ee1a3203713dc2f0f8b3a8 Filtered ref: 52a911b7100ca6a6ed84159c51ce514a98ae9cf5 Upstream diff: rust-lang/rust@c5dabe8...8401398 This merge was created using https://github.com/rust-lang/josh-sync.
compiletest: Run the `lldb_batchmode.py` script in LLDB's embedded Python Historically, LLDB debuginfo tests have used a Python script to control LLDB via its Python API, instead of invoking the `lldb` command directly. Unfortunately, this requires us to find and use a version of Python that is compatible with LLDB's Python bindings. However, it turns out that there is a simpler way to find a compatible Python interpreter: use the one that is embedded in LLDB itself, via the `script` command.
stop specializing on `Copy` fixes rust-lang/rust#132442 `std` specializes on `Copy` to optimize certain library functions such as `clone_from_slice`. This is unsound, however, as the `Copy` implementation may not be always applicable because of lifetime bounds, which specialization does not take into account; the result being that values are copied even though they are not `Copy`. For instance, this code: ```rust struct SometimesCopy<'a>(&'a Cell<bool>); impl<'a> Clone for SometimesCopy<'a> { fn clone(&self) -> Self { self.0.set(true); Self(self.0) } } impl Copy for SometimesCopy<'static> {} let clone_called = Cell::new(false); // As SometimesCopy<'clone_called> is not 'static, this must run `clone`, // setting the value to `true`. let _ = [SometimesCopy(&clone_called)].clone(); assert!(clone_called.get()); ``` should not panic, but does ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6be7a48cad849d8bd064491616fdb43c)). To solve this, this PR introduces a new `unsafe` trait: `TrivialClone`. This trait may be implemented whenever the `Clone` implementation is equivalent to copying the value (so e.g. `fn clone(&self) -> Self { *self }`). Because of lifetime erasure, there is no way for the `Clone` implementation to observe lifetime bounds, meaning that even if the `TrivialClone` has stricter bounds than the `Clone` implementation, its invariant still holds. Therefore, it is sound to specialize on `TrivialClone`. I've changed all `Copy` specializations in the standard library to specialize on `TrivialClone` instead. Unfortunately, the unsound `#[rustc_unsafe_specialization_marker]` attribute on `Copy` cannot be removed in this PR as `hashbrown` still depends on it. I'll make a PR updating `hashbrown` once this lands. With `Copy` no longer being considered for specialization, this change alone would result in the standard library optimizations not being applied for user types unaware of `TrivialClone`. To avoid this and restore the optimizations in most cases, I have changed the expansion of `#[derive(Clone)]`: Currently, whenever both `Clone` and `Copy` are derived, the `clone` method performs a copy of the value. With this PR, the derive macro also adds a `TrivialClone` implementation to make this case observable using specialization. I anticipate that most users will use `#[derive(Clone, Copy)]` whenever both are applicable, so most users will still profit from the library optimizations. Unfortunately, Hyrum's law applies to this PR: there are some popular crates which rely on the precise specialization behaviour of `core` to implement "specialization at home", e.g. [`libAFL`](https://github.com/AFLplusplus/LibAFL/blob/89cff637025c1652c24e8d97a30a2e3d01f187a4/libafl_bolts/src/tuples.rs#L27-L49). I have no remorse for breaking such horrible code, but perhaps we should open other, better ways to satisfy their needs – for example by dropping the `'static` bound on `TypeId::of`...
Rustc pull update
Implement IsZero for (), and optimize `IsZero::is_zero` for arrays
These are probably not super useful optimizations, but they make it so that `vec![expr; LARGE_LENGTH]` has better performance for some `expr`s, e.g.
* array of length zero in debug mode
* tuple containing `()` and zero-valued integers in debug and release mode
* array of `()` or other zero-sized `IsZero` type in debug mode
<details> <summary>very rough benchmarks</summary>
```Rust
use std::time::Instant;
use std::sync::atomic::{AtomicUsize, Ordering::Relaxed};
struct NonCopyZst;
static COUNTER: AtomicUsize = AtomicUsize::new(0);
impl Clone for NonCopyZst {
fn clone(&self) -> Self {
COUNTER.fetch_add(1, Relaxed);
Self
}
}
macro_rules! timeit {
($e:expr) => {
let start = Instant::now();
_ = $e;
println!("{:56}: {:?}", stringify!($e), start.elapsed());
};
}
fn main() {
timeit!(vec![[String::from("hello"); 0]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![(0u8, (), 0u16); 1_000_000_000]); // gets a lot better in debug *and* release mode
timeit!(vec![[[(); 37]; 1_000_000_000]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![[NonCopyZst; 0]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![[[1u8; 0]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
timeit!(vec![[[(); 37]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
timeit!(vec![[[1u128; 0]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
// check that we don't regress existing optimizations
timeit!(vec![(0u8, 0u16); 1_000_000_000]); // about the same time
timeit!(vec![0u32; 1_000_000_000]); // about the same time
// check that we still call clone for non-IsZero ZSTs
timeit!(vec![[const { NonCopyZst }; 2]; 1_000]); // about the same time
assert_eq!(COUNTER.load(Relaxed), 1998);
timeit!(vec![NonCopyZst; 10_000]); // about the same time
assert_eq!(COUNTER.load(Relaxed), 1998 + 9_999);
}
```
```rs
$ cargo +nightly run
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 11.13999724s
vec![(0u8, (), 0u16); 1_000_000_000] : 5.254646651s
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 2.738062531s
vec![[NonCopyZst; 0]; 1_000_000_000] : 9.483690922s
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 2.919236ms
vec![[[(); 37]; 1_000_000]; 1_000_000] : 2.927755ms
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 2.931486ms
vec![(0u8, 0u16); 1_000_000_000] : 19.46µs
vec![0u32; 1_000_000_000] : 9.34µs
vec![[const { NonCopyZst }; 2]; 1_000] : 31.88µs
vec![NonCopyZst; 10_000] : 36.519µs
```
```rs
$ cargo +dev run
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 4.12µs
vec![(0u8, (), 0u16); 1_000_000_000] : 16.299µs
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 210ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 210ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 170ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 110ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 140ns
vec![(0u8, 0u16); 1_000_000_000] : 11.56µs
vec![0u32; 1_000_000_000] : 10.71µs
vec![[const { NonCopyZst }; 2]; 1_000] : 36.08µs
vec![NonCopyZst; 10_000] : 73.21µs
```
(checking release mode to make sure this doesn't regress perf there)
```rs
$ cargo +nightly run --release
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 70ns
vec![(0u8, (), 0u16); 1_000_000_000] : 1.269457501s
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 10ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 20ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 10ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 20ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 20ns
vec![(0u8, 0u16); 1_000_000_000] : 20ns
vec![0u32; 1_000_000_000] : 20ns
vec![[const { NonCopyZst }; 2]; 1_000] : 2.66µs
vec![NonCopyZst; 10_000] : 13.39µs
```
```rs
$ cargo +dev run --release
vec![[String::from("hello"); 0]; 1_000_000_000] : 90ns
vec![(0u8, (), 0u16); 1_000_000_000] : 30ns
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 20ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 30ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 20ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 20ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 20ns
vec![(0u8, 0u16); 1_000_000_000] : 30ns
vec![0u32; 1_000_000_000] : 20ns
vec![[const { NonCopyZst }; 2]; 1_000] : 3.52µs
vec![NonCopyZst; 10_000] : 17.13µs
```
</details>
The specific expression I ran into a perf issue that this PR addresses is `vec![[(); LARGE]; LARGE]`, as I was trying to demonstrate `Vec::into_flattened` panicking on length overflow in the playground, but got a timeout error instead since `vec![[(); LARGE]; LARGE]` took so long to run in debug mode (it runs fine on the playground in release mode)
…=urgau
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to rust-lang/rust#81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks
This PR makes `...` arguments without a pattern in non-foreign functions (such as the argument in `unsafe extern "C" fn f(...) {}`) a future-compatibility warning; making this error would be consistent with how `unsafe extern "C" fn f(u32) {}` is handled. Allowing `...` arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing `...` arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. `...` arguments without a pattern in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations).
As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0:
```rust
#[cfg(any())] // Equivalent to the more recent #[cfg(false)]
unsafe extern "C" fn bar(_: u32, ...) {}
```
Since this is more or less a stability hole and a Crater run shows only the `binrw` crate is using this, I think it would be ok to break this. This will require a lang FCP.
The idea of rejecting `...` pre-expansion was first raised here rust-lang/rust#143546 (comment).
Tracking issue: rust-lang/rust#44930
cc `@folkertdev` `@workingjubilee`
r? `@joshtriplett`
…=GuillaumeGomez rustdoc: Erase `#![doc(document_private_items)]` I just found out about the existence of `#![doc(document_private_items)]`. Apparently it was added by PR rust-lang/rust#50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed `#![doc(passes)]` / `#![doc(no_default_passes)]`. However, rustc and rustdoc actually emit the deny-by-default lint `invalid_doc_attributes` for it (but if you allow it, the attribute does function)! To be more precise since PR rust-lang/rust#82708 (1.52, May 2021) which introduced lint `invalid_doc_attributes`, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR rust-lang/rust#111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted. Given the fact that since 2021 nobody has ever opened a ticket ([via](https://github.com/rust-lang/rust/issues?q=is%3Aissue+document_private_items)) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses ([via](https://github.com/search?q=%2F%23%21%5C%5Bdoc%5C%28.*%3Fdocument_private_items%2F+language%3ARust&type=code&ref=advsearch)), I'm led to believe that nobody knows about and uses this attribute. I don't find the existence of this attribute to be justified since in my view the flag `--document-private-items` is strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like `.cargo/config.toml` or via a command runner like `just` I'd say. Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.
Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`
Related to rust-lang/rust#144336 and rust-lang/rust#139911, see rust-lang/rust#139911 (comment). I haven't touched the `exact_div`, `exact_udiv` and `exact_sdiv` intrinsics. Let me know if I should.
rustdoc-json: move `target` to `json::conversions` It belongs here, because it moves from a `rustc_*` type to a `rustdoc_json_types` type. r? ```````@GuillaumeGomez```````
compiletest: Migrate `TestProps` directive handling to a system of named handlers One of the very silly things about directive processing in compiletest is that for each directive in the test file, we proceed to check it against dozens of different directive names in linear sequence, without any kind of indexed lookup, and without any early-exit after a known directive name is found (unless a panic occurs). This PR is a big step away from that, by taking the `iter_directives` loop in `TestProps::load_from` and making all of its directive processing dispatch to a hashtable of individual name-specific handlers instead. --- The handler system is set up in a way that should allow us to add capabilities or change the implementation as needed, without having to mass-modify the existing handlers (e.g. this is why the `handler` and `multi_handler` functions are used). --- This PR is focused on mass-migrating all of the `TestProps` directive processing into handlers. Most of the resulting handlers could obviously be simplified further (e.g. by avoiding the redundant name checks that were needed in the pre-migration code), but I've avoided doing any such simplifications in this PR to keep its scope limited and make reviewing easier. The patches in this PR have been arranged so that the main migration can be inspected with `git diff --color-moved --color-moved-ws=ignore-all-space` to verify that it moves all of the relevant lines intact, without modifying or discarding any of them. r? jieyouxu
Add `Steal::risky_hack_borrow_mut` I'm working on a rustc driver (Creusot) which needs to modify the MIR read by two queries, `mir_borrowck` and `check_liveness`, in different ways for each query. Both of these queries use `mir_promoted` to read the MIR, which is immutable (until it is stolen). This adds an escape hatch so rustc drivers can mutate MIR for specific queries. And this removes `get_mut` which is unused and also unusable now that there's no way to get a `&mut Steal` from the rustc API. Another approach may be to override the queries to modify the MIR after having read it from `mir_promoted`. However the implementation of queries is largely hidden, so I can't just copy their code to then modify it. A solution would be to parameterize the queries with callbacks which get instantiated with `mir_promoted` by default, but that seems more involved and ad hoc. That's why I'm proposing this smaller change instead.
Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`
```
error[E0310]: the parameter type `R` may not live long enough
--> $DIR/implicit-static-lifetime-in-dyn-trait-return-type.rs:10:5
|
LL | fn bb<R>(r: R) -> Box<dyn Foo> {
| ------- this `dyn Trait` has an implicit `'static` lifetime bound
LL | Box::new(Bar(r))
| ^^^^^^^^^^^^^^^^
| |
| the parameter type `R` must be valid for the static lifetime...
| ...so that the type `R` will meet its required lifetime bounds
|
help: consider adding an explicit lifetime bound
|
LL | fn bb<R: 'static>(r: R) -> Box<dyn Foo> {
| +++++++++
```
Partly address rust-lang/rust#41966 and rust-lang/rust#54753. rust-lang/rust#103849, which shows a case where there's an intermediary binding, is not addressed at all, as aren't cases *other* than `Box<dyn Trait>` return type.
Provide more context when mutably borrowing an imutably borrowed value
Point at statics and consts being mutable borrowed or written to:
```
error[E0594]: cannot assign to immutable static item `NUM`
--> $DIR/E0594.rs:4:5
|
LL | static NUM: i32 = 18;
| --------------- this `static` cannot be written to
...
LL | NUM = 20;
| ^^^^^^^^ cannot assign
```
Point at the expression that couldn't be mutably borrowed from a pattern:
```
error[E0596]: cannot borrow data in a `&` reference as mutable
--> $DIR/mut-pattern-of-immutable-borrow.rs:19:14
|
LL | match &arg.field {
| ---------- this cannot be borrowed as mutable
LL | Some(ref mut s) => s.push('a'),
| ^^^^^^^^^ cannot borrow as mutable
```
Partially address rust-lang/rust#74617.
…mentation, r=Kobzol update the bootstrap readme This PR updates the bootstrap readme and makes it consistent with the latest stage 0 redesign. r? ```@Kobzol```
Add test for --test-builder success path Fixes rust-lang/rust#148586
…youxu bootstrap: respect `build.python` on macOS The `python()` method was hardcoded to return `/usr/bin/python3` on macOS, ignoring the `build.python` config option. This change respects the config while maintaining the system Python as the default.
test(rustdoc): move tests into jump-to-def Fixes rust-lang/rust#148548
…nszelmann Check unsafety for non-macro attributes in `validate_attr` r? `````@jdonszelmann````` Also adds a test for a previously untested case, unnecessary unsafe on a proc macro attribute In preparation for rust-lang/rust#148453
a few small clippy fixes
std: support `RwLock` and thread parking on TEEOS Since TEEOS supports pthread mutexes and condvars, it can share the pthread-based thread parking implementation and thus also the queue-based `RwLock` implementation used on other platforms. CC ``@petrochenkov`` ``@Sword-Destiny``
Port `cfg_select!` to the new attribute parsing system Best reviewed commit by commit, since it involves some moving around of code r? `````@jdonszelmann`````
rustc_target: hide TargetOptions::vendor Discussed in rust-lang/rust#148531 (comment). r? `````@bjorn3`````
Rollup of 15 pull requests Successful merges: - rust-lang/rust#141470 (Add new `function_casts_as_integer` lint) - rust-lang/rust#143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - rust-lang/rust#146495 (rustdoc: Erase `#![doc(document_private_items)]`) - rust-lang/rust#147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - rust-lang/rust#147833 (rustdoc-json: move `target` to `json::conversions`) - rust-lang/rust#147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - rust-lang/rust#148480 (Add `Steal::risky_hack_borrow_mut`) - rust-lang/rust#148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - rust-lang/rust#148508 (Provide more context when mutably borrowing an imutably borrowed value) - rust-lang/rust#148530 (update the bootstrap readme) - rust-lang/rust#148608 (Add test for --test-builder success path) - rust-lang/rust#148636 (bootstrap: respect `build.python` on macOS) - rust-lang/rust#148639 (test(rustdoc): move tests into jump-to-def) - rust-lang/rust#148647 (Check unsafety for non-macro attributes in `validate_attr`) - rust-lang/rust#148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup
IAT: Reinstate early bailout Apparently, some people are already using IATs in their projects and get blocked by rust-lang/rust#142006 (comment) (cc dupes rust-lang/rust#143952 & rust-lang/rust#148535). Since the (temporary) fix is so trivial, let's just do it. Addresses rust-lang/rust#142006 (comment). cc ```@luissantosHCIT``` (rust-lang/rust#148535). r? ```@BoxyUwU```
Fix a typo in the documentation for the strict_shr function fix: rust-lang/rust#148761
…llaumeGomez rustdoc: Don't pass `RenderOptions` to `DocContext` `RenderOptions` is full of HTML specific fields. The only ones that `DocContext` needs are `document_private` and `document_hidden`, which are accessable via `Cache` anyway. Part of a larger campeign against `RenderOption`: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Using.20.60RenderOptions.60.20in.20less.20places.2E/with/545705812
…estebank Improve diagnostics for buffer reuse with borrowed references Addresses rust-lang/rust#147694 I'm not sure the current note wording is the best so I appreciate any feedback.
…arycat [rustdoc] Fix invalid jump to def macro link generation Follow-up of rust-lang/rust#147820. I realized that when there was no intra-doc link linking to the same item, then the generated link for macros in jump to def would be invalid. To make the code less redundant, I merged the "registering" of items and the href generation use the same code for macros. r? `````@notriddle`````
Adjust spans into the `for` loops context before creating the new desugaring spans.
When lowering `for` loops, the spans for the `into_iter` call and the `Some` pattern used the span of the provided pattern and head expression. If either of those came from a different `SyntaxContext` this would result in some very strange contexts. e.g.:
```rust
macro_rules! m { ($e:expr) => { { $e } } }
for _ in m!(expr) {}
```
This would result in the `into_iter` call have a context chain of `desugar => m!() => root` which is completely nonsensical; `m!()` does not have a `for` loop. The `into_iter` call also ends up located at `{ $e }` rather than inside the `for _ in _` part.
This fixes that by walking the spans up to the `for` loop's context first. This will not handle adjusting the location of macro variable expansions (e.g. `for _ in $e`), but this does adjust the context to match the `for` loops.
---
This ended up causing rust-lang/rust-clippy#16008. Clippy should be using a `debug_assert` rather than `unreachable`, but it still results in a bug either way.
Update git index before running diff-index Discussed in https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/tidy.3A.20strange.20number.20of.20modified.20files/with/553714742. This is apparently the cause of `x test tidy` printing weird number of formatted files, and also of sometimes quirky behavior of finding the files modified from a base commit.
rustc_target: introduce Abi, Env, Os Improve type safety by using an enum rather than strings. I'm not really sure this is better since only a few vendors have special semantics. r? ``@nnethercote``
cmse: add test for `async` and `const` functions tracking issue: rust-lang/rust#81391 tracking issue: rust-lang/rust#75835 Some additional tests that seemed useful while working on the RFC text. `async` functions are disallowed (because `-> impl Trait` is not supported). `const` entry functions are allowed, `nonsecure-call` does not make sense, because this abi can only be used on function pointers, which cannot be evaluated during constant evaluation. The async test is in the `c-variadic.rs` file because it has the minicore-compatible machinery for defining an async function. Splitting that logic out (like `minisimd.rs`) turns out to be complicated because the async stuff relies on types defined by minicore. r? `````@davidtwco`````
implement `feature(c_variadic_naked_functions)` tracking issue: rust-lang/rust#148767 [#t-lang > C-variadic naked functions](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/C-variadic.20naked.20functions/with/554593886) This feature allows naked c-variadic function definitions with any ABI that is supported for foreign c-variadic functions. ```rust #![feature(c_variadic, c_variadic_naked_functions)] #[unsafe(naked)] unsafe extern "win64" fn variadic_win64(_: u32, _: ...) -> u32 { core::arch::naked_asm!( r#" push rax mov qword ptr [rsp + 40], r9 mov qword ptr [rsp + 24], rdx mov qword ptr [rsp + 32], r8 lea rax, [rsp + 40] mov qword ptr [rsp], rax lea eax, [rdx + rcx] add eax, r8d pop rcx ret "#, ) } ``` r? ````@workingjubilee````
fix filecheck typos in tests Fixes few filecheck annotation typos in tests.
Remove specialized warning for removed target It has been removed 9 months ago, which is more than a few months.
miri subtree update Lands the new avx512 support for zlib-rs, and the epoll fixes for Tokio. Subtree update of `miri` to 667796b. Created using https://github.com/rust-lang/josh-sync. r? ````@ghost````
…=ehuss Update rustbook dependencies rust-lang/rust#145849 (comment)
fix(rustdoc): Color doctest errors `@fmease's` [Deep analysis](rust-lang/rust#148749 (comment)) on the problem > Yeah, here's a deep analysis by me from a few weeks back of what's going on ([#148101 (comment)](rust-lang/rust#148101 (comment))): > > > […] > > However, since said PR ([#147207](rust-lang/rust#147207): migrating coloring crates), `HumanEmitter::supports_color()` unconditionally(!) returns `false` (in fact, `Emitter::supports_color` is no longer used by anyone else and should be removed), so there's no reason to keep it. Rephrased, since that PR all compiler diagnostics for doctests are uncolored. > > You could argue that I should keep it and patch `supports_color` in rustc to "work again". However, I'd rather rework our doctest coloring wholesale in a separate PR. At least before that migration PR, our setup was quite busted: > > > > 1. First of all, it didn't query+set `supports_color` for syntactically invalid doctests, so syntax errors were always shown without color (contrary to e.g., name resolution errors). > > 2. Second of all, calling `supports_color()` here was quite frankly wrong: Piping the output of `rustdoc … --test` into a file (or `| cat` or whatever) did **not** suppress colors. I'm not actually sure if we can ever address that nicely (without stripping ANSI codes after the fact) since we pass that diagnostic to `libtest`, right? I might very well be wrong here, maybe it's a non-issue. <hr> ```rust /// ``` /// foo /// ``` fn foo() {} ``` ``` rustdoc --test lib.rs ``` Stable: <img width="377" height="290" alt="stable" src="https://github.com/user-attachments/assets/cd20f947-b58d-42db-8735-797613baa9cc" /> Beta: <img width="377" height="290" alt="beta" src="https://github.com/user-attachments/assets/f02588fd-41d2-4642-b03a-5554a68671eb" /> Nightly: <img width="377" height="290" alt="nightly" src="https://github.com/user-attachments/assets/871cb417-f47e-4058-8a76-3bcd538ce141" /> After: <img width="377" height="290" alt="after" src="https://github.com/user-attachments/assets/5734c01f-3f1c-44bb-9404-628c0c33b440" /> Note: This will need to be backported to `beta` Fixes: rust-lang/rust#148749
Remove more `#[must_use]` from portable-simd These lines were missed in <https://github.com/rust-lang/rust/commit/f3515fb127ae07f1b13340dde0c61a20291eb304>/rust-lang/rust#136923 because core_simd/src/masks/bitmask.rs is only conditionally compiled. https://github.com/rust-lang/rust/blob/25d319a0f656ee8faa7a534da299e76e96068a40/library/portable-simd/crates/core_simd/src/masks.rs#L9-L13 Removing them unblocks bootstrapping rustc in an environment where avx512f is enabled. Without this change: ```console error: `#[must_use]` attribute cannot be used on trait methods in impl blocks --> library/core/src/../../portable-simd/crates/core_simd/src/masks/bitmask.rs:173:5 | 173 | #[must_use = "method returns a new mask and does not mutate the original value"] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = help: `#[must_use]` can be applied to data types, functions, unions, required trait methods, provided trait methods, inherent methods, foreign functions, and traits = note: `-D unused-attributes` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unused_attributes)]` ``` To reproduce: `RUSTC_BOOTSTRAP=1 RUSTFLAGS=-Ctarget-feature=+avx512f cargo +nightly check --manifest-path=library/portable-simd/crates/core_simd/Cargo.toml --target=x86_64-unknown-linux-gnu --no-default-features`
Rollup of 16 pull requests Successful merges: - rust-lang/rust#146627 (Simplify `jemalloc` setup) - rust-lang/rust#147753 (Suggest add bounding value for RangeTo) - rust-lang/rust#147832 (rustdoc: Don't pass `RenderOptions` to `DocContext`) - rust-lang/rust#147974 (Improve diagnostics for buffer reuse with borrowed references) - rust-lang/rust#148080 ([rustdoc] Fix invalid jump to def macro link generation) - rust-lang/rust#148465 (Adjust spans into the `for` loops context before creating the new desugaring spans.) - rust-lang/rust#148500 (Update git index before running diff-index) - rust-lang/rust#148531 (rustc_target: introduce Abi, Env, Os) - rust-lang/rust#148536 (cmse: add test for `async` and `const` functions) - rust-lang/rust#148770 (implement `feature(c_variadic_naked_functions)`) - rust-lang/rust#148780 (fix filecheck typos in tests) - rust-lang/rust#148819 (Remove specialized warning for removed target) - rust-lang/rust#148830 (miri subtree update) - rust-lang/rust#148833 (Update rustbook dependencies) - rust-lang/rust#148834 (fix(rustdoc): Color doctest errors) - rust-lang/rust#148841 (Remove more `#[must_use]` from portable-simd) r? `@ghost` `@rustbot` modify labels: rollup
This updates the rust-version file to 0b329f801a09004dacb19aaf09d5cb8b4c51d3f8.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 0b329f801a09004dacb19aaf09d5cb8b4c51d3f8 Filtered ref: f63ba2a Upstream diff: rust-lang/rust@8401398...0b329f8 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two. |
RalfJung
force-pushed
the
rustup-2025-11-12
branch
from
d45ac61 to
205a287
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merge ref '0b329f801a09' from rust-lang/rust
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 0b329f801a09004dacb19aaf09d5cb8b4c51d3f8
Filtered ref: f63ba2a
Upstream diff: rust-lang/rust@8401398...0b329f8
This merge was created using https://github.com/rust-lang/josh-sync.