[llvm-bugs] [Bug 41100] New: "in call to f(x)" note should pretty-print original value of argument 'x', not mutated value

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41100

            Bug ID: 41100
           Summary: "in call to f(x)" note should pretty-print original
                    value of argument 'x', not mutated value
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: arthur.j.odwyer at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

When Clang prints diagnostic notes of the form "...in call to f(arg1,
arg2)...", it seems to lose track of the arguments' ORIGINAL values. Clang ends
up pretty-printing the CHANGED values of those arguments. This can be very
confusing, especially when there's recursion involved, because the text of the
diagnostic will appear to be talking about a call that never appears in the
source code (or worse, a call that coincidentally DOES appear in the source
code, but isn't the culprit). Here's a reduced test case:

```
// https://godbolt.org/z/PIL0lW
constexpr int f(int i) {
    i = -i;
    return 1 << i;
}
static_assert(f(1));
```

The problematic part of the following error message is where it mentions "call
to 'f(-1)'". It should mention "call to 'f(1)'" instead.

```
<source>:7:15: error: static_assert expression is not an integral constant
expression
static_assert(f(1));
              ^~~~
<source>:4:14: note: negative shift count -1
    return 1 << i;
             ^
<source>:7:15: note: in call to 'f(-1)'
static_assert(f(1));
              ^
1 error generated.
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190316/5d039019/attachment.html>