@@ -36,33 +36,3 @@ byteorder = { version = "1.1", features = ["i128"]}
3636chalk-engine = { version = " 0.9.0" , default-features =false }
3737rustc_fs_util = { path = " ../librustc_fs_util" }
3838smallvec = { version = " 0.6.7" , features = [" union" , " may_dangle" ] }
39-
40- # Note that these dependencies are a lie, they're just here to get linkage to
41- # work.
42- #
43- # We're creating a bunch of dylibs for the compiler but we're also compiling a
44- # bunch of crates.io crates. Everything in the compiler is compiled as an
45- # rlib/dylib pair but all crates.io crates tend to just be rlibs. This means
46- # we've got a problem for dependency graphs that look like:
47- #
48- # foo - rustc_codegen_llvm
49- # / \
50- # rustc ---- rustc_driver
51- # \ /
52- # foo - rustc_metadata
53- #
54- # Here the crate `foo` is linked into the `rustc_codegen_llvm` and the
55- # `rustc_metadata` dylibs, meaning we've got duplicate copies! When we then
56- # go to link `rustc_driver` the compiler notices this and gives us a compiler
57- # error.
58- #
59- # To work around this problem we just add these crates.io dependencies to the
60- # `rustc` crate which is a shared dependency above. That way the crate `foo`
61- # shows up in the dylib for the `rustc` crate, deduplicating it and allowing
62- # crates like `rustc_codegen_llvm` to use `foo` *through* the `rustc` crate.
63- #
64- # tl;dr; this is not needed to get `rustc` to compile, but if you remove it then
65- # later crate stop compiling. If you can remove this and everything
66- # compiles, then please feel free to do so!
67- flate2 = " 1.0"
68- tempfile = " 3.0"
0 commit comments