[llvm-bugs] [Bug 24592] New: Cannot find the right back trace of the macro expansion
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Aug 26 13:58:08 PDT 2015
https://llvm.org/bugs/show_bug.cgi?id=24592
Bug ID: 24592
Summary: Cannot find the right back trace of the macro
expansion
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangbugs at nondot.org
Reporter: zhengkai at google.com
CC: llvm-bugs at lists.llvm.org, rtrieu at google.com
Classification: Unclassified
In /llvm/tools/clang/test/Misc/caret-diags-macros.c
#line 204
#define sprintf2(str, ...) \
__builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
#define Cstrlen(a) strlen_test(a)
#define Csprintf sprintf2
void f(char* pMsgBuf, char* pKeepBuf) {
Csprintf(pMsgBuf,"\nEnter minimum anagram length (2-%1d): ",
Cstrlen(pKeepBuf));
The error message is :
warning: format specifies type 'int' but the argument has type 'unsigned long'
Csprintf(pMsgBuf,"\nEnter minimum anagram length (2-%1d): ",
Cstrlen(pKeepBuf));
~~~ ^
%1lu
Should be
warning: format specifies type 'int' but the argument has type 'unsigned long'
Csprintf(pMsgBuf,"\nEnter minimum anagram length (2-%1d): ",
Cstrlen(pKeepBuf));
~~~ ^~~~~~~~~~~~~~~~~
%1lu
This bug is caused in /llvm/tools/clang/lib/Frontend/DiagnosticRenderer.cpp
in the procedure void DiagnosticRenderer::emitCaret, the procedure used
function void mapDiagnosticRanges.
This function doesn't map the right spelling ranges for the ranges given.
In the new version of this function (), the output is:
warning: format specifies type 'int' but the argument has type 'unsigned long'
Csprintf(pMsgBuf,"\nEnter minimum anagram length (2-%1d): ",
Cstrlen(pKeepBuf));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
%1lu
This is caused by the argument Ranges which is passed to the procedure
void DiagnosticRenderer::emitCaret indicates that the underlined part should be
#define Cstrlen(a) strlen_test(a)
~~~~~~~~~~~~~~
But there is a kind of high-level macro invocation here. Csprintf is a macro
and it expand to sprintf2 which is a new macro name. So it continues to expand
the macro sprintf2.
So when I trace back the range in the macro expansion stack, the range map
backs to the
#define Csprintf sprintf2
~~~~~~~~
So it finally map backs to the entire macro invocation.
I think the essential cause of this bug is that the back trace algorithm of the
macro expansions is not right in the SourceManager Class.
May be due to a similar reason with the bug:
https://llvm.org/bugs/show_bug.cgi?id=16799
--
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/20150826/e9b8215a/attachment-0001.html>
More information about the llvm-bugs
mailing list