-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Make SourceMap
available for early debug-printing of Span
s
#72618
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
cc #72669 |
…crum rustc_session: Cleanup session creation Noticed while reviewing rust-lang#72618.
…crum rustc_session: Cleanup session creation Noticed while reviewing rust-lang#72618.
This is a bit hacky, but we don't have much choice here, I guess. |
…crum rustc_session: Cleanup session creation Noticed while reviewing rust-lang#72618.
☔ The latest upstream changes (presumably #72794) made this pull request unmergeable. Please resolve the merge conflicts. |
a1149ff
to
d13b3f0
Compare
@petrochenkov: Rebased |
r=me after the cleanup (#72618 (comment)) and squashing commits. |
Actually I need to look at #72799 first. |
f836cf2
to
5909611
Compare
@bors r=petrochenkov |
📌 Commit 5909611eb1e9c1ac0207ec631dee8f51217fe1d8 has been approved by |
Normally, we debug-print `Spans` using the `SourceMap` retrieved from the global `TyCtxt`. However, we fall back to printing out the `Span`'s raw fields (instead of a file and line number) when we try to print a `Span` before a `TyCtxt` is available. This makes debugging early phases of the compile, such as parsing, much more difficult. This commit stores a `SourceMap` in `rustc_span::GlOBALS` as a fallback. When a `TyCtxt` is not available, we try to retrieve one from `GLOBALS` - only if this is not available do we fall back to the raw field output. I'm not sure how to write a test for this - however, this can be verified locally by setting `RUSTC_LOG="rustc_parse=debug"`, and verifying that the output contains filenames and line numbers.
5909611
to
717fd66
Compare
Forgot to run tidy @bors r- r=petrochenkov |
📌 Commit 717fd66 has been approved by |
…r=petrochenkov Make `SourceMap` available for early debug-printing of `Span`s Normally, we debug-print `Spans` using the `SourceMap` retrieved from the global `TyCtxt`. However, we fall back to printing out the `Span`'s raw fields (instead of a file and line number) when we try to print a `Span` before a `TyCtxt` is available. This makes debugging early phases of the compile, such as parsing, much more difficult. This commit stores a `SourceMap` in `rustc_span::GlOBALS` as a fallback. When a `TyCtxt` is not available, we try to retrieve one from `GLOBALS` - only if this is not available do we fall back to the raw field output. I'm not sure how to write a test for this - however, this can be verified locally by setting `RUSTC_LOG="rustc_parse=debug"`, and verifying that the output contains filenames and line numbers.
⌛ Testing commit 717fd66 with merge b6d3f6ea8c95f4d6d9d16f428c79df5e0342db1a... |
@bors retry yield |
⌛ Testing commit 717fd66 with merge c0c40d8ccada6a3ecbbbd09e4e88b7082588dbb8... |
@bors retry |
☀️ Test successful - checks-azure |
Currently, the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating, since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled, the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once rust-lang#72618 is merged, this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees, we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise, we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.
…rochenkov Add `-Z span-debug` to allow for easier debugging of proc macros Currently, the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating, since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled, the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once rust-lang#72618 is merged, this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees, we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise, we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.
…rochenkov Add `-Z span-debug` to allow for easier debugging of proc macros Currently, the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating, since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled, the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once rust-lang#72618 is merged, this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees, we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise, we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.
…rochenkov Add `-Z span-debug` to allow for easier debugging of proc macros Currently, the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating, since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled, the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once rust-lang#72618 is merged, this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees, we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise, we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.
Normally, we debug-print
Spans
using theSourceMap
retrieved fromthe global
TyCtxt
. However, we fall back to printing out theSpan
'sraw fields (instead of a file and line number) when we try to print a
Span
before aTyCtxt
is available. This makes debugging early phasesof the compile, such as parsing, much more difficult.
This commit stores a
SourceMap
inrustc_span::GlOBALS
as a fallback.When a
TyCtxt
is not available, we try to retrieve one fromGLOBALS
I'm not sure how to write a test for this - however, this can be
verified locally by setting
RUSTC_LOG="rustc_parse=debug"
, andverifying that the output contains filenames and line numbers.