Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upHow to determine hygienic context for the "crate root" in absolute-by-default paths #50376
Comments
petrochenkov
added
the
A-macros-2.0
label
May 1, 2018
petrochenkov
referenced this issue
May 23, 2018
Closed
don't ask what edition we are in; ask what edition a span is in #50999
This comment has been minimized.
This comment has been minimized.
|
In #50999 I was pondering similar questions. It occurs to me that I don't entirely know what you are asking. Are you suggesting that, for In that case, the question is whether the path is interpreted as a Rust 2015 Absolute Path (relative to crate root) or a Rust 2018 Absolute Path (relative to crate universe; i.e., begins with a crate). I feel like this decision should be made based on the span of the first segment of the path. This is because the later segments ( macro_rules! m {
($x:ident) => {
{
use $x::bar;
bar();
}
}
}then if |
This comment has been minimized.
This comment has been minimized.
|
This behavior I expect from your example is as follows (note in particular that the source of the macro m() {
use a::b::c; // "def-site" as `a` appears in `def-site`
use a::$b; // def-site
use ::$a; // XXX interesting example, see below
use $a; // global path, but call-site determines relative to what
$use_passed_from_the_outside a::b::c; // def-site
$use_passed_from_the_outside $a; // same as `use $a`
}However, one interesting example is |
nikomatsakis
referenced this issue
May 30, 2018
Open
How to determine hygienic context for "non-atomic" code fragments #50122
This comment has been minimized.
This comment has been minimized.
Edition hygiene wasn't implemented when this issue was created, so I meant "what crate the root refers to", i.e. // crate a;
macro m {
use x::y::z;
}
// crate b;
m!(); // crate_a::x::y::z or crate_b::x::y::z?but the "crate root or universe" decision should be equivalent. |
This comment has been minimized.
This comment has been minimized.
|
Context of the first segment looks like a quite reasonable choice. |
This was referenced Jul 30, 2018
XAMPPRocky
added
C-enhancement
T-compiler
labels
Oct 2, 2018
petrochenkov
referenced this issue
Nov 19, 2018
Merged
[beta] resolve: Implement edition hygiene for imports and absolute paths #56053
bors
added a commit
that referenced
this issue
Nov 19, 2018
bors
added a commit
that referenced
this issue
Nov 19, 2018
bors
added a commit
that referenced
this issue
Nov 25, 2018
bors
added a commit
that referenced
this issue
Nov 26, 2018
This comment has been minimized.
This comment has been minimized.
|
Closed by #56053 |
petrochenkov commentedMay 1, 2018
Procedural macros generate tokens, but sometimes the information is kept not in tokens, but rather in the lack of them (compare with #50130).
In particular, paths in
useare resolved as absolute-by-default.Effectively, they have one extra segment added at the start during name resolution
The added root segment has its hygienic context and may be resolved at definition site (similarly to
use $crate::a::b::cfrom Macros 1.0) or at call site (similarly touse a::b::cin Macros 1.0).The question is how to determine this context, given that the root segment doesn't have its own explicit token?
Without its own token the crate root needs to inherit context from some other token that really exists (compare with #50122), but what token it should be exactly is a pretty tough choice.
I hope this issue doesn't affect Procedural Macros 1.2 (crossing my fingers).
Since all tokens generated and accepted by those macros are supposed to have the same call-site context, implicitly created crate roots will have the same call-site context anyway regardless of the token from which it's going to inherit it.