2007-06-07 17:34:54 +08:00
|
|
|
//===--- TextDiagnosticPrinter.cpp - Diagnostic Printer -------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 03:59:25 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2007-06-07 17:34:54 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This diagnostic client prints out their diagnostic messages.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2009-03-02 14:16:29 +08:00
|
|
|
#include "clang/Frontend/TextDiagnosticPrinter.h"
|
2007-06-07 17:34:54 +08:00
|
|
|
#include "clang/Basic/SourceManager.h"
|
|
|
|
#include "clang/Lex/Lexer.h"
|
2009-05-06 06:03:18 +08:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2008-11-19 14:56:25 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2008-11-19 14:51:40 +08:00
|
|
|
#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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
#include <algorithm>
|
2007-06-07 17:34:54 +08:00
|
|
|
using namespace clang;
|
|
|
|
|
2009-06-04 15:18:23 +08:00
|
|
|
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;
|
|
|
|
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
/// \brief Number of spaces to indent when word-wrapping.
|
|
|
|
const unsigned WordWrapIndentation = 6;
|
|
|
|
|
2007-06-07 17:34:54 +08:00
|
|
|
void TextDiagnosticPrinter::
|
2009-01-27 15:57:44 +08:00
|
|
|
PrintIncludeStack(SourceLocation Loc, const SourceManager &SM) {
|
|
|
|
if (Loc.isInvalid()) return;
|
2007-07-21 00:37:10 +08:00
|
|
|
|
2009-01-27 15:57:44 +08:00
|
|
|
PresumedLoc PLoc = SM.getPresumedLoc(Loc);
|
2007-07-21 00:37:10 +08:00
|
|
|
|
2007-06-07 17:34:54 +08:00
|
|
|
// Print out the other include frames first.
|
2009-01-27 15:57:44 +08:00
|
|
|
PrintIncludeStack(PLoc.getIncludeLoc(), SM);
|
2009-04-21 11:57:54 +08:00
|
|
|
|
|
|
|
if (ShowLocation)
|
|
|
|
OS << "In file included from " << PLoc.getFilename()
|
|
|
|
<< ':' << PLoc.getLine() << ":\n";
|
|
|
|
else
|
|
|
|
OS << "In included file:\n";
|
2007-06-07 17:34:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// HighlightRange - Given a SourceRange and a line number, highlight (with ~'s)
|
|
|
|
/// any characters in LineNo that intersect the SourceRange.
|
2007-12-12 05:27:55 +08:00
|
|
|
void TextDiagnosticPrinter::HighlightRange(const SourceRange &R,
|
2009-01-27 15:57:44 +08:00
|
|
|
const SourceManager &SM,
|
2009-01-17 16:45:21 +08:00
|
|
|
unsigned LineNo, FileID FID,
|
2008-08-10 03:58:22 +08:00
|
|
|
std::string &CaretLine,
|
2008-08-06 03:40:20 +08:00
|
|
|
const std::string &SourceLine) {
|
2008-08-10 03:58:22 +08:00
|
|
|
assert(CaretLine.size() == SourceLine.size() &&
|
|
|
|
"Expect a correspondence between source and caret line!");
|
2007-06-07 17:34:54 +08:00
|
|
|
if (!R.isValid()) return;
|
|
|
|
|
2009-01-27 15:57:44 +08:00
|
|
|
SourceLocation Begin = SM.getInstantiationLoc(R.getBegin());
|
|
|
|
SourceLocation End = SM.getInstantiationLoc(R.getEnd());
|
|
|
|
|
2009-02-17 13:19:10 +08:00
|
|
|
// 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;
|
|
|
|
|
2009-02-04 09:06:56 +08:00
|
|
|
unsigned StartLineNo = SM.getInstantiationLineNumber(Begin);
|
2009-01-27 15:57:44 +08:00
|
|
|
if (StartLineNo > LineNo || SM.getFileID(Begin) != FID)
|
2008-01-12 14:43:35 +08:00
|
|
|
return; // No intersection.
|
2007-06-07 17:34:54 +08:00
|
|
|
|
2009-02-04 09:06:56 +08:00
|
|
|
unsigned EndLineNo = SM.getInstantiationLineNumber(End);
|
2009-01-27 15:57:44 +08:00
|
|
|
if (EndLineNo < LineNo || SM.getFileID(End) != FID)
|
2008-01-12 14:43:35 +08:00
|
|
|
return; // No intersection.
|
2007-06-07 17:34:54 +08:00
|
|
|
|
|
|
|
// Compute the column number of the start.
|
|
|
|
unsigned StartColNo = 0;
|
|
|
|
if (StartLineNo == LineNo) {
|
2009-02-04 08:55:58 +08:00
|
|
|
StartColNo = SM.getInstantiationColumnNumber(Begin);
|
2007-06-07 17:34:54 +08:00
|
|
|
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.
|
2008-08-10 03:58:22 +08:00
|
|
|
unsigned EndColNo = CaretLine.size();
|
2007-06-07 17:34:54 +08:00
|
|
|
if (EndLineNo == LineNo) {
|
2009-02-04 08:55:58 +08:00
|
|
|
EndColNo = SM.getInstantiationColumnNumber(End);
|
2007-06-07 17:34:54 +08:00
|
|
|
if (EndColNo) {
|
|
|
|
--EndColNo; // Zero base the col #.
|
|
|
|
|
|
|
|
// Add in the length of the token, so that we cover multi-char tokens.
|
2009-04-15 07:22:57 +08:00
|
|
|
EndColNo += Lexer::MeasureTokenLength(End, SM, *LangOpts);
|
2007-06-07 17:34:54 +08:00
|
|
|
} else {
|
2008-08-10 03:58:22 +08:00
|
|
|
EndColNo = CaretLine.size();
|
2007-06-07 17:34:54 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Pick the last non-whitespace column.
|
2008-08-06 03:40:20 +08:00
|
|
|
if (EndColNo <= SourceLine.size())
|
|
|
|
while (EndColNo-1 &&
|
|
|
|
(SourceLine[EndColNo-1] == ' ' || SourceLine[EndColNo-1] == '\t'))
|
|
|
|
--EndColNo;
|
|
|
|
else
|
|
|
|
EndColNo = SourceLine.size();
|
2007-06-07 17:34:54 +08:00
|
|
|
|
|
|
|
// Fill the range with ~'s.
|
|
|
|
assert(StartColNo <= EndColNo && "Invalid range!");
|
2008-08-06 03:40:20 +08:00
|
|
|
for (unsigned i = StartColNo; i < EndColNo; ++i)
|
2008-08-10 03:58:22 +08:00
|
|
|
CaretLine[i] = '~';
|
2007-06-07 17:34:54 +08:00
|
|
|
}
|
|
|
|
|
2009-05-02 07:32:58 +08:00
|
|
|
/// \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,
|
2009-05-04 14:27:32 +08:00
|
|
|
unsigned EndOfCaretToken,
|
2009-05-02 07:32:58 +08:00
|
|
|
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;
|
2009-05-04 14:27:32 +08:00
|
|
|
|
|
|
|
// Make sure we don't chop the string shorter than the caret token
|
|
|
|
// itself.
|
|
|
|
if (CaretEnd < EndOfCaretToken)
|
|
|
|
CaretEnd = EndOfCaretToken;
|
|
|
|
|
2009-05-03 12:33:32 +08:00
|
|
|
// 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;
|
2009-05-02 07:32:58 +08:00
|
|
|
|
2009-05-03 12:33:32 +08:00
|
|
|
for (; FixItEnd != FixItStart; --FixItEnd)
|
|
|
|
if (!isspace(FixItInsertionLine[FixItEnd - 1]))
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (FixItStart < CaretStart)
|
|
|
|
CaretStart = FixItStart;
|
|
|
|
if (FixItEnd > CaretEnd)
|
|
|
|
CaretEnd = FixItEnd;
|
|
|
|
}
|
|
|
|
|
2009-05-02 07:32:58 +08:00
|
|
|
// 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.
|
2009-05-16 02:05:24 +08:00
|
|
|
if (Columns > 3 && CaretEnd < Columns - 3)
|
2009-05-02 07:32:58 +08:00
|
|
|
CaretStart = 0;
|
|
|
|
|
2009-05-16 02:05:24 +08:00
|
|
|
unsigned TargetColumns = Columns;
|
|
|
|
if (TargetColumns > 8)
|
|
|
|
TargetColumns -= 8; // Give us extra room for the ellipses.
|
2009-05-02 07:32:58 +08:00
|
|
|
unsigned SourceLength = SourceLine.size();
|
2009-05-04 14:45:38 +08:00
|
|
|
while ((CaretEnd - CaretStart) < TargetColumns) {
|
2009-05-02 07:32:58 +08:00
|
|
|
bool ExpandedRegion = false;
|
|
|
|
// Move the start of the interesting region left until we've
|
|
|
|
// pulled in something else interesting.
|
2009-05-04 14:45:38 +08:00
|
|
|
if (CaretStart == 1)
|
|
|
|
CaretStart = 0;
|
|
|
|
else if (CaretStart > 1) {
|
|
|
|
unsigned NewStart = CaretStart - 1;
|
2009-05-02 07:32:58 +08:00
|
|
|
|
2009-05-04 14:45:38 +08:00
|
|
|
// 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;
|
2009-05-02 07:32:58 +08:00
|
|
|
|
|
|
|
// If we're still within our limit, update the starting
|
|
|
|
// position within the source/caret line.
|
2009-05-04 14:45:38 +08:00
|
|
|
if (CaretEnd - NewStart <= TargetColumns) {
|
2009-05-02 07:32:58 +08:00
|
|
|
CaretStart = NewStart;
|
|
|
|
ExpandedRegion = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Move the end of the interesting region right until we've
|
|
|
|
// pulled in something else interesting.
|
2009-05-04 07:04:40 +08:00
|
|
|
if (CaretEnd != SourceLength) {
|
2009-05-02 07:32:58 +08:00
|
|
|
unsigned NewEnd = CaretEnd;
|
|
|
|
|
|
|
|
// Skip over any whitespace we see here; we're looking for
|
|
|
|
// another bit of interesting text.
|
2009-05-19 06:09:16 +08:00
|
|
|
while (NewEnd != SourceLength && isspace(SourceLine[NewEnd - 1]))
|
2009-05-02 07:32:58 +08:00
|
|
|
++NewEnd;
|
|
|
|
|
|
|
|
// Skip over this bit of "interesting" text.
|
2009-05-19 06:09:16 +08:00
|
|
|
while (NewEnd != SourceLength && !isspace(SourceLine[NewEnd - 1]))
|
2009-05-02 07:32:58 +08:00
|
|
|
++NewEnd;
|
|
|
|
|
|
|
|
if (NewEnd - CaretStart <= TargetColumns) {
|
|
|
|
CaretEnd = NewEnd;
|
|
|
|
ExpandedRegion = true;
|
|
|
|
}
|
|
|
|
}
|
2009-05-04 07:04:40 +08:00
|
|
|
|
|
|
|
if (!ExpandedRegion)
|
|
|
|
break;
|
2009-05-02 07:32:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// [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.
|
2009-05-03 12:12:51 +08:00
|
|
|
if (CaretEnd < SourceLine.size())
|
|
|
|
SourceLine.replace(CaretEnd, std::string::npos, "...");
|
2009-05-03 23:24:25 +08:00
|
|
|
if (CaretEnd < CaretLine.size())
|
|
|
|
CaretLine.erase(CaretEnd, std::string::npos);
|
2009-05-02 07:32:58 +08:00
|
|
|
if (FixItInsertionLine.size() > CaretEnd)
|
|
|
|
FixItInsertionLine.erase(CaretEnd, std::string::npos);
|
|
|
|
|
|
|
|
if (CaretStart > 2) {
|
2009-05-03 12:12:51 +08:00
|
|
|
SourceLine.replace(0, CaretStart, " ...");
|
|
|
|
CaretLine.replace(0, CaretStart, " ");
|
2009-05-02 07:32:58 +08:00
|
|
|
if (FixItInsertionLine.size() >= CaretStart)
|
2009-05-03 12:12:51 +08:00
|
|
|
FixItInsertionLine.replace(0, CaretStart, " ");
|
2009-05-02 07:32:58 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-02-20 08:18:51 +08:00
|
|
|
void TextDiagnosticPrinter::EmitCaretDiagnostic(SourceLocation Loc,
|
2009-02-20 08:25:28 +08:00
|
|
|
SourceRange *Ranges,
|
2009-02-20 08:18:51 +08:00
|
|
|
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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
SourceManager &SM,
|
|
|
|
const CodeModificationHint *Hints,
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
unsigned NumHints,
|
2009-05-02 07:32:58 +08:00
|
|
|
unsigned Columns) {
|
2009-02-17 16:44:50 +08:00
|
|
|
assert(!Loc.isInvalid() && "must have a valid source location here");
|
2009-05-06 06:03:18 +08:00
|
|
|
|
|
|
|
// 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.
|
2009-02-17 16:44:50 +08:00
|
|
|
if (!Loc.isFileID()) {
|
2009-02-19 02:50:45 +08:00
|
|
|
SourceLocation OneLevelUp = SM.getImmediateInstantiationRange(Loc).first;
|
2009-05-06 06:03:18 +08:00
|
|
|
// FIXME: Map ranges?
|
2009-05-06 12:43:47 +08:00
|
|
|
EmitCaretDiagnostic(OneLevelUp, Ranges, NumRanges, SM, 0, 0, Columns);
|
2009-02-20 08:25:28 +08:00
|
|
|
|
2009-05-06 06:03:18 +08:00
|
|
|
Loc = SM.getImmediateSpellingLoc(Loc);
|
|
|
|
|
2009-02-20 08:25:28 +08:00
|
|
|
// Map the ranges.
|
|
|
|
for (unsigned i = 0; i != NumRanges; ++i) {
|
|
|
|
SourceLocation S = Ranges[i].getBegin(), E = Ranges[i].getEnd();
|
2009-05-06 06:03:18 +08:00
|
|
|
if (S.isMacroID()) S = SM.getImmediateSpellingLoc(S);
|
|
|
|
if (E.isMacroID()) E = SM.getImmediateSpellingLoc(E);
|
2009-02-20 08:25:28 +08:00
|
|
|
Ranges[i] = SourceRange(S, E);
|
|
|
|
}
|
2009-02-17 16:44:50 +08:00
|
|
|
|
2009-04-21 11:57:54 +08:00
|
|
|
if (ShowLocation) {
|
2009-05-06 06:03:18 +08:00
|
|
|
std::pair<FileID, unsigned> IInfo = SM.getDecomposedInstantiationLoc(Loc);
|
|
|
|
|
2009-04-21 11:57:54 +08:00
|
|
|
// Emit the file/line/column that this expansion came from.
|
2009-05-06 06:03:18 +08:00
|
|
|
OS << SM.getBuffer(IInfo.first)->getBufferIdentifier() << ':'
|
|
|
|
<< SM.getLineNumber(IInfo.first, IInfo.second) << ':';
|
2009-04-21 11:57:54 +08:00
|
|
|
if (ShowColumn)
|
2009-05-06 06:03:18 +08:00
|
|
|
OS << SM.getColumnNumber(IInfo.first, IInfo.second) << ':';
|
2009-04-21 11:57:54 +08:00
|
|
|
OS << ' ';
|
|
|
|
}
|
|
|
|
OS << "note: instantiated from:\n";
|
2009-05-06 06:03:18 +08:00
|
|
|
|
2009-05-06 12:43:47 +08:00
|
|
|
EmitCaretDiagnostic(Loc, Ranges, NumRanges, SM, Hints, NumHints, Columns);
|
2009-05-06 06:03:18 +08:00
|
|
|
return;
|
2009-02-17 16:44:50 +08:00
|
|
|
}
|
2009-02-17 15:51:53 +08:00
|
|
|
|
|
|
|
// 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);
|
2009-05-04 14:27:32 +08:00
|
|
|
unsigned CaretEndColNo
|
|
|
|
= ColNo + Lexer::MeasureTokenLength(Loc, SM, *LangOpts);
|
|
|
|
|
2009-02-17 15:38:37 +08:00
|
|
|
// Rewind from the current position to the start of the line.
|
2009-02-17 15:51:53 +08:00
|
|
|
const char *TokPtr = BufStart+FileOffset;
|
|
|
|
const char *LineStart = TokPtr-ColNo+1; // Column # is 1-based.
|
|
|
|
|
2009-02-17 15:38:37 +08:00
|
|
|
|
|
|
|
// Compute the line end. Scan forward from the error position to the end of
|
|
|
|
// the line.
|
2009-02-17 15:51:53 +08:00
|
|
|
const char *LineEnd = TokPtr;
|
2009-03-08 16:11:22 +08:00
|
|
|
while (*LineEnd != '\n' && *LineEnd != '\r' && *LineEnd != '\0')
|
2009-02-17 15:38:37 +08:00
|
|
|
++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.
|
2009-02-20 08:18:51 +08:00
|
|
|
if (NumRanges) {
|
2009-02-17 15:51:53 +08:00
|
|
|
unsigned LineNo = SM.getLineNumber(FID, FileOffset);
|
|
|
|
|
2009-02-20 08:18:51 +08:00
|
|
|
for (unsigned i = 0, e = NumRanges; i != e; ++i)
|
|
|
|
HighlightRange(Ranges[i], SM, LineNo, FID, CaretLine, SourceLine);
|
2009-02-17 15:51:53 +08:00
|
|
|
}
|
2009-02-17 15:38:37 +08:00
|
|
|
|
|
|
|
// 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] == '~' ? '~' : ' ');
|
|
|
|
}
|
|
|
|
|
2009-04-29 06:33:16 +08:00
|
|
|
// 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;
|
|
|
|
}
|
2009-05-02 07:32:58 +08:00
|
|
|
|
|
|
|
std::string FixItInsertionLine;
|
2009-04-19 15:44:08 +08:00
|
|
|
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).
llvm-svn: 65570
2009-02-27 05:00:50 +08: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
|
2009-03-03 04:58:48 +08:00
|
|
|
= 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).
llvm-svn: 65570
2009-02-27 05:00:50 +08: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
|
|
|
|
= SM.getColumnNumber(HintLocInfo.first, HintLocInfo.second);
|
|
|
|
unsigned LastColumnModified
|
|
|
|
= HintColNo - 1 + Hint->CodeToInsert.size();
|
2009-05-02 07:32:58 +08:00
|
|
|
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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
std::copy(Hint->CodeToInsert.begin(), Hint->CodeToInsert.end(),
|
2009-05-02 07:32:58 +08:00
|
|
|
FixItInsertionLine.begin() + HintColNo - 1);
|
2009-05-03 12:33:32 +08:00
|
|
|
} 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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-05-02 07:32:58 +08: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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
|
2009-05-02 07:32:58 +08: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,
|
2009-05-04 14:27:32 +08:00
|
|
|
CaretEndColNo, Columns);
|
2009-05-02 07:32:58 +08:00
|
|
|
|
|
|
|
// 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';
|
2009-06-04 15:18:23 +08:00
|
|
|
|
|
|
|
if (UseColors)
|
|
|
|
OS.changeColor(caretColor, true);
|
2009-05-02 07:32:58 +08:00
|
|
|
OS << CaretLine << '\n';
|
2009-06-04 15:18:23 +08:00
|
|
|
if (UseColors)
|
|
|
|
OS.resetColor();
|
2009-05-02 07:32:58 +08:00
|
|
|
|
|
|
|
if (!FixItInsertionLine.empty()) {
|
2009-06-04 15:18:23 +08:00
|
|
|
if (UseColors)
|
|
|
|
// Print fixit line in color
|
|
|
|
OS.changeColor(fixitColor, false);
|
2009-05-02 07:32:58 +08:00
|
|
|
if (PrintRangeInfo)
|
|
|
|
OS << ' ';
|
|
|
|
OS << FixItInsertionLine << '\n';
|
2009-06-04 15:18:23 +08:00
|
|
|
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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
}
|
2009-02-17 15:38:37 +08:00
|
|
|
}
|
|
|
|
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08: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.
|
2009-05-03 11:52:38 +08:00
|
|
|
OS << '\n';
|
|
|
|
OS.write(&IndentStr[0], Indentation);
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
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;
|
|
|
|
}
|
2009-02-17 15:38:37 +08:00
|
|
|
|
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?!
llvm-svn: 59502
2008-11-18 15:04:44 +08:00
|
|
|
void TextDiagnosticPrinter::HandleDiagnostic(Diagnostic::Level Level,
|
|
|
|
const DiagnosticInfo &Info) {
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
// 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();
|
|
|
|
|
2009-01-27 15:57:44 +08:00
|
|
|
// If the location is specified, print out a file/line/col and include trace
|
|
|
|
// if enabled.
|
|
|
|
if (Info.getLocation().isValid()) {
|
2009-01-29 04:47:47 +08:00
|
|
|
const SourceManager &SM = Info.getLocation().getManager();
|
2009-01-27 15:57:44 +08:00
|
|
|
PresumedLoc PLoc = SM.getPresumedLoc(Info.getLocation());
|
|
|
|
unsigned LineNo = PLoc.getLine();
|
2007-06-07 17:34:54 +08:00
|
|
|
|
|
|
|
// First, if this diagnostic is not in the main file, print out the
|
|
|
|
// "included from" lines.
|
2009-01-27 15:57:44 +08:00
|
|
|
if (LastWarningLoc != PLoc.getIncludeLoc()) {
|
|
|
|
LastWarningLoc = PLoc.getIncludeLoc();
|
|
|
|
PrintIncludeStack(LastWarningLoc, SM);
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
StartOfLocationInfo = OS.tell();
|
2007-06-07 17:34:54 +08:00
|
|
|
}
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
|
2009-01-27 15:57:44 +08:00
|
|
|
// Compute the column number.
|
2009-01-31 01:41:53 +08:00
|
|
|
if (ShowLocation) {
|
2009-06-04 15:18:23 +08:00
|
|
|
if (UseColors)
|
|
|
|
OS.changeColor(savedColor, true);
|
2009-01-31 01:41:53 +08:00
|
|
|
OS << PLoc.getFilename() << ':' << LineNo << ':';
|
2009-02-17 15:34:34 +08:00
|
|
|
if (ShowColumn)
|
|
|
|
if (unsigned ColNo = PLoc.getColumn())
|
|
|
|
OS << ColNo << ':';
|
2009-03-13 09:08:23 +08:00
|
|
|
|
|
|
|
if (PrintRangeInfo && Info.getNumRanges()) {
|
|
|
|
FileID CaretFileID =
|
|
|
|
SM.getFileID(SM.getInstantiationLoc(Info.getLocation()));
|
|
|
|
bool PrintedRange = false;
|
|
|
|
|
|
|
|
for (unsigned i = 0, e = Info.getNumRanges(); i != e; ++i) {
|
2009-04-20 06:24:10 +08:00
|
|
|
// Ignore invalid ranges.
|
|
|
|
if (!Info.getRange(i).isValid()) continue;
|
|
|
|
|
2009-03-13 09:08:23 +08:00
|
|
|
SourceLocation B = Info.getRange(i).getBegin();
|
|
|
|
SourceLocation E = Info.getRange(i).getEnd();
|
2009-06-15 13:18:27 +08:00
|
|
|
B = SM.getInstantiationLoc(B);
|
2009-03-13 09:08:23 +08:00
|
|
|
E = SM.getInstantiationLoc(E);
|
2009-06-15 13:18:27 +08:00
|
|
|
|
|
|
|
// 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);
|
2009-03-13 09:08:23 +08:00
|
|
|
std::pair<FileID, unsigned> EInfo = SM.getDecomposedLoc(E);
|
|
|
|
|
|
|
|
// If the start or end of the range is in another file, just discard
|
|
|
|
// it.
|
|
|
|
if (BInfo.first != CaretFileID || EInfo.first != CaretFileID)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Add in the length of the token, so that we cover multi-char tokens.
|
2009-04-15 07:22:57 +08:00
|
|
|
unsigned TokSize = Lexer::MeasureTokenLength(E, SM, *LangOpts);
|
2009-03-13 09:08:23 +08: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;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (PrintedRange)
|
|
|
|
OS << ':';
|
|
|
|
}
|
2009-01-31 01:41:53 +08:00
|
|
|
OS << ' ';
|
2009-06-04 15:18:23 +08:00
|
|
|
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;
|
2009-01-31 01:41:53 +08:00
|
|
|
}
|
2007-06-07 17:34:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
switch (Level) {
|
2009-02-06 11:57:44 +08:00
|
|
|
case Diagnostic::Ignored: assert(0 && "Invalid diagnostic type");
|
2008-04-18 02:06:57 +08:00
|
|
|
case Diagnostic::Note: OS << "note: "; break;
|
|
|
|
case Diagnostic::Warning: OS << "warning: "; break;
|
|
|
|
case Diagnostic::Error: OS << "error: "; break;
|
2009-02-06 11:57:44 +08:00
|
|
|
case Diagnostic::Fatal: OS << "fatal error: "; break;
|
2007-06-07 17:34:54 +08:00
|
|
|
}
|
2009-06-04 15:18:23 +08:00
|
|
|
|
|
|
|
if (UseColors)
|
|
|
|
OS.resetColor();
|
|
|
|
|
2008-11-19 14:51:40 +08:00
|
|
|
llvm::SmallString<100> OutStr;
|
|
|
|
Info.FormatDiagnostic(OutStr);
|
2009-04-16 13:44:38 +08:00
|
|
|
|
|
|
|
if (PrintDiagnosticOption)
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
if (const char *Opt = Diagnostic::getWarningOptionForDiag(Info.getID())) {
|
|
|
|
OutStr += " [-W";
|
|
|
|
OutStr += Opt;
|
|
|
|
OutStr += ']';
|
|
|
|
}
|
2009-04-16 13:44:38 +08:00
|
|
|
|
2009-06-04 15:18:23 +08:00
|
|
|
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
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
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;
|
2009-05-06 12:43:47 +08:00
|
|
|
PrintWordWrapped(OS, OutStr, MessageLength, Column);
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
} else {
|
|
|
|
OS.write(OutStr.begin(), OutStr.size());
|
|
|
|
}
|
2008-11-19 14:51:40 +08:00
|
|
|
OS << '\n';
|
2009-06-04 15:18:23 +08:00
|
|
|
if (UseColors)
|
|
|
|
OS.resetColor();
|
2007-06-07 17:34:54 +08:00
|
|
|
|
2009-03-11 04:44:00 +08:00
|
|
|
// 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.
|
2009-01-27 15:57:44 +08:00
|
|
|
if (CaretDiagnostics && Info.getLocation().isValid() &&
|
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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
((LastLoc != Info.getLocation()) || Info.getNumRanges() ||
|
2009-03-11 04:44:00 +08:00
|
|
|
(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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
Info.getNumCodeModificationHints())) {
|
2008-02-09 06:06:17 +08:00
|
|
|
// Cache the LastLoc, it allows us to omit duplicate source/caret spewage.
|
2009-01-27 15:57:44 +08:00
|
|
|
LastLoc = Info.getLocation();
|
2009-03-11 04:44:00 +08:00
|
|
|
LastCaretDiagnosticWasNote = (Level == Diagnostic::Note);
|
2009-01-27 15:57:44 +08:00
|
|
|
|
2009-02-20 08:18:51 +08:00
|
|
|
// 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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
SourceRange Ranges[20];
|
2009-02-20 08:18:51 +08:00
|
|
|
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).
llvm-svn: 65570
2009-02-27 05:00:50 +08:00
|
|
|
assert(NumRanges < 20 && "Out of space");
|
2009-02-20 08:18:51 +08:00
|
|
|
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).
llvm-svn: 65570
2009-02-27 05:00:50 +08: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(),
|
Implement -fmessage-length=N, which word-wraps diagnostics to N columns.
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>.
llvm-svn: 70578
2009-05-02 05:53:04 +08:00
|
|
|
Info.getNumCodeModificationHints(),
|
2009-05-02 07:32:58 +08:00
|
|
|
MessageLength);
|
2007-06-07 17:34:54 +08:00
|
|
|
}
|
2008-11-19 14:56:25 +08:00
|
|
|
|
|
|
|
OS.flush();
|
2007-06-07 17:34:54 +08:00
|
|
|
}
|