Adding upstream version 1.65.0+dfsg1.upstream/1.65.0+dfsg1

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 6 insertions, 6 deletions

diff --git a/src/tools/rustc-workspace-hack/README.md b/src/tools/rustc-workspace-hack/README.md
index 4a5286fae..3c6147035 100644
--- a/src/tools/rustc-workspace-hack/README.md
+++ b/src/tools/rustc-workspace-hack/README.md
@@ -2,18 +2,18 @@
 
 This crate is a bit of a hack to make workspaces in rustc work a bit better.
 The rationale for this existence is a bit subtle, but the general idea is that
-we want commands like `./x.py build src/tools/{rls,clippy,cargo}` to share as
+we want commands like `./x.py build src/tools/{clippy,cargo}` to share as
 many dependencies as possible.
 
 Each invocation is a different invocation of Cargo, however. Each time Cargo
 runs a build it will re-resolve the dependency graph, notably selecting
 different features sometimes for each build.
 
-For example, let's say there's a very deep dependency like `num-traits` in each
-of these builds. For Cargo the `num-traits`'s `default` feature is turned off.
-In RLS, however, the `default` feature is turned. This means that building Cargo
-and then the RLS will actually build Cargo twice (as a transitive dependency
-changed). This is bad!
+For example, let's say there's a very deep dependency like `winapi` in each of
+these builds. For Cargo, `winapi` has 33 features enabled. In Clippy, however,
+`winapi` has 22 features enabled. This means that building Cargo and then the
+Clippy will actually build winapi twice, which in turn will build duplicates
+of everything that depends on `winapi`. This is bad!
 
 The goal of this crate is to solve this problem and ensure that the resolved
 dependency graph for all of these tools is the same in the various subsets of