After deduplication the block conceptually belongs to multiple locations
in the source. Although these blocks are unreachable, in rust-lang#123341 we did
come across a real side effect, an unreachable block that survives into
the compiled code can cause a debugger to set a breakpoint on the wrong
instruction. Erasing the source information ensures that a debugger will
never be misled into thinking that the unreachable block is worth setting
a breakpoint on, especially after rust-lang#128627.

Technically we don't need to erase the source information if all the
deduplicated blocks have identical source information, but tracking
that seems like more effort than it's worth.

…, r=nnethercote

When deduplicating unreachable blocks, erase the source information.

After deduplication the block conceptually belongs to multiple locations in the source. Although these blocks are unreachable, in rust-lang#123341 we did come across a real side effect, an unreachable block that survives into the compiled code can cause a debugger to set a breakpoint on the wrong instruction. Erasing the source information ensures that a debugger will never be misled into thinking that the unreachable block is worth setting a breakpoint on, especially after rust-lang#128627.

Technically we don't need to erase the source information if all the deduplicated blocks have identical source information, but tracking that seems like more effort than it's worth.

I'll let njn redirect this one too. r? `@nnethercote`

Rollup merge of rust-lang#128628 - khuey:simply-cfg-erase-source-info, r=nnethercote

When deduplicating unreachable blocks, erase the source information.

After deduplication the block conceptually belongs to multiple locations in the source. Although these blocks are unreachable, in rust-lang#123341 we did come across a real side effect, an unreachable block that survives into the compiled code can cause a debugger to set a breakpoint on the wrong instruction. Erasing the source information ensures that a debugger will never be misled into thinking that the unreachable block is worth setting a breakpoint on, especially after rust-lang#128627.

Technically we don't need to erase the source information if all the deduplicated blocks have identical source information, but tracking that seems like more effort than it's worth.

I'll let njn redirect this one too. r? `@nnethercote`

Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.

Line 0 has a special meaning in DWARF. From the version 5 spec:

    The compiler may emit the value 0 in cases
    where an instruction cannot be attributed to any
    source line.

DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.

Rollup of 6 pull requests

Successful merges:

 - rust-lang#127623 (fix: fs::remove_dir_all: treat internal ENOENT as success)
 - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.)
 - rust-lang#129187 (bootstrap: fix clean's remove_dir_all implementation)
 - rust-lang#129190 (Added f16 and f128 to tests/ui/consts/const-float-bits-conv.rs)
 - rust-lang#129231 (improve submodule updates)
 - rust-lang#129257 (Allow rust staticlib to work with MSVC's /WHOLEARCHIVE)

r? `@ghost`
`@rustbot` modify labels: rollup

Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.

Line 0 has a special meaning in DWARF. From the version 5 spec:

    The compiler may emit the value 0 in cases
    where an instruction cannot be attributed to any
    source line.

DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.

Rollup of 6 pull requests

Successful merges:

 - rust-lang#127623 (fix: fs::remove_dir_all: treat internal ENOENT as success)
 - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.)
 - rust-lang#129187 (bootstrap: fix clean's remove_dir_all implementation)
 - rust-lang#129190 (Added f16 and f128 to tests/ui/consts/const-float-bits-conv.rs)
 - rust-lang#129231 (improve submodule updates)
 - rust-lang#129284 (rustdoc: animate the `:target` highlight)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup of 6 pull requests

Successful merges:

 - rust-lang#127623 (fix: fs::remove_dir_all: treat internal ENOENT as success)
 - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.)
 - rust-lang#129187 (bootstrap: fix clean's remove_dir_all implementation)
 - rust-lang#129190 (Added f16 and f128 to tests/ui/consts/const-float-bits-conv.rs)
 - rust-lang#129231 (improve submodule updates)
 - rust-lang#129284 (rustdoc: animate the `:target` highlight)

r? `@ghost`
`@rustbot` modify labels: rollup

Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.

Line 0 has a special meaning in DWARF. From the version 5 spec:

    The compiler may emit the value 0 in cases
    where an instruction cannot be attributed to any
    source line.

DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.

Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.

Line 0 has a special meaning in DWARF. From the version 5 spec:

    The compiler may emit the value 0 in cases
    where an instruction cannot be attributed to any
    source line.

DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.

Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.

Line 0 has a special meaning in DWARF. From the version 5 spec:

    The compiler may emit the value 0 in cases
    where an instruction cannot be attributed to any
    source line.

DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.

Rollup of 7 pull requests

Successful merges:

 - rust-lang#128432 (WASI: forbid `unsafe_op_in_unsafe_fn` for `std::{os, sys}`)
 - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.)
 - rust-lang#129187 (bootstrap: fix clean's remove_dir_all implementation)
 - rust-lang#129257 (Allow rust staticlib to work with MSVC's /WHOLEARCHIVE)
 - rust-lang#129264 (Update `library/Cargo.toml` in weekly job)
 - rust-lang#129284 (rustdoc: animate the `:target` highlight)
 - rust-lang#129332 (Avoid extra `cast()`s after `CStr::as_ptr()`)

r? `@ghost`
`@rustbot` modify labels: rollup

…iaskrgr

Rollup of 10 pull requests

