mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
92482cabaa
rust/compiler/rustc_codegen_ssa/Cargo.toml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

47 lines
1.4 KiB
TOML
Raw Normal View History

mv compiler to compiler/
2020-08-27 22:58:48 -05:00
[package]
name = "rustc_codegen_ssa"
version = "0.0.0"
Migrate to 2021
2021-09-19 11:49:55 -05:00
edition = "2021"
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
[lib]
test = false
[dependencies]
bitflags = "1.2.1"
Upgrade `cc` crate to 1.0.69
2021-07-13 03:58:50 -05:00
cc = "1.0.69"
Update `itertools` Update to 0.10.1
2022-03-04 11:54:28 -06:00
itertools = "0.10.1"
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
tracing = "0.1"
libc = "0.2.50"
bump jobserver dependency the newest jobserver version should slightly reduce context switches in highly parallel build environments on linux kernels >= 5.6
2021-04-21 15:02:54 -05:00
jobserver = "0.1.22"
Use tempfile
2021-04-23 17:33:09 -05:00
tempfile = "3.2"
Update `thorin-dwp` to deduplicate `object`
2022-01-20 08:09:05 -06:00
thorin-dwp = "0.2"
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
pathdiff = "0.2.0"
Use object crate for .rustc metadata generation We already use the object crate for generating uncompressed .rmeta metadata object files. This switches the generation of compressed .rustc object files to use the object crate as well. These have slightly different requirements in that .rmeta should be completely excluded from any final compilation artifacts, while .rustc should be part of shared objects, but not loaded into memory. The primary motivation for this change is #90326: In LLVM 14, the current way of setting section flags (and in particular, preventing the setting of SHF_ALLOC) will no longer work. There are other ways we could work around this, but switching to the object crate seems like the most elegant, as we already use it for .rmeta, and as it makes this independent of the codegen backend. In particular, we don't need separate handling in codegen_llvm and codegen_gcc. codegen_cranelift should be able to reuse the implementation as well, though I have omitted that here, as it is not based on codegen_ssa. This change mostly extracts the existing code for .rmeta handling to allow using it for .rustc as well, and adjust the codegen infrastructure to handle the metadata object file separately: We no longer create a backend-specific module for it, and directly produce the compiled module instead. This does not fix #90326 by itself yet, as .llvmbc will need to be handled separately.
2021-12-02 05:24:25 -06:00
snap = "1"
[debuginfo] Emit associated type bindings in trait object type names.
2021-07-14 08:50:42 -05:00
smallvec = { version = "1.6.1", features = ["union", "may_dangle"] }
Allow more "unknown argument" strings from linker Some toolchains emit slightly different errors, e.g. ppc-vle-gcc: error: unrecognized option '-no-pie'
2021-07-30 14:18:14 -05:00
regex = "1.4"
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
rustc_serialize = { path = "../rustc_serialize" }
cg: use thorin instead of llvm-dwp `thorin` is a Rust implementation of a DWARF packaging utility that supports reading DWARF objects from archive files (i.e. rlibs) and therefore is better suited for integration into rustc. Signed-off-by: David Wood <david.wood@huawei.com>
2021-12-03 08:24:05 -06:00
rustc_arena = { path = "../rustc_arena" }
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
rustc_ast = { path = "../rustc_ast" }
rustc_span = { path = "../rustc_span" }
rustc_middle = { path = "../rustc_middle" }
rustc_apfloat = { path = "../rustc_apfloat" }
rustc_attr = { path = "../rustc_attr" }
rustc_symbol_mangling = { path = "../rustc_symbol_mangling" }
Update cc Recent commits to cc have helped to address #83043 and #43468
2021-05-24 17:34:12 -05:00
rustc_data_structures = { path = "../rustc_data_structures" }
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
rustc_errors = { path = "../rustc_errors" }
rustc_fs_util = { path = "../rustc_fs_util" }
rustc_hir = { path = "../rustc_hir" }
rustc_incremental = { path = "../rustc_incremental" }
rustc_index = { path = "../rustc_index" }
rustc_macros = { path = "../rustc_macros" }
Move EncodedMetadata to rustc_metadata.
2021-09-24 11:15:36 -05:00
rustc_metadata = { path = "../rustc_metadata" }
Remove re-export.
2020-11-14 09:48:54 -06:00
rustc_query_system = { path = "../rustc_query_system" }
mv compiler to compiler/
2020-08-27 22:58:48 -05:00
rustc_target = { path = "../rustc_target" }
rustc_session = { path = "../rustc_session" }
Disable wasm feature of object in cg_ssa The version 1 resolver unifies enabled features across the whole workspace. This includes libstd which isn't allowed to depend on wasmparser.
2021-05-07 11:57:22 -05:00
[dependencies.object]
update Cargo.lock and gimli-rs/object for rustc_codegen_ssa
2022-01-06 23:32:58 -06:00
version = "0.28.0"
Disable wasm feature of object in cg_ssa The version 1 resolver unifies enabled features across the whole workspace. This includes libstd which isn't allowed to depend on wasmparser.
2021-05-07 11:57:22 -05:00
default-features = false
rustc: Store metadata-in-rlibs in object files This commit updates how rustc compiler metadata is stored in rlibs. Previously metadata was stored as a raw file that has the same format as `--emit metadata`. After this commit, however, the metadata is encoded into a small object file which has one section which is the contents of the metadata. The motivation for this commit is to fix a common case where #83730 arises. The problem is that when rustc crates a `dylib` crate type it needs to include entire rlib files into the dylib, so it passes `--whole-archive` (or the equivalent) to the linker. The problem with this, though, is that the linker will attempt to read all files in the archive. If the metadata file were left as-is (today) then the linker would generate an error saying it can't read the file. The previous solution was to alter the rlib just before linking, creating a new archive in a temporary directory which has the metadata file removed. This problem from before this commit is now removed if the metadata file is stored in an object file that the linker can read. The only caveat we have to take care of is to ensure that the linker never actually includes the contents of the object file into the final output. We apply similar tricks as the `.llvmbc` bytecode sections to do this. This involved changing the metadata loading code a bit, namely updating some of the LLVM C APIs used to use non-deprecated ones and fiddling with the lifetimes a bit to get everything to work out. Otherwise though this isn't intended to be a functional change really, only that metadata is stored differently in archives now. This should end up fixing #83730 because by default dylibs will no longer have their rlib dependencies "altered" meaning that split-debuginfo will continue to have valid paths pointing at the original rlibs. (note that we still "alter" rlibs if LTO is enabled to remove Rust object files and we also "alter" for the #[link(cfg)] feature, but that's rarely used). Closes #83730
2021-04-22 13:53:33 -05:00
features = ["read_core", "elf", "macho", "pe", "unaligned", "archive", "write"]
Reference in New Issue Copy Permalink