| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
driver taking lib/Driver.
llvm-svn: 65811
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 64959
|
|
|
|
|
|
|
|
| |
getColumnNumber. This fixes a FIXME in
SourceManager::getPresumedLoc because we now just decompose
the sloc once.
llvm-svn: 63701
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
| |
no longer such thing as a non-canonical FileID.
llvm-svn: 62499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"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
|
|
|
|
|
|
| |
*is* the location. This eliminates some weird X.getLocation().getLocation()'s.
llvm-svn: 62376
|
|
|
|
| |
llvm-svn: 62374
|
|
|
|
| |
llvm-svn: 62370
|
|
|
|
|
|
| |
"logical" location, refer to the "instantiation" location.
llvm-svn: 62316
|
|
|
|
| |
llvm-svn: 58646
|
|
|
|
|
|
| |
ranges that occur within macros would not be emitted at all.
llvm-svn: 58550
|
|
|
|
| |
llvm-svn: 58111
|
|
|
|
| |
llvm-svn: 56440
|
|
|
|
|
|
| |
contents of the message.
llvm-svn: 56400
|
|
|
|
|
|
| |
Changed casing of many bug names. The convention will be to have bug names (mostly) lower cased, and categories use some capitalization.
llvm-svn: 56385
|
|
|
|
|
|
|
| |
"Here is a patch what replaces std::ostream with llvm::raw_ostream. This patch
covers the AST library, but ignores Analysis lib."
llvm-svn: 56185
|
|
llvm-svn: 55274
|