clang-1/lib/Frontend/TextDiagnosticPrinter.cpp

774 строки
28 KiB
C++
Исходник Обычный вид История

//===--- TextDiagnosticPrinter.cpp - Diagnostic Printer -------------------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This diagnostic client prints out their diagnostic messages.
//
//===----------------------------------------------------------------------===//
#include "clang/Frontend/TextDiagnosticPrinter.h"
#include "clang/Basic/SourceManager.h"
#include "clang/Lex/Lexer.h"
#include "llvm/Support/MemoryBuffer.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/ADT/SmallString.h"
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
#include <algorithm>
using namespace clang;
static const enum llvm::raw_ostream::Colors noteColor =
llvm::raw_ostream::BLACK;
static const enum llvm::raw_ostream::Colors fixitColor =
llvm::raw_ostream::GREEN;
static const enum llvm::raw_ostream::Colors caretColor =
llvm::raw_ostream::GREEN;
static const enum llvm::raw_ostream::Colors warningColor =
llvm::raw_ostream::MAGENTA;
static const enum llvm::raw_ostream::Colors errorColor = llvm::raw_ostream::RED;
static const enum llvm::raw_ostream::Colors fatalColor = llvm::raw_ostream::RED;
// used for changing only the bold attribute
static const enum llvm::raw_ostream::Colors savedColor =
llvm::raw_ostream::SAVEDCOLOR;
/// \brief Number of spaces to indent when word-wrapping.
const unsigned WordWrapIndentation = 6;
void TextDiagnosticPrinter::
PrintIncludeStack(SourceLocation Loc, const SourceManager &SM) {
if (Loc.isInvalid()) return;
PresumedLoc PLoc = SM.getPresumedLoc(Loc);
// Print out the other include frames first.
PrintIncludeStack(PLoc.getIncludeLoc(), SM);
if (ShowLocation)
OS << "In file included from " << PLoc.getFilename()
<< ':' << PLoc.getLine() << ":\n";
else
OS << "In included file:\n";
}
/// HighlightRange - Given a SourceRange and a line number, highlight (with ~'s)
/// any characters in LineNo that intersect the SourceRange.
void TextDiagnosticPrinter::HighlightRange(const SourceRange &R,
const SourceManager &SM,
unsigned LineNo, FileID FID,
std::string &CaretLine,
const std::string &SourceLine) {
assert(CaretLine.size() == SourceLine.size() &&
"Expect a correspondence between source and caret line!");
if (!R.isValid()) return;
SourceLocation Begin = SM.getInstantiationLoc(R.getBegin());
SourceLocation End = SM.getInstantiationLoc(R.getEnd());
// If the End location and the start location are the same and are a macro
// location, then the range was something that came from a macro expansion
// or _Pragma. If this is an object-like macro, the best we can do is to
// highlight the range. If this is a function-like macro, we'd also like to
// highlight the arguments.
if (Begin == End && R.getEnd().isMacroID())
End = SM.getInstantiationRange(R.getEnd()).second;
unsigned StartLineNo = SM.getInstantiationLineNumber(Begin);
if (StartLineNo > LineNo || SM.getFileID(Begin) != FID)
return; // No intersection.
unsigned EndLineNo = SM.getInstantiationLineNumber(End);
if (EndLineNo < LineNo || SM.getFileID(End) != FID)
return; // No intersection.
// Compute the column number of the start.
unsigned StartColNo = 0;
if (StartLineNo == LineNo) {
StartColNo = SM.getInstantiationColumnNumber(Begin);
if (StartColNo) --StartColNo; // Zero base the col #.
}
// Pick the first non-whitespace column.
while (StartColNo < SourceLine.size() &&
(SourceLine[StartColNo] == ' ' || SourceLine[StartColNo] == '\t'))
++StartColNo;
// Compute the column number of the end.
unsigned EndColNo = CaretLine.size();
if (EndLineNo == LineNo) {
EndColNo = SM.getInstantiationColumnNumber(End);
if (EndColNo) {
--EndColNo; // Zero base the col #.
// Add in the length of the token, so that we cover multi-char tokens.
EndColNo += Lexer::MeasureTokenLength(End, SM, *LangOpts);
} else {
EndColNo = CaretLine.size();
}
}
// Pick the last non-whitespace column.
if (EndColNo <= SourceLine.size())
while (EndColNo-1 &&
(SourceLine[EndColNo-1] == ' ' || SourceLine[EndColNo-1] == '\t'))
--EndColNo;
else
EndColNo = SourceLine.size();
// Fill the range with ~'s.
assert(StartColNo <= EndColNo && "Invalid range!");
for (unsigned i = StartColNo; i < EndColNo; ++i)
CaretLine[i] = '~';
}
/// \brief When the source code line we want to print is too long for
/// the terminal, select the "interesting" region.
static void SelectInterestingSourceRegion(std::string &SourceLine,
std::string &CaretLine,
std::string &FixItInsertionLine,
unsigned EndOfCaretToken,
unsigned Columns) {
if (CaretLine.size() > SourceLine.size())
SourceLine.resize(CaretLine.size(), ' ');
// Find the slice that we need to display the full caret line
// correctly.
unsigned CaretStart = 0, CaretEnd = CaretLine.size();
for (; CaretStart != CaretEnd; ++CaretStart)
if (!isspace(CaretLine[CaretStart]))
break;
for (; CaretEnd != CaretStart; --CaretEnd)
if (!isspace(CaretLine[CaretEnd - 1]))
break;
// Make sure we don't chop the string shorter than the caret token
// itself.
if (CaretEnd < EndOfCaretToken)
CaretEnd = EndOfCaretToken;
// If we have a fix-it line, make sure the slice includes all of the
// fix-it information.
if (!FixItInsertionLine.empty()) {
unsigned FixItStart = 0, FixItEnd = FixItInsertionLine.size();
for (; FixItStart != FixItEnd; ++FixItStart)
if (!isspace(FixItInsertionLine[FixItStart]))
break;
for (; FixItEnd != FixItStart; --FixItEnd)
if (!isspace(FixItInsertionLine[FixItEnd - 1]))
break;
if (FixItStart < CaretStart)
CaretStart = FixItStart;
if (FixItEnd > CaretEnd)
CaretEnd = FixItEnd;
}
// CaretLine[CaretStart, CaretEnd) contains all of the interesting
// parts of the caret line. While this slice is smaller than the
// number of columns we have, try to grow the slice to encompass
// more context.
// If the end of the interesting region comes before we run out of
// space in the terminal, start at the beginning of the line.
if (Columns > 3 && CaretEnd < Columns - 3)
CaretStart = 0;
unsigned TargetColumns = Columns;
if (TargetColumns > 8)
TargetColumns -= 8; // Give us extra room for the ellipses.
unsigned SourceLength = SourceLine.size();
while ((CaretEnd - CaretStart) < TargetColumns) {
bool ExpandedRegion = false;
// Move the start of the interesting region left until we've
// pulled in something else interesting.
if (CaretStart == 1)
CaretStart = 0;
else if (CaretStart > 1) {
unsigned NewStart = CaretStart - 1;
// Skip over any whitespace we see here; we're looking for
// another bit of interesting text.
while (NewStart && isspace(SourceLine[NewStart]))
--NewStart;
// Skip over this bit of "interesting" text.
while (NewStart && !isspace(SourceLine[NewStart]))
--NewStart;
// Move up to the non-whitespace character we just saw.
if (NewStart)
++NewStart;
// If we're still within our limit, update the starting
// position within the source/caret line.
if (CaretEnd - NewStart <= TargetColumns) {
CaretStart = NewStart;
ExpandedRegion = true;
}
}
// Move the end of the interesting region right until we've
// pulled in something else interesting.
if (CaretEnd != SourceLength) {
unsigned NewEnd = CaretEnd;
// Skip over any whitespace we see here; we're looking for
// another bit of interesting text.
while (NewEnd != SourceLength && isspace(SourceLine[NewEnd - 1]))
++NewEnd;
// Skip over this bit of "interesting" text.
while (NewEnd != SourceLength && !isspace(SourceLine[NewEnd - 1]))
++NewEnd;
if (NewEnd - CaretStart <= TargetColumns) {
CaretEnd = NewEnd;
ExpandedRegion = true;
}
}
if (!ExpandedRegion)
break;
}
// [CaretStart, CaretEnd) is the slice we want. Update the various
// output lines to show only this slice, with two-space padding
// before the lines so that it looks nicer.
if (CaretEnd < SourceLine.size())
SourceLine.replace(CaretEnd, std::string::npos, "...");
if (CaretEnd < CaretLine.size())
CaretLine.erase(CaretEnd, std::string::npos);
if (FixItInsertionLine.size() > CaretEnd)
FixItInsertionLine.erase(CaretEnd, std::string::npos);
if (CaretStart > 2) {
SourceLine.replace(0, CaretStart, " ...");
CaretLine.replace(0, CaretStart, " ");
if (FixItInsertionLine.size() >= CaretStart)
FixItInsertionLine.replace(0, CaretStart, " ");
}
}
void TextDiagnosticPrinter::EmitCaretDiagnostic(SourceLocation Loc,
SourceRange *Ranges,
unsigned NumRanges,
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
SourceManager &SM,
const CodeModificationHint *Hints,
unsigned NumHints,
unsigned Columns) {
assert(!Loc.isInvalid() && "must have a valid source location here");
// If this is a macro ID, first emit information about where this was
// instantiated (recursively) then emit information about where. the token was
// spelled from.
if (!Loc.isFileID()) {
SourceLocation OneLevelUp = SM.getImmediateInstantiationRange(Loc).first;
// FIXME: Map ranges?
EmitCaretDiagnostic(OneLevelUp, Ranges, NumRanges, SM, 0, 0, Columns);
Loc = SM.getImmediateSpellingLoc(Loc);
// Map the ranges.
for (unsigned i = 0; i != NumRanges; ++i) {
SourceLocation S = Ranges[i].getBegin(), E = Ranges[i].getEnd();
if (S.isMacroID()) S = SM.getImmediateSpellingLoc(S);
if (E.isMacroID()) E = SM.getImmediateSpellingLoc(E);
Ranges[i] = SourceRange(S, E);
}
if (ShowLocation) {
std::pair<FileID, unsigned> IInfo = SM.getDecomposedInstantiationLoc(Loc);
// Emit the file/line/column that this expansion came from.
OS << SM.getBuffer(IInfo.first)->getBufferIdentifier() << ':'
<< SM.getLineNumber(IInfo.first, IInfo.second) << ':';
if (ShowColumn)
OS << SM.getColumnNumber(IInfo.first, IInfo.second) << ':';
OS << ' ';
}
OS << "note: instantiated from:\n";
EmitCaretDiagnostic(Loc, Ranges, NumRanges, SM, Hints, NumHints, Columns);
return;
}
// Decompose the location into a FID/Offset pair.
std::pair<FileID, unsigned> LocInfo = SM.getDecomposedLoc(Loc);
FileID FID = LocInfo.first;
unsigned FileOffset = LocInfo.second;
// Get information about the buffer it points into.
std::pair<const char*, const char*> BufferInfo = SM.getBufferData(FID);
const char *BufStart = BufferInfo.first;
unsigned ColNo = SM.getColumnNumber(FID, FileOffset);
unsigned CaretEndColNo
= ColNo + Lexer::MeasureTokenLength(Loc, SM, *LangOpts);
// Rewind from the current position to the start of the line.
const char *TokPtr = BufStart+FileOffset;
const char *LineStart = TokPtr-ColNo+1; // Column # is 1-based.
// Compute the line end. Scan forward from the error position to the end of
// the line.
const char *LineEnd = TokPtr;
while (*LineEnd != '\n' && *LineEnd != '\r' && *LineEnd != '\0')
++LineEnd;
// Copy the line of code into an std::string for ease of manipulation.
std::string SourceLine(LineStart, LineEnd);
// Create a line for the caret that is filled with spaces that is the same
// length as the line of source code.
std::string CaretLine(LineEnd-LineStart, ' ');
// Highlight all of the characters covered by Ranges with ~ characters.
if (NumRanges) {
unsigned LineNo = SM.getLineNumber(FID, FileOffset);
for (unsigned i = 0, e = NumRanges; i != e; ++i)
HighlightRange(Ranges[i], SM, LineNo, FID, CaretLine, SourceLine);
}
// Next, insert the caret itself.
if (ColNo-1 < CaretLine.size())
CaretLine[ColNo-1] = '^';
else
CaretLine.push_back('^');
// Scan the source line, looking for tabs. If we find any, manually expand
// them to 8 characters and update the CaretLine to match.
for (unsigned i = 0; i != SourceLine.size(); ++i) {
if (SourceLine[i] != '\t') continue;
// Replace this tab with at least one space.
SourceLine[i] = ' ';
// Compute the number of spaces we need to insert.
unsigned NumSpaces = ((i+8)&~7) - (i+1);
assert(NumSpaces < 8 && "Invalid computation of space amt");
// Insert spaces into the SourceLine.
SourceLine.insert(i+1, NumSpaces, ' ');
// Insert spaces or ~'s into CaretLine.
CaretLine.insert(i+1, NumSpaces, CaretLine[i] == '~' ? '~' : ' ');
}
// If we are in -fdiagnostics-print-source-range-info mode, we are trying to
// produce easily machine parsable output. Add a space before the source line
// and the caret to make it trivial to tell the main diagnostic line from what
// the user is intended to see.
if (PrintRangeInfo) {
SourceLine = ' ' + SourceLine;
CaretLine = ' ' + CaretLine;
}
std::string FixItInsertionLine;
if (NumHints && PrintFixItInfo) {
for (const CodeModificationHint *Hint = Hints, *LastHint = Hints + NumHints;
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
Hint != LastHint; ++Hint) {
if (Hint->InsertionLoc.isValid()) {
// We have an insertion hint. Determine whether the inserted
// code is on the same line as the caret.
std::pair<FileID, unsigned> HintLocInfo
= SM.getDecomposedInstantiationLoc(Hint->InsertionLoc);
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
if (SM.getLineNumber(HintLocInfo.first, HintLocInfo.second) ==
SM.getLineNumber(FID, FileOffset)) {
// Insert the new code into the line just below the code
// that the user wrote.
unsigned HintColNo
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
= SM.getColumnNumber(HintLocInfo.first, HintLocInfo.second);
unsigned LastColumnModified
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
= HintColNo - 1 + Hint->CodeToInsert.size();
if (LastColumnModified > FixItInsertionLine.size())
FixItInsertionLine.resize(LastColumnModified, ' ');
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
std::copy(Hint->CodeToInsert.begin(), Hint->CodeToInsert.end(),
FixItInsertionLine.begin() + HintColNo - 1);
} else {
FixItInsertionLine.clear();
break;
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
}
}
}
}
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
// If the source line is too long for our terminal, select only the
// "interesting" source region within that line.
if (Columns && SourceLine.size() > Columns)
SelectInterestingSourceRegion(SourceLine, CaretLine, FixItInsertionLine,
CaretEndColNo, Columns);
// Finally, remove any blank spaces from the end of CaretLine.
while (CaretLine[CaretLine.size()-1] == ' ')
CaretLine.erase(CaretLine.end()-1);
// Emit what we have computed.
OS << SourceLine << '\n';
if (UseColors)
OS.changeColor(caretColor, true);
OS << CaretLine << '\n';
if (UseColors)
OS.resetColor();
if (!FixItInsertionLine.empty()) {
if (UseColors)
// Print fixit line in color
OS.changeColor(fixitColor, false);
if (PrintRangeInfo)
OS << ' ';
OS << FixItInsertionLine << '\n';
if (UseColors)
OS.resetColor();
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
}
}
/// \brief Skip over whitespace in the string, starting at the given
/// index.
///
/// \returns The index of the first non-whitespace character that is
/// greater than or equal to Idx or, if no such character exists,
/// returns the end of the string.
static unsigned skipWhitespace(unsigned Idx,
const llvm::SmallVectorImpl<char> &Str,
unsigned Length) {
while (Idx < Length && isspace(Str[Idx]))
++Idx;
return Idx;
}
/// \brief If the given character is the start of some kind of
/// balanced punctuation (e.g., quotes or parentheses), return the
/// character that will terminate the punctuation.
///
/// \returns The ending punctuation character, if any, or the NULL
/// character if the input character does not start any punctuation.
static inline char findMatchingPunctuation(char c) {
switch (c) {
case '\'': return '\'';
case '`': return '\'';
case '"': return '"';
case '(': return ')';
case '[': return ']';
case '{': return '}';
default: break;
}
return 0;
}
/// \brief Find the end of the word starting at the given offset
/// within a string.
///
/// \returns the index pointing one character past the end of the
/// word.
unsigned findEndOfWord(unsigned Start,
const llvm::SmallVectorImpl<char> &Str,
unsigned Length, unsigned Column,
unsigned Columns) {
unsigned End = Start + 1;
// Determine if the start of the string is actually opening
// punctuation, e.g., a quote or parentheses.
char EndPunct = findMatchingPunctuation(Str[Start]);
if (!EndPunct) {
// This is a normal word. Just find the first space character.
while (End < Length && !isspace(Str[End]))
++End;
return End;
}
// We have the start of a balanced punctuation sequence (quotes,
// parentheses, etc.). Determine the full sequence is.
llvm::SmallVector<char, 16> PunctuationEndStack;
PunctuationEndStack.push_back(EndPunct);
while (End < Length && !PunctuationEndStack.empty()) {
if (Str[End] == PunctuationEndStack.back())
PunctuationEndStack.pop_back();
else if (char SubEndPunct = findMatchingPunctuation(Str[End]))
PunctuationEndStack.push_back(SubEndPunct);
++End;
}
// Find the first space character after the punctuation ended.
while (End < Length && !isspace(Str[End]))
++End;
unsigned PunctWordLength = End - Start;
if (// If the word fits on this line
Column + PunctWordLength <= Columns ||
// ... or the word is "short enough" to take up the next line
// without too much ugly white space
PunctWordLength < Columns/3)
return End; // Take the whole thing as a single "word".
// The whole quoted/parenthesized string is too long to print as a
// single "word". Instead, find the "word" that starts just after
// the punctuation and use that end-point instead. This will recurse
// until it finds something small enough to consider a word.
return findEndOfWord(Start + 1, Str, Length, Column + 1, Columns);
}
/// \brief Print the given string to a stream, word-wrapping it to
/// some number of columns in the process.
///
/// \brief OS the stream to which the word-wrapping string will be
/// emitted.
///
/// \brief Str the string to word-wrap and output.
///
/// \brief Columns the number of columns to word-wrap to.
///
/// \brief Column the column number at which the first character of \p
/// Str will be printed. This will be non-zero when part of the first
/// line has already been printed.
///
/// \brief Indentation the number of spaces to indent any lines beyond
/// the first line.
///
/// \returns true if word-wrapping was required, or false if the
/// string fit on the first line.
static bool PrintWordWrapped(llvm::raw_ostream &OS,
const llvm::SmallVectorImpl<char> &Str,
unsigned Columns,
unsigned Column = 0,
unsigned Indentation = WordWrapIndentation) {
unsigned Length = Str.size();
// If there is a newline in this message somewhere, find that
// newline and split the message into the part before the newline
// (which will be word-wrapped) and the part from the newline one
// (which will be emitted unchanged).
for (unsigned I = 0; I != Length; ++I)
if (Str[I] == '\n') {
Length = I;
break;
}
// The string used to indent each line.
llvm::SmallString<16> IndentStr;
IndentStr.assign(Indentation, ' ');
bool Wrapped = false;
for (unsigned WordStart = 0, WordEnd; WordStart < Length;
WordStart = WordEnd) {
// Find the beginning of the next word.
WordStart = skipWhitespace(WordStart, Str, Length);
if (WordStart == Length)
break;
// Find the end of this word.
WordEnd = findEndOfWord(WordStart, Str, Length, Column, Columns);
// Does this word fit on the current line?
unsigned WordLength = WordEnd - WordStart;
if (Column + WordLength < Columns) {
// This word fits on the current line; print it there.
if (WordStart) {
OS << ' ';
Column += 1;
}
OS.write(&Str[WordStart], WordLength);
Column += WordLength;
continue;
}
// This word does not fit on the current line, so wrap to the next
// line.
OS << '\n';
OS.write(&IndentStr[0], Indentation);
OS.write(&Str[WordStart], WordLength);
Column = Indentation + WordLength;
Wrapped = true;
}
if (Length == Str.size())
return Wrapped; // We're done.
// There is a newline in the message, followed by something that
// will not be word-wrapped. Print that.
OS.write(&Str[Length], Str.size() - Length);
return true;
}
void TextDiagnosticPrinter::HandleDiagnostic(Diagnostic::Level Level,
This reworks some of the Diagnostic interfaces a bit to change how diagnostics are formed. In particular, a diagnostic with all its strings and ranges is now packaged up and sent to DiagnosticClients as a DiagnosticInfo instead of as a ton of random stuff. This has the benefit of simplifying the interface, making it more extensible, and allowing us to do more checking for things like access past the end of the various arrays passed in. In addition to introducing DiagnosticInfo, this also substantially changes how Diagnostic::Report works. Instead of being passed in all of the info required to issue a diagnostic, Report now takes only the required info (a location and ID) and returns a fresh DiagnosticInfo *by value*. The caller is then free to stuff strings and ranges into the DiagnosticInfo with the << operator. When the dtor runs on the DiagnosticInfo object (which should happen at the end of the statement), the diagnostic is actually emitted with all of the accumulated information. This is a somewhat tricky dance, but it means that the accumulated DiagnosticInfo is allowed to keep pointers to other expression temporaries without those pointers getting invalidated. This is just the minimal change to get this stuff working, but this will allow us to eliminate the zillions of variant "Diag" methods scattered throughout (e.g.) sema. For example, instead of calling: Diag(BuiltinLoc, diag::err_overload_no_match, typeNames, SourceRange(BuiltinLoc, RParenLoc)); We will soon be able to just do: Diag(BuiltinLoc, diag::err_overload_no_match) << typeNames << SourceRange(BuiltinLoc, RParenLoc)); This scales better to support arbitrary types being passed in (not just strings) in a type-safe way. Go operator overloading?! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@59502 91177308-0d34-0410-b5e6-96231b3b80d8
2008-11-18 10:04:44 +03:00
const DiagnosticInfo &Info) {
// Keeps track of the the starting position of the location
// information (e.g., "foo.c:10:4:") that precedes the error
// message. We use this information to determine how long the
// file+line+column number prefix is.
uint64_t StartOfLocationInfo = OS.tell();
// If the location is specified, print out a file/line/col and include trace
// if enabled.
if (Info.getLocation().isValid()) {
const SourceManager &SM = Info.getLocation().getManager();
PresumedLoc PLoc = SM.getPresumedLoc(Info.getLocation());
unsigned LineNo = PLoc.getLine();
// First, if this diagnostic is not in the main file, print out the
// "included from" lines.
if (LastWarningLoc != PLoc.getIncludeLoc()) {
LastWarningLoc = PLoc.getIncludeLoc();
PrintIncludeStack(LastWarningLoc, SM);
StartOfLocationInfo = OS.tell();
}
// Compute the column number.
if (ShowLocation) {
if (UseColors)
OS.changeColor(savedColor, true);
OS << PLoc.getFilename() << ':' << LineNo << ':';
if (ShowColumn)
if (unsigned ColNo = PLoc.getColumn())
OS << ColNo << ':';
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
if (PrintRangeInfo && Info.getNumRanges()) {
FileID CaretFileID =
SM.getFileID(SM.getInstantiationLoc(Info.getLocation()));
bool PrintedRange = false;
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
for (unsigned i = 0, e = Info.getNumRanges(); i != e; ++i) {
// Ignore invalid ranges.
if (!Info.getRange(i).isValid()) continue;
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
SourceLocation B = Info.getRange(i).getBegin();
SourceLocation E = Info.getRange(i).getEnd();
B = SM.getInstantiationLoc(B);
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
E = SM.getInstantiationLoc(E);
// If the End location and the start location are the same and are a
// macro location, then the range was something that came from a macro
// expansion or _Pragma. If this is an object-like macro, the best we
// can do is to highlight the range. If this is a function-like
// macro, we'd also like to highlight the arguments.
if (B == E && Info.getRange(i).getEnd().isMacroID())
E = SM.getInstantiationRange(Info.getRange(i).getEnd()).second;
std::pair<FileID, unsigned> BInfo = SM.getDecomposedLoc(B);
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
std::pair<FileID, unsigned> EInfo = SM.getDecomposedLoc(E);
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
// If the start or end of the range is in another file, just discard
// it.
if (BInfo.first != CaretFileID || EInfo.first != CaretFileID)
continue;
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
// Add in the length of the token, so that we cover multi-char tokens.
unsigned TokSize = Lexer::MeasureTokenLength(E, SM, *LangOpts);
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
OS << '{' << SM.getLineNumber(BInfo.first, BInfo.second) << ':'
<< SM.getColumnNumber(BInfo.first, BInfo.second) << '-'
<< SM.getLineNumber(EInfo.first, EInfo.second) << ':'
<< (SM.getColumnNumber(EInfo.first, EInfo.second)+TokSize) << '}';
PrintedRange = true;
}
implement a new -fprint-source-range-info option, which 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
2009-03-13 04:08:23 +03:00
if (PrintedRange)
OS << ':';
}
OS << ' ';
if (UseColors)
OS.resetColor();
}
}
if (UseColors) {
// Print diagnostic category in bold and color
switch (Level) {
case Diagnostic::Ignored: assert(0 && "Invalid diagnostic type");
case Diagnostic::Note: OS.changeColor(noteColor, true); break;
case Diagnostic::Warning: OS.changeColor(warningColor, true); break;
case Diagnostic::Error: OS.changeColor(errorColor, true); break;
case Diagnostic::Fatal: OS.changeColor(fatalColor, true); break;
}
}
switch (Level) {
case Diagnostic::Ignored: assert(0 && "Invalid diagnostic type");
case Diagnostic::Note: OS << "note: "; break;
case Diagnostic::Warning: OS << "warning: "; break;
case Diagnostic::Error: OS << "error: "; break;
case Diagnostic::Fatal: OS << "fatal error: "; break;
}
if (UseColors)
OS.resetColor();
llvm::SmallString<100> OutStr;
Info.FormatDiagnostic(OutStr);
if (PrintDiagnosticOption)
if (const char *Opt = Diagnostic::getWarningOptionForDiag(Info.getID())) {
OutStr += " [-W";
OutStr += Opt;
OutStr += ']';
}
if (UseColors) {
// Print warnings, errors and fatal errors in bold, no color
switch (Level) {
case Diagnostic::Warning: OS.changeColor(savedColor, true); break;
case Diagnostic::Error: OS.changeColor(savedColor, true); break;
case Diagnostic::Fatal: OS.changeColor(savedColor, true); break;
default: break; //don't bold notes
}
}
if (MessageLength) {
// We will be word-wrapping the error message, so compute the
// column number where we currently are (after printing the
// location information).
unsigned Column = OS.tell() - StartOfLocationInfo;
PrintWordWrapped(OS, OutStr, MessageLength, Column);
} else {
OS.write(OutStr.begin(), OutStr.size());
}
OS << '\n';
if (UseColors)
OS.resetColor();
// If caret diagnostics are enabled and we have location, we want to
// emit the caret. However, we only do this if the location moved
// from the last diagnostic, if the last diagnostic was a note that
// was part of a different warning or error diagnostic, or if the
// diagnostic has ranges. We don't want to emit the same caret
// multiple times if one loc has multiple diagnostics.
if (CaretDiagnostics && Info.getLocation().isValid() &&
((LastLoc != Info.getLocation()) || Info.getNumRanges() ||
(LastCaretDiagnosticWasNote && Level != Diagnostic::Note) ||
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
Info.getNumCodeModificationHints())) {
// Cache the LastLoc, it allows us to omit duplicate source/caret spewage.
LastLoc = Info.getLocation();
LastCaretDiagnosticWasNote = (Level == Diagnostic::Note);
// Get the ranges into a local array we can hack on.
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
SourceRange Ranges[20];
unsigned NumRanges = Info.getNumRanges();
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
assert(NumRanges < 20 && "Out of space");
for (unsigned i = 0; i != NumRanges; ++i)
Ranges[i] = Info.getRange(i);
Introduce code modification hints into the diagnostics system. When we 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27 00:00:50 +03:00
unsigned NumHints = Info.getNumCodeModificationHints();
for (unsigned idx = 0; idx < NumHints; ++idx) {
const CodeModificationHint &Hint = Info.getCodeModificationHint(idx);
if (Hint.RemoveRange.isValid()) {
assert(NumRanges < 20 && "Out of space");
Ranges[NumRanges++] = Hint.RemoveRange;
}
}
EmitCaretDiagnostic(LastLoc, Ranges, NumRanges, LastLoc.getManager(),
Info.getCodeModificationHints(),
Info.getNumCodeModificationHints(),
MessageLength);
}
OS.flush();
}