Successful merges:

 - rust-lang#128627 (Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.)
 - rust-lang#128843 (Minor Refactor: Remove a Redundant Conditional Check)
 - rust-lang#129179 (CFI: Erase regions when projecting ADT to its transparent non-1zst field)
 - rust-lang#129281 (Tweak unreachable lint wording)
 - rust-lang#129312 (Fix stability attribute of `impl !Error for &str`)
 - rust-lang#129332 (Avoid extra `cast()`s after `CStr::as_ptr()`)
 - rust-lang#129339 (Make `ArgAbi::make_indirect_force` more specific)
 - rust-lang#129344 (Use `bool` in favor of `Option<()>` for diagnostics)
 - rust-lang#129345 (Use shorthand field initialization syntax more aggressively in the compiler)
 - rust-lang#129355 (fix comment on PlaceMention semantics)

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of rust-lang#128627 - khuey:DUMMY_SP-line-no, r=nnethercote

Special case DUMMY_SP to emit line 0/column 0 locations on DWARF platforms.

Line 0 has a special meaning in DWARF. From the version 5 spec:

    The compiler may emit the value 0 in cases
    where an instruction cannot be attributed to any
    source line.

DUMMY_SP spans cannot be attributed to any line. However, because rustc internally stores line numbers starting at zero, lookup_debug_loc() adjusts every line number by one. Special casing DUMMY_SP to actually emit line 0 ensures rustc communicates to the debugger that there's no meaningful source code for this instruction, rather than telling the debugger to jump to line 1 randomly.

…ulacrum

Refine dummy_span.rs test

The test that is introduced in rust-lang#128627 is a BBs order problem in LLVM. I'm not 100% confident in the following investigation, but I think this is presumably the result.

Per the following content that is mentioned at https://llvm.org/docs/KeyInstructionsDebugInfo.html:

> DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the `is_stmt` flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM’s current approach to deciding `is_stmt` placement essentially reduces down to “is the associated line number different to the previous instruction’s?”.

Taking the example from https://rust.godbolt.org/z/GvToxj6vh. The partial assembly code with `SimplifyComparisonIntegral` is:

```asm
.LBB40_21:
        .loc    6 14 16 is_stmt 1
; RET = Ok(())
        mov     byte ptr [rsp + 79], 5
        .loc    6 0 0 is_stmt 0
        jmp     .LBB40_23
...
.LBB40_23:
        .loc    6 18 1 is_stmt 1
        lea     rdi, [rsp + 112]
; drop(number_str)
        call    qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL]
        jmp     .LBB40_27
```

without `SimplifyComparisonIntegral`:

```asm
.LBB40_22:
        .loc    6 14 16 is_stmt 1
; RET = Ok(())
        mov     byte ptr [rsp + 79], 5
        .loc    6 0 0 is_stmt 0
        jmp     .LBB40_27
...
.LBB40_26:
        .loc    6 18 2 is_stmt 0
        mov     al, byte ptr [rsp + 79]
        .loc    6 18 2 epilogue_begin
        add     rsp, 360
        .cfi_def_cfa_offset 8
        ret
.LBB40_27:
; same line number to the previous instruction, so don't place `is_stmt` flag.
; this flag is `is_stmt 0` that will follow the flag of `.LBB40_26`.
        .loc    6 18 1
        lea     rdi, [rsp + 112]
; drop(number_str)
        call    qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL]
        jmp     .LBB40_26
```

GDB doesn't step to `LBB40_27` due to `is_stmt 0`, so the next step is `__rust_begin_short_backtrace`. I have verified the new test works well with or without ``SimplifyComparisonIntegral`.

…ulacrum

Refine dummy_span.rs test

The test that is introduced in rust-lang#128627 is a BBs order problem in LLVM. I'm not 100% confident in the following investigation, but I think this is presumably the result.

Per the following content that is mentioned at https://llvm.org/docs/KeyInstructionsDebugInfo.html:

> DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the `is_stmt` flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM’s current approach to deciding `is_stmt` placement essentially reduces down to “is the associated line number different to the previous instruction’s?”.

Taking the example from https://rust.godbolt.org/z/GvToxj6vh. The partial assembly code with `SimplifyComparisonIntegral` is:

```asm
.LBB40_21:
        .loc    6 14 16 is_stmt 1
; RET = Ok(())
        mov     byte ptr [rsp + 79], 5
        .loc    6 0 0 is_stmt 0
        jmp     .LBB40_23
...
.LBB40_23:
        .loc    6 18 1 is_stmt 1
        lea     rdi, [rsp + 112]
; drop(number_str)
        call    qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL]
        jmp     .LBB40_27
```

without `SimplifyComparisonIntegral`:

```asm
.LBB40_22:
        .loc    6 14 16 is_stmt 1
; RET = Ok(())
        mov     byte ptr [rsp + 79], 5
        .loc    6 0 0 is_stmt 0
        jmp     .LBB40_27
...
.LBB40_26:
        .loc    6 18 2 is_stmt 0
        mov     al, byte ptr [rsp + 79]
        .loc    6 18 2 epilogue_begin
        add     rsp, 360
        .cfi_def_cfa_offset 8
        ret
.LBB40_27:
; same line number to the previous instruction, so don't place `is_stmt` flag.
; this flag is `is_stmt 0` that will follow the flag of `.LBB40_26`.
        .loc    6 18 1
        lea     rdi, [rsp + 112]
; drop(number_str)
        call    qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL]
        jmp     .LBB40_26
```

GDB doesn't step to `LBB40_27` due to `is_stmt 0`, so the next step is `__rust_begin_short_backtrace`. I have verified the new test works well with or without ``SimplifyComparisonIntegral`.