Proc-Macro Dependency with Dependencies

[daxpedda]

I noticed that while proc-macro dependencies in dependencies are supported, a direct dependency being a proc-macro fails on finding its dependencies.

Example:

/Cargo.toml:

[workspace]
members = ["a", "b"]

/a/Cargo.toml:

[package]
edition = "2021"
name = "a"
version = "0.0.0"

[lib]
proc-macro = true

[dependencies]
b = { version = "0.0.0", path = "../b" }

[[test]]
harness = false
name = "ui"

/a/tests/ui.rs:

use ui_test::color_eyre::Result;
use ui_test::dependencies::DependencyBuilder;
use ui_test::Config;

fn main() -> Result<()> {
	let mut config = Config::rustc("tests/ui");
	config
		.comment_defaults
		.base()
		.set_custom("dependencies", DependencyBuilder::default());

	ui_test::run_tests(config)
}

/b/Cargo.toml

[package]
edition = "2021"
name = "b"
version = "0.0.0"

This fails with:

thread '<unnamed>' (123) panicked at /.../ui_test-0.30.4/src/dependencies.rs:324:29:
no artifact found for `b`(`path+file:///b#0.0.0`):`
{"reason":"compiler-artifact","package_id":"path+file:///b#0.0.0","manifest_path":"/b/Cargo.toml","target":{"kind":["lib"],"crate_types":["lib"],"name":"b","src_path":"/b/src/lib.rs","edition":"2021","doc":true,"doctest":true,"test":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/a/target/ui/0/debug/deps/libb-123.rlib","/a/target/ui/0/debug/deps/libb-123.rmeta"],"executable":null,"fresh":true}
{"reason":"compiler-artifact","package_id":"path+file:///a#0.0.0","manifest_path":"/a/Cargo.toml","target":{"kind":["proc-macro"],"crate_types":["proc-macro"],"name":"a","src_path":"/a/src/lib.rs","edition":"2021","doc":true,"doctest":true,"test":true},"profile":{"opt_level":"0","debuginfo":2,"debug_assertions":true,"overflow_checks":true,"test":false},"features":[],"filenames":["/a/target/ui/0/debug/liba.so"],"executable":null,"fresh":false}
{"reason":"build-finished","success":true}

Simply removing proc-macro = true from crate a makes everything work.
Removing the dependency on crate b also makes everything work.

[daxpedda]

The issue happens here:

ui_test/src/dependencies.rs

Lines 159 to 202 in 502eaf7

	if let Some(target) = &config.target {
	// We passed `--target` to cargo. This means host and target dependencies will
	// end up in different folders, which we can use to distinguish them! We only
	// want to add target dependencies, and their folder will look something like:
	// ```
	// .../target/ui_test/0/x86_64-unknown-linux-gnu/debug/deps/libquote-031e34ffdd9a346e.rlib
	// ```
	// So we skip all artifacts where, popping the top 3 components, we do not see
	// the target. However, we do *not* do this for proc-macro crates as those will
	// only ever show up as host crates anyway.
	let skip_crate = 'skip_crate: {
	let Some(filename) = artifact.filenames.first() else {
	// No filename? No idea what this is...
	break 'skip_crate false;
	};
	if artifact
	.target
	.crate_types
	.iter()
	.any(|ctype| ctype == "proc-macro")
	{
	// Proc macros are only ever built for the host, don't skip that.
	break 'skip_crate false;
	}
	// Not a proc macro, let's check the path.
	let mut filename = filename.to_path_buf();
	filename.pop();
	// We also validate that the path looks as expected before we actually skip.
	if filename.file_name().unwrap_or_default() != "deps" {
	// Either cargo changed or this is a weird corner case, let's just
	// keep it.
	break 'skip_crate false;
	}
	filename.pop();
	// This is the profile name, `debug` or `release` or so.
	filename.pop();
	// And now this should be the target name.
	// If not, skip it.
	filename.file_name().unwrap_or_default() != target
	};
	if skip_crate {
	continue;
	}
	}

The issue seems to be that the artifact of the dependency of the proc-macro doesn't have a target triple in its path:
/a/target/ui/0/debug/deps/libb-123.rlib

The dependency gets skipped if all of the following is true:

• We have a filename.
• Its not a proc-macro crate.
• The file is in a deps folder.
• The file doesn't have the target triple in its path.

I've no idea why it doesn't have a target triple in its path. But I'm using the regular stable compiler on Linux, so nothing special going on here. Something seems different if its a dependency of a proc-macro.

Let me know if you have any idea how to address this and I'm happy to make the PR.