- Add Options.def file, collects option information.
- Actual option instantiation is handled lazily by OptTable to allow
the driver to not need to instantiate all options.
- cast<> support for Option, other minor tweaks.
llvm-svn: 66028
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
llvm-svn: 65570
"after" group instead of the system group makes it so #include <limits.h>
picks up the *system* limits.h file before clang's. This causes a failure
on linux and is definitely not what we want.
llvm-svn: 65026
keep searching for C++ headers when in C++ mode). In theory clang
should be able to find all of its own headers now. If not, the
CPATH or C_INCLUDE_PATH environment variables can be specified to
add a include path.
llvm-svn: 64862
diagnostics. I'm not sure I want to keep this, but hey, it's easy
and could be useful or something, even if guarded by a
-fshow-me-tons-of-details option. A silly example is:
#define A B
#define C A
#define D C
int y = D;
We now emit:
t.c:11:9: error: use of undeclared identifier 'B'
int y = D;
^
t.c:9:11: note: instantiated from:
#define D C
^
t.c:8:11: note: instantiated from:
#define C A
^
t.c:7:11: note: instantiated from:
#define A B
^
A more useful example is from tgmath:
t.c:4:9: error: no matching function for call to '__tg_acos'
return acos(x);
^~~~~~~
/Users/sabre/llvm/Debug/Headers/tgmath-sofar.h:51:17: note: instantiated from:
#define acos(x) __tg_acos(x)
^
... candidate set follows ...
This does not yet print ranges in instantiation info, (e.g. highlighting the
range "__tg_acos(x)" in the last example), but that could be added if we
decide this is a good idea :).
Thoughts and bug reports welcome!
llvm-svn: 64761
highlight the arguments to the macro as well as the identifier.
Before:
t.c:3:9: error: no matching function for call to '__tg_acos'; candidates are:
return acos(x);
^~~~
after:
t.c:3:9: error: no matching function for call to '__tg_acos'; candidates are:
return acos(x);
^~~~~~~
llvm-svn: 64743
the "system dirs win over user dirs" logic to framework and headermap
search locations as well as normal directories. This means that
clang t.m -F/System/Library/Frameworks will treat /System/Library/Frameworks
as a system directory not a user directory. If you use -v, the difference is:
Before:
ignoring nonexistent directory "/usr/libdata/gcc41"
ignoring duplicate framework "/System/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
After:
ignoring nonexistent directory "/usr/libdata/gcc41"
ignoring duplicate directory "/System/Library/Frameworks"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
This fixes rdar://6566429.
llvm-svn: 64060
makes it clear to clients that they have to pick an instantiation
or spelling location before calling it and allows optimization based
on that.
llvm-svn: 63698
parameter that allows users to omit the printing of the source
location on a diagnostic. So basically it would omit the "abc.c:5:1: "
at the beginning of the line."
Patch by Alexei Svitkine!
llvm-svn: 63396
as reported to the user and as manipulated by #line. This is what __FILE__,
__INCLUDE_LEVEL__, diagnostics and other things should follow (but not
dependency generation!).
This patch also includes several cleanups along the way:
- SourceLocation now has a dump method, and several other places
that did similar things now use it.
- I cleaned up some code in AnalysisConsumer, but it should probably be
simplified further now that NamedDecl is better.
- TextDiagnosticPrinter is now simplified and cleaned up a bit.
This patch is a prerequisite for #line, but does not actually provide
any #line functionality.
llvm-svn: 63098
- Add the distinction between the 'bug type' and the 'bug description'
HTMLDiagnostics:
- Output the bug type field as HTML comments
scan-build:
- Use the bug type field instead of the bug description for the HTML table.
- Radar filing now automatically picks up the bug description in the title (addresses <rdar://problem/6265970>)
llvm-svn: 63084
the chunk ID not the file ID. This exposes problems in
TextDiagnosticPrinter where it should have been using the canonical
file ID but wasn't. Fix these along the way.
llvm-svn: 62427
"FileID" a concept that is now enforced by the compiler's type checker
instead of yet-another-random-unsigned floating around.
This is an important distinction from the "FileID" currently tracked by
SourceLocation. *That* FileID may refer to the start of a file or to a
chunk within it. The new FileID *only* refers to the file (and its
#include stack and eventually #line data), it cannot refer to a chunk.
FileID is a completely opaque datatype to all clients, only SourceManager
is allowed to poke and prod it.
llvm-svn: 62407
Daniel Dunbar