Initial support for dynamically linked crates #134767

Bryanskiy · 2024-12-25T17:49:53Z

This PR is an initial implementation of 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:

#[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:

#[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(#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:

// simple-lib.rs
#![crate_type = "sdylib"]

#[extern]
pub extern "C" fn foo() -> i32 {
    42
}

// 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 .

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:

#[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). For now, it includes:

hash of the type name for primitive types
for ADT types with public fields the implementation follows this 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

Unresolved questions

Interfaces:

Move the interface generator to HIR and add an exportable items filter.
Compatibility of auto-generated interfaces and macro hygiene.
There is an open issue with interface files compilation: Initial support for dynamically linked crates #134767 (comment)
Put an interface into a dylib.

Mangling scheme:

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)
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.

rustbot · 2024-12-25T17:50:02Z

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Bryanskiy · 2024-12-25T17:56:21Z

cc @m-ou-se

compiler/rustc_ast/src/ast.rs

compiler/rustc_session/src/config.rs

bjorn3 · 2024-12-26T09:54:25Z

However, in that case, we encounter a "disambiguation" issue:

I think that is indicative of a fundamental issue with your implementation. Adding new private impls should not change the ABI. The whole point of the RFC is to allow changing the implementation of the dylib without changing it's ABI. We already have support for dylibs where the ABI depends on the implementation.

bjorn3 · 2024-12-26T10:54:41Z

Also the interface file is missing either the StableCrateId or it's constituent parts (crate name and all -Cmetadata arguments). Without this it is impossible for the consumer to mangle symbols in the same way as the dylib itself.

Replacing all function bodies in an interface file with loop {} does not work in the presence of RPIT. And serializing it as a rust source file misses the expansion context which is essential for hygiene. I did much rather use a format like JSON of while we don't guarantee a stable ABI across rustc versions a binary format.

compiler/rustc_metadata/src/locator.rs

bjorn3 · 2024-12-26T11:04:05Z

component 4: stable ABI mangling scheme

A stable ABI across rustc versions is a lot more involved than just mangling all symbols the same. You have to make sure multiple copies of the standard library seamlessly interoperate including using the same TypeId for &str and String (and thus identical layout for these) for panics to work, you have to make sure the same #[global_allocator] is used, all standard library types remain layout compatible across versions (which would be very limiting and eg lock is in forever on which OSes use pthread_mutex and which use futex) and more. Realistically I don't think a stable ABI across rustc versions is possible without severely limiting what can be passed across the ABI boundary (crABI), which is completely orthogonal to making rust dylibs work across crate versions. crABI can work with cdylib's just as easily.

Edit: To put it another way, I did strongly prefer if stable ABI across rustc versions and stable ABI across crate versions with a single rustc version are treated as entirely separate problems implemented entirely separately. For stable ABI across crate versions you don't need to generate interface files. You can just reuse the existing rmeta file format, but only encode the subset of the items corresponding to the stable ABI.

Bryanskiy · 2025-01-13T12:14:49Z

@bjorn3

I think that is indicative of a fundamental issue with your implementation. Adding new private impls should not change the ABI. The whole point of the RFC is to allow changing the implementation of the dylib without changing it's ABI.

I can suggest the following solution for the above problem with impl's:

Split indices (disambiguators) into 2 sets: $S_1 = { 0, 1, ..., k }$, $S_2 = { k + 1, ..., n }$ where $k$ - number of exported impls, $n$ - total number of impls. For the exportable impls we assign indices from $S_1$ based on the their order in the source code. For the other impls we assign indices from $S_2$ in any way. This approach is stable across rustc versions and doesn't depend on private items.

Also the interface file is missing either the StableCrateId or it's constituent parts (crate name and all -Cmetadata arguments).

Crate name is encoded in the interface name: lib{crate_name}.rs.
-Cmetadata arguments are not yet supported. At the moment, dependence on them has been removed for stable "mangled" symbols.

Replacing all function bodies in an interface file with loop {} does not work in the presence of RPIT.

I used loop {} as a temporary solution since fn foo(); syntax is not allowed 😄.
Regarding the RPIT, yes, it is incompatible with the "header file" concept. But anyway, as you have already said, stable ABI should not depend on implementation. However, computing a hidden type is depends on implementation. So, I don't believe it is possible to support RPIT's without imposing strict limitations.

