Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v2 resolver: a proc macro being specified with the key "proc_macro" vs "proc-macro" causes different results #8315

Closed
sunshowers opened this issue Jun 3, 2020 · 2 comments · Fixed by #8319
Labels
C-bug Category: bug

Comments

@sunshowers
Copy link
Contributor

sunshowers commented Jun 3, 2020

Problem

A proc-macro is usually specified as:

[lib]
proc-macro = true

but can also be specified as

[lib]
proc_macro = true

The first one appears to be fine, but the second one appears to cause some strange issues with the v2 resolver.

Steps

Test workspace is here.

git clone https://github.com/facebookincubator/cargo-guppy && cd cargo-guppy
git checkout d5781f069ea57b2d0ec80fddb410978eb1b0f2d5
cd fixtures/workspace/inside-outside/workspace
cargo clean && cargo +nightly build -Zfeatures=all --verbose 2>&1 | grep -F -- '--crate-name internal_macro'

You'll see one line:

     Running `rustc --crate-name internal_macro --edition=2018 internal-macro/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type
proc-macro --emit=dep-info,link -C prefer-dynamic -Cembed-bitcode=no -C debuginfo=2 --cfg 'feature="internal-normal-feature"' --cfg 'feature="main-build-feature"' [...]`

Now edit internal-macro/Cargo.toml and change proc-macro = true to proc_macro = true.

Afterwards:

$ cargo clean && cargo +nightly build -Zfeatures=all --verbose 2>&1 | grep -F -- '--crate-name internal_macro'
     Running `rustc --crate-name internal_macro --edition=2018 internal-macro/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type
proc-macro --emit=dep-info,link -C prefer-dynamic -Cembed-bitcode=no -C debuginfo=2 --cfg 'feature="internal-normal-feature"' --cfg 'feature="main-build-feature"' [...]
     Running `rustc --crate-name internal_macro --edition=2018 internal-macro/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type
proc-macro --emit=dep-info,link -C prefer-dynamic -Cembed-bitcode=no -C debuginfo=2 --cfg 'feature="internal-normal-feature"' [...]

Possible Solution(s)

I guess you could either treat both the same or warn/error on specifying it as proc_macro.

Notes

Output of cargo version:

cargo 1.45.0-nightly (9fcb8c1d2 2020-05-25)

cc @ehuss again I guess!

@sunshowers sunshowers added the C-bug Category: bug label Jun 3, 2020
@sunshowers
Copy link
Contributor Author

We addressed this in the libra repo in diem/diem#4212

@alexcrichton
Copy link
Member

What a bizarre bug, wow thanks for the detailed report, And wow I can't believe this was found!

bors added a commit that referenced this issue Jun 3, 2020
Fix an accidental raw access of field

The manifest has a few different ways of specifying whether a crate is a
procedural macro, and there's a `TomlTarget::proc_macro()` method to
unify these various lines. Unfortunately though we had a bug where one
location forgot to call the method and read the raw field! This led to
surprising behavior where the different ways to specify a proc macro
would have subtly different changes in behavior. The fix here in this PR
is to ensure that we access the property always via the method.

Closes #8315
@bors bors closed this as completed in 442f629 Jun 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants