Closed
Description
Hi,
I have a crate that CI fails for all the tests on the latest nightly with the following output:
--> refinery/tests/mod_migrations/mod.rs:2:5
|
2 | refinery::include_migration_mods!("./tests/mod_migrations");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: to create the module `V2__add_cars_table`, create file "refinery/tests/mod_migrations/migrations/V2__add_cars_table.rs"
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0583]: file not found for module `V1__initial`
--> refinery/tests/mod_migrations/mod.rs:2:5
|
2 | refinery::include_migration_mods!("./tests/mod_migrations");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: to create the module `V1__initial`, create file "refinery/tests/mod_migrations/migrations/V1__initial.rs"
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0583]: file not found for module `V4__add_year_to_motos_table`
--> refinery/tests/mod_migrations/mod.rs:2:5
|
2 | refinery::include_migration_mods!("./tests/mod_migrations");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: to create the module `V4__add_year_to_motos_table`, create file "refinery/tests/mod_migrations/migrations/V4__add_year_to_motos_table.rs"
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0583]: file not found for module `V3__add_brand_to_cars_table`
--> refinery/tests/mod_migrations/mod.rs:2:5
|
2 | refinery::include_migration_mods!("./tests/mod_migrations");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: to create the module `V3__add_brand_to_cars_table`, create file "refinery/tests/mod_migrations/migrations/V3__add_brand_to_cars_table.rs"
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0425]: cannot find function `migration` in module `V2__add_cars_table`
--> refinery/tests/mod_migrations/mod.rs:2:5
|
2 | refinery::include_migration_mods!("./tests/mod_migrations");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `V2__add_cars_table`
|
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0425]: cannot find function `migration` in module `V1__initial`
--> refinery/tests/mod_migrations/mod.rs:2:5
|
2 | refinery::include_migration_mods!("./tests/mod_migrations");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `V1__initial`
|
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0425]: cannot find function `migration` in module `V4__add_year_to_motos_table`
--> refinery/tests/mod_migrations/mod.rs:2:5
|
2 | refinery::include_migration_mods!("./tests/mod_migrations");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `V4__add_year_to_motos_table`
|
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
error[E0425]: cannot find function `migration` in module `V3__add_brand_to_cars_table`
--> refinery/tests/mod_migrations/mod.rs:2:5
|
2 | refinery::include_migration_mods!("./tests/mod_migrations");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `V3__add_brand_to_cars_table`
|
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)
the refered code is here and the macro used is defined here the same tests pass on stable channel.
If there is there is anything else that I can do to help, I am happy to contribute
thanks!
Metadata
Metadata
Assignees
Labels
Area: Compiler frontend (errors, parsing and HIR)Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)Category: This is a bug.Helping to "clean up" bugs with minimal examples and bisectionsHigh priorityRelevant to the compiler team, which will review and decide on the PR/issue.Performance or correctness regression from stable to nightly.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
jonas-schievink commentedon Mar 23, 2020
Which version are you on? Your "CI" link requires a login.
Probably a duplicate of #70185 and you need to wait for the nightly version to update.
spastorino commentedon Mar 25, 2020
@jxs can you try out if it works for you using
nightly-2020-03-22
or superior?spastorino commentedon Mar 25, 2020
pre-triage: assigning
P-high
just in case is not a dupe of #70185jonas-schievink commentedon Mar 25, 2020
Still an issue on rustc 1.44.0-nightly (02046a5 2020-03-24)
Centril commentedon Mar 25, 2020
Let's try to shrink the input into something more manageable for finding a fix / understanding the cause.
@rustbot ping cleanup
rustbot commentedon Mar 25, 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
16 remaining items
petrochenkov commentedon Apr 16, 2020
Looks like there's a minimized reproduction in #70314 (comment), so yes, I'll try to look at this during this or next weekend.
pnkfelix commentedon Apr 21, 2020
I have independently reduced the test input into something pretty small; small enough for me to cut and paste into this comment (I hope):
Click to see the files for pnkfelix's MCVE test input
pnkfelix commentedon Apr 21, 2020
My hypothesis is that something has changed in the metadata (spans/hygiene/etc) associated with
ident
(defined bylet ident = syn::Ident::new("V1__initial", proc_macro2::Span::call_site());
) when it occurs in the context of this macro invocation:In particular, in nightly-2020-03-19, it successfully resolves to the file stored at path refinery/tests/mod_migrations/V1__initial.rs; but in nightly-2020-03-20, it attempts to instead resolve to the path refinery/tests/mod_migrations/migrations/V1__initial.rs
I.e., it is not searching relative to the source file where the macro invocation appears. Instead, it is searching relative to the directory it expects to exist based on where in the module hierarchy that the macro invocation appears.
(This might actually be expected breakage; I'll need to review some of the discussions the language team was having around this team regarding the changes to expansion.)
pnkfelix commentedon Apr 21, 2020
Well I don't know if this breakage was expected; there were some discussions that seem at least tangentially related on PR #69838, such as #69838 (comment) that imply to me that we were not intending to change behavior in cases like this.
pnkfelix commentedon Apr 21, 2020
(also, I have confirmed via a local build that PR #69838 is indeed where this was injected. I have not yet dissected which aspect of that PR injected it though.)
pnkfelix commentedon Apr 24, 2020
I removed the E-needs-mcve label because I figured my demo above is pretty minimal. But I do note there is still more reduction possible: Namely, finding ways to restructure the macro definition so that it doesn't rely on external crates like
quote
andsyn
. However, I also suspect there isn't that much value in working on reduction in that direction, so I am leaving the E-needs-mcve label off of the issue.pnkfelix commentedon Apr 24, 2020
I also did a
git bisect
within the commit series within PR #69838, and that identified 83a757a as the first bad commit.petrochenkov commentedon Apr 25, 2020
This change is pretty much by design, it's the same change that fixed #58818, for example.
Previously parser sometimes inferred the "current directory" from spans:
https://github.com/rust-lang/rust/pull/69838/files#diff-da8eccd50b4abe306482925ebf6e6a90L392-L402
, which was a really hacky and unreliable thing, incompatible with #49511 in particular.
pnkfelix commentedon Apr 27, 2020
Do we have documentation somewhere of the semantics that we've settled on, and/or the change itself suitable for e.g. the release notes?
petrochenkov commentedon May 3, 2020
I don't think the span-based directory inference was ever documented anywhere.
The current behavior should match what is written in the reference (https://doc.rust-lang.org/stable/reference/items/modules.html), I'm not sure there's a more detailed description. (Perhaps in some of the PRs implementing 2018 edition module directories? I don't know.)
jxs commentedon May 9, 2020
thank you all for the support! ❤️
i finally took some time, and with the of the demo above was able to understand the problem, I fixed it by resorting to the default case which still works: having the macro being called on the top level of a mod file.