@@ -36,33 +36,3 @@ byteorder = { version = "1.1", features = ["i128"]}
36
36
chalk-engine = { version = " 0.9.0" , default-features =false }
37
37
rustc_fs_util = { path = " ../librustc_fs_util" }
38
38
smallvec = { 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