bkchr / proc-macro-crate

`$crate` in procedural macros.
Apache License 2.0
65 stars 17 forks source link

Support workspace dependencies in the root crate of a workspace #46

Closed Waridley closed 10 months ago

Waridley commented 11 months ago

The root of a workspace is itself a crate, and thus its manifest can contain both [dependencies] and [workspace.dependencies]. Without this fix I need to add a superfluous package key to my renamed dependency to get proc-macro-crate to find it, but that causes Cargo to warn about an unused manifest key.

[workspace.dependencies]
bar = { package = "foo", version = "1.2.3" }

[dependencies]
bar = { package = "foo", workspace = true }
#       ^^^^^^^^^^^^^^^ unused manifest key

Also, renaming workspace dependencies seems to only be possible within the [workspace.dependencies] table. If I try this:

[workspace.dependencies]
foo = "1.2.3"

[dependencies]
bar = { package = "foo", workspace = true }

I get:

error: failed to parse manifest at ./Cargo.toml

Caused by: error inheriting bar from workspace root manifest's workspace.dependencies.bar

Caused by: dependency.bar was not found in workspace.dependencies

So it should check for dep_name rather than pkg_name in the workspace dependencies.

Waridley commented 11 months ago

This actually breaks the workspace_deps_twice_renamed test, but that's because I intentionally changed it due to lack of support in Cargo. As of right now, if proc-macro-crate accepted twice-renamed dependencies in Cargo.toml, it would not actually work within the crate that used the proc macro.

I found the relevant issue in Cargo's repo: https://github.com/rust-lang/cargo/issues/12546

It doesn't look like the feature is likely to be implemented any time soon, but I could make it work in case it does happen to be implemented in the future if you want. But unless you say otherwise, I will remove the failing test and add one for workspace-root crates instead for now.

bkchr commented 10 months ago

Ty for the work!