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

compiler/rustc_metadata/src/locator.rs

compiler/rustc_metadata/src/dependency_format.rs

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

@rustbot ready

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

Ping @bjorn3 , since it has been 2 weeks.

compiler/rustc_ast_passes/src/ast_validation.rs

compiler/rustc_ast_pretty/src/pprust/state.rs

compiler/rustc_codegen_ssa/src/back/link.rs

compiler/rustc_codegen_ssa/src/back/symbol_export.rs

compiler/rustc_metadata/src/locator.rs

compiler/rustc_middle/src/ty/context.rs

compiler/rustc_metadata/src/locator.rs

compiler/rustc_passes/src/check_export.rs

compiler/rustc_resolve/src/build_reduced_graph.rs

compiler/rustc_session/src/config.rs

compiler/rustc_symbol_mangling/src/export.rs

compiler/rustc_symbol_mangling/src/lib.rs

compiler/rustc_symbol_mangling/src/v0.rs

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 · 2025-03-27T18:22:38Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

rust-log-analyzer · 2025-03-27T18:33:19Z

The job mingw-check-tidy failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

info: removing rustup binaries
info: rustup is uninstalled
##[group]Image checksum input
mingw-check-tidy
# We use the ghcr base image because ghcr doesn't have a rate limit
# and the mingw-check-tidy job doesn't cache docker images in CI.
FROM ghcr.io/rust-lang/ubuntu:22.04

ARG DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
  g++ \
  make \
---

COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
COPY host-x86_64/mingw-check/validate-error-codes.sh /scripts/

# NOTE: intentionally uses python2 for x.py so we can test it still works.
# validate-toolstate only runs in our CI, so it's ok for it to only support python3.
ENV SCRIPT TIDY_PRINT_DIFF=1 python2.7 ../x.py test \
           --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
#
# This file is autogenerated by pip-compile with Python 3.10
# by the following command:
#
#    pip-compile --allow-unsafe --generate-hashes reuse-requirements.in
---
#12 4.357   Downloading distlib-0.3.9-py2.py3-none-any.whl (468 kB)
#12 4.365      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 469.0/469.0 KB 86.9 MB/s eta 0:00:00
#12 4.404 Collecting filelock<4,>=3.12.2
#12 4.408   Downloading filelock-3.18.0-py3-none-any.whl (16 kB)
#12 4.443 Collecting platformdirs<5,>=3.9.1
#12 4.447   Downloading platformdirs-4.3.7-py3-none-any.whl (18 kB)
#12 4.532 Installing collected packages: distlib, platformdirs, filelock, virtualenv
#12 4.729 Successfully installed distlib-0.3.9 filelock-3.18.0 platformdirs-4.3.7 virtualenv-20.29.3
#12 4.729 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
#12 DONE 4.8s

#13 [7/8] COPY host-x86_64/mingw-check/validate-toolstate.sh /scripts/
#13 DONE 0.0s
---
DirectMap4k:      126912 kB
DirectMap2M:     4067328 kB
DirectMap1G:    14680064 kB
##[endgroup]
Executing TIDY_PRINT_DIFF=1 python2.7 ../x.py test            --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
+ TIDY_PRINT_DIFF=1 python2.7 ../x.py test --stage 0 src/tools/tidy tidyselftest --extra-checks=py,cpp
##[group]Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.05s
##[endgroup]
WARN: currently no CI rustc builds have rustc debug assertions enabled. Please either set `rust.debug-assertions` to `false` if you want to use download CI rustc or set `rust.download-rustc` to `false`.
[TIMING] core::build_steps::tool::LibcxxVersionTool { target: x86_64-unknown-linux-gnu } -- 0.220
---
fmt check
fmt: checked 5930 files
tidy check
tidy: Skipping binary file check, read-only filesystem
tidy error: /checkout/compiler/rustc_passes/messages.ftl: message `passes_report_stable_impl_id` is not used
removing old virtual environment
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'venv'
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'virtualenv'
Requirement already satisfied: pip in ./build/venv/lib/python3.10/site-packages (25.0.1)
linting python files
All checks passed!
checking python file formatting
26 files already formatted
checking C++ file formatting
some tidy checks failed
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:01:46
  local time: Thu Mar 27 18:33:06 UTC 2025
  network time: Thu, 27 Mar 2025 18:33:06 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

petrochenkov · 2025-03-27T19:04:22Z

compiler/rustc_metadata/src/locator.rs

+                .arg("--emit=metadata")
+                .arg(format!("--crate-name={}", crate_name))
+                .arg(format!("--out-dir={}", tmp_path.path().display()))
+                .arg("--crate-type=rlib") // shadow `sdylib` crate type in interface build


I think for interface builds the crate type needs to be overridden in fn collect_crate_types, similarly to --test builds.
Otherwise it doesn't affect even tests added in this PR, which set #![crate_type = "sdylib"] through an attribute.

petrochenkov · 2025-03-27T19:14:47Z

compiler/rustc_metadata/src/rmeta/decoder.rs

@@ -1488,6 +1488,17 @@ impl<'a> CrateMetadataRef<'a> {
        tcx.arena.alloc_from_iter(self.root.lang_items_missing.decode(self))
    }

+    fn get_exportable_items(self) -> impl Iterator<Item = DefId> + 'a {


Suggested change

fn get_exportable_items(self) -> impl Iterator<Item = DefId> + 'a {

fn get_exportable_items(self) -> impl Iterator<Item = DefId> {

IIUC, this should no longer be necessary on 2024 edition.
(Same in get_stable_order_of_exportable_impls below.)

petrochenkov · 2025-03-27T19:20:01Z

compiler/rustc_metadata/src/rmeta/encoder.rs

+        let exportable_items = stat!("exportable-items", || self.encode_exportable_items());
+
+        let stable_order_of_exportable_impls =
+            stat!("exportable-items", || self.encode_stable_order_of_exportable_impls());


Should these be encoded only in interface build mode?

petrochenkov · 2025-03-27T19:24:01Z

compiler/rustc_feature/src/builtin_attrs.rs

@@ -506,6 +506,11 @@ pub static BUILTIN_ATTRIBUTES: &[BuiltinAttribute] = &[
        naked_functions, experimental!(naked)
    ),

+    gated!(
+        export, Normal, template!(Word), WarnFollowing,
+        EncodeCrossCrate::Yes, experimental!(export)


Suggested change

EncodeCrossCrate::Yes, experimental!(export)

EncodeCrossCrate::No, experimental!(export)

The results of exportable_items are encoded instead.

petrochenkov · 2025-03-27T19:24:53Z

compiler/rustc_interface/src/passes.rs

@@ -715,6 +720,27 @@ pub fn write_dep_info(tcx: TyCtxt<'_>) {
    }
 }

+pub fn write_interface<'tcx>(tcx: TyCtxt<'tcx>) {
+    if !tcx.crate_types().contains(&rustc_session::config::CrateType::Sdylib)


This is redundant now that interfaces are built as rlibs.

petrochenkov · 2025-03-27T19:26:47Z

compiler/rustc_interface/src/passes.rs

@@ -883,6 +909,10 @@ fn run_required_analyses(tcx: TyCtxt<'_>) {
                CStore::from_tcx(tcx).report_unused_deps(tcx);
            },
            {
+                if tcx.crate_types().contains(&CrateType::Sdylib) {


This works accidentally because all the tests use #![crate_type = "sdylib"].
I think it's supposed to use if is_inteface_buid instead.

The is_inteface_buid optimization can be put inside the exportable_items and stable_order_of_exportable_impls queries, then we won't need to do it explicitly neither here nor in metadata encoder.

petrochenkov · 2025-03-27T19:36:48Z

compiler/rustc_metadata/src/locator.rs

@@ -601,6 +614,11 @@ impl<'a> CrateLocator<'a> {
                }
                Err(MetadataError::LoadFailure(err)) => {
                    info!("no metadata found: {}", err);
+                    // Metadata was loaded from interface file earlier.
+                    if let Some((_, _, _, CrateFlavor::SDylib)) = slot {


Suggested change

if let Some((_, _, _, CrateFlavor::SDylib)) = slot {

if let Some((.., CrateFlavor::SDylib)) = slot {

petrochenkov · 2025-03-27T19:39:19Z

compiler/rustc_metadata/src/locator.rs

@@ -762,7 +780,8 @@ impl<'a> CrateLocator<'a> {
        }

        // Extract the dylib/rlib/rmeta triple.
-        self.extract_lib(rlibs, rmetas, dylibs).map(|opt| opt.map(|(_, lib)| lib))
+        self.extract_lib(rlibs, rmetas, dylibs, FxIndexMap::default())


--extern name=/path/to/interface.rs is not implemented.

petrochenkov · 2025-03-27T19:42:55Z

compiler/rustc_metadata/src/locator.rs

+                Ok(tmp_path) => tmp_path,
+                Err(error) => {
+                    return Err(MetadataError::LoadFailure(format!(
+                        "Cannot create temporary directory: {}",


Suggested change

"Cannot create temporary directory: {}",

"couldn't create a temp dir: {}",

To match FailedCreateTempdir.

petrochenkov · 2025-03-27T19:43:15Z

compiler/rustc_metadata/src/locator.rs

+        CrateFlavor::SDylib => {
+            let compiler = std::env::current_exe().map_err(|_err| {
+                MetadataError::LoadFailure(
+                    "couldn't obtain current compiler binary when loading `extern dyn` dependency"


Outdated message, extern dyn no longer exist.

petrochenkov · 2025-03-27T19:45:57Z

Other remaining unaddressed comments:

@rustbot author

bors · 2025-04-01T14:14:45Z

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

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

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

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

This comment was marked as resolved.

Sign in to view

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

Initial support for dynamically linked crates

701fd96

Bryanskiy force-pushed the dylibs-3 branch from a9a6a80 to 701fd96 Compare March 27, 2025 18:22

petrochenkov reviewed Mar 27, 2025

View reviewed changes

	fn get_exportable_items(self) -> impl Iterator<Item = DefId> + 'a {
	fn get_exportable_items(self) -> impl Iterator<Item = DefId> {

	EncodeCrossCrate::Yes, experimental!(export)
	EncodeCrossCrate::No, experimental!(export)

	if let Some((_, _, _, CrateFlavor::SDylib)) = slot {
	if let Some((.., CrateFlavor::SDylib)) = slot {

	"Cannot create temporary directory: {}",
	"couldn't create a temp dir: {}",

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

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

Bryanskiy commented Mar 2, 2025

This comment was marked as resolved.

Bryanskiy commented Mar 13, 2025

petrochenkov commented Mar 19, 2025 • edited Loading

petrochenkov commented Mar 19, 2025

rustbot commented Mar 27, 2025

rust-log-analyzer commented Mar 27, 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

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 27, 2025

bors commented Apr 1, 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

petrochenkov commented Mar 19, 2025 •

edited

Loading