How does feature unification work in crates universe?

[rbtcollins]

This was prompted by a discussion about the use of features in workspace.dependencies, with Bazel. I looked for docs, but was not smart enough to find them.

I realise that in Bazel's model each named target needs to be hermetic, not influenced by its downstream dependencies, and thats fine - my goal here is to understand how crates-universe works in order to figure out how to get what we want (or perhaps crate a feature request).

Do we get all the possible features unified?
Or two targets for each crate, one for dev and one for prod, but features unified all deps within that variant?
Or N targets for each create, for each unique combination of unification target would have done given build/test on each binary?

--scenario--

Given two crates in a workspace, A and B, both using a third (lets say crates.io sourced) crate in cargo, A can set the features to be used when building B and C:

When building all packages, cargo unifies the features for C from A, and for C from B.

When building just A, the ones from B are not included. This is surprising to folk, because sudden rebuilds of a bunch of dependencies are common.

Now, when we lift dependency versions to a workspace, there's a third source of features.

What goes crates universe use when selecting the features to build a universe crate with? The workspace features? Unified features from A and B's default-features (and anything any transitive dep happens to enable?) Something else?

And of course then there is an extra source of features - A and B's dev dependencies.

A classic case of this is tokio's feature test-utils which enables apis that control time - https://docs.rs/tokio/latest/tokio/time/fn.pause.html - something that we'd really rather not have accidentally slip into a production build.

[rbtcollins]

I think the answer is that everything is unified with no distinction, meaning that we have to manage the separate configurations with renames:

tokio = { version = "1.34.0", features = ["macros", "sync", "time", "rt"] }
tokio_test = { version = "1.34.0", features = ["macros", "sync", "time", "rt", "test-util"], package="tokio"}

And then build the module under test twice, once as normal, and once with out the deps helper macro, and instead precisely listed dependencies, and an alias mapping tokio_test back to tokio.

Is this right? (Note that I'm not looking to judge the ergonomics - at this point I just want to know whether my understanding of rules_rust's behaviour is correct).

[illicitonion]

This is the code which selects features for each crate:

rules_rust/crate_universe/src/metadata.rs

Lines 456 to 560 in 90e4505

	/// Computes the set of enabled features for each target triplet for each crate.
	#[tracing::instrument(name = "FeatureGenerator::generate", skip_all)]
	pub fn generate(
	&self,
	manifest_path: &Path,
	target_triples: &BTreeSet<TargetTriple>,
	) -> Result<BTreeMap<CrateId, Select<BTreeSet<String>>>> {
	debug!(
	"Generating features for manifest {}",
	manifest_path.display()
	);
	let manifest_dir = manifest_path.parent().unwrap();
	let mut target_triple_to_child = BTreeMap::new();
	debug!("Spawning processes for {:?}", target_triples);
	for target_triple in target_triples {
	// We use `cargo tree` here because `cargo metadata` doesn't report
	// back target-specific features (enabled with `resolver = "2"`).
	// This is unfortunately a bit of a hack. See:
	// - https://github.com/rust-lang/cargo/issues/9863
	// - https://github.com/bazelbuild/rules_rust/issues/1662
	let output = self
	.cargo_bin
	.command()?
	.current_dir(manifest_dir)
	.arg("tree")
	.arg("--locked")
	.arg("--manifest-path")
	.arg(manifest_path)
	.arg("--prefix=none")
	// https://doc.rust-lang.org/cargo/commands/cargo-tree.html#tree-formatting-options
	.arg("--format=|{p}|{f}|")
	.arg("--color=never")
	.arg("--workspace")
	.arg("--target")
	.arg(target_triple.to_cargo())
	.env("RUSTC", &self.rustc_bin)
	.stdout(std::process::Stdio::piped())
	.stderr(std::process::Stdio::piped())
	.spawn()
	.with_context(|| {
	format!(
	"Error spawning cargo in child process to compute features for target '{}', manifest path '{}'",
	target_triple,
	manifest_path.display()
	)
	})?;
	target_triple_to_child.insert(target_triple, output);
	}
	let mut crate_features =
	BTreeMap::<CrateId, BTreeMap<TargetTriple, BTreeSet<String>>>::new();
	for (target_triple, child) in target_triple_to_child.into_iter() {
	let output = child
	.wait_with_output()
	.with_context(|| {
	format!(
	"Error running cargo in child process to compute features for target '{}', manifest path '{}'",
	target_triple,
	manifest_path.display()
	)
	})?;
	if !output.status.success() {
	eprintln!("{}", String::from_utf8_lossy(&output.stdout));
	eprintln!("{}", String::from_utf8_lossy(&output.stderr));
	bail!(format!("Failed to run cargo tree: {}", output.status))
	}
	debug!("Process complete for {}", target_triple);
	for (crate_id, features) in
	parse_features_from_cargo_tree_output(output.stdout.lines())?
	{
	debug!("\tFor {} features were: {:?}", crate_id, features);
	crate_features
	.entry(crate_id)
	.or_default()
	.insert(target_triple.clone(), features);
	}
	}
	let mut result = BTreeMap::<CrateId, Select<BTreeSet<String>>>::new();
	for (crate_id, features) in crate_features.into_iter() {
	let common = features
	.iter()
	.fold(
	None,
	|common: Option<BTreeSet<String>>, (_, features)| match common {
	Some(common) => Some(common.intersection(features).cloned().collect()),
	None => Some(features.clone()),
	},
	)
	.unwrap_or_default();
	let mut select: Select<BTreeSet<String>> = Select::default();
	for (target_triple, fs) in features {
	if fs != common {
	for f in fs {
	select.insert(f, Some(target_triple.to_bazel()));
	}
	}
	}
	for f in common {
	select.insert(f, None);
	}
	result.insert(crate_id, select);
	}
	Ok(result)
	}
	}

I'm not sure what cargo tree does for different kinds of dependencies, but we do whatever it does based on those flags.