source line wider than the terminal where the associated fix-it line
is longer than the caret line. Previously, we would crash in this
case, which was rather unfortunate. Fixes <rdar://problem/7856226>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101426 91177308-0d34-0410-b5e6-96231b3b80d8
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86430 91177308-0d34-0410-b5e6-96231b3b80d8
will have \r\n.
- Perhaps we should make FileCheck normalize line-endings, even in
strict-whitespace mode?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85066 91177308-0d34-0410-b5e6-96231b3b80d8
column computation isn't correct and could exceed the line length, which
resulted in a buffer overflow later.
- Chris, is there a better way for this code to compute the final column used
by the caret?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84475 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
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
Douglas Gregor
Daniel Dunbar
Chris Lattner