Unconsistent dwarf information between 1.70 and 1.71

[godzie44]

Code

I tried this code:

fn main() {
    let var_a = 1;
    let var_b = 2; // <- stop here
    let var_c = 3;
}

Then run this with rust-gdb:

> b test.rs:3
> r
> info locals

for rust 1.70 output is correct:

var_a = 1

for rust 1.71 output contains uninitialized variable:

var_b = 0
var_a = 1

Lets see whats changed in dwarf, i dump'd 1.70 and 1.71 versions and check difference.

First for 1.70, lexical block of var_b:

< 4><0x00000063>          DW_TAG_lexical_block
                            DW_AT_low_pc                0x00071010
                            DW_AT_high_pc               <offset-from-lowpc> 8 <highpc: 0x00071018>

And line number info for line 3:

0x00071008  [   3,17] NS

So it's ok, pc of lexical block for var_b greater then pc of line 3 start, and debugger doesnt show var_b.

Now for 1.71. Lexical block of var_b:

< 4><0x00000063>          DW_TAG_lexical_block
                            DW_AT_low_pc                0x0006dd28
                            DW_AT_high_pc               <offset-from-lowpc> 16 <highpc: 0x0006dd38>

And line number info for line 3:

0x0006dd28  [   3, 9] NS

In dwarf generated by rustc 1.71 pc of var_b lexical block are equal to pc of line 3, that's why we see an uninitialized variable.

Version it worked on

Rust 1.70

Version with regression

rustc 1.71.0 (8ede3aa 2023-07-12)
binary: rustc
commit-hash: 8ede3aa
commit-date: 2023-07-12
host: x86_64-unknown-linux-gnu
release: 1.71.0
LLVM version: 16.0.5

[Jules-Bertholet]

@rustbot label -regression-untriaged +regression-from-stable-to-stable

[saethlin]

The previous behavior can be reproduced by adding -Zmir-enable-passes=-SimplifyLocals-final. I don't really know what the exact cause of this is, but it seems very likely this is related to MIR opts.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium +E-needs-bisection

[khuey]

********************************************************************************
Regression in nightly-2023-04-24
********************************************************************************

fetching https://static.rust-lang.org/dist/2023-04-23/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2023-04-23: 40 B / 40 B [===================================================================] 100.00 % 562.29 KB/s converted 2023-04-23 to b628260df0587ae559253d8640ecb8738d3de613
fetching https://static.rust-lang.org/dist/2023-04-24/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2023-04-24: 40 B / 40 B [=====================================================================] 100.00 % 1.25 MB/s converted 2023-04-24 to 7f94b314cead7059a71a265a8b64905ef2511796
looking for regression commit between 2023-04-23 and 2023-04-24
fetching (via remote github) commits from max(b628260df0587ae559253d8640ecb8738d3de613, 2023-04-21) to 7f94b314cead7059a71a265a8b64905ef2511796
ending github query because we found starting sha: b628260df0587ae559253d8640ecb8738d3de613
get_commits_between returning commits, len: 9
  commit[0] 2023-04-22: Auto merge of #110523 - ecnelises:llvm_isa_fix, r=cuviper
  commit[1] 2023-04-22: Auto merge of #110703 - clubby789:synstructure-remove, r=Nilstrieb
  commit[2] 2023-04-23: Auto merge of #110186 - Nilstrieb:update-time, r=Mark-Simulacrum
  commit[3] 2023-04-23: Auto merge of #110655 - ChrisDenton:read-to-end, r=joshtriplett
  commit[4] 2023-04-23: Auto merge of #110497 - cjgillot:span-ctxt, r=b-naber
  commit[5] 2023-04-23: Auto merge of #107404 - cjgillot:const-debuginfo, r=oli-obk
  commit[6] 2023-04-23: Auto merge of #108118 - oli-obk:lazy_typeck, r=cjgillot
  commit[7] 2023-04-23: Auto merge of #110705 - saethlin:ignore-locals-cost, r=cjgillot
  commit[8] 2023-04-23: Auto merge of #110281 - ozkanonur:multiarch-compatible-sysroot-finding, r=jackh726
ERROR: no CI builds available between b628260df0587ae559253d8640ecb8738d3de613 and 7f94b314cead7059a71a265a8b64905ef2511796 within last 167 days

[khuey]

Continuing manually

4e8b642646f4e36ad23313d5ecf3332adb3e6f21 is the first bad commit
commit 4e8b642646f4e36ad23313d5ecf3332adb3e6f21
Author: Wesley Wiser <wesleywiser@microsoft.com>
Date:   Fri Oct 28 15:01:05 2022 -0400

    Turn on ConstDebugInfo pass.

[khuey]

Disabling the SingleUseConsts pass (which is the successor to ConstDebugInfo) does fix this.

[khuey]

@rustbot claim