From 040f9849dce936a16dcba73ba543e41d147af943 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Tue, 24 Apr 2018 10:35:20 -0700 Subject: [PATCH] Comment why `deps_of` doesn't need to keep track of `profile_for` in map. --- src/cargo/core/compiler/context/unit_dependencies.rs | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/cargo/core/compiler/context/unit_dependencies.rs b/src/cargo/core/compiler/context/unit_dependencies.rs index e5fdcb523..84ee755b7 100644 --- a/src/cargo/core/compiler/context/unit_dependencies.rs +++ b/src/cargo/core/compiler/context/unit_dependencies.rs @@ -52,6 +52,12 @@ fn deps_of<'a, 'b, 'cfg>( deps: &'b mut HashMap, Vec>>, profile_for: ProfileFor, ) -> CargoResult<&'b [Unit<'a>]> { + // Currently the `deps` map does not include `profile_for`. This should + // be safe for now. `TestDependency` only exists to clear the `panic` + // flag, and you'll never ask for a `unit` with `panic` set as a + // `TestDependency`. `CustomBuild` should also be fine since if the + // requested unit's settings are the same as `Any`, `CustomBuild` can't + // affect anything else in the hierarchy. if !deps.contains_key(unit) { let unit_deps = compute_deps(unit, cx, deps, profile_for)?; let to_insert: Vec<_> = unit_deps.iter().map(|&(unit, _)| unit).collect(); -- 2.30.2