-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Make SourceMap
available for early debug-printing of Span
s
#72618
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.