Description
Found via rust-icci: https://travis-ci.org/rust-icci/regex/jobs/291213197
The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode:
@str.0 = internal constant [15 x i8] c"src/literals.rs"
@str.1 = internal constant [28 x i8] c"attempt to add with overflow"
@panic_loc.2 = internal unnamed_addr constant { %str_slice, %str_slice, i32, i32 }
{ %str_slice
{ i8* getelementptr inbounds ([28 x i8], [28 x i8]* @str.1, i32 0, i32 0), i64 28 },
%str_slice
{ i8* getelementptr inbounds ([15 x i8], [15 x i8]* @str.0, i32 0, i32 0), i64 15 },
i32 105, i32 59
; ^^^^^^^ The line number is not updated
}, align 8
I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows:
rust/src/librustc/ich/impls_hir.rs
Lines 564 to 577 in 4c053db
There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages.
This is another span-related papercut :(