Rustc pull update #2374
Merged
Rustc pull update #2374
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Automatic Rustup
Automatic Rustup
minor: Sync from downstream
fix: if item exsits on module, resolve as module instead of type
Fix off-by-one error in RangeFormatting
Automatic Rustup
fix: Make `rust-analyzer.files.excludeDirs` work, actually
Fix: don't emit implicit drop inlay hints for macro
fix: Lower range pattern bounds to expressions
fix: Censor cfg_attr for attribute macros
Simplify panic_context
fix: Apply adjustments to proper expr when invoking `CoerceMany`
Automatic Rustup
Automatic Rustup
feat: Refactor path lowering and serve a new path diagnostic
pass struct fields to chalk
minor: Sync from downstream
doc: move dev docs to manual
Automatic Rustup
…rk-Simulacrum Use target-cpu=z13 on s390x codegen const vector test The default s390x cpu(z10) does not have vector support. Setting target-cpu at least to z13 enables vectorisation for s390x architecture and makes the test pass.
Rollup of 6 pull requests Successful merges: - #137280 (stabilize ptr::swap_nonoverlapping in const) - #140457 (Use target-cpu=z13 on s390x codegen const vector test) - #140619 (Small adjustments to `check_attribute_safety` to make the logic more obvious) - #140625 (Suggest `retain_mut` over `retain` as `Vec::extract_if` alternative) - #140627 (Allow linking rustc and rustdoc against the same single tracing crate) - #140630 (Async drop source info fix for proxy-drop-coroutine) r? `@ghost` `@rustbot` modify labels: rollup
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 36 packages to latest compatible versions
Updating addr2line v0.21.0 -> v0.24.2
Updating anyhow v1.0.97 -> v1.0.98
Updating askama v0.13.0 -> v0.13.1 (available: v0.14.0)
Updating askama_derive v0.13.0 -> v0.13.1
Updating backtrace v0.3.71 -> v0.3.74
Updating blake3 v1.8.1 -> v1.8.2
Updating chrono v0.4.40 -> v0.4.41
Updating clap v4.5.36 -> v4.5.37
Updating clap_builder v4.5.36 -> v4.5.37
Updating color-eyre v0.6.3 -> v0.6.4
Updating color-spantrace v0.2.1 -> v0.2.2
Updating derive-where v1.2.7 -> v1.4.0
Updating getrandom v0.2.15 -> v0.2.16
Removing gimli v0.28.1
Updating hashbrown v0.15.2 -> v0.15.3
Updating jiff v0.2.6 -> v0.2.12
Updating jiff-static v0.2.6 -> v0.2.12
Updating libm v0.2.11 -> v0.2.13
Removing object v0.32.2
Updating openssl-sys v0.9.107 -> v0.9.108
Adding owo-colors v4.2.0
Updating proc-macro2 v1.0.94 -> v1.0.95
Updating psm v0.1.25 -> v0.1.26
Updating rand v0.9.0 -> v0.9.1
Updating redox_syscall v0.5.11 -> v0.5.12
Updating rustix v1.0.5 -> v1.0.7
Updating sha2 v0.10.8 -> v0.10.9
Updating stacker v0.1.20 -> v0.1.21
Updating syn v2.0.100 -> v2.0.101
Updating synstructure v0.13.1 -> v0.13.2
Updating toml_datetime v0.6.8 -> v0.6.9
Adding windows v0.61.1
Adding windows-collections v0.2.0
Adding windows-future v0.2.0
Adding windows-numerics v0.2.0
Updating winnow v0.7.6 -> v0.7.9
Updating zerocopy v0.8.24 -> v0.8.25
Updating zerocopy-derive v0.8.24 -> v0.8.25
note: pass `--verbose` to see 33 unchanged dependencies behind latest
library dependencies:
Locking 2 packages to latest compatible versions
Removing allocator-api2 v0.2.21
Updating hashbrown v0.15.2 -> v0.15.3
Removing proc-macro2 v1.0.94
Removing quote v1.0.40
Updating rand v0.9.0 -> v0.9.1
Removing syn v2.0.100
Removing unicode-ident v1.0.18
Removing zerocopy v0.8.24
Removing zerocopy-derive v0.8.24
note: pass `--verbose` to see 3 unchanged dependencies behind latest
rustbook dependencies:
Locking 31 packages to latest compatible versions
Updating ammonia v4.0.0 -> v4.1.0
Updating anyhow v1.0.97 -> v1.0.98
Updating cc v1.2.19 -> v1.2.21
Updating chrono v0.4.40 -> v0.4.41
Updating clap v4.5.36 -> v4.5.37
Updating clap_builder v4.5.36 -> v4.5.37
Updating clap_complete v4.5.47 -> v4.5.48
Adding cssparser v0.35.0
Adding cssparser-macros v0.6.1
Adding dtoa v1.0.10
Adding dtoa-short v0.3.5
Updating hashbrown v0.15.2 -> v0.15.3
Updating html5ever v0.27.0 -> v0.31.0
Updating jiff v0.2.6 -> v0.2.12
Updating jiff-static v0.2.6 -> v0.2.12
Updating libc v0.2.171 -> v0.2.172
Updating markup5ever v0.12.1 -> v0.16.1
Adding match_token v0.1.0
Adding phf_macros v0.11.3
Updating proc-macro2 v1.0.94 -> v1.0.95
Updating redox_syscall v0.5.11 -> v0.5.12
Updating rustix v1.0.5 -> v1.0.7
Updating sha2 v0.10.8 -> v0.10.9
Updating syn v2.0.100 -> v2.0.101
Updating synstructure v0.13.1 -> v0.13.2
Updating toml v0.8.20 -> v0.8.22
Updating toml_datetime v0.6.8 -> v0.6.9
Updating toml_edit v0.22.24 -> v0.22.26
Adding toml_write v0.1.1
Adding web_atoms v0.1.1
Updating winnow v0.7.6 -> v0.7.9
```
Remove -Zunique-is-unique
Initial support for dynamically linked crates This PR is an initial implementation of [rust-lang/rfcs#3435](rust-lang/rfcs#3435) proposal. ### component 1: interface generator Interface generator - a tool for generating a stripped version of crate source code. The interface is like a C header, where all function bodies are omitted. For example, initial crate: ```rust #[export] #[repr(C)] pub struct S { pub x: i32 } #[export] pub extern "C" fn foo(x: S) { m1::bar(x); } pub fn bar(x: crate::S) { // some computations } ``` generated interface: ```rust #[export] #[repr(C)] pub struct S { pub x: i32, } #[export] pub extern "C" fn foo(x: S); pub fn bar(x: crate::S); ``` The interface generator was implemented as part of the pretty-printer. Ideally interface should only contain exportable items, but here is the first problem: - pass for determining exportable items relies on privacy information, which is totally available only in HIR - HIR pretty-printer uses pseudo-code(at least for attributes) So, the interface generator was implemented in AST. This has led to the fact that non-exportable items cannot be filtered out, but I don't think this is a major issue at the moment. To emit an interface use a new `sdylib` crate type which is basically the same as `dylib`, but it doesn't contain metadata, and also produces the interface as a second artifact. The current interface name is `lib{crate_name}.rs`. #### Why was it decided to use a design with an auto-generated interface? One of the main objectives of this proposal is to allow building the library and the application with different compiler versions. This requires either a metadata format compatible across rustc versions or some form of a source code. The option with a stable metadata format has not been investigated in detail, but it is not part of RFC either. Here is the the related discussion: rust-lang/rfcs#3435 (comment) Original proposal suggests using the source code for the dynamic library and all its dependencies. Metadata is obtained from `cargo check`. I decided to use interface files since it is more or less compatible with the original proposal, but also allows users to hide the source code. ##### Regarding the design with interfaces in Rust, files generally do not have a special meaning, unlike C++. A translation unit i.e. a crate is not a single file, it consists of modules. Modules, in turn, can be declared either in one file or divided into several. That's why the "interface file" isn't a very coherent concept in Rust. I would like to avoid adding an additional level of complexity for users until it is proven necessary. Therefore, the initial plan was to make the interfaces completely invisible to users i. e. make them auto-generated. I also planned to put them in the dylib, but this has not been done yet. (since the PR is already big enough, I decided to postpone it) There is one concern, though, which has not yet been investigated(rust-lang/rust#134767 (comment)): > Compiling the interface as pretty-printed source code doesn't use correct macro hygiene (mostly relevant to macros 2.0, stable macros do not affect item hygiene). I don't have much hope for encoding hygiene data in any stable way, we should rather support a way for the interface file to be provided manually, instead of being auto-generated, if there are any non-trivial requirements. ### component 2: crate loader When building dynamic dependencies, the crate loader searches for the interface in the file system, builds the interface without codegen and loads it's metadata. Routing rules for interface files are almost the same as for `rlibs` and `dylibs`. Firstly, the compiler checks `extern` options and then tries to deduce the path himself. Here are the code and commands that corresponds to the compilation process: ```rust // simple-lib.rs #![crate_type = "sdylib"] #[extern] pub extern "C" fn foo() -> i32 { 42 } ``` ```rust // app.rs extern crate simple_lib; fn main() { assert!(simple_lib::foo(), 42); } ``` ``` // Generate interface, build library. rustc +toolchain1 lib.rs // Build app. Perhaps with a different compiler version. rustc +toolchain2 app.rs -L. ``` P.S. The interface name/format and rules for file system routing can be changed further. ### component 3: exportable items collector Query for collecting exportable items. Which items are exportable is defined [here](https://github.com/m-ou-se/rfcs/blob/export/text/0000-export.md#the-export-attribute) . ### component 4: "stable" mangling scheme The mangling scheme proposed in the RFC consists of two parts: a mangled item path and a hash of the signature. #### mangled item path For the first part of the symbol it has been decided to reuse the `v0` mangling scheme as it much less dependent on compiler internals compared to the `legacy` scheme. The exception is disambiguators (https://doc.rust-lang.org/rustc/symbol-mangling/v0.html#disambiguator): For example, during symbol mangling rustc uses a special index to distinguish between two impls of the same type in the same module(See `DisambiguatedDefPathData`). The calculation of this index may depend on private items, but private items should not affect the ABI. Example: ```rust #[export] #[repr(C)] pub struct S<T>(pub T); struct S1; pub struct S2; impl S<S1> { extern "C" fn foo() -> i32 { 1 } } #[export] impl S<S2> { // Different symbol names can be generated for this item // when compiling the interface and source code. pub extern "C" fn foo() -> i32 { 2 } } ``` In order to make disambiguation independent of the compiler version we can assign an id to each impl according to their relative order in the source code. The second example is `StableCrateId` which is used to disambiguate different crates. `StableCrateId` consists of crate name, `-Cmetadata` arguments and compiler version. At the moment, I have decided to keep only the crate name, but a more consistent approach to crate disambiguation could be added in the future. Actually, there are more cases where such disambiguation can be used. For instance, when mangling internal rustc symbols, but it also hasn't been investigated in detail yet. #### hash of the signature Exportable functions from stable dylibs can be called from safe code. In order to provide type safety, 128 bit hash with relevant type information is appended to the symbol ([description from RFC](https://github.com/m-ou-se/rfcs/blob/export/text/0000-export.md#name-mangling-and-safety)). For now, it includes: - hash of the type name for primitive types - for ADT types with public fields the implementation follows [this](https://github.com/m-ou-se/rfcs/blob/export/text/0000-export.md#types-with-public-fields) rules `#[export(unsafe_stable_abi = "hash")]` syntax for ADT types with private fields is not yet implemented. Type safety is a subtle thing here. I used the approach from RFC, but there is the ongoing research project about it. [https://rust-lang.github.io/rust-project-goals/2025h1/safe-linking.html](https://rust-lang.github.io/rust-project-goals/2025h1/safe-linking.html) ### Unresolved questions Interfaces: 1. Move the interface generator to HIR and add an exportable items filter. 2. Compatibility of auto-generated interfaces and macro hygiene. 3. There is an open issue with interface files compilation: rust-lang/rust#134767 (comment) 4. Put an interface into a dylib. Mangling scheme: 1. Which information is required to ensure type safety and how should it be encoded? ([https://rust-lang.github.io/rust-project-goals/2025h1/safe-linking.html](https://rust-lang.github.io/rust-project-goals/2025h1/safe-linking.html)) 2. Determine all other possible cases, where path disambiguation is used. Make it compiler independent. We also need a semi-stable API to represent types. For example, the order of fields in the `VariantDef` must be stable. Or a semi-stable representation for AST, which ensures that the order of the items in the code is preserved. There are some others, mentioned in the proposal.
Remove global `next_disambiguator` state and handle it with a `DisambiguatorState` type This removes `Definitions.next_disambiguator` as it doesn't guarantee deterministic def paths when `create_def` is called in parallel. Instead a new `DisambiguatorState` type is passed as a mutable reference to `create_def` to help create unique def paths. `create_def` calls with distinct `DisambiguatorState` instances must ensure that that the def paths are unique without its help. Anon associated types did rely on this global state for uniqueness and are changed to use (method they're defined in + their position in the method return type) as the `DefPathData` to ensure uniqueness. This also means that the method they're defined in appears in error messages, which is nicer. `DefPathData::NestedStatic` is added to use for nested data inside statics instead of reusing `DefPathData::AnonConst` to avoid conflicts with those. cc `@oli-obk`
Tree Borrows: Correctly handle interior mutable data in `Box`
Subtree update of `rust-analyzer` r? `@ghost`
Miri subtree update r? `@ghost`
…ty-lint-for-rustc-middle, r=oli-obk Handle `rustc_middle` cases of `rustc::potential_query_instability` lint This PR removes `#![allow(rustc::potential_query_instability)]` line from [`compiler/rustc_middle/src/lib.rs`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/lib.rs#L29) and converts `FxHash{Map,Set}` types into `FxIndex{Map,Set}` to suppress lint errors. A somewhat tracking issue: rust-lang/rust#84447 r? `@compiler-errors`
Stabilize proc_macro::Span::{file, local_file}.
Stabilizes this part of rust-lang/rust#54725:
```rust
impl Span {
pub fn file(&self) -> String; // Mapped/artificial file name, for display purposes.
pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on the local file system.
}
```
See also the naming discussion in rust-lang/rust#139903
Use thread local dep graph encoding This adds thread local encoding of dep graph nodes. Each thread has a `MemEncoder` that gets flushed to the global `FileEncoder` when it exceeds 64 kB. Each thread also has a local cache of dep indices. This means there can now be empty gaps in `SerializedDepGraph`. Indices are marked green and also allocated by the new atomic operation `DepNodeColorMap::try_mark_green` as the encoder lock is removed.
…r=davidtwco Separate dataflow analysis and results `Analysis` gets put into `Results` with `EntryStates`, by `iterate_to_fixpoint`. This has two problems: - `Results` is passed various places where only `Analysis` is needed. - `EntryStates` is passed around mutably everywhere even though it is immutable. This commit mostly separates `Analysis` from `Results` and fixes these two problems. r? `@davidtwco`
…r=davidtwco Correct warning message in restricted visibility Fixes #131220
Parser: Recover error from named params while parse_path Fixes #140169 I added test to the first commit and the second added the code and changes to test. r? `@petrochenkov`
Don't crash on error codes passed to `--explain` which exceed our internal limit of 9999 removed panic in case where we do `--explain > 9999` and added check for it now error looks like this instead of ICE ``` $ rustc.exe --explain E10000 error: E10000 is not a valid error code ``` fixes #140647 r? `@fmease`
…, r=notriddle [rustdoc] Ensure that temporary doctest folder is correctly removed even if doctests failed Fixes #139899. The bug was due to the fact that if any doctest fails for any reason, we call `exit` (or it's called inside `libtest` if not edition 2024), meaning that `TempDir`'s destructor isn't called, and therefore the temporary folder isn't cleaned up. Took me a while to figure out how to reproduce but finally I was able to reproduce the bug with: `````rust #![doc(test(attr(deny(warnings))))] //! ``` //! let a = 12; //! ``` ````` And then I ensured that panicking doctests were cleaned up as well: `````rust //! ``` //! panic!(); //! ``` ````` And finally I checked if it was fixed for merged doctests too (`--edition 2024`). To make this work, I needed to add a new public function in `libtest` too which would call a function once all tests have been run. So only issue is: I have absolutely no idea how we can add a regression test for this fix. If anyone has an idea... r? `@notriddle`
Fix regression from #140393 for espidf / horizon / nuttx / vita #140393 introduced changes to the layout of the `std::sys::process` code. As a result, the Tier 3 ESP-IDF (and I suspect Horizon, Nuttx and Vita targets as well) no longer build. A `pub use unsupported::output` is all that was missing - for the above OSes specifically. This explicit `pub use` is now necessary, because #140393 moved the `output` function to module-level, where it was previously part of `Command` and was thus re-exported automatically, as part of the `imp::Command` re-export further down the file containing the one-liner fix. Note that - with the change introduced by #140393 - we **can't** anymore just do an unconditional `pub use imp::output` as this function simply does not exist anymore anywhere else but in the `unsupported` module. r? `@joboet`
…, r=jieyouxu add armv5te-unknown-linux-gnueabi target maintainer My employer is interested in having this target maintained and we already have some tests in our CI running for it. armv5te-unknown-linux-gnueabi can be ticket off in #113739.
…, r=jieyouxu run-make-support: set rustc dylib path for cargo wrapper Some run-make tests invoke Cargo via run_make_support::cargo(), but fail to execute correctly when rustc is built without rpath. In these setups, runtime loading of rustc’s shared libraries fails unless the appropriate dynamic library path is set manually. This commit updates the cargo() wrapper to call set_host_compiler_dylib_path(), aligning its behavior with the existing rustc() wrapper: https://github.com/rust-lang/rust/blob/f76c7367c6363d33ddb5a93b5de0d158b2d827f6/src/tools/run-make-support/src/external_deps/rustc.rs#L39-L43 This ensures that Cargo invocations during tests inherit the necessary dylib paths, avoiding errors related to missing shared libraries in rpath-less builds. Fixes part of #140738
borrowck nested items in dead code fixes rust-lang/rust#140583 r? `@compiler-errors`
Rollup of 8 pull requests Successful merges: - #140234 (Separate dataflow analysis and results) - #140614 (Correct warning message in restricted visibility) - #140671 (Parser: Recover error from named params while parse_path) - #140700 (Don't crash on error codes passed to `--explain` which exceed our internal limit of 9999 ) - #140706 ([rustdoc] Ensure that temporary doctest folder is correctly removed even if doctests failed) - #140734 (Fix regression from #140393 for espidf / horizon / nuttx / vita) - #140741 (add armv5te-unknown-linux-gnueabi target maintainer) - #140745 (run-make-support: set rustc dylib path for cargo wrapper) r? `@ghost` `@rustbot` modify labels: rollup
allow deref patterns to participate in exhaustiveness analysis Per [this proposal](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Exhaustiveness), this PR allows deref patterns to participate in exhaustiveness analysis. Currently all deref patterns enforce `DerefPure` bounds on their scrutinees, so this assumes all patterns it's analyzing are well-behaved. This also doesn't support [mixed exhaustiveness](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Mixed-exhaustiveness), and instead emits an error if deref patterns are used together with normal constructors. I think mixed exhaustiveness would be nice to have (especially if we eventually want to support arbitrary `Deref` impls[^1]), but it'd require more work to get reasonable diagnostics[^2]. Tracking issue for deref patterns: #87121 r? `@Nadrieril` [^1]: Regardless of whether we support limited exhaustiveness checking for untrusted `Deref` or always require other arms to be exhaustive, I think it'd be useful to allow mixed matching for user-defined smart pointers. And it'd be strange if it worked there but not for `Cow`. [^2]: I think listing out witnesses of non-exhaustiveness can be confusing when they're not necessarily disjoint, and when you only need to cover some of them, so we'd probably want special formatting and/or explanatory subdiagnostics. And if it's implemented similarly to unions, we'd probably also want some way of merging witnesses; the way witnesses for unions can appear duplicated is pretty unfortunate. I'm not sure yet how the diagnostics should look, especially for deeply nested patterns.
|
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.
Latest update from rustc.