Rollup of 10 pull requests - #160654
Open
JonathanBrouwer wants to merge 79 commits into
Open
Conversation
Add tests for generic function pointers Change FnPtr tests to use assert_eq!() rather than println!()
don't force intrinsic results into memory
This updates the rust-version file to 7218ebe.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@7218ebe Filtered ref: rust-lang/miri@1b56e03 Upstream diff: rust-lang/rust@73dc916...7218ebe This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
Move command-result printing into a helper and keep CLI loop control at the call site.
Consume Priroda's --dap flag before handing arguments to rustc_driver::run_compiler, then dispatch the freshly-created PrirodaContext to either the existing CLI loop or a new DAP loop stub.
Add FirstUserSourceLocation ResumeMode variant that stops when the interpreter reaches a user-relevant frame with a source location. This gives the DAP frontend an entry-stop primitive that skips Miri-internal and std frames.
Wire `next` and `stepIn` DAP requests to Priroda's existing source-line step. Both commands use the same `handle_step` handler for now; true step-over vs step-in semantics are deferred. Add `stopped_reason` to map `StepResult` variants to DAP `StoppedEventReason` so the editor can distinguish a manual step from a breakpoint hit. Add a `handle_disconnect` handler that sends the `terminated` event and exits the session cleanly. Document the `SourceLocation` span-storage rationale and refine the `SourceLine` resume-mode comment to be clearer about the "no source location → first mapped location" semantics.
When the session receives an unsupported DAP request, return `DispatchOutcome::Continue` instead of `Exit` so the debug adapter keeps running after sending the error response. Remove the `eprintln!` side channel from `handle_unsupported_request` since the framed DAP error response is the single authoritative error-reporting path. Include the command name in the error message string so the DAP client sees which request was rejected.
Revive L4Re target This revives the target for the L4Re OS. It changes the way, linking is done and adds aarch64 support and documentation including a maintainer for the target. The update of the libc crate is necessary since only in 0.2.179 and higher is the fixed support for L4Re on uclibc.
Add support for splatted function pointers Tracking issue: rust-lang#153629 This PR adds support for splatted function pointers. Currently splatted function pointers ICE due to unpopulated side-tables. This PR fixes the ICE by populating the side-table correctly, and fixes the MIR lowering code. It also refactors the surrounding code to reduce code duplication. Generic function pointers also work. I'm sure if there's something extra we need to do to support all generic function pointers? Close rust-lang#158603
…ng-3, r=petrochenkov
delegation: add support for wrapping of the return value with `From::from`
This PR supports wrapping the return value of the delegation with `From::from(...)` call. This wrapping is applied only if we understand that `Self` generic param is present in the output of the signature function. The default case are output types such as `Rc<Self>`, `Box<Self>`, etc. So given
```rust
trait MyAdd {
fn add(self, other: Self) -> Box<Self>;
}
impl MyAdd for usize {
fn add(self, other: usize) -> Box<usize> {
Box::new(self + other)
}
}
#[derive(Eq, PartialEq, Debug)]
struct W(Box<usize>);
reuse impl MyAdd for W { *self.0 }
// Desugaring:
#[attr = Inline(Hint)]
fn add(self: _, arg1: _) ->_ {
From::from(Self { 0: MyAdd::add(*self.0, *self.0) })
}
```
As return type of the trait is `Box<Self>` for the delegation to work we need to wrap the return value in the `From::from` call.
## Many from calls
Now only single from is generated which limits the number of supported cases. Consider the return type `Box<Box<Self>>` , in order to support such chains of types we need to generate several `From::from` calls: `From::<Box<_>>::from(From::from(...))`. In such cases there are two problems:
- First we need to create a heuristic two understand how many `From::from` calls should be generated, it is easy for pointer types like `Box`, `Arc`, etc., however if custom types with complex type trees will be considered, the choice is not that obvious: `Struct<Box<Rc<Self>>, Arc<Self>>`. This approach is useful for pointer types but it does not cover all cases in general,
- Next, there will be problems with `From` generic arg inference, if we comeback to case with `Box<Box<Self>>` and generate the following `from` chain: `From::from(From::from(...))` we would get an inference error:
```rust
fn f() -> Box<Box<Box<usize>>> {
Box::from(Box::from(Box::from(1)))
}
// Error:
error[E0283]: type annotations needed
--> src/main.rs:5:9
|
5 | Box::from(Box::from(Box::from(1)))
| ^^^ cannot infer type for struct `Box<_, _>`
|
= note: multiple `impl`s satisfying `Box<Box<Box<usize>>>: From<Box<_, _>>` found in the following crates: `alloc`, `core`:
- impl<T> From<T> for Box<T>;
- impl<T> From<T> for T;
```
We need to explicitly specify generics of `From` trait for this to work, and if we have non-trivial type trees it is not obvious whose generics to specify, in case of chains of pointers it is easy, but in general it is not trivial.
Given those concerns for now we generate a single `From::from` call, which supports simple cases like `Box<Self>`, and if a complex type is used then the user should implement a `From` trait for it.
## Alternative designs
As an alternative we can create any kind of marker that can be used to mark the function that should be used for output type conversion instead of `From::from` call. However this will implicitly grow delegation's syntax budget because it is equivalent to specifying output conversion explicitly: `reuse Trait::foo { self.0 } { MyStruct::delegation_from(self) }`.
Part of rust-lang#118212.
r? @petrochenkov
… r=nnethercote refactor handling of target features in Session `Session` currently contains two lists of target features: `target_features`, which is also exposed in `cfg`, and `unstable_target_features`, which is used internally to communicate between various parts of the compiler which target features are *actually* available, including some that we don't have plans to put in `cfg`, namely "forbidden" target features. The `unstable_target_features` list is *not* equivalent to what nightly code sees in `cfg(target_features)` as the latter excludes "forbidden" target features. Both lists are computed by `fn cfg_target_features` even though one of them is never used for `cfg`. It's all kind of messy. This PR refactors that: `fn cfg_target_features` is replaced by `fn internal_target_features` which computes all enabled Rust target features (including "forbidden" ones -- which are really more like "internal-only" ones so the 2nd commit renames them). We then compute `cfg(target_features)` from that. The session only stores one list, `internal_target_features`, which corresponds to the previous `unstable_target_features`. To simplify computing `internal_target_features` I also refactored `parse_rust_feature_list` to better distinguish actual Rust target features from unknown target features that we are just grandfathering in. I also made `implied_target_features` not rebuild the same hash map over and over again. And I got rid of a bunch of silly temporary vectors and iterations over all Rust target features.
bootstrap: Store and use an explicit CheckKind in `check::Rustc` rust-lang#160417 tried to fix `./x fix compiler` by making the `check::Rustc` step properly use `builder.kind` instead of hardcoding `Kind::Check`. However, that ended up breaking `./x clippy`, which was relying on that hardcoded `Kind::Check` to really invoke `cargo check`. This PR therefore adds an explicit CheckKind to individual instances of `check::Rustc`, allowing command-line invocations to perform a `cargo check` or `cargo fix` as appropriate, without breaking other callers that were relying on the hardcoded `cargo check`. As a result, `./x fix compiler` now works. r? Kobzol (or bootstrap)
miri subtree update Subtree update of `miri` to rust-lang/miri@13801c6. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…-obk Fix FutureDropPoll shim for by-move async closures Related rust-lang#142559 When the coroutine is coroutine-closures, `build_adrop_for_coroutine_shim` used the the ref of the coroutine body. This PR uses `coroutine_by_move_body_def_id` to fetch the by-move body. (matching the existing `DropGlue` behavior in `shim.rs`)
cleanup borrowck, improve c-variadic handling The first commits of rust-lang#160491. Hopefully all of them make sense. It feels intuitive to me that the `c-variadic` region should be just another late-bound region and tracking region correctly for rust-lang#160491 is otherwise a mess. r? types
platform-support/netbsd.md: No longer mention 8.x, due to EoL. Also change the pkgsrc-wip link to indicate a more current rust version. To be re-visited again once 9.x reaches end of maintnance and EoL by the end of the current month. <!-- homu-ignore:start --> - [ x] I did not use an LLM to create a change in this PR. - [ ] I used an LLM to create a change in this PR, and I have explained below how it was used.
derive(Diagnostic): link to proper docs I confirmed that this makes the doc comment show up in RA when hovering a `derive(Diagnostic)`. Also it's not correct that `note` etc can only be used on the struct, those attributes also work on (some) fields. So also fix the comment.
rustbot
added
A-LLVM
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 6, 2026
Rollup of 10 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple-* try-job: x86_64-mingw-1 try-job: i686-msvc-*
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
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.
Successful merges:
From::from#160433 (delegation: add support for wrapping of the return value withFrom::from)check::Rustc#160606 (bootstrap: Store and use an explicit CheckKind incheck::Rustc)r? @ghost
Create a similar rollup