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 with only "exported" items included, and 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);

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)

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:

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

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

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

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:

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

The sequential number of an impl during the intravisit::Visitor traversal.
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 rules

#[export(unsafe_stable_abi = "hash")] syntax for ADT types with private fields is not yet implemented.

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-26T10:58:12Z

compiler/rustc_metadata/src/locator.rs

+            let interface_dir = interface.parent().unwrap();
+            let crate_name = crate_name.unwrap();
+
+            let res = std::process::Command::new(compiler)


This will need to be done either within the current compiler session or as a separate compiler session in the same process. As implemented this will break rustdoc and any other custom driver that has a different cli from rustc itself.

Is it a blocking issue? I don't see an easy way to do this. (I have left a FIXME comment at the moment)

I think not, but at the very least make sure to put the produced rmeta file in a temporary directory. As is you could have multiple rustc instances race trying to write an rmeta file and then read a partially written rmeta file.

Maybe an alternative to invoking rustc from within rustc would be to require the end user to compile interface files to rmeta files themself?

Maybe an alternative to invoking rustc from within rustc would be to require the end user to compile interface files to rmeta files themself?

My concern is that 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 also planned to put them in the dylib, but this has not been done yet.

A translation unit i.e. a crate is not a single file, it consists of modules.

There is a single interface file for the entire crate, right?

but at the very least make sure to put the produced rmeta file in a temporary directory

Done

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

rustbot · 2025-02-14T10:59:29Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

jieyouxu · 2025-02-14T11:06:51Z

r? @bjorn3 (since you already did a bunch fo reviewers, or reroll)

Bryanskiy · 2025-02-14T11:13:47Z

I can split it into several PR's/commits if necessary.

compiler/rustc_ast_passes/src/ast_validation.rs

compiler/rustc_ast_pretty/src/pprust/state/item.rs

compiler/rustc_middle/src/ty/context.rs

compiler/rustc_passes/src/lang_items.rs

compiler/rustc_monomorphize/src/collector.rs

bjorn3 · 2025-02-21T09:47:44Z

compiler/rustc_mir_build/src/builder/mod.rs

@@ -1002,7 +1002,9 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
            self.source_scope = source_scope;
        }

