[pull] master from rust-lang:master #2289
Open
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Mark-Simulacrum
force-pushed
the
master
branch
from
90e092f to
89b9f7b
Compare
Mark-Simulacrum
force-pushed
the
master
branch
from
47c0792 to
999ac5f
Compare
…ad disable problematic test
…=Amanieu Optimize `ToString` implementation for integers Part of #135543. Follow-up of #133247 and #128204. The benchmark results are: | name| 1.87.0-nightly (3ea711f 2025-03-09) | With this PR | diff | |-|-|-|-| | bench_i16 | 32.06 ns/iter (+/- 0.12) | 17.62 ns/iter (+/- 0.03) | -45% | | bench_i32 | 31.61 ns/iter (+/- 0.04) | 15.10 ns/iter (+/- 0.06) | -52% | | bench_i64 | 31.71 ns/iter (+/- 0.07) | 15.02 ns/iter (+/- 0.20) | -52% | | bench_i8 | 13.21 ns/iter (+/- 0.14) | 14.93 ns/iter (+/- 0.16) | +13% | | bench_u16 | 31.20 ns/iter (+/- 0.06) | 16.14 ns/iter (+/- 0.11) | -48% | | bench_u32 | 33.27 ns/iter (+/- 0.05) | 16.18 ns/iter (+/- 0.10) | -51% | | bench_u64 | 31.44 ns/iter (+/- 0.06) | 16.62 ns/iter (+/- 0.21) | -47% | | bench_u8 | 10.57 ns/iter (+/- 0.30) | 13.00 ns/iter (+/- 0.43) | +22% | More information about it in [the original comment](#136264 (comment)). r? `@workingjubilee`
…ypo-necessarily-to-necessary, r=joboet docs(library/core/src/pin): fix typo "necessarily" -> "necessary" Fix a typo in [`library/core/src/pin.rs`](https://github.com/ruancomelli/rust/blob/14662fabeb69fe5ab6c6e68051bf9f80d4aaaa35/library/core/src/pin.rs), from > As we'll see later, this is **necessarily** from the time the value is first pinned until the end of its lifespan. to > As we'll see later, this is **necessary** from the time the value is first pinned until the end of its lifespan. (my emphasis).
Simplify `Vec::as_non_null` implementation and make it `const` Tracking issue: #130364.
normalization: avoid incompletely constraining GAT args We need to copy the behavior of #125214 in the new solver. This fixes rust-lang/trait-system-refactor-initiative#202 which seems to be the cause of the regression in `deptypes`. r? ```@compiler-errors```
Improve `dangerous_implicit_aurorefs` diagnostic output This PR *greatly* improves the `dangerous_implicit_aurorefs` lint diagnostic output. Kind of related to #140721. r? ```@jieyouxu``` (maybe)
VxWorks: updates from recent libc versions Vxworks changes. Required changes were added to libc in pr rust-lang/libc#4407 and rust-lang/libc#4337
…r=albertlarsan68 remove `RustfmtState` to reduce `initial_rustfmt` complexity The current use of `RustfmtState` doesn't serve its main purpose as it never does the lazy evaulation since `Build::build` forces it to be ready on the early stage. If we want rustfmt to be ready on the early stage, we don't need to have `RustfmtState` complexity at all.
Including:
- Infer `label {}` and `const` operands.
- Correctly handle unsafe check inside `label {}`.
- Fix an embarrassing parser typo that cause labels to never be part of the AST
On Fuchsia, we have an internal Gerrit mirrors of the rust repositories to avoid excess load on the public github servers. Since rust uses submodules, we need to then use git's `url.<base>.insteadOf` to point our checkouts at our mirrors. We'd prefer to be able to point all repositories under `https://github.com/rust-lang` to `https://rust.googlesource.com/rust-lang`, but unfortunately it seems that when Rust mirrored Enzyme, the repository name was lower cased to `https://github.com/rust-lang/enzyme`, but kept the name capitalized in the .gitmodules file. This didn't cause a problem for Github, which seems to handle repository names in a case insensitive way, Gerrit is case sensitive, so we can't use a glob rule. Instead we have to setup `insteadOf` rules for each repository. This renames the URL to match the case of the repository name, which should avoid the issue.
One could be tempted to replace the "then" `hir::Expr` with kind `hir::ExprKind::Block` by a `hir::Block`. Explain why this would not be a good idea.
Rollup of 7 pull requests Successful merges: - #139749 (docs(library/core/src/pin): fix typo "necessarily" -> "necessary") - #140685 (Simplify `Vec::as_non_null` implementation and make it `const`) - #140712 (normalization: avoid incompletely constraining GAT args) - #140768 (Improve `dangerous_implicit_aurorefs` diagnostic output) - #140947 (Flush errors before deep normalize in `dropck_outlives`) - #140990 (VxWorks: updates from recent libc versions) - #141027 (remove `RustfmtState` to reduce `initial_rustfmt` complexity) r? `@ghost` `@rustbot` modify labels: rollup
Remove manual WF hack We do not need this hack anymore since we fixed the candidate selection problems with `Sized` bounds. We prefer built-in sized bounds now since #138176, which fixes the only regression this hack was intended to fix. While this theoretically is broken for some code, for example, when there a param-env bound that shadows an impl or built-in trait, we don't see it in practice and IMO it's not worth the burden of having to maintain this wart in `compare_method_predicate_entailment`. The code that regresses is, for example: ```rust trait Bar<'a> {} trait Foo<'a, T> { fn method(&self) where Self: Bar<'a>; } struct W<'a, T>(&'a T) where Self: Bar<'a>; impl<'a, 'b, T> Bar<'a> for W<'b, T> {} impl<'a, 'b, T> Foo<'a, T> for W<'b, T> { fn method(&self) {} } ``` Specifically, I don't believe this is really going to be encountered in practice. For this to fail, there must be a where clause in the *trait method* that would shadow an impl or built-in (non-`Sized`) candidate in the trait, and this shadowing would need to be encountered when solving a nested WF goal from the impl self type. See #108544 for the original regression. Crater run is clean! r? lcnr
std: explain prefer `TryInto` over `TryFrom` when specifying traits bounds on generic function Fixes #140761 This PR keeps the explanations of `Into` and `From` consistent and adds explanations for `TryInto` and `TryFrom`. r? libs
move (or remove) some impl Trait tests Probably not actually worth the effort, so I am stopping here 😅
…ion, r=joboet Remove `stable` attribute from wasi fs (read_exact|write_all)_at The docs for [`std::os::wasi::fs::FileExt::read_exact_at`](https://doc.rust-lang.org/1.86.0/std/os/wasi/fs/trait.FileExt.html#method.read_exact_at) and [`std::os::wasi::fs::FileExt::write_all_at`](https://doc.rust-lang.org/1.86.0/std/os/wasi/fs/trait.FileExt.html#method.write_all_at) show the methods to be stable since v1.33, which is not correct and was a mistake made when the methods were added in (#74076 (review)). The reviewer seemed to think this was an insta-stabilization, but the entire file is marked as unstable so that was not right. The stabilization version would also have been wrong either way.
fix doc for UnixStream Doc example was using `UdpSocket` instead of `UnixStream`.
update llvm-tools logic for `dist` and `install` steps First commit aligns `build_steps::compile` and `build_steps::dist` logics for copying llvm-tools, and the second commit adds the correct `should_run` condition for `LlvmTools` step as the previous one was clearly incorrect. Fixes #140913
Error on recursive opaque ty in HIR typeck "Non-trivially recursive" opaques are opaques whose hidden types are inferred to be equal to something other than themselves. For example, if we have a TAIT like `type TAIT = impl Sized`, if we infer the hidden type to be `TAIT := (TAIT,)`, that would be a non-trivial recursive definition. We don't want to support opaques that are non-trivially recursive, since they will (almost!! -- see caveat below) always result in borrowck errors, and are generally a pain to deal with. On the contrary, trivially recursive opaques may occur today because the old solver overagerly uses `replace_opaque_types_with_inference_vars`. This infer var can then later be constrained to be equal to the opaque itself. These cases will not necessarily result in borrow-checker errors, since other uses of the opaque may properly constrain the opaque. If there are no other uses we may instead fall back to `()` today. The only weird case that we have to unfortunately deal with was discovered in #139406: ```rust #![allow(unconditional_recursion)] fn what1<T>(x: T) -> impl Sized { what1(x) } fn what2<T>(x: T) -> impl Sized { what2(what2(x)) } fn print_return_type<T, U>(_: impl Fn(T) -> U) { println!("{}", std::any::type_name::<U>()) } fn main() { print_return_type(what1::<i32>); // () print_return_type(what2::<i32>); // i32 } ``` > HIR typeck eagerly replaces the return type with an infer var, ending up with `RPIT<T> = RPIT<RPIT<T>>` in the storage. While we return this in the `TypeckResults`, it's never actually used anywhere. > > MIR building then results in the following statement > ```rust > let _0: impl RPIT<T> /* the return place */ = build<RPIT<T>>(_some_local); > ``` > Unlike HIR typeck MIR typeck now directly equates `RPIT<T>` with `RPIT<RPIT<T>>`. This does not try to define `RPIT` but instead relates its generic arguments https://github.com/rust-lang/rust/blob/b9856b6e400709392dd14599265b6fd52fc19f3e/compiler/rustc_infer/src/infer/relate/type_relating.rs#L185-L190 > > This means we relate `T` with `RPIT<T>`, which results in a defining use `RPIT<T> = T` I think it's pretty obvious that this is not desirable behavior, and according to the crater run there were no regressions, so let's break this so that we don't have any inference hazards in the new solver. In the future `what2` may end up compiling again by also falling back to `()`. However, that is not yet guaranteed and the transition to this state is made significantly harder by not temporarily breaking it on the way. It is also concerning to change the inferred hidden type like this without any notification to the user, even if likely not an issue in this concrete case.
Resolved issue with mismatched types triggering ICE in certain scenarios ## Background The function `annotate_mut_binding_to_immutable_binding` called in `emit_coerce_suggestions` performs a type comparison between the `expected` and `found` types from `ExpectedFound` in the `TypeError`. This can fail if the `found` type contains a region variable that's been rolled back. ## What is being changed? This updates `annotate_mut_binding_to_immutable_binding` to use `expr_ty` and `expected` from the parent function instead of the types from the `TypeError`. This sidesteps the issue of using `found` from `TypeError` which may leak lingering inference region variables. This does change the diagnostic behavior to _only_ support cases where the expected outermost type is `&T`, but that seems to be the intended functionality. Also fixed the example in the `annotate_mut_binding_to_immutable_binding` rustdocs. r? rust-lang/types Fixes #140823
…tency-warning, r=oli-obk Warning added when dependency crate has async drop types, and the feature is disabled In continue of #141031. When dependency crate has non-empty `adt_async_destructor` table in metadata, and `async_drop` feature is disabled for local crate, warning will be emitted. Test `dependency-dropped` has two revisions - with and without feature enabled. With feature enabled, async drop for dropee is executed ("Async drop" printed). Without the feature enabled, sync drop is executed ("Sync drop" printed) and warning is emitted. Warning example: ``` warning: found async drop types in dependecy `async_drop_dep`, but async_drop feature is disabled for `dependency_dropped` --> $DIR/dependency-dropped.rs:7:1 | LL | #![cfg_attr(with_feature, feature(async_drop))] | ^ | = help: if async drop type will be dropped in a crate without `feature(async_drop)`, sync Drop will be used ```
rustc-dev-guide subtree update r? `@ghost`
…iler-errors `gather_locals`: only visit guard pattern guards when checking the guard When checking a pattern with guards in it, `GatherLocalsVisitor` will visit both the pattern (when type-checking the let, arm, or param containing it) and local declarations in the guard expression (when checking the guard itself). This keeps it from visiting the guard when visiting the pattern, since otherwise it would gather locals from the guard twice, which would lead to a delayed bug: "evaluated expression more than once". Tracking issue for guard patterns: #129967
`lower_to_hir` cleanups Some minor cleanups I made when reading this code. r? `@Nadrieril`
Add tick to `RePlaceholder` debug output Present when debug printing canonical queries r? lcnr
When these functions were added in #138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute. We ran into this in Color - https://github.com/linebender/color - and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`. As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this breakage doesn't adversely impact anyone else.
Rollup of 7 pull requests Successful merges: - #139419 (Error on recursive opaque ty in HIR typeck) - #141236 (Resolved issue with mismatched types triggering ICE in certain scenarios) - #141253 (Warning added when dependency crate has async drop types, and the feature is disabled) - #141269 (rustc-dev-guide subtree update) - #141275 (`gather_locals`: only visit guard pattern guards when checking the guard) - #141279 (`lower_to_hir` cleanups) - #141285 (Add tick to `RePlaceholder` debug output) r? `@ghost` `@rustbot` modify labels: rollup
Add TRACING_ENABLED to Machine and add enter_trace_span!()
This PR adds the necessary infrastructure to make it possible to do tracing calls from within `rustc_const_eval` when running Miri, while making sure they don't impact the performance of normal compiler execution. This is done by adding a `const` boolean to `Machine`, false by default, but that will be set to true in Miri only. The tracing macro `enter_trace_span!()` checks if it is true before doing anything, and since the value of a `const` is known at compile time, if it it false it the whole tracing call should be optimized out.
I will soon open further PRs to add tracing macro calls similar to this one, so that afterwards it will be possible to learn more about Miri's time spent in the various interpretation steps:
```rs
let _guard = enter_trace_span!(M, "eval_statement", "{:?}", stmt);
```
r? `@RalfJung`
`core_float_math`: Move functions to `math` module When these functions were added in #138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over the `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute. We ran into this in [Color](https://github.com/linebender/color) and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`. As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this "breakage" doesn't adversely impact anyone else. I believe that I've made the module unstable correctly. I presume that this does not require a test to make sure stable code can't depend on the module existing? I've left the stability attribute on each function - happy to tweak this if a different pattern is more correct. Tracking issue for `core_float_math`: #137578. This PR is as requested in #138087. r? `@tgross35` Recommended reviewing with whitespace hidden. (This is my first PR to `std/core`/this repository, as far as I can remember)
…llaumeGomez Get rid of unnecessary `BufDisplay` abstraction r? `@GuillaumeGomez` , since you reviewed the introduction of `BufDisplay` in #136784 . Not sure when it became unnecessary, but it did :) (feel free to reassign if you wish)
use `Self` alias in self types rather than manually substituting it Of the rougly 145 uses of `self: Ty` in the standard library, 5 of them don't use `Self` but instead choose to manually "substitute" the `impl`'s self type into the type. This leads to weird behavior sometimes (#140611 (comment)) -- **to be clear**, none of these usages actually trigger any bugs, but it's possible that they may break in the future (or at least lead to lints), so let's just "fix" them proactively.
link tracking issue in explicit-extern-abis.md
…Void triagebot: ping me if rustdoc js is modified r? `@aDotInTheVoid`
Fix pagetoc inactive color in rustc book This PR fixes the color of inactive entry in rustc pagetoc, particularly with the "Rust" theme. | Before | After | |--------|-------| |  |  | Live preview at: http://urgau.rf.gd/book Related to #140113 (comment) r? `@ehuss`
[win][ci] Update LLVM toolchain used to build LLVM to 20 While trying to get the aarch64-msvc build working correctly (#140136), I needed to update the version of LLVM used to build LLVM in Windows CI runners to 20 (as this has improved support for Arm64 and Arm64EC on Windows). This catches Windows up to Linux which was updated to 20 by #137189 try-job: `x86_64-apple-*` try-job: `aarch64-apple` try-job: `x86_64-msvc-*` try-job: `i686-msvc-*` try-job: `x86_64-mingw-*`
Rollup of 7 pull requests Successful merges: - #140972 (Add TRACING_ENABLED to Machine and add enter_trace_span!()) - #141282 (`core_float_math`: Move functions to `math` module) - #141288 (Get rid of unnecessary `BufDisplay` abstraction) - #141289 (use `Self` alias in self types rather than manually substituting it) - #141291 (link tracking issue in explicit-extern-abis.md) - #141294 (triagebot: ping me if rustdoc js is modified) - #141303 (Fix pagetoc inactive color in rustc book) r? `@ghost` `@rustbot` modify labels: rollup
collect doc alias as tips during resolution Close #124273 Collect the symbol in the doc alias attributes and provide a tip when a match is found. r? `@estebank`
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )