Skip to content
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

debuginfo: Emit ZST struct debuginfo for unit type when CPP-like debuginfo is enabled #96316

Merged
merged 1 commit into from
Apr 23, 2022

Conversation

michaelwoerister
Copy link
Member

As already discovered in 24a728a, PDB does not play well with custom basic types. This PR extends to the fix to (): Instead of a custom basic type, we treat it like an empty tuple (i.e. it is described as a struct which happens to have no fields).

Before this change anything with a () in it would cause trouble, which is especially bad for *const () and *mut () which are often used for opaque pointers. E.g. the test case added in this PR would look like:

0:000>  dx _ref
Error: Unable to bind name '_ref'
0:000>  dx _ptr
Error: Unable to bind name '_ptr'
0:000>  dx _local
Error: Unable to bind name '_local'
0:000>  dx _field,d
_field,d         [Type: unit_type::_TypeContainingUnitField]
    [+0x008] _a               : 123 [Type: unsigned int]
    [+0x000] _unit            : Unexpected failure to dereference object
    [+0x000] _b               : 456 [Type: unsigned __int64]
0:000>  dx ((__int64 *)_ptr),x
Error: Unable to bind name '_ptr'

With the PR it produces the expected output:

0:000>  dx _ref
_ref             : 0x7ff6f2012230 : () [Type: tuple$<> *]
0:000>  dx _ptr
_ptr             : 0x7e8ddffc20 : () [Type: tuple$<> *]
0:000>  dx _local
_local           : () [Type: tuple$<>]
0:000>  dx _field,d
_field,d         [Type: unit_type::_TypeContainingUnitField]
    [+0x008] _a               : 123 [Type: unsigned int]
    [+0x000] _unit            : () [Type: tuple$<>]
    [+0x000] _b               : 456 [Type: unsigned __int64]
0:000>  dx ((__int64 *)_ptr),x
((__int64 *)_ptr),x : 0x7e8ddffc20 : 0x1122334455667788 [Type: __int64 *]

r? @wesleywiser

@michaelwoerister michaelwoerister added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Apr 22, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 22, 2022
…ginfo is enabled (instead of custom basic type).
@wesleywiser
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Apr 22, 2022

📌 Commit 8b23008 has been approved by wesleywiser

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 22, 2022
@bors
Copy link
Contributor

bors commented Apr 23, 2022

⌛ Testing commit 8b23008 with merge 09064a2...

@bors
Copy link
Contributor

bors commented Apr 23, 2022

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 09064a2 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 23, 2022
@bors bors merged commit 09064a2 into rust-lang:master Apr 23, 2022
@rustbot rustbot added this to the 1.62.0 milestone Apr 23, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (09064a2): comparison url.

Summary:

  • Primary benchmarks: 😿 relevant regression found
  • Secondary benchmarks: no relevant changes found
Regressions 😿
(primary)
Regressions 😿
(secondary)
Improvements 🎉
(primary)
Improvements 🎉
(secondary)
All 😿 🎉
(primary)
count1 1 0 0 0 1
mean2 0.4% N/A N/A N/A 0.4%
max 0.4% N/A N/A N/A 0.4%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. number of relevant changes

  2. the arithmetic mean of the percent change

@wesleywiser
Copy link
Member

The regressed benchmark is serde-derive-opt full which has been experiencing some fluctuations since at least 4/22. This PR doesn't touch any code relevant to that benchmark (changes target debuginfo on Windows and the test is release on Linux) so I'm confident this is not actually a regression.

@michaelwoerister michaelwoerister deleted the debuginfo-fix-unit-msvc branch April 25, 2022 07:37
@michaelwoerister
Copy link
Member Author

Agreed, I see no way how this PR could affect performance in a meaningful way, especially on Linux.
@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-bug Category: This is a bug. merged-by-bors This PR was explicitly merged by bors. perf-regression-triaged The performance regression has been triaged. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants