diff options
| author | bors <bors@rust-lang.org> | 2021-05-14 12:58:58 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2021-05-14 12:58:58 +0000 |
| commit | 75da570d784a798a34ff1e5048cd9a6a2fb23170 (patch) | |
| tree | 7e2ffecffbd250a725092db3d0bc5190c52b4fdb /library/std/src/sys/unix/stack_overflow.rs | |
| parent | 36a4d14c7edba21bba14df00b9e6e4a111dfc6f2 (diff) | |
| parent | 6381aaf8ae2df01cdb70b6f3123153cf4f1e03cd (diff) | |
| download | rust-75da570d784a798a34ff1e5048cd9a6a2fb23170.tar.gz rust-75da570d784a798a34ff1e5048cd9a6a2fb23170.zip | |
Auto merge of #83640 - bjorn3:shared_metadata_reader, r=nagisa
Use the object crate for metadata reading This allows sharing the metadata reader between cg_llvm, cg_clif and other codegen backends. This is not currently useful for rlib reading with cg_spirv ([rust-gpu](https://github.com/EmbarkStudios/rust-gpu/)) as it uses tar rather than ar as .rlib format, but it is useful for dylib reading required for loading proc macros. (cc `@eddyb)` The object crate is already trusted as dependency of libstd through backtrace. As far as I know it supports reading all object file formats used by targets for which we support rust dylibs with crate metadata, but I am not certain. If this happens to not be the case, I could keep using LLVM for reading dylib metadata. Marked as WIP for a perf run and as it is based on #83637.
Diffstat (limited to 'library/std/src/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions