Document module resolution inside include!#158001
Conversation
A `mod` declaration in an included file is resolved relative to the included file's directory, not the directory of the file that contains the `include!` invocation. That trips people up, so spell it out in the macro docs and point at the `#[path]` attribute for overriding it.
rustbot
added
S-waiting-on-review
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aapoalas (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
Why was this reviewer chosen?The reviewer was selected based on:
|
|
r? lang Perhaps best that lang blesses this as it's more of a language primitive just exposed from the std. |
|
This behavior is actually accidental, but it's probably too late to fix it at this point. Upd: ah, the tracking issue actually talks about this too - #149810 (comment). |
rustbot
removed
the
S-waiting-on-review
5 participants
include! resolves
moddeclarations in the included file relative to that file's directory, not the file holding theinclude!call. The docs never said so and people hit it, for instance with build-script output that containsmod. This adds a short note and points at#[path]for overriding it.Fixes #149810