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

Require type_map::stub callers to supply file information #104342

Merged
merged 25 commits into from
Dec 3, 2024

Conversation

mweber15
Copy link
Contributor

This change attaches file information (DIFile reference and line number) to struct debug info nodes.

Before:

; foo.ll
...
!5 = !DIFile(filename: "<unknown>", directory: "")
...
!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !5, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "4cb373851db92e732c4cb5651b886dd0")
...

After:

; foo.ll
...
!3 = !DIFile(filename: "foo.rs", directory: "/home/matt/src/rust98678", checksumkind: CSK_SHA1, checksum: "bcb9f08512c8f3b8181ef4726012bc6807bc9be4")
...
!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !3, line: 3, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "9e5968c7af39c148acb253912b7f409f")
...

Fixes #98678

r? @wesleywiser

@rustbot
Copy link
Collaborator

rustbot commented Nov 13, 2022

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @wesleywiser (or someone else) soon.

Please see the contribution instructions for more information.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 13, 2022
@mweber15 mweber15 force-pushed the add_file_location_to_more_types branch from 90c9907 to 12da85d Compare November 13, 2022 01:06
Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is on the right track, thanks for working on this!

@bors
Copy link
Contributor

bors commented Nov 21, 2022

☔ The latest upstream changes (presumably #102717) made this pull request unmergeable. Please resolve the merge conflicts.

@wesleywiser
Copy link
Member

I didn't expand this original test yet because I think it would be better to remove it instead

That seems fine to me! I think the important part we want to test is that we're generating the right LLVM IR. What it does with that depends on the target and some debuggers probably don't provide this data to the user anyway.

I'm not super confident that the DW_TAG_variant_part is pointing to the right place (it's currently referring to the enum definition itself)

I believe that is correct. In DWARF, you define a struct/class and a part of that which is the variant. For Rust enums, we model this as essentially a struct whose only member is a DW_TAG_variant_part so both the outer struct and the DW_TAG_variant_part should refer to the (Rust) enum definition.

The file_metadata_from_def_id function in particular feels clunkier than it probably should be.

You might be able to clean that up using the unstable let-chains feature. The other option would be to use some of the Option combinator methods to avoid the duplication of the unknown file/line items.

It feels like the places where I'm using Option to accept defs and DefIds would instead not be optional if this were complete.

While I think there are some places this is true, there will be a few kinds of types that cannot have locations emitted. For things like tuples or trait objects, there is no real definition location that can be meaningfully assigned. We'll always need to omit location data for those types.

Overall this looks good; nice work!

@wesleywiser
Copy link
Member

Oh, just as an FYI, the Windows and Linux targets differ in how they name and generate some kinds of debuginfo so we'll either need to adapt the codegen test to match both or have one codegen test for Linux and one for Windows (I think we do want to have both under test). If you don't have access to a Windows machine, I can pull that together when the PR is ready to merge.

@mweber15 mweber15 force-pushed the add_file_location_to_more_types branch from 93f52b3 to 3007f9f Compare November 24, 2022 03:34
@mweber15 mweber15 force-pushed the add_file_location_to_more_types branch from 877ec89 to 23b58af Compare December 7, 2022 02:22
@mweber15
Copy link
Contributor Author

mweber15 commented Dec 7, 2022

Oh, just as an FYI, the Windows and Linux targets differ in how they name and generate some kinds of debuginfo so we'll either need to adapt the codegen test to match both or have one codegen test for Linux and one for Windows (I think we do want to have both under test). If you don't have access to a Windows machine, I can pull that together when the PR is ready to merge.

Let me know what you think of how I've split up the tests when adding MSVC checks. The order in which debuginfo is produced varies between compilers so it seemed less fragile this way. The only alternative I could think of would be to use a lot of -DAG checks, but maybe there's a better way to do this.

You might be able to clean that up using the unstable let-chains feature. The other option would be to use some of the Option combinator methods to avoid the duplication of the unknown file/line items.

Seemed like a good fit for let-chains. Thank you for pointing that out. 👍

@bors
Copy link
Contributor

bors commented Dec 10, 2022

