Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upExpose span locations on stable #166
Conversation
dtolnay
referenced this pull request
Jan 28, 2019
Closed
Make span location information available through a feature #165
mitsuhiko
suggested changes
Jan 28, 2019
src/fallback.rs Outdated
This comment was marked as resolved.
This comment was marked as resolved.
mitsuhiko
commented
Jan 28, 2019
|
Currently fails like this with the feature enabled:
|
dtolnay
force-pushed the
dtolnay:location
branch
from
f24566c
to
383649a
Jan 28, 2019
This comment has been minimized.
This comment has been minimized.
mitsuhiko
commented
Jan 28, 2019
|
Can confirm this works! |
dtolnay
added
the
wip
label
Jan 28, 2019
This comment has been minimized.
This comment has been minimized.
|
Tagging wip because this needs tests. Does not work when I tried it: use proc_macro2::TokenTree;
fn main() {
let sp = syn::parse_str::<TokenTree>("testing").unwrap().span();
println!("start line={} column={}", sp.start().line, sp.start().column);
println!("end line={} column={}", sp.end().line, sp.end().column);
}start line=1 column=0
end line=1 column=0I am not going to be able to get to this today. @mitsuhiko could you investigate? |
This comment has been minimized.
This comment has been minimized.
mitsuhiko
commented
Jan 28, 2019
|
Yes, will investigate. Information seems absent indeed. |
This comment has been minimized.
This comment has been minimized.
|
If we're going to offer this in a published stable version then I think we can probably go ahead and do this without a feature. The I think that may also simplify the cfg story here (which I am always confused by every time I look at this!). That way outside of a proc-macro context you always have accurate information, but in a proc-macro context you'll only have accurate information if a nightly feature toggle is enabled. |
This comment has been minimized.
This comment has been minimized.
|
I kept a feature because last time I checked there was a big performance hit for Span going from 0 bytes to 8 bytes. There are a lot of spans in the syntax tree... |
This comment has been minimized.
This comment has been minimized.
|
Ah ok that makes sense to me, and in that case seems fine to document as such as to why it's a feature |
This comment has been minimized.
This comment has been minimized.
|
Hmm, I wonder if a span interning system could compress span sizes down even more, and if that would be helpful here. |
dtolnay
force-pushed the
dtolnay:location
branch
from
383649a
to
6078302
Jan 28, 2019
This comment has been minimized.
This comment has been minimized.
|
I added a note in build.rs about the performance hit. |
dtolnay
force-pushed the
dtolnay:location
branch
from
6078302
to
f7b7f73
Jan 28, 2019
dtolnay
removed
the
wip
label
Jan 28, 2019
dtolnay
force-pushed the
dtolnay:location
branch
from
f7b7f73
to
3b1f7d2
Jan 28, 2019
This comment has been minimized.
This comment has been minimized.
|
I think this works now. I filed #167 to follow up on mitigating the performance impact. |
This comment has been minimized.
This comment has been minimized.
mitsuhiko
commented
Jan 31, 2019
|
Is this blocked on #167 or is it mergeable as such? |
This comment has been minimized.
This comment has been minimized.
|
I don't think this needs to block on the performance work, because the increase in size of Span only happens if you opt in to the new feature. Thanks for the reminder! |
dtolnay
merged commit 2b01a3f
into
alexcrichton:master
Jan 31, 2019
dtolnay
deleted the
dtolnay:location
branch
Jan 31, 2019
This comment has been minimized.
This comment has been minimized.
|
Published in 0.4.27. |
dtolnay commentedJan 28, 2019
In the way suggested by #165 (comment).