| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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
|
|
```
error[E0308]: mismatched types
--> $DIR/expr-as-stmt-2.rs:15:15
|
LL | if true { true } else { false } && true;
| ----------^^^^-----------------
| | |
| | expected `()`, found `bool`
| expected this to be `()`
|
help: parentheses are required to parse this as an expression
|
LL | (if true { true } else { false }) && true;
| + +
```
|
|
outside of local_sources
add test against crashing with --html-after-content file
correctly add --html-after-content to env not args
formatting fix for rustdoc-call-locations-after-content/rmake.rs
Use local crate source file as default span in `render_call_locations`
- avoids unwrapping the first file added to the source map as a local file in
`href_from_span`
move test to tests/rustdoc-gui, rename to scrape_examples_ice
test link is correct
use rustdocflags, rename path in example, track lock file
factor out duplicate function calls
use compile-flags to make sure the after.html file is actually included in the rustdoc call
fix goml go-to path
increment assert-count in sidebar-source-code.goml
adjust crate-search width in search-result-display.goml
renamed Bar in scrape_examples_ice test
make crate name shorter ..
|
|
`-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`
|
|
Normally, changes to rustfmt go into the separate repo. But, in
this case, the bug is introduced in a local change and therefore
isn't present in the rustfmt repo.
|
|
|
|
|
|
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).
|
|
rust-lang/revert-2556-date-sweep-2025-08-diag-tests
Revert "dates: refresh diagnostics/ and tests/ annotated dates to August 2025"
|
|
|
|
Revert "dates: refresh infra/tooling date annotations to Aug 2025"
|
|
|
|
Revert "dates: refresh query-system date annotations to 2025-08 (preserve style)"
|
|
style)"
|
|
rust-lang/revert-2559-date-sweep-2025-08-types-traits
Revert "dates: refresh type system & traits date annotations to Aug/2025"
|
|
|
|
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`
|
|
improve output for 'cargo miri test --help'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
when func itself is monomorphized
|
|
Replace unimplemented()! with a more helpful compiler error.
|
|
Automatic Rustup
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 828e45ad11ce4ab56dd64e93f1fb5dd8f0c0ae93
Filtered ref: 10ab51e1b1b8eadb430163bd78ef39c0721cfbf8
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to 828e45ad11ce4ab56dd64e93f1fb5dd8f0c0ae93.
|
|
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?
|
