Rustc pull update #2372
Closed
Rustc pull update #2372
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
Remove -Zunique-is-unique
|
will let this one wait for thu automated pull, given how tiny it is |
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
github-actions
bot
force-pushed
the
rustc-pull
branch
from
0d3837e to
05b4b0d
Compare
|
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.