☔ The latest upstream changes (presumably #105525) made this pull request unmergeable. Please resolve the merge conflicts.

@wesleywiser
Copy link
Member

Overall this is looking really good! I think we're close to merging but it would be good to have a few more tests. In particular, I think async blocks and async functions should already be getting the correct line numbers because of the generator case but it would be good to have that under test. It looks like there is support for setting line numbers for fields in enum variants but that doesn't have a test case.

Can you also rebase over master? The test folder was recently moved to the top level so all new tests should be under test/ instead of the old src/test path.

@mweber15 mweber15 force-pushed the add_file_location_to_more_types branch from 23b58af to 9ceeedc Compare January 21, 2023 19:03
@mweber15
Copy link
Contributor Author

I recombined the two enum tests into one and used the examples you suggested. If I understand correctly, and please feel free to correct me, the difference between "native" and "cpp-like" enums is an implementation detail and not the direct result of how enums are expressed in Rust. That being the case I see no reason for having the two separate test cases that I did.

Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really great work! Thanks for all your effort on this!

@wesleywiser
Copy link
Member

Let's do a perf run real quick just to see if there is any impact to LLVM throughput.

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jan 27, 2023
@bors
Copy link
Contributor

bors commented Jan 27, 2023

⌛ Trying commit 2838ec9 with merge 2c129ea29c5d78e5d60baa102938ad79f286cf7b...

@bors
Copy link
Contributor

bors commented Jan 27, 2023

☀️ Try build successful - checks-actions
Build commit: 2c129ea29c5d78e5d60baa102938ad79f286cf7b (2c129ea29c5d78e5d60baa102938ad79f286cf7b)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (2c129ea29c5d78e5d60baa102938ad79f286cf7b): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
72.9% [0.2%, 465.5%] 29
Regressions ❌
(secondary)
1.2% [0.3%, 1.5%] 9
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 72.9% [0.2%, 465.5%] 29

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
24.3% [0.4%, 61.9%] 16
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.4% [-2.4%, -2.4%] 1
All ❌✅ (primary) 24.3% [0.4%, 61.9%] 16

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
134.9% [14.6%, 464.8%] 15
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 134.9% [14.6%, 464.8%] 15

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Jan 28, 2023
@wesleywiser
Copy link
Member

wesleywiser commented Jan 30, 2023

The perf results are very strange. It looks like performing code generation for more modules than before but it's unclear to me why that is. The worst results are in incremental patch benchmarks. Perhaps line numbers or something in the other module changed and we were able to ignore that before?

@SparrowLii
Copy link
Member

@bors r=wesleywiser

@bors
Copy link
Contributor

bors commented Dec 2, 2024

📌 Commit d151593 has been approved by wesleywiser

It is now in the queue for this repository.

@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 Dec 2, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 2, 2024
…ypes, r=wesleywiser

Require `type_map::stub` callers to supply file information

This change attaches file information (`DIFile` reference and line number) to struct debug info nodes.

Before:

```
; foo.ll
...
!5 = !DIFile(filename: "<unknown>", directory: "")
...
!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !5, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "4cb373851db92e732c4cb5651b886dd0")
...
```

After:

```
; foo.ll
...
!3 = !DIFile(filename: "foo.rs", directory: "/home/matt/src/rust98678", checksumkind: CSK_SHA1, checksum: "bcb9f08512c8f3b8181ef4726012bc6807bc9be4")
...
!16 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyType", scope: !2, file: !3, line: 3, size: 32, align: 32, elements: !17, templateParams: !19, identifier: "9e5968c7af39c148acb253912b7f409f")
...
```

Fixes rust-lang#98678

r? `@wesleywiser`
@bors
Copy link
Contributor

bors commented Dec 2, 2024

⌛ Testing commit d151593 with merge 18a6e9e...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Dec 2, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 2, 2024
@SparrowLii
Copy link
Member

SparrowLii commented Dec 2, 2024

Looks like i686-mingw still failed, do you have some clues now? @mweber15

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 2, 2024
@mweber15
Copy link
Contributor Author

mweber15 commented Dec 2, 2024

This particular failure seems to be due to the path separator, as I wrote the NONMSVC-DAG checks assuming they applied to Unix-like systems exclusively. I'm not sure what other issues might be lurking behind this one, though it might be the only problem. I don't personally use any MinGW toolchains so I don't have it readily available for testing.

Why wasn't this CI triggered automatically after I pushed? Finding out this is still a problem weeks after last touching this is incredibly frustrating. Was there something else I should have done to trigger this to run?

@SparrowLii
Copy link
Member

@Kobzol Do you konw if there is a command for the bot to test a certain target?

@mweber15
Copy link
Contributor Author

mweber15 commented Dec 3, 2024

I reproduced and fixed the problem using x86_64-pc-windows-gnu. I ran into a linker error trying to test i686-pc-windows-gnu, so I was not able to confirm that there aren't any other issues lurking with that toolchain. I will circle back to that if that CI still fails after this change, but hopefully it was only the separator issue.

@SparrowLii
Copy link
Member

@bors r=wesleywiser

@bors
Copy link
Contributor

bors commented Dec 3, 2024

📌 Commit e9fbb6f has been approved by wesleywiser

It is now in the queue for this repository.

@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 3, 2024
@Kobzol
Copy link
Contributor

Kobzol commented Dec 3, 2024

@Kobzol Do you konw if there is a command for the bot to test a certain target?

What do you mean by target here?

@SparrowLii
Copy link
Member

@Kobzol Do you konw if there is a command for the bot to test a certain target?

What do you mean by target here?

run CI for i686-mingw separately, for example

@Kobzol
Copy link
Contributor

Kobzol commented Dec 3, 2024

Yeah, you can do that with arbitrary try builds (https://rustc-dev-guide.rust-lang.org/tests/ci.html#try-builds - see the part with try-job).

@bors
Copy link
Contributor

bors commented Dec 3, 2024

⌛ Testing commit e9fbb6f with merge 8575f8f...

@bors
Copy link
Contributor

bors commented Dec 3, 2024

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 8575f8f to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 3, 2024
@bors bors merged commit 8575f8f into rust-lang:master Dec 3, 2024
7 checks passed
@rustbot rustbot added this to the 1.85.0 milestone Dec 3, 2024
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (8575f8f): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (secondary 4.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
4.1% [4.1%, 4.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 767.254s -> 766.323s (-0.12%)
Artifact size: 331.98 MiB -> 332.01 MiB (0.01%)

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.) merged-by-bors This PR was explicitly merged by bors. 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. WG-debugging Working group: Bad Rust debugging experiences
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Missing debug information about type definitions in PDB