https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=master 2025-09-02T09:12:54+00:00 2025-09-02T09:12:54+00:00 Nicholas Nethercote n.nethercote@gmail.com 2025-09-02T09:09:13+00:00 urn:sha1:301655eafe56a4b5064adebd412becf94b59221c This was done in #145740 and #145947. It is causing problems for people using r-a on anything that uses the rustc-dev rustup package, e.g. Miri, clippy. This repository has lots of submodules and subtrees and various different projects are carved out of pieces of it. It seems like `[workspace.dependencies]` will just be more trouble than it's worth. 2025-08-28T09:48:54+00:00 Robert Bastian robertbastian@unicode.org 2025-08-28T09:48:54+00:00 urn:sha1:359cbd205f4d8a1d4c3f03307fe2ca524c378340 2025-08-28T09:38:55+00:00 Robert Bastian robertbastian@unicode.org 2025-08-28T09:09:15+00:00 urn:sha1:d82a20e025701be09e87fbfa3a49bc4c2ae5662c 2025-08-27T04:21:19+00:00 Nicholas Nethercote n.nethercote@gmail.com 2025-08-22T00:39:58+00:00 urn:sha1:c50d2cc8078280a0dfdd562c7688e81b664e5880 2025-08-20T22:01:13+00:00 Josh Triplett josh@joshtriplett.org 2025-08-14T07:28:44+00:00 urn:sha1:b65fab62999e96acd3683826ffd4140091f185f2 `rustc_errors` depends on numerous crates, solely to implement its `IntoDiagArg` trait on types from those crates. Many crates depend on `rustc_errors`, and it's on the critical path. We can't swap things around to make all of those crates depend on `rustc_errors` instead, because `rustc_errors` would end up in dependency cycles. Instead, move `IntoDiagArg` into `rustc_error_messages`, which has far fewer dependencies, and then have most of these crates depend on `rustc_error_messages`. This allows `rustc_errors` to drop dependencies on several crates, including the large `rustc_target`. (This doesn't fully reduce dependency chains yet, as `rustc_errors` still depends on `rustc_hir` which depends on `rustc_target`. That will get fixed in a subsequent commit.) 2025-06-28T23:36:46+00:00 Yotam Ofek yotamofek@microsoft.com 2025-06-28T22:59:23+00:00 urn:sha1:8429c9911b68afe9c0cc5804cb15fc22f03d913c 2025-06-24T13:00:04+00:00 Vadim Petrochenkov vadim.petrochenkov@gmail.com 2025-06-20T15:52:13+00:00 urn:sha1:0be37cab97cf330d0470cf6e7db383d944a90975 Also avoid creating and cloning sysroot unnecessarily. 2025-06-19T18:02:04+00:00 Cameron Steffen cam.steffen94@gmail.com 2025-06-19T18:02:04+00:00 urn:sha1:07b9bb1855596ac84a80d898b40c4b403f1dcc3f 2025-06-06T14:20:48+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-06-06T14:20:48+00:00 urn:sha1:e4c4c4c677f00a35aef0cfbe5e5ab3b30eafda4c 2025-06-05T16:54:10+00:00 bjorn3 17426603+bjorn3@users.noreply.github.com 2025-06-05T16:53:12+00:00 urn:sha1:dff8ee5b01b7251937860da41afd55958c13456a Before this change we had two different ways to attempt to locate the sysroot which are inconsistently used: * get_or_default_sysroot which tries to locate based on the 0th cli argument and if that doesn't work falls back to locating it using the librustc_driver.so location and returns a single path., * sysroot_candidates which takes the former and additionally does another attempt at locating using librustc_driver.so except without linux multiarch handling and then returns both paths., The latter was originally introduced to be able to locate the codegen backend back when cg_llvm was dynamically linked even for a custom driver when the --sysroot passed in does not contain a copy of cg_llvm. Back then get_or_default_sysroot did not attempt to locate the sysroot based on the location of librustc_driver.so yet. Because that is now done, the only case where removing sysroot_candidates can break things is if you have a custom driver inside what looks like a sysroot including the lib/rustlib directory, but which is missing some parts of the full sysroot like eg rust-lld.