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

Duplicate crate macros failing to differentiate #71259

Open
LucioFranco opened this issue Apr 17, 2020 · 7 comments
Open

Duplicate crate macros failing to differentiate #71259

LucioFranco opened this issue Apr 17, 2020 · 7 comments
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@LucioFranco
Copy link
Member

Here is a reproduction:

https://github.com/LucioFranco/rustc-duplicate-macro-bug/

I've added comments on how to trigger the bug. But it looks like if we have one crate but two versions imported into the same project. Aka using cargo's rename feature, then rust picks up that if we use one of the macros that the other one even if its from a different version is the same. Commenting out the tower01 assert_request_eq allows the second one to compile properly. If its not commented out the tower03 version will fail to compile because it is attempting to use the tower01 version which doesn't await the inner future.

Meta

This happens currently on rustc 1.42.0 (b8cedc004 2020-03-09) but not on a newer nightly cargo 1.44.0-nightly (390e8f245 2020-04-07). So this has probably been fixed but I couldn't find any issue for this specific problem.

@LucioFranco LucioFranco added the C-bug Category: This is a bug. label Apr 17, 2020
@LucioFranco
Copy link
Member Author

Since, this has been fixed on nightly, I assume we can close it. I thought I'd open for reference reasons.

@jonas-schievink jonas-schievink added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-resolve Area: Name resolution E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 17, 2020
@jonas-schievink
Copy link
Contributor

Sounds like something @petrochenkov might know about

@petrochenkov petrochenkov self-assigned this Apr 17, 2020
@petrochenkov
Copy link
Contributor

No idea how this happened and I don't remember fixing anything similar.

This look like a serious bug, it would be great to bisect this to find out what made it disappear.
Perhaps it was just masked and not really fixed.

@petrochenkov petrochenkov added E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc ICEBreaker-Cleanup-Crew Helping to "clean up" bugs with minimal examples and bisections labels Apr 17, 2020
@petrochenkov
Copy link
Contributor

@rustbot ping bisect

@rustbot
Copy link
Collaborator

rustbot commented Apr 17, 2020

Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @AminArria @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @jakevossen5 @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke

@robjtede
Copy link
Contributor

robjtede commented Apr 17, 2020

bisect-rustc points to 1581278, PR #66364

@petrochenkov
Copy link
Contributor

@robjtede
Thanks!

Before #66364 in this line

https://github.com/rust-lang/rust/pull/66364/files#diff-2b18e583c8286c5f266dcc0aea004e91L426

two assert_request_eq macros had the same source_name so the second macro hit the cache inside new_source_file and returned the string for the first macro instead of its own.

So #66364 indeed fixed the issue and not masked it.

The condition for the test is that two library crates should have the same name and should export macros with the same name.
Then any crate using these two macros together will hit the issue.

@petrochenkov petrochenkov removed their assignment Apr 18, 2020
@petrochenkov petrochenkov removed E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc ICEBreaker-Cleanup-Crew Helping to "clean up" bugs with minimal examples and bisections A-resolve Area: Name resolution labels Apr 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants