| Age | Commit message (Collapse) | Author |
|---|
|
ranges more similar to the console output. Consider:
#define FOO(X, Y) X/ Y
void foo(int *P, int *Q) {
FOO(P, Q);
}
Before we emitted:
t.c:4:3:{4:3-4:6}{4:3-4:6}: error: invalid operands to binary expression ('int *' and 'int *')
FOO(P, Q);
^~~~~~~~~
...
Note that while we underline the macro args that the range info just includes FOO
without its macros. This change teaches the printed ranges to include macro args
also so that we get:
t.c:4:3:{4:3-4:12}{4:3-4:12}: error: invalid operands to binary expression ('int *' and 'int *')
FOO(P, Q);
^~~~~~~~~
...
This fixes rdar://6939599
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73378 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72855 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SelectInterestingSourceRegion()," from Jay Foad!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72049 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
columns. Fixes <rdar://problem/6892178>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71870 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71066 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
generates untraceable warnings
The "instantiated from" messages coming from the caret diagnostics system are
basically walking the macro expansion tree, emitting each level as it goes. However, it was
skipping certain leaves in the tree by skipping up the entire instantiation arm every time
it went up one spelling arm. This caused it to miss some things. For example, in this
testcase:
#define M1(x) x
#define M2 1;
void foo() {
M1(M2)
}
we now print:
/Users/sabre/Desktop/clang-unused-value-macro.c:6:2: warning: expression result unused
M1(M2)
^~~~~~
/Users/sabre/Desktop/clang-unused-value-macro.c:6:5: note: instantiated from:
M1(M2)
^~
/Users/sabre/Desktop/clang-unused-value-macro.c:3:12: note: instantiated from:
#define M2 1;
^
Previously we didn't print the last line, so we never emitted the caret pointing to the 1!
Incidentally, the spaces between the lines is really noisy, I think we should reconsider
this heuristic (which adds them when the printed code starts too close to the start of the
line).
The regression test can't use -verify, because -verify doesn't catch notes for macro
instantiation history.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71025 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-whitespace text with each expansion step. It's easier and seems to have better results.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70833 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
1) First of all, we treat _ as part of an identifier and not as
punctuation (oops).
2) Second of all, always make sure that the token that the ^ is
pointing at is fully within the "interesting" part of the range.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70831 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- The diagnostic is still poor, however. Doug, can you investigate?
- Improved the test case to not depend on the file name, now it can
be extended to actually check the formatting of the diagnostics
(I'm hoping grep -A is portable here).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70807 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
printing. Also, when we only need to truncate the line at the end,
make sure there is room for the ellipsis.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70681 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
fix-it hint is much worse than no fix-it hint. (Fixes PR4084).
When we need to truncate a source line to fix in the terminal, make
sure to take the width of the fix-it information into account, too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
show an ellipsis where we have removed text. An example:
/Users/dgregor/Projects/llvm/tools/clang/test/Misc/message-length.c:18:120:
warning:
comparison of distinct pointer types ('int *' and 'float *')
...a_func_to_call(ip == FloatPointer, ip[ALongIndexName], ...
~~ ^ ~~~~~~~~~~~~
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70655 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
word-wrapping by default in Emacs; yay!). Thanks, Daniel.
Use LLVM's System layer rather than calling isatty() directly.
Fix a thinko in printing the indentation string that was causing some
weird output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70654 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
might be wider than we're supposed to print. In this case, we try to
select the "important" subregion of the source line, which contains
everything that we want to show (e.g., with underlining and the caret
itself) and tries to also contain some of the context.
From the fantastically long line in the test case, we get an error
message that slices down to this:
message-length.c:18:120: warning: comparison of distinct pointer types
('int *' and 'float *')
a_func_to_call(ip == FloatPointer, ip[ALongIndexName],
~~ ^ ~~~~~~~~~~~~
There are a bunch of gee-it-sounds-good heuristics in here, which seem
to do well on the various simple tests I've thrown at it. However,
we're going to need to look at a bunch more diagnostics to tweak these
heuristics.
This is the second part of <rdar://problem/6711348>. Almost there!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70597 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also, put a line of whitespace between the diagnostic and the source
code/caret line when the start of the actual source code text lines up
(or nearly lines up) with the most recent line of the diagnostic. For
example, here it's okay for the last line of the diagnostic to be
(vertically) next to the source line, because there is horizontal
whitespace to separate them:
decl-expr-ambiguity.cpp:12:16: error: function-style cast to a builtin
type can only take one argument
typeof(int)(a,5)<<a;
However, here is a case where we need the vertical separation (since
there is no horizontal separation):
message-length.c:10:46: warning: incompatible pointer types initializing 'void
(int, float, char, float)', expected 'int (*)(int, float, short,
float)'
int (*fp1)(int, float, short, float) = f;
This is part one of <rdar://problem/6711348>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70578 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
lines that clang extracts from the source code so that machine parsing can
easily ignore them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70337 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-fno-show-location, patch by Alexei Svitkine (PR4024)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69657 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
mode, just ignore them as usual.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69558 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rdar://6805442
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69525 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69269 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
passing down the right info yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69268 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This allows it to accurately measure tokens, so that we get:
t.cpp:8:13: error: unknown type name 'X'
static foo::X P;
~~~~~^
instead of the woefully inferior:
t.cpp:8:13: error: unknown type name 'X'
static foo::X P;
~~~~ ^
Most of this is just plumbing to push the reference around.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69099 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
defaults to off. When enabled, it emits range info along
with the file/line/col information for a diagnostic. This
allows tools that textually parse the output of clang to know
where the ranges are, even if they span multiple lines. For
example, with:
$ clang exprs.c -fprint-source-range-info
We now produce:
exprs.c:21:11:{21:12-21:13}: warning: use of unary operator that may be intended as compound assignment (+=)
var =+ 5; // expected-warning {{use of unary operator that may be intended as compound assignment (+=)}}
^~
exprs.c:22:11:{22:12-22:13}: warning: use of unary operator that may be intended as compound assignment (-=)
var =- 5; // expected-warning {{use of unary operator that may be intended as compound assignment (-=)}}
^~
exprs.c:36:13:{36:3-36:12}: error: assignment to cast is illegal, lvalue casts are not supported
(float*)X = P; // expected-error {{assignment to cast is illegal, lvalue casts are not supported}}
~~~~~~~~~ ^
exprs.c:41:4:{41:3-41:4}: error: called object type 'int' is not a function or function pointer
X(); // expected-error {{called object type 'int' is not a function or function pointer}}
~^
exprs.c:45:15:{45:8-45:14}{45:17-45:24}: error: invalid operands to binary expression ('int *' and '_Complex float')
P = (P-42) + Gamma*4; // expected-error {{invalid operands to binary expression ('int *' and '_Complex float')}}
~~~~~~ ^ ~~~~~~~
exprs.c:61:7:{61:16-61:22}: error: invalid application of '__alignof' to bitfield
R = __alignof(P->x); // expected-error {{invalid application of '__alignof' to bitfield}} expected-warning {{extension used}}
^ ~~~~~~
Note the range info after the column in the initial diagnostic.
This is obviously really annoying if you're not a tool parsing the
output of clang, which is why it is off by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66862 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
context of a template-id for which we need to instantiate default
template arguments.
In the TextDiagnosticPrinter, don't suppress the caret diagnostic if
we are producing a non-note diagnostic that follows a note diagnostic
with the same location, because notes are (conceptually) a part of the
warning or error that comes before them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66572 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
end of line instead of just the end of buffer. Scratch buffers contain
embedded \0's between tokens which are logic line separators. If a
normal text buffer contains \0's, it doesn't make a lot of sense to include
them in the caret diag output anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66374 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65869 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
driver taking lib/Driver.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65811 91177308-0d34-0410-b5e6-96231b3b80d8
|
