-
-
Notifications
You must be signed in to change notification settings - Fork 117
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
Empty versions of Span::start
and Span::end
returned on stable compiler
#237
Comments
I got a bit excited that this was available in stable because it would make hacks like It makes total sense as I had no idea how proc_macro2 was going to do this in stable if it was to have parity with proc_macro. But a disclaimer in the method docs about it being mocked would be good. 😄 |
Helps dtolnay#237 **What it does:** - Adds warning of methods `Span::start` and `Span::end` methods
Helps dtolnay#237 **What it does:** - Adds warning on methods `Span::start` and `Span::end` methods
Helps #237 **What it does:** - Adds warning on methods `Span::start` and `Span::end` methods
Introduced in #166.
With a stable compiler with the
span-locations
feature enabled, we now have a situation whereSpan::start
andSpan::end
reports mocked values (LineColumn { line: 0, column: 0 }
) (see code). This is understandable since the underlying function in the compiler is nightly-only behind a feature flag (proc_macro_span
and rust-lang/rust#54725), but it was somewhat surprising to me thatproc_macro2
falls back to reporting fake spans.The surprising behavior can be mitigated by documenting in
Span::start
andSpan::end
that their values will be mocked on stable compilers until the relevant features are stabilized. But also, downstream projects which for whatever reason rely on accurate spans don't have a great avenue for erroring at compile time in case the compiler version is too old to support them*.*: Span::unwrap could in principle be used, but would mean that the code no longer can run outside of a proc_macro.
This is also a potential future compatibility hazard if
start
andend
were to be broken out into a separate feature flag (as discussed here) to ease the road towards future stabilization. So I'm tying it together here since I'm looking into if and how it can be done.The text was updated successfully, but these errors were encountered: