| Age | Commit message (Collapse) | Author | Lines |
|---|
|
LLVM upstream switched layouts to support 256-bit vector load/store.
|
|
cleanup and cache proof tree building
There's some cruft left over from when we had deep proof trees. We never encounter overflow when evaluating proof trees. Even if the recursion limit is `0`, we still only hit the overflow limit when evaluating nested goals of the root. The root goal simply inherits the `root_depth` of the `SearchGraph`.
Split `evaluate_root_goal_for_proof_tree` from the rest of the trait solver. This enables us to simplify the implementation of `evaluate_goal_raw` and the `ProofTreeBuilder` as we no longer need to manually track the state of the builder and can instead use separate types for that. It does require making a few internal methods into associated functions taking a `delegate` and a `span` instead of the `EvalCtxt` itself.
I've also split `SearchGraph::evaluate_goal` and `SearchGraph::evaluate_root_goal_for_proof_tree` for the same reason. Both functions don't actually share too much code, so by splitting them each version gets significantly easier to read.
Add a `query evaluate_root_goal_for_proof_tree_raw` to cache proof tree building. This requires arena allocating `inspect::Probe`. I've added a new type alias `I::ProbeRef` for this. We may need to adapt this for rust-analyzer? It would definitely be easy to remove the `Copy` bound here :thinking:
|
|
Revert introduction of `[workspace.dependencies]`.
This was done in rust-lang/rust#145740 and rust-lang/rust#145947. It is causing problems for people using r-a on anything that uses the rustc-dev rustup package, e.g. Miri, clippy.
This repository has lots of submodules and subtrees and various different projects are carved out of pieces of it. It seems like `[workspace.dependencies]` will just be more trouble than it's worth.
r? `@Kobzol`
|
|
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
|
|
explicitly end the lifetime of `va_list`
tracking issue: https://github.com/rust-lang/rust/issues/44930
split out from: https://github.com/rust-lang/rust/pull/144549
The `va_list` is created in the compiler itself when the variable argument list `...` is desugared, and hence the lifetime end is not inserted automatically. The value can't outlive the function in which it was created, so it is correct to end the lifetime here. Ending the lifetime explicitly also appears to give slightly better codegen in https://github.com/rust-lang/rust/pull/144549.
I also included a little drive-by improvement to not cast pointers to integers and back again.
r? codegen
|
|
`-Znext-solver`: support non-defining uses in closures
Cleaned up version of rust-lang/rust#139587, finishing the implementation of https://github.com/rust-lang/types-team/issues/129. This does not affect stable. The reasoning for why this is the case is subtle however.
## What does it do
We split `do_mir_borrowck` into `borrowck_collect_region_constraints` and `borrowck_check_region_constraints`, where `borrowck_collect_region_constraints` returns an enormous `CollectRegionConstraintsResult` struct which contains all the relevant data to actually handle opaque type uses and to check the region constraints later on.
`query mir_borrowck` now simply calls `BorrowCheckRootCtxt::do_mir_borrowck` which starts by iterating over all nested bodies of the current function - visiting nested bodies before their parents - and computing their `CollectRegionConstraintsResult`.
After we've collected all constraints it's time to actually compute the concrete types for the opaques defined by this function. With this PR we now compute the concrete types of opaques for each body before using them to check the non-defining uses of any of them.
After we've computed the concrete types by using all bodies, we use `apply_computed_concrete_opaque_types` for each body to constrain non-defining uses, before finally finishing with `borrowck_check_region_constraints`. We always visit nested bodies before their parents when doing this.
## `ClosureRegionRequirements`
As we only call `borrowck_collect_region_constraints` for nested bodies before type checking the parent, we can't simply use the final `ClosureRegionRequirements` of the nested body during MIR type check. We instead track that we need to apply these requirements in `deferred_closure_requirements`.
We now manually apply the final closure requirements to each body after handling opaque types.
This works, except that we may need the region constraints of nested bodies to successfully define an opaque type in the parent. This is handled by using a new `fn compute_closure_requirements_modulo_opaques` which duplicates region checking - while ignoring any errors - before we've added the constraints from `apply_computed_concrete_opaque_types`. This is necessary for a lot of async tests, as pretty much the entire function is inside of an async block while the opaque type gets defined in the parent.
As an performance optimization we only use `fn compute_closure_requirements_modulo_opaques` in case the nested body actually depends on any opaque types. Otherwise we eagerly call `borrowck_check_region_constraints` and apply the final closure region requirements right away.
## Impact on stable code
Handling the opaque type uses in the parent function now only uses the closure requirements *modulo opaques*, while it previously also considered member constraints from nested bodies. `External` regions are never valid choice regions. Also, member constraints will never constrain a member region if it is required to be outlived by an external region, as that fails the upper-bound check. https://github.com/rust-lang/rust/blob/564ee219127b796d56f74767366fd359758b97de/compiler/rustc_borrowck/src/region_infer/opaque_types/member_constraints.rs#L90-L96
Member constraints therefore never add constraints for external regions :>
r? `@BoxyUwU`
|
|
support non-defining uses in closures
|
|
Update to ar_archive_writer 0.5
This updates `ar_archive_writer` to 0.5, which in turn was updated to match LLVM 20.1.8: <https://github.com/rust-lang/ar_archive_writer/pull/24>
As part of this, I refactored part of `SymbolWrapper.cpp` to pull common code that I was about to duplicate again into a new function.
NOTE: `ar_archive_writer` does include a breaking change where it no longer supports mangling C++ mangled names for Arm64EC. Since we don't need the mangled name (it's not the "exported name" which we're trying to load from the external dll), I'm setting the `import_name` when building for Arm64EC to prevent error when failing to mangle.
r? `@bjorn3`
|
|
fix `#[loop_match]` on diverging loop
tracking issue: https://github.com/rust-lang/rust/issues/132306
fixes https://github.com/rust-lang/rust/issues/144492
fixes https://github.com/rust-lang/rust/issues/144493
fixes https://github.com/rust-lang/rust/issues/144781
this generated invalid MIR before. issue https://github.com/rust-lang/rust/issues/143806 still has an issue where we assign `state = state` which is invalid in MIR. Fixing that problem is tricky, so I'd like to do that separately.
r? `@bjorn3`
|
|
pub async fn impl is monomorphized when func itself is monomorphized
Implentation coroutine (`func::{closure#0}`) is monomorphized, when func itself is monomorphized.
Currently, when `pub async fn foo(..)` is exported from lib and used in several dependent crates, only 'header' function is monomorphized in the defining crate. 'header' function, returning coroutine object, is monomorphized, but the coroutine's poll function (which actually implements all the logic for the function) is not. In such situation, `func::{closure#0}` will be monomorphized in every dependency.
This PR adds monomorphization for `func::{closure#0}` (coroutine poll function), when func itself is monomorphized.
Simple test with one lib async function and ten dependent crates (executable) that use the function, shows 5-7% compilation time improvement (single-threaded).
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#145468 (dedup recip, powi, to_degrees, and to_radians float tests)
- rust-lang/rust#145643 (coverage: Build an "expansion tree" and use it to unexpand raw spans)
- rust-lang/rust#145754 (fix(lexer): Don't require frontmatters to be escaped with indented fences)
- rust-lang/rust#146060 (fixup nix dev shell again)
- rust-lang/rust#146068 (compiletest: Capture panic messages via a custom panic hook)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
compiletest: Capture panic messages via a custom panic hook
Currently, output-capture of panic messages relies on special cooperation between `#![feature(internal_output_capture)]` and the default panic hook. That's a problem if we want to perform our own output capture, because the default panic hook won't know about our custom output-capture mechanism.
We can work around that by installing a custom panic hook that prints equivalent panic messages to a buffer instead.
The custom hook is always installed, but delegates to the default panic hook unless a panic-capture buffer has been installed on the current thread. A panic-capture buffer is only installed on compiletest test threads (by the executor), and only if output-capture is enabled.
---
Right now this PR doesn't provide any particular concrete benefits. But it will be essential as part of further efforts to replace compiletest's use of `#![feature(internal_output_capture)]` with our own output-capture mechanism.
r? jieyouxu
|
|
fixup nix dev shell again
r? Noratrieb
|
|
fix(lexer): Don't require frontmatters to be escaped with indented fences
The RFC only limits hyphens at the beginning of lines and not if they are indented or embedded in other content.
Sticking to that approach was confirmed by the T-lang liason at https://github.com/rust-lang/rust/issues/141367#issuecomment-3202217544
There is a regression in error message quality which I'm leaving for someone if they feel this needs improving.
Tracking issue: rust-lang/rust#136889
Fixes rust-lang/rust#141367
|
|
coverage: Build an "expansion tree" and use it to unexpand raw spans
Historically and currently, coverage instrumentation assumes that all of a function's spans are in the same file and have the same syntax context. The spans extracted directly from MIR don't satisfy that assumption, so there is an “unexpansion” step that walks up each span's expansion-call-site tree to find a suitable span in the same context as the function's body span.
(That unexpansion step is what allows us to have somewhat reasonable coverage instrumentation for macros like `println!`, and for syntax like `for` and `?` that undergo desugaring expansion.)
The current unexpansion code mostly works fine in that “flat” single-file single-context world. But it's not suitable for incremental work towards proper expansion-aware coverage instrumentation, which would allow a function's coverage spans to encompass multiple expansion contexts and multiple files.
This PR therefore replaces the current unexpansion code with a more sophisticated system that uses the raw MIR spans to reconstruct an “expansion tree”, and then uses that tree to help perform most of the unexpansion work.
Building the tree is “overkill” for current unexpansion needs (though it does give some minor edge-case improvements), but my hope is that having the explicit tree available will be a big help when taking the next steps towards proper expansion-region support.
|
|
dedup recip, powi, to_degrees, and to_radians float tests
Deduplicates recip, powi, to_degrees, and to_radians float tests.
I had to fiddle and slightly increase the tolerances for a few comparisons, so maybe not all of the tests are worth deduplicating.
Part of rust-lang/rust#141726.
Best reviewed commit-by-commit.
r? `@tgross35`
|
|
when func itself is monomorphized
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#145421 (`dump_mir` cleanups)
- rust-lang/rust#145968 (Add `Bound::copied`)
- rust-lang/rust#146004 (resolve: Refactor `struct ExternPreludeEntry`)
- rust-lang/rust#146042 (Detect negative literal inferred to unsigned integer)
- rust-lang/rust#146046 (Suggest method name with maybe ty mismatch)
- rust-lang/rust#146051 (Change std f32 test to pass under Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Change std f32 test to pass under Miri
Adds `APPROX_DELTA` to 2 tests of `f32::log` reported in [#miri > Miri test-libstd Failure (2025-08)](https://rust-lang.zulipchat.com/#narrow/channel/269128-miri/topic/Miri.20test-libstd.20Failure.20.282025-08.29).
I changed 2 lines, the first one is the actual failure. The second one is precautionary.
|
|
chenyukang:yukang-fix-method-exists-for-ret-ty-error, r=estebank
Suggest method name with maybe ty mismatch
Fixes rust-lang/rust#146008
I think it's ok to suggest method name even when the return ty mismatch, since we only reporting in `Applicability::MaybeIncorrect`, user may add `()` and continue to fix following errors.
r? ```@estebank```
|
|
Detect negative literal inferred to unsigned integer
```
error[E0277]: the trait bound `usize: Neg` is not satisfied
--> $DIR/negative-literal-infered-to-unsigned.rs:2:14
|
LL | for x in -5..5 {
| ^^ the trait `Neg` is not implemented for `usize`
|
help: consider specifying an integer type that can be negative
|
LL | for x in -5isize..5 {
| +++++
```
Applying this suggestion will always end up in another E0308 error at the point where the unsigned inference comes from, which should help with understanding what the actual problem is.
Fix rust-lang/rust#83413.
|
|
resolve: Refactor `struct ExternPreludeEntry`
Avoid impossible combinations of fields and apply the first part of https://github.com/rust-lang/rust/pull/144737 (do not resolve erroneous entries repeatedly, keep them as `PendingBinding::Ready(None)` instead).
|
|
Add `Bound::copied`
Tracking Issue: https://github.com/rust-lang/rust/issues/145966
Some questions:
- [x] Should I update the documentation for `cloned` to actual used a `Clone` type instead of an integer?
- [x] I removed the `must_use` since this is a cheap copy, does that make sense?
|
|
`dump_mir` cleanups
I found this code hard to read, so I cleaned it up. Details in individual commits.
r? ``@davidtwco``
|
|
Enforce in bootstrap that test must have stage at least 1 (except for compiletest)
This PR cleans up a bunch of test steps and adds metadata to them. I didn't yet touch the most complicated step (`CompileTest`), I'm leaving that for another PR.
Testing anything on stage 0 is only possible for compiletest and with `build.allow-compiletest-stage0`. Testing anything else on stage 0 will either produce a nice error or crash with a stage being subtracted below zero.
r? `@jieyouxu`
try-job: dist-x86_64-linux
try-job: aarch64-gnu
try-job: arm-android
try-job: `x86_64-gnu-llvm-20*`
try-job: `x86_64-msvc-*`
try-job: aarch64-apple
try-job: test-various
|
|
MIR dumping is a mess. There are lots of functions and entry points,
e.g. `dump_mir`, `dump_mir_with_options`, `dump_polonius_mir`,
`dump_mir_to_writer`. Also, it's crucial that `create_dump_file` is
never called without `dump_enabled` first being checked, but there is no
mechanism for ensuring this and it's hard to tell if it is satisfied on
all paths. (`dump_enabled` is checked twice on some paths, however!)
This commit introduces `MirWriter`, which controls the MIR writing, and
encapsulates the `extra_data` closure and `options`. Two existing
functions are now methods of this type. It sets reasonable defaults,
allowing the removal of many `|_, _| Ok(())` closures.
The commit also introduces `MirDumper`, which is layered on top of
`MirWriter`, and which manages the creation of the dump files,
encapsulating pass names, disambiguators, etc. Four existing functions
are now methods of this type.
- `MirDumper::new` will only succeed if dumps are enabled, and will
return `None` otherwise, which makes it impossible to dump when you
shouldn't.
- It also sets reasonable defaults for various things like
disambiguators, which means you no longer need to specify them in many
cases. When they do need to be specified, it's now done via setter
methods.
- It avoids some repetition. E.g. `dump_nll_mir` previously specifed the
pass name `"nll"` four times and the disambiguator `&0` three times;
now it specifies them just once, to put them in the `MirDumper`.
- For Polonius, the `extra_data` closure can now be specified earlier,
which avoids having to pass some arguments through some functions.
|
|
This commit exists purely to simplify reviewing: these functions will
become methods in the next commit. This commit indents them so that the
next commit is more readable.
|
|
The dynamic dispatch cost doesn't matter for MIR dumping, which is
perf-insensitive. And it's necessary for the next commit, which will
store some `extra_data` closures in a struct.
|
|
|
|
The code is more readable without it.
|
|
It has a single call site.
|
|
|
|
rustdoc-search: split function inverted index by input/output
Fixes rust-lang/rust#146015
With a patch applied to count the number of unifications, and running the query `Option<T>, (T -> U) -> Option<U>`
before: performed unifyFunctionType on 17484 functions
after: performed unifyFunctionType on 3055 functions
preview:
https://notriddle.com/rustdoc-html-demo-12/polarity/doc/std/index.html
https://notriddle.com/rustdoc-html-demo-12/polarity/compiler-doc/rustc_hir/index.html
|
|
|
|
std: fix `SplitPaths` regression
Fixes rust-lang/rust#146045 by defining the TAIT more precisely, ensuring that `'a` does not need to be live on drop.
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#144443 (Make target pointer width in target json an integer)
- rust-lang/rust#145174 (Ensure consistent drop for panicking drop in hint::select_unpredictable)
- rust-lang/rust#145592 (Fix format string grammar in docs and improve alignment error message for rust-lang/rust#144023)
- rust-lang/rust#145931 (Clarify that align_offset overaligns)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Clarify that align_offset overaligns
The current documentation is not clear whether adding `a` to a pointer overaligns (align up) or underaligns (align down).
It should say this explicitly.
cc `@nagisa`
|
|
Fix format string grammar in docs and improve alignment error message for #144023
This PR improves error messages and documentation for format strings involving alignment and formatting traits.
Highlights:
- Clearer error messages for invalid alignment specifiers (e.g., `{0:#X>18}`), showing the expected `<`, `^`, or `>` and a working example:
println!("{0:>#18X}", value);
- Updated UI test `format-alignment-hash.rs` to reflect the improved error output.
- Documentation clarification: ensures examples correctly show how width, alignment, and traits like `x`, `X`, `#` combine.
Motivation:
Previously, using `#` with alignment and width produced confusing errors. This PR guides users on the correct syntax and provides actionable examples.
Testing:
- Built the compiler (`./x build`)
- Blessed and ran UI tests (`./x. test src/test/ui/fmt/format-alignment-hash.rs --bless`)
- Verified full test suite passes (`./x test`)
Issue: rust-lang/rust#144023
|
|
Ensure consistent drop for panicking drop in hint::select_unpredictable
There are a few alternatives to the implementation. The principal problem is that the selected value must be owned (in the sense of having a drop flag of sorts) when the unselected value is dropped, such that panic unwind goes through the drop of both. This ownership must then be passed on in return when the drop went smoothly.
The basic way of achieving this is by extracting the selected value first, at the cost of relying on the optimizer a little more for detecting the copy as constructing the return value despite having a place in the body. Unfortunately, that causes LLVM to discard the !unpredictable annotation (for some reason that is beyond my comprehension of LLVM).
<details>
<summary>Extract from the build log showing an unannotated select being used</summary>
```
2025-08-09T16:51:06.8790764Z 39: define noundef i64 `@test_int2(i1` noundef zeroext %p, i64 noundef %a, i64 noundef %b) unnamed_addr #0 personality ptr `@rust_eh_personality` {
2025-08-09T16:51:06.8791368Z check:47'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
2025-08-09T16:51:06.8791700Z 40: start:
2025-08-09T16:51:06.8791858Z check:47'0 ~~~~~~~
2025-08-09T16:51:06.8792043Z 41: %ret.i = select i1 %p, i64 %a, i64 %b
2025-08-09T16:51:06.8792293Z check:47'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-08-09T16:51:06.8792686Z check:47'1 ? possible intended match
2025-08-09T16:51:06.8792946Z 42: ret i64 %ret.i
2025-08-09T16:51:06.8793127Z check:47'0 ~~~~~~~~~~~~~~~~
```
</details>
So instead, this PR includes a guard to drop the selected `MaybeUnit<T>` which is active only for the section where the unselected value is dropped. That leaves the code for selecting the result intact leading to the expected ir. That complicates the 'unselection' process a little bit since we require _both_ values as a result of that intrinsic call. Since the arguments alias, this portion as well as the drop guard uses raw pointers.
Closes: rust-lang/rust#145148
Prior: rust-lang/rust#139977
|
|
Make target pointer width in target json an integer
r? Noratrieb
cc `@RalfJung` (https://github.com/rust-lang/rust/pull/142352/files#r2230380120)
try-job: x86_64-rust-for-linux
|
|
Use absolute path to llvm-bolt, merge-fdata rather than PATH
This unconditionally uses the provided LLVM toolchain's BOLT. I'm not sure that makes sense, but since we don't build BOLT as part of Rust's build of LLVM today, it's probably the right option for now.
This avoids breaking the build on not being able to find the llvm-bolt executable.
|
|
|
|
|