-        if self.tcx.intrinsic(self.def_id).is_some_and(|i| i.must_be_overridden) {
+        if self.tcx.intrinsic(self.def_id).is_some_and(|i| i.must_be_overridden)
+            || self.tcx.is_interface_build()


We should just skip building MIR entirely rather than adding a ad-hoc hack like this.

I don't understand how to do this correctly. Many analysis passes depend on mir_built. Adding checks around these passes seems like a bad idea.

Maybe skip it in encode_mir in metadata encoding?
Since we are in --emit=metadata most MIR won't (?) be built unless it's needed for encoding.

bjorn3 · 2025-02-21T09:51:04Z

compiler/rustc_metadata/src/locator.rs

+            let interface_dir = interface.parent().unwrap();
+            let crate_name = crate_name.unwrap();
+
+            let res = std::process::Command::new(compiler)


I think not, but at the very least make sure to put the produced rmeta file in a temporary directory. As is you could have multiple rustc instances race trying to write an rmeta file and then read a partially written rmeta file.

Maybe an alternative to invoking rustc from within rustc would be to require the end user to compile interface files to rmeta files themself?

compiler/rustc_metadata/src/dependency_format.rs

Bryanskiy · 2025-03-02T18:37:11Z

@rustbot ready

bors · 2025-03-04T02:58:44Z

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

Bryanskiy · 2025-03-13T11:18:08Z

Ping @bjorn3 , since it has been 2 weeks.

petrochenkov · 2025-03-18T16:58:35Z

compiler/rustc_ast_passes/src/ast_validation.rs

@@ -82,6 +82,8 @@ struct AstValidator<'a> {
    /// Used to ban explicit safety on foreign items when the extern block is not marked as unsafe.
    extern_mod_safety: Option<Safety>,

+    is_interface: bool,


Suggested change

is_interface: bool,

is_sdylib_interface: bool,

In other places (pretty-printing, etc) too.

This will be more useful to any unsuspecting reader looking at the code.

petrochenkov · 2025-03-18T17:01:23Z

compiler/rustc_ast_pretty/src/pprust/state.rs

+    s.s.eof()
+}
+
+pub fn print_crate_as_interface(


It's ok to add a new flag to fn print_crate instead of introducing a new function.

I would prefer a new function. For the interface dump, PpAnn must always be fixed and comments must always be skipped.

petrochenkov · 2025-03-18T17:03:56Z

compiler/rustc_codegen_ssa/src/back/link.rs

@@ -2872,7 +2876,11 @@ fn add_upstream_rust_crates(
            }
            Linkage::Dynamic => {
                let src = &codegen_results.crate_info.used_crate_source[&cnum];
-                add_dynamic_crate(cmd, sess, &src.dylib.as_ref().unwrap().0);
+                let lib = match &src.dylib.as_ref() {


Suggested change

let lib = match &src.dylib.as_ref() {

let lib = match &src.dylib.as_ref().unwrap_or_else(...)

petrochenkov · 2025-03-18T17:05:39Z

compiler/rustc_codegen_ssa/src/back/symbol_export.rs

@@ -44,7 +44,7 @@ pub fn crates_export_threshold(crate_types: &[CrateType]) -> SymbolExportLevel {
 }

 fn reachable_non_generics_provider(tcx: TyCtxt<'_>, _: LocalCrate) -> DefIdMap<SymbolExportInfo> {
-    if !tcx.sess.opts.output_types.should_codegen() {
+    if !tcx.sess.opts.output_types.should_codegen() && !tcx.is_interface_build() {


Do we even get to this logic in --emit=metadata builds?

Yes, see encode_crate_root.

petrochenkov · 2025-03-18T17:05:56Z

compiler/rustc_codegen_ssa/src/back/symbol_export.rs

@@ -172,7 +172,7 @@ fn exported_symbols_provider_local(
    tcx: TyCtxt<'_>,
    _: LocalCrate,
 ) -> &[(ExportedSymbol<'_>, SymbolExportInfo)] {
-    if !tcx.sess.opts.output_types.should_codegen() {
+    if !tcx.sess.opts.output_types.should_codegen() && !tcx.is_interface_build() {


Same question as for fn reachable_non_generics_provider.

petrochenkov · 2025-03-18T17:31:28Z

compiler/rustc_metadata/src/locator.rs

+                )
+            })?;
+
+            let tmp_path = match tempfile::tempdir() {


Other code uses TempFileBuilder for this.

petrochenkov · 2025-03-18T17:31:53Z

compiler/rustc_metadata/src/locator.rs

+            let tmp_path = match tempfile::tempdir() {
+                Ok(tmp_path) => tmp_path,
+                Err(error) => {
+                    return Err(MetadataError::LoadFailure(format!(


rustc_metadata has the FailedCreateTempdir error type for this.

petrochenkov · 2025-03-18T17:32:43Z

compiler/rustc_metadata/src/locator.rs

+                }
+            };
+
+            let crate_name = dyn_crate.unwrap_or(kw::Empty);


Suggested change

let crate_name = dyn_crate.unwrap_or(kw::Empty);

let crate_name = dyn_crate.unwrap();

See the comment about assert above.

petrochenkov · 2025-03-18T17:35:23Z

compiler/rustc_middle/src/ty/context.rs

@@ -1746,7 +1746,9 @@ impl<'tcx> TyCtxt<'tcx> {
                    MetadataKind::None
                }
                CrateType::Rlib => MetadataKind::Uncompressed,
-                CrateType::Dylib | CrateType::ProcMacro => MetadataKind::Compressed,
+                CrateType::Dylib | CrateType::ProcMacro | CrateType::Sdylib => {
+                    MetadataKind::Compressed


Sdylibs aren't supposed to have metadata (well, in the usual unstable format at least).

Unless the interface libraries are also considered CrateType::Sdylibs during the build.
CrateType::Sdylib with and without is_interface_build behave quite differently.
Maybe they should be split into two crate types, or CrateType::Sdylib should be reset to CrateType::Rlib or something during the interface build? Not sure.

Or maybe crate_type and is_interface_build should just be passed together to all places where the distinction is necessary.

petrochenkov · 2025-03-18T17:51:34Z

compiler/rustc_metadata/src/locator.rs

+                .unwrap_or(self.target.dll_suffix.as_ref());
+            let dylib = interface.0.with_extension(suffix);
+            if !dylib.exists() {
+                return Err(CrateError::ExternLocationNotExist(self.crate_name, dylib));


Ideally, all these errors should be covered by tests (unless they occur due to some external system failures that are hard to reproduce).

Same applies to the new errors in compiler/rustc_passes/src/errors.rs.

petrochenkov · 2025-03-19T11:55:59Z

compiler/rustc_passes/src/check_export.rs

+    tcx: TyCtxt<'tcx>,
+    exportable_items: FxIndexSet<DefId>,
+    in_exportable_mod: bool,
+    catch_exportable_in_mod: bool,


Suggested change

catch_exportable_in_mod: bool,

seen_exportable_in_mod: bool,

petrochenkov · 2025-03-19T11:58:17Z

compiler/rustc_passes/src/check_export.rs

+        if self.tcx.get_attr(def_id, sym::export).is_some() {
+            self.in_exportable_mod = true;
+        }
+        let old_catch_exportable_in_mod = self.catch_exportable_in_mod;


Suggested change

let old_catch_exportable_in_mod = self.catch_exportable_in_mod;

let old_catch_exportable_in_mod = mem::replace(&mut self.catch_exportable_in_mod, false);

petrochenkov · 2025-03-19T12:00:43Z

compiler/rustc_passes/src/check_export.rs

+            && impl_.of_trait.is_none()
+            && self.tcx.is_exportable(item.owner_id.def_id.to_def_id())
+        {
+            self.order.insert(item.owner_id.def_id.to_def_id(), self.id);


self.id is always equal to self.order.len() here, no need to track it.

petrochenkov · 2025-03-19T12:02:11Z

compiler/rustc_passes/src/check_export.rs

+        stable_order_of_exportable_impls,
+        ..*providers
+    };
+}


I didn't look at the logic in this file in detail, it 100% has issues, but it should be ok approximation for a first prototype.

petrochenkov · 2025-03-19T12:06:28Z

compiler/rustc_resolve/src/build_reduced_graph.rs

-                }
+                match item.kind {
+                    ItemKind::ExternCrate(Some(orig_name))
+                    | ItemKind::ExternDynCrate(Some(orig_name)) => {


extern dyn crate self as foo; should produce an error even earlier, so this probably shouldn't be necessary.

extern dyn crate self as foo; should produce an error even earlier

I tried it. It is not true.

petrochenkov · 2025-03-19T12:07:49Z

compiler/rustc_session/src/config.rs

@@ -1049,6 +1050,10 @@ impl OutputFilenames {
            .unwrap_or_else(|| OutFileName::Real(self.output_path(flavor)))
    }

+    pub fn interface_path(&self) -> PathBuf {
+        self.out_directory.join(format!("lib{}.{}", self.crate_stem, RUST_EXT))


Suggested change

self.out_directory.join(format!("lib{}.{}", self.crate_stem, RUST_EXT))

self.out_directory.join(format!("lib{}.rs", self.crate_stem))

The constant isn't used anywhere else.

petrochenkov · 2025-03-19T12:08:58Z

compiler/rustc_session/src/config.rs

 }

 impl CrateType {
    pub fn has_metadata(self) -> bool {
        match self {
-            CrateType::Rlib | CrateType::Dylib | CrateType::ProcMacro => true,
+            CrateType::Rlib | CrateType::Dylib | CrateType::ProcMacro | CrateType::Sdylib => true,


Same comment as in https://github.com/rust-lang/rust/pull/134767/files#r2001606923.

petrochenkov · 2025-03-19T12:12:16Z

compiler/rustc_symbol_mangling/src/export.rs

+use rustc_span::symbol::{Symbol, sym};
+
+trait AbiHashStable<'tcx> {
+    fn hash(&self, tcx: TyCtxt<'tcx>, hasher: &mut StableHasher);


Does this need to be a trait? It's not currently used generically.

Also, probably better to rename the method to something like abi_hash to avoid confusing it with regular hash.

petrochenkov · 2025-03-19T12:14:33Z

compiler/rustc_symbol_mangling/src/lib.rs

-            v0::mangle(tcx, instance, instantiating_crate)
-        }),
+    let mut symbol = match tcx.is_exportable(def_id) {
+        true => v0::mangle(tcx, instance, instantiating_crate),


Suggested change

true => v0::mangle(tcx, instance, instantiating_crate),

true => format!("{}_{}", v0::mangle(tcx, instance, instantiating_crate), export::compute_hash_of_export_fn(tcx, instance))

petrochenkov · 2025-03-19T12:17:22Z

compiler/rustc_symbol_mangling/src/v0.rs

@@ -32,6 +32,7 @@ pub(super) fn mangle<'tcx>(
    let mut cx: SymbolMangler<'_> = SymbolMangler {
        tcx,
        start_offset: prefix.len(),
+        is_exportable: tcx.is_exportable(def_id),


Maybe pass this as an argument to fn mangle, we already know whether it's exportable when calling this.

petrochenkov · 2025-03-19T12:32:16Z

There are also several big, but non-blocking, issues here.

extern dyn crate probably shouldn't exist. We should determine the crate type when attempting to find and load it in crate loader.
Most crates are passed through --extern and do not use extern crate items.
It's possible to add a modifier to --extern too, but probably better to just detect the crate type automatically.
Running a new compiler with Command::new.
It's clear that we cannot call any rustc_interface APIs from rustc_metadata directly due to the crate dependency structure, but maybe it can be done through a function pointer?
(If possible, using the hook mechanism compiler\rustc_middle\src\hooks\mod.rs)
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.

petrochenkov · 2025-03-19T12:32:37Z

The PR description also needs some updates.
@rustbot author

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

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 from 3ff903c to 03faed3 Compare February 12, 2025 15:45

rustbot added the A-meta Area: Issues & PRs about the rust-lang/rust repository itself label Feb 12, 2025

This comment has been minimized.

Sign in to view

Bryanskiy force-pushed the dylibs-3 branch from 03faed3 to b50b887 Compare February 12, 2025 16:03

This comment has been minimized.

Sign in to view

Bryanskiy force-pushed the dylibs-3 branch from b50b887 to 9925282 Compare February 13, 2025 12:39

This comment was marked as resolved.

Sign in to view

Bryanskiy marked this pull request as ready for review February 14, 2025 10:59

rustbot assigned bjorn3 Feb 14, 2025

bjorn3 requested changes Feb 21, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 21, 2025

m-ou-se mentioned this pull request Feb 28, 2025

Research: How to achieve safety when linking separately compiled code rust-lang/rust-project-goals#267

Open

11 tasks

Initial support for dynamically linked crates

a9a6a80

Bryanskiy force-pushed the dylibs-3 branch from 9925282 to a9a6a80 Compare March 2, 2025 16:46

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 2, 2025

petrochenkov self-assigned this Mar 18, 2025

petrochenkov reviewed Mar 18, 2025

View reviewed changes

petrochenkov reviewed Mar 19, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 19, 2025

	let lib = match &src.dylib.as_ref() {
	let lib = match &src.dylib.as_ref().unwrap_or_else(...)

	let crate_name = dyn_crate.unwrap_or(kw::Empty);
	let crate_name = dyn_crate.unwrap();

	let old_catch_exportable_in_mod = self.catch_exportable_in_mod;
	let old_catch_exportable_in_mod = mem::replace(&mut self.catch_exportable_in_mod, false);

	self.out_directory.join(format!("lib{}.{}", self.crate_stem, RUST_EXT))
	self.out_directory.join(format!("lib{}.rs", self.crate_stem))

	true => v0::mangle(tcx, instance, instantiating_crate),
	true => format!("{}_{}", v0::mangle(tcx, instance, instantiating_crate), export::compute_hash_of_export_fn(tcx, instance))

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?

component 2: crate loader

component 3: exportable items collector

component 4: "stable" mangling scheme

mangled item path

hash of the signature

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

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.

This comment has been minimized.

This comment has been minimized.

This comment was marked as resolved.

rustbot commented Feb 14, 2025

jieyouxu commented Feb 14, 2025

Bryanskiy commented Feb 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bryanskiy commented Mar 2, 2025

bors commented Mar 4, 2025

Bryanskiy commented Mar 13, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bryanskiy Mar 25, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov Mar 18, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Bryanskiy Mar 25, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petrochenkov commented Mar 19, 2025

petrochenkov commented Mar 19, 2025

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

Bryanskiy commented Feb 14, 2025 •

edited

Loading

Bryanskiy Mar 25, 2025 •

edited

Loading

petrochenkov Mar 18, 2025 •

edited

Loading

Bryanskiy Mar 25, 2025 •

edited

Loading