And serializing it as a rust source file misses the expansion context which is essential for hygiene. I did much rather use a format like JSON of while we don't guarantee a stable ABI across rustc versions a binary format.

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 source code. Stable metadata format is not a part of the RFC.

component 4: stable ABI mangling scheme
A stable ABI across rustc versions is a lot more involved than just mangling all symbols the same. You have to make sure multiple copies of the standard library seamlessly interoperate including using the same TypeId for &str and String ...

"stable ABI" is a bad wording here. Neither I nor the RFC offers a stable ABI. And all these issues are outside the scope of the proposal.

bjorn3 · 2025-01-13T12:21:05Z

One of the main objectives of this proposal is to allow building the library and the application with different compiler versions.

"stable ABI" is a bad wording here. Neither I nor the RFC offers a stable ABI. And all these issues are outside the scope of the proposal.

These two statements are conflicting with each other. Being able to build a library and application with a different compiler version requires both to share an ABI, in other words it requires having a stable ABI.

Bryanskiy · 2025-01-13T12:26:44Z

These two statements are conflicting with each other. Being able to build a library and application with a different compiler version requires both to share an ABI, in other words it requires having a stable ABI.

Only extern "C" functions and types with stable representation are allowed to be "exportable" right now. https://github.com/m-ou-se/rfcs/blob/export/text/0000-export.md#the-export-attribute.

compiler/rustc_driver_impl/src/lib.rs

compiler/rustc_metadata/src/locator.rs

petrochenkov · 2025-04-07T16:10:04Z

@bors try @rust-timer queue

Initial support for dynamically linked crates This PR is an initial implementation of 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 with only "exported" items included, and 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); ``` In this example `bar` function is not a part of the interface as it doesn't have `#[export]` attribute. To emit interface use a new `sdylib` crate type which is basically the same as `dylib`, but it also produces the interface as a second artifact. The current interface name is `lib{crate_name}.rs`. Interface generator was implemented as part of the HIR pretty-printer. In order to filter out unnecessary items, the `PpAnn` trait was used. #### 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 was rejected because it is not a part of the RFC. ([discussion](rust-lang/rfcs#3435 (comment))) Regarding the design with interfaces there are 2 possibilities: manually written or auto-generated. I would personally prefer the auto-generated interface for the following reason: we can put it in the dynamic library instead of metadata, which will make it completely invisible to users. (this was my initial plan, but since the PR is already big enough, I decided to postpone it) But even if we end up with a different design, I believe the interface generator could be a useful tool for testing and experimenting with the entire feature. ### 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. For now, it's assumed that interface and dynamic lib are located in the same directory. `extern dyn crate` annotation serves as a signal for the building of a dynamic dependency. 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 dyn crate simple_lib; fn main() { assert!(simple_lib::foo(), 42); } ``` ``` // Generate interface, build library. rustc +toolchain1 lib.rs -Csymbol-mangling-version=v0 // Build app. Perhaps with a different compiler version. rustc +toolchain2 app.rs -L. -Csymbol-mangling-version=v0 ``` 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 is _mostly_ independent of the compiler internals. The first exception is an impl's disambiguation. 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; // This impl is not part of the interface. 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. However, I have not found the right way to get this order, so I decided to use: 1. The sequential number of an impl during the `intravisit::Visitor` traversal. 2. A new attribute `#[rustc_stable_impl_id]` that outputs this sequential number as a compiler error. If the visitor's implementation is changed, the corresponding test will fail. Then you will need to rewrite the implementation of `stable_order_of_exportable_impls` query to preserve order. P.S. is it possible to compare spans instead? The second exception 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. #### hash of the signature Second part of the symbol name is 128 bit hash containing _relevant_ type information. 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.

bors · 2025-04-07T16:11:18Z

⌛ Trying commit e213390 with merge 4ea9e0d...

bors · 2025-04-07T18:11:12Z

☀️ Try build successful - checks-actions
Build commit: 4ea9e0d (4ea9e0dd4fef386791084d17eaa5e0d01cba735b)

rust-timer · 2025-04-07T19:28:05Z

Finished benchmarking commit (4ea9e0d): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 1.1%, secondary 0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.2%	[4.2%, 4.2%]	1
Regressions ❌ (secondary)	1.7%	[1.3%, 2.3%]	5
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-2.3%	[-2.4%, -2.2%]	3
All ❌✅ (primary)	1.1%	[-2.0%, 4.2%]	2

Cycles

Results (primary -1.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.2%	[-1.2%, -1.2%]	1

Binary size

Results (secondary 0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Bootstrap: 778.658s -> 779.323s (0.09%)
Artifact size: 366.00 MiB -> 366.02 MiB (0.00%)

petrochenkov · 2025-04-07T21:47:07Z

@bjorn3 Do you want to take a final look?

If not, r=me with the FIXME #134767 (comment) added.

petrochenkov · 2025-04-11T12:15:40Z

I'll nominate this for the language team to get a formal approval for merging.
This is a prototype implementation for RFC #3435 "#[export] (dynamically linked crates)", which is also related to one of the 2025H1 project goals Research: How to achieve safety when linking separately compiled code.

bors · 2025-04-14T04:24:41Z

☔ The latest upstream changes (presumably #139766) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis · 2025-04-16T16:37:04Z

Hi all,

I am happy to serve as champion for a lang-team experiment on this work. We would need a feature gate and a suitable tracking issue to be created:

https://lang-team.rust-lang.org/how_to/experiment.html

You can put me down as the champion/liaison though. And @m-ou-se you and I need to setup a regular sync time for this and other things. =) But that is better suited to Zulip...

nikomatsakis · 2025-04-16T16:37:17Z

@rustbot labels -I-lang-nominated

m-ou-se · 2025-04-16T22:17:00Z

I am happy to serve as champion for a lang-team experiment on this work. We would need a feature gate and a suitable tracking issue to be created

Created a tracking issue for #[export]: #139939

m-ou-se · 2025-04-16T22:22:46Z

compiler/rustc_feature/src/unstable.rs

+    /// Allows using `#[export]` which indicates that an item is exportable.
+    (internal, export, "CURRENT_RUSTC_VERSION", None),


You can now add #139939 as the tracking issue (and move this to the section for features with a tracking issue).

rustbot assigned oli-obk Dec 25, 2024

This comment has been minimized.

Sign in to view

workingjubilee reviewed Dec 25, 2024

View reviewed changes

compiler/rustc_ast/src/ast.rs Outdated Show resolved Hide resolved

workingjubilee reviewed Dec 25, 2024

View reviewed changes

compiler/rustc_ast/src/ast.rs Outdated Show resolved Hide resolved

workingjubilee reviewed Dec 25, 2024

View reviewed changes

compiler/rustc_session/src/config.rs Outdated Show resolved Hide resolved

bjorn3 reviewed Dec 26, 2024

View reviewed changes

compiler/rustc_metadata/src/locator.rs Outdated Show resolved Hide resolved

bjorn3 reviewed Dec 26, 2024

View reviewed changes

compiler/rustc_metadata/src/locator.rs Show resolved Hide resolved

oli-obk removed their assignment Jan 7, 2025

This comment was marked as resolved.

Sign in to view

bjorn3 reviewed Jan 16, 2025

View reviewed changes

compiler/rustc_driver_impl/src/lib.rs Outdated Show resolved Hide resolved

Bryanskiy force-pushed the dylibs-3 branch from b9f1d81 to abe0d2e Compare February 5, 2025 18:33

This comment has been minimized.

Sign in to view

This comment was marked as resolved.

Sign in to view

Bryanskiy force-pushed the dylibs-3 branch from abe0d2e to aa5831d Compare February 11, 2025 16:40

rustbot added the A-attributes Area: Attributes (`#[…]`, `#![…]`) label Feb 11, 2025

This comment has been minimized.

Sign in to view

Bryanskiy force-pushed the dylibs-3 branch from aa5831d to a570c97 Compare February 11, 2025 17:30

This comment has been minimized.

Sign in to view

Bryanskiy force-pushed the dylibs-3 branch 3 times, most recently from 683025c to e213390 Compare April 7, 2025 15:25

petrochenkov reviewed Apr 7, 2025

View reviewed changes

compiler/rustc_metadata/src/locator.rs Show resolved Hide resolved

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 7, 2025

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 7, 2025

petrochenkov approved these changes Apr 7, 2025

View reviewed changes

petrochenkov removed their assignment Apr 7, 2025

Initial support for dynamically linked crates

54b1740

Bryanskiy force-pushed the dylibs-3 branch from e213390 to 54b1740 Compare April 11, 2025 08:39

petrochenkov added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Apr 11, 2025

rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Apr 16, 2025

m-ou-se mentioned this pull request Apr 16, 2025

Tracking Issue for #[export] (RFC 3435) #139939

Open

13 tasks

m-ou-se reviewed Apr 16, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initial support for dynamically linked crates #134767

Initial support for dynamically linked crates #134767

Bryanskiy commented Dec 25, 2024 •

edited

Loading

rustbot commented Dec 25, 2024

Bryanskiy commented Dec 25, 2024

This comment has been minimized.

bjorn3 commented Dec 26, 2024 •

edited

Loading

bjorn3 commented Dec 26, 2024 •

edited

Loading

bjorn3 commented Dec 26, 2024 •

edited

Loading

Bryanskiy commented Jan 13, 2025

bjorn3 commented Jan 13, 2025

Bryanskiy commented Jan 13, 2025 •

edited

Loading

This comment was marked as resolved.

This comment has been minimized.

This comment was marked as resolved.

This comment has been minimized.

This comment has been minimized.

petrochenkov commented Apr 7, 2025

This comment has been minimized.

bors commented Apr 7, 2025

bors commented Apr 7, 2025

This comment has been minimized.

rust-timer commented Apr 7, 2025

petrochenkov commented Apr 7, 2025

petrochenkov commented Apr 11, 2025

bors commented Apr 14, 2025

nikomatsakis commented Apr 16, 2025

nikomatsakis commented Apr 16, 2025

m-ou-se commented Apr 16, 2025 •

edited

Loading

m-ou-se Apr 16, 2025

		/// Allows using `#[export]` which indicates that an item is exportable.
		(internal, export, "CURRENT_RUSTC_VERSION", None),

Initial support for dynamically linked crates #134767

Are you sure you want to change the base?

Initial support for dynamically linked crates #134767

Conversation

Bryanskiy commented Dec 25, 2024 • edited Loading

component 1: interface generator

Why was it decided to use a design with an auto-generated interface?

Regarding the design with interfaces

component 2: crate loader

component 3: exportable items collector

component 4: "stable" mangling scheme

mangled item path

hash of the signature

Unresolved questions

rustbot commented Dec 25, 2024

Bryanskiy commented Dec 25, 2024

This comment has been minimized.

bjorn3 commented Dec 26, 2024 • edited Loading

bjorn3 commented Dec 26, 2024 • edited Loading

bjorn3 commented Dec 26, 2024 • edited Loading

Bryanskiy commented Jan 13, 2025

bjorn3 commented Jan 13, 2025

Bryanskiy commented Jan 13, 2025 • edited Loading

This comment was marked as resolved.

This comment has been minimized.

This comment was marked as resolved.

This comment has been minimized.

This comment has been minimized.

petrochenkov commented Apr 7, 2025

This comment has been minimized.

bors commented Apr 7, 2025

bors commented Apr 7, 2025

This comment has been minimized.

rust-timer commented Apr 7, 2025

Overall result: ❌✅ regressions and improvements - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

petrochenkov commented Apr 7, 2025

petrochenkov commented Apr 11, 2025

bors commented Apr 14, 2025

nikomatsakis commented Apr 16, 2025

nikomatsakis commented Apr 16, 2025

m-ou-se commented Apr 16, 2025 • edited Loading

m-ou-se Apr 16, 2025

Choose a reason for hiding this comment

Bryanskiy commented Dec 25, 2024 •

edited

Loading

bjorn3 commented Dec 26, 2024 •

edited

Loading

bjorn3 commented Dec 26, 2024 •

edited

Loading

bjorn3 commented Dec 26, 2024 •

edited

Loading

Bryanskiy commented Jan 13, 2025 •

edited

Loading

m-ou-se commented Apr 16, 2025 •

edited

Loading