2009-06-21 05:36:54 +02:00
|
|
|
//===- SourceMgr.cpp - Manager for Simple Source Buffers & Diagnostics ----===//
|
2009-03-13 08:05:43 +01:00
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2009-03-13 08:05:43 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2009-06-21 05:36:54 +02:00
|
|
|
// This file implements the SourceMgr class. This class is used as a simple
|
|
|
|
// substrate for diagnostics, #include handling, and other low level things for
|
|
|
|
// simple parsers.
|
2009-03-13 08:05:43 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-06-06 13:49:48 +02:00
|
|
|
#include "llvm/Support/SourceMgr.h"
|
2017-02-15 23:17:02 +01:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2016-08-12 02:18:03 +02:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2017-06-06 13:49:48 +02:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2017-02-15 23:17:02 +01:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/ADT/Twine.h"
|
2017-02-15 23:17:02 +01:00
|
|
|
#include "llvm/Support/ErrorOr.h"
|
2013-01-10 19:50:15 +01:00
|
|
|
#include "llvm/Support/Locale.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/Support/MemoryBuffer.h"
|
2014-05-16 15:16:30 +02:00
|
|
|
#include "llvm/Support/Path.h"
|
2017-02-15 23:17:02 +01:00
|
|
|
#include "llvm/Support/SMLoc.h"
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
#include "llvm/Support/WithColor.h"
|
2017-06-06 13:49:48 +02:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2017-02-15 23:17:02 +01:00
|
|
|
#include <algorithm>
|
|
|
|
#include <cassert>
|
|
|
|
#include <cstddef>
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
#include <limits>
|
2017-02-15 23:17:02 +01:00
|
|
|
#include <memory>
|
|
|
|
#include <string>
|
|
|
|
#include <utility>
|
|
|
|
|
2009-03-13 08:05:43 +01:00
|
|
|
using namespace llvm;
|
|
|
|
|
2013-01-10 19:50:15 +01:00
|
|
|
static const size_t TabStop = 8;
|
|
|
|
|
2014-07-09 10:30:15 +02:00
|
|
|
unsigned SourceMgr::AddIncludeFile(const std::string &Filename,
|
|
|
|
SMLoc IncludeLoc,
|
|
|
|
std::string &IncludedFile) {
|
2011-06-01 15:10:15 +02:00
|
|
|
IncludedFile = Filename;
|
2014-07-06 19:43:13 +02:00
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> NewBufOrErr =
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
MemoryBuffer::getFile(IncludedFile);
|
2009-06-21 07:06:04 +02:00
|
|
|
|
|
|
|
// If the file didn't exist directly, see if it's in an include path.
|
2014-07-06 19:43:13 +02:00
|
|
|
for (unsigned i = 0, e = IncludeDirectories.size(); i != e && !NewBufOrErr;
|
|
|
|
++i) {
|
|
|
|
IncludedFile =
|
|
|
|
IncludeDirectories[i] + sys::path::get_separator().data() + Filename;
|
2014-11-06 02:13:27 +01:00
|
|
|
NewBufOrErr = MemoryBuffer::getFile(IncludedFile);
|
2009-06-21 07:06:04 +02:00
|
|
|
}
|
2010-01-27 11:13:11 +01:00
|
|
|
|
2014-07-06 19:43:13 +02:00
|
|
|
if (!NewBufOrErr)
|
2014-07-06 12:33:31 +02:00
|
|
|
return 0;
|
2009-06-21 07:06:04 +02:00
|
|
|
|
2014-08-21 22:44:56 +02:00
|
|
|
return AddNewSourceBuffer(std::move(*NewBufOrErr), IncludeLoc);
|
2009-06-21 07:06:04 +02:00
|
|
|
}
|
|
|
|
|
2014-07-06 12:33:31 +02:00
|
|
|
unsigned SourceMgr::FindBufferContainingLoc(SMLoc Loc) const {
|
2009-03-13 08:05:43 +01:00
|
|
|
for (unsigned i = 0, e = Buffers.size(); i != e; ++i)
|
2009-03-13 17:01:53 +01:00
|
|
|
if (Loc.getPointer() >= Buffers[i].Buffer->getBufferStart() &&
|
2009-03-18 21:36:45 +01:00
|
|
|
// Use <= here so that a pointer to the null at the end of the buffer
|
|
|
|
// is included as part of the buffer.
|
|
|
|
Loc.getPointer() <= Buffers[i].Buffer->getBufferEnd())
|
2014-07-06 12:33:31 +02:00
|
|
|
return i + 1;
|
|
|
|
return 0;
|
2009-03-13 08:05:43 +01:00
|
|
|
}
|
|
|
|
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
template <typename T>
|
2020-04-25 23:39:31 +02:00
|
|
|
static std::vector<T> &GetOrCreateOffsetCache(void *&OffsetCache,
|
|
|
|
MemoryBuffer *Buffer) {
|
|
|
|
if (OffsetCache)
|
|
|
|
return *static_cast<std::vector<T> *>(OffsetCache);
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
|
|
|
|
// Lazily fill in the offset cache.
|
|
|
|
auto *Offsets = new std::vector<T>();
|
|
|
|
size_t Sz = Buffer->getBufferSize();
|
|
|
|
assert(Sz <= std::numeric_limits<T>::max());
|
|
|
|
StringRef S = Buffer->getBuffer();
|
|
|
|
for (size_t N = 0; N < Sz; ++N) {
|
|
|
|
if (S[N] == '\n')
|
|
|
|
Offsets->push_back(static_cast<T>(N));
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
}
|
|
|
|
|
2020-04-25 23:39:31 +02:00
|
|
|
OffsetCache = Offsets;
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
return *Offsets;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
unsigned SourceMgr::SrcBuffer::getLineNumberSpecialized(const char *Ptr) const {
|
|
|
|
std::vector<T> &Offsets =
|
|
|
|
GetOrCreateOffsetCache<T>(OffsetCache, Buffer.get());
|
|
|
|
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
const char *BufStart = Buffer->getBufferStart();
|
|
|
|
assert(Ptr >= BufStart && Ptr <= Buffer->getBufferEnd());
|
|
|
|
ptrdiff_t PtrDiff = Ptr - BufStart;
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
assert(PtrDiff >= 0 &&
|
|
|
|
static_cast<size_t>(PtrDiff) <= std::numeric_limits<T>::max());
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
T PtrOffset = static_cast<T>(PtrDiff);
|
|
|
|
|
2019-06-21 07:40:31 +02:00
|
|
|
// llvm::lower_bound gives the number of EOL before PtrOffset. Add 1 to get
|
|
|
|
// the line number.
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
return llvm::lower_bound(Offsets, PtrOffset) - Offsets.begin() + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Look up a given \p Ptr in in the buffer, determining which line it came
|
|
|
|
/// from.
|
|
|
|
unsigned SourceMgr::SrcBuffer::getLineNumber(const char *Ptr) const {
|
|
|
|
size_t Sz = Buffer->getBufferSize();
|
|
|
|
if (Sz <= std::numeric_limits<uint8_t>::max())
|
|
|
|
return getLineNumberSpecialized<uint8_t>(Ptr);
|
|
|
|
else if (Sz <= std::numeric_limits<uint16_t>::max())
|
|
|
|
return getLineNumberSpecialized<uint16_t>(Ptr);
|
|
|
|
else if (Sz <= std::numeric_limits<uint32_t>::max())
|
|
|
|
return getLineNumberSpecialized<uint32_t>(Ptr);
|
|
|
|
else
|
|
|
|
return getLineNumberSpecialized<uint64_t>(Ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
template <typename T>
|
|
|
|
const char *SourceMgr::SrcBuffer::getPointerForLineNumberSpecialized(
|
|
|
|
unsigned LineNo) const {
|
|
|
|
std::vector<T> &Offsets =
|
|
|
|
GetOrCreateOffsetCache<T>(OffsetCache, Buffer.get());
|
|
|
|
|
|
|
|
// We start counting line and column numbers from 1.
|
|
|
|
if (LineNo != 0)
|
|
|
|
--LineNo;
|
|
|
|
|
|
|
|
const char *BufStart = Buffer->getBufferStart();
|
|
|
|
|
|
|
|
// The offset cache contains the location of the \n for the specified line,
|
|
|
|
// we want the start of the line. As such, we look for the previous entry.
|
|
|
|
if (LineNo == 0)
|
|
|
|
return BufStart;
|
|
|
|
if (LineNo > Offsets.size())
|
|
|
|
return nullptr;
|
|
|
|
return BufStart + Offsets[LineNo - 1] + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Return a pointer to the first character of the specified line number or
|
|
|
|
/// null if the line number is invalid.
|
|
|
|
const char *
|
|
|
|
SourceMgr::SrcBuffer::getPointerForLineNumber(unsigned LineNo) const {
|
|
|
|
size_t Sz = Buffer->getBufferSize();
|
|
|
|
if (Sz <= std::numeric_limits<uint8_t>::max())
|
|
|
|
return getPointerForLineNumberSpecialized<uint8_t>(LineNo);
|
|
|
|
else if (Sz <= std::numeric_limits<uint16_t>::max())
|
|
|
|
return getPointerForLineNumberSpecialized<uint16_t>(LineNo);
|
|
|
|
else if (Sz <= std::numeric_limits<uint32_t>::max())
|
|
|
|
return getPointerForLineNumberSpecialized<uint32_t>(LineNo);
|
|
|
|
else
|
|
|
|
return getPointerForLineNumberSpecialized<uint64_t>(LineNo);
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
SourceMgr::SrcBuffer::SrcBuffer(SourceMgr::SrcBuffer &&Other)
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
: Buffer(std::move(Other.Buffer)), OffsetCache(Other.OffsetCache),
|
|
|
|
IncludeLoc(Other.IncludeLoc) {
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
Other.OffsetCache = nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
SourceMgr::SrcBuffer::~SrcBuffer() {
|
2020-04-25 23:39:31 +02:00
|
|
|
if (OffsetCache) {
|
|
|
|
size_t Sz = Buffer->getBufferSize();
|
|
|
|
if (Sz <= std::numeric_limits<uint8_t>::max())
|
|
|
|
delete static_cast<std::vector<uint8_t> *>(OffsetCache);
|
|
|
|
else if (Sz <= std::numeric_limits<uint16_t>::max())
|
|
|
|
delete static_cast<std::vector<uint16_t> *>(OffsetCache);
|
|
|
|
else if (Sz <= std::numeric_limits<uint32_t>::max())
|
|
|
|
delete static_cast<std::vector<uint32_t> *>(OffsetCache);
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
else
|
2020-04-25 23:39:31 +02:00
|
|
|
delete static_cast<std::vector<uint64_t> *>(OffsetCache);
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
OffsetCache = nullptr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-05-06 00:17:32 +02:00
|
|
|
std::pair<unsigned, unsigned>
|
2014-07-06 12:33:31 +02:00
|
|
|
SourceMgr::getLineAndColumn(SMLoc Loc, unsigned BufferID) const {
|
|
|
|
if (!BufferID)
|
|
|
|
BufferID = FindBufferContainingLoc(Loc);
|
2020-09-22 19:58:54 +02:00
|
|
|
assert(BufferID && "Invalid location!");
|
2010-01-27 11:13:11 +01:00
|
|
|
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
auto &SB = getBufferInfo(BufferID);
|
|
|
|
const char *Ptr = Loc.getPointer();
|
|
|
|
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
unsigned LineNo = SB.getLineNumber(Ptr);
|
[Support] Make line-number cache robust against access patterns.
Summary:
The LLVM SourceMgr class (which is used indirectly by Swift, though not Clang)
has a routine for looking up line numbers of SMLocs. This routine uses a
shared, special-purpose cache that handles exactly one access pattern
efficiently: looking up the line number of an SMLoc that points into the same
buffer as the last query made to the SourceMgr, at a location in the buffer at
or ahead of the last query.
When this works it's fine, but when it fails it's catastrophic for performancer:
one recent out-of-order access from a Swift utility routine ran for tens of
seconds, spending 99% of its time repeatedly scanning buffers for '\n'.
This change removes the shared cache from the SourceMgr and installs a new
cache in each SrcBuffer. The per-SrcBuffer caches are also "full", in the sense
that rather than caching a single last-query pointer, they cache _all_ the
line-ending offsets, in a binary-searchable array, such that once it's
populated (on first access), all subsequent access patterns run at the same
speed.
Performance measurements I've done show this is actually a little bit faster on
real codebases (though only a couple fractions of a percent). Memory usage is
up by a few tens to hundreds of bytes per SrcBuffer that has a line lookup done
on it; I've attempted to minimize this by using dynamic selection of integer
sized when storing offset arrays. But the main motive here is to
make-impossible the cases we don't always see, that show up by surprise when
there is an out-of-order access pattern.
Reviewers: jordan_rose
Reviewed By: jordan_rose
Subscribers: probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45003
llvm-svn: 329470
2018-04-07 02:44:02 +02:00
|
|
|
const char *BufStart = SB.Buffer->getBufferStart();
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
size_t NewlineOffs = StringRef(BufStart, Ptr - BufStart).find_last_of("\n\r");
|
|
|
|
if (NewlineOffs == StringRef::npos)
|
|
|
|
NewlineOffs = ~(size_t)0;
|
|
|
|
return std::make_pair(LineNo, Ptr - BufStart - NewlineOffs);
|
|
|
|
}
|
|
|
|
|
2020-09-22 19:58:54 +02:00
|
|
|
// FIXME: Note that the formatting of source locations is spread between
|
|
|
|
// multiple functions, some in SourceMgr and some in SMDiagnostic. A better
|
|
|
|
// solution would be a general-purpose source location formatter
|
|
|
|
// in one of those two classes, or possibly in SMLoc.
|
|
|
|
|
|
|
|
/// Get a string with the source location formatted in the standard
|
|
|
|
/// style, but without the line offset. If \p IncludePath is true, the path
|
|
|
|
/// is included. If false, only the file name and extension are included.
|
|
|
|
std::string SourceMgr::getFormattedLocationNoOffset(SMLoc Loc,
|
|
|
|
bool IncludePath) const {
|
|
|
|
auto BufferID = FindBufferContainingLoc(Loc);
|
|
|
|
assert(BufferID && "Invalid location!");
|
|
|
|
auto FileSpec = getBufferInfo(BufferID).Buffer->getBufferIdentifier();
|
|
|
|
|
|
|
|
if (IncludePath) {
|
|
|
|
return FileSpec.str() + ":" + std::to_string(FindLineNumber(Loc, BufferID));
|
|
|
|
} else {
|
|
|
|
auto I = FileSpec.find_last_of("/\\");
|
|
|
|
I = (I == FileSpec.size()) ? 0 : (I + 1);
|
|
|
|
return FileSpec.substr(I).str() + ":" +
|
|
|
|
std::to_string(FindLineNumber(Loc, BufferID));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
/// Given a line and column number in a mapped buffer, turn it into an SMLoc.
|
|
|
|
/// This will return a null SMLoc if the line/column location is invalid.
|
|
|
|
SMLoc SourceMgr::FindLocForLineAndColumn(unsigned BufferID, unsigned LineNo,
|
|
|
|
unsigned ColNo) {
|
|
|
|
auto &SB = getBufferInfo(BufferID);
|
|
|
|
const char *Ptr = SB.getPointerForLineNumber(LineNo);
|
|
|
|
if (!Ptr)
|
|
|
|
return SMLoc();
|
|
|
|
|
|
|
|
// We start counting line and column numbers from 1.
|
|
|
|
if (ColNo != 0)
|
|
|
|
--ColNo;
|
|
|
|
|
|
|
|
// If we have a column number, validate it.
|
|
|
|
if (ColNo) {
|
|
|
|
// Make sure the location is within the current line.
|
|
|
|
if (Ptr + ColNo > SB.Buffer->getBufferEnd())
|
|
|
|
return SMLoc();
|
|
|
|
|
|
|
|
// Make sure there is no newline in the way.
|
|
|
|
if (StringRef(Ptr, ColNo).find_first_of("\n\r") != StringRef::npos)
|
|
|
|
return SMLoc();
|
|
|
|
|
|
|
|
Ptr += ColNo;
|
|
|
|
}
|
|
|
|
|
|
|
|
return SMLoc::getFromPointer(Ptr);
|
2009-03-13 08:05:43 +01:00
|
|
|
}
|
|
|
|
|
2009-07-03 00:24:20 +02:00
|
|
|
void SourceMgr::PrintIncludeStack(SMLoc IncludeLoc, raw_ostream &OS) const {
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
if (IncludeLoc == SMLoc())
|
|
|
|
return; // Top of stack.
|
2010-01-27 11:13:11 +01:00
|
|
|
|
2014-07-06 12:33:31 +02:00
|
|
|
unsigned CurBuf = FindBufferContainingLoc(IncludeLoc);
|
|
|
|
assert(CurBuf && "Invalid or unspecified location!");
|
2009-03-13 08:05:43 +01:00
|
|
|
|
2009-07-03 00:24:20 +02:00
|
|
|
PrintIncludeStack(getBufferInfo(CurBuf).IncludeLoc, OS);
|
2010-01-27 11:13:11 +01:00
|
|
|
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
OS << "Included from " << getBufferInfo(CurBuf).Buffer->getBufferIdentifier()
|
2009-07-03 00:24:20 +02:00
|
|
|
<< ":" << FindLineNumber(IncludeLoc, CurBuf) << ":\n";
|
2009-03-13 08:05:43 +01:00
|
|
|
}
|
|
|
|
|
2011-10-16 07:43:57 +02:00
|
|
|
SMDiagnostic SourceMgr::GetMessage(SMLoc Loc, SourceMgr::DiagKind Kind,
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
const Twine &Msg, ArrayRef<SMRange> Ranges,
|
2013-01-10 19:50:15 +01:00
|
|
|
ArrayRef<SMFixIt> FixIts) const {
|
2009-03-13 08:05:43 +01:00
|
|
|
// First thing to do: find the current buffer containing the specified
|
2012-05-06 18:20:49 +02:00
|
|
|
// location to pull out the source line.
|
2011-10-16 06:47:35 +02:00
|
|
|
SmallVector<std::pair<unsigned, unsigned>, 4> ColRanges;
|
2012-05-06 18:20:49 +02:00
|
|
|
std::pair<unsigned, unsigned> LineAndCol;
|
2016-10-01 18:38:28 +02:00
|
|
|
StringRef BufferID = "<unknown>";
|
2020-12-26 18:53:32 +01:00
|
|
|
StringRef LineStr;
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2012-05-06 18:20:49 +02:00
|
|
|
if (Loc.isValid()) {
|
2014-07-06 12:33:31 +02:00
|
|
|
unsigned CurBuf = FindBufferContainingLoc(Loc);
|
|
|
|
assert(CurBuf && "Invalid or unspecified location!");
|
2012-05-06 18:20:49 +02:00
|
|
|
|
2014-06-25 02:41:15 +02:00
|
|
|
const MemoryBuffer *CurMB = getMemoryBuffer(CurBuf);
|
2012-05-06 18:20:49 +02:00
|
|
|
BufferID = CurMB->getBufferIdentifier();
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2012-05-06 18:20:49 +02:00
|
|
|
// Scan backward to find the start of the line.
|
|
|
|
const char *LineStart = Loc.getPointer();
|
|
|
|
const char *BufStart = CurMB->getBufferStart();
|
|
|
|
while (LineStart != BufStart && LineStart[-1] != '\n' &&
|
|
|
|
LineStart[-1] != '\r')
|
|
|
|
--LineStart;
|
|
|
|
|
|
|
|
// Get the end of the line.
|
|
|
|
const char *LineEnd = Loc.getPointer();
|
|
|
|
const char *BufEnd = CurMB->getBufferEnd();
|
|
|
|
while (LineEnd != BufEnd && LineEnd[0] != '\n' && LineEnd[0] != '\r')
|
|
|
|
++LineEnd;
|
2020-12-26 18:53:32 +01:00
|
|
|
LineStr = StringRef(LineStart, LineEnd - LineStart);
|
2012-05-06 18:20:49 +02:00
|
|
|
|
|
|
|
// Convert any ranges to column ranges that only intersect the line of the
|
|
|
|
// location.
|
|
|
|
for (unsigned i = 0, e = Ranges.size(); i != e; ++i) {
|
|
|
|
SMRange R = Ranges[i];
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
if (!R.isValid())
|
|
|
|
continue;
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2012-05-06 18:20:49 +02:00
|
|
|
// If the line doesn't contain any part of the range, then ignore it.
|
|
|
|
if (R.Start.getPointer() > LineEnd || R.End.getPointer() < LineStart)
|
|
|
|
continue;
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2012-05-06 18:20:49 +02:00
|
|
|
// Ignore pieces of the range that go onto other lines.
|
|
|
|
if (R.Start.getPointer() < LineStart)
|
|
|
|
R.Start = SMLoc::getFromPointer(LineStart);
|
|
|
|
if (R.End.getPointer() > LineEnd)
|
|
|
|
R.End = SMLoc::getFromPointer(LineEnd);
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2012-05-06 18:20:49 +02:00
|
|
|
// Translate from SMLoc ranges to column ranges.
|
2013-01-10 19:50:15 +01:00
|
|
|
// FIXME: Handle multibyte characters.
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
ColRanges.push_back(std::make_pair(R.Start.getPointer() - LineStart,
|
|
|
|
R.End.getPointer() - LineStart));
|
2012-05-06 18:20:49 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
LineAndCol = getLineAndColumn(Loc, CurBuf);
|
2011-10-16 06:47:35 +02:00
|
|
|
}
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2012-05-06 18:20:49 +02:00
|
|
|
return SMDiagnostic(*this, Loc, BufferID, LineAndCol.first,
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
LineAndCol.second - 1, Kind, Msg.str(), LineStr,
|
|
|
|
ColRanges, FixIts);
|
2009-07-03 01:08:13 +02:00
|
|
|
}
|
|
|
|
|
2014-06-17 04:15:40 +02:00
|
|
|
void SourceMgr::PrintMessage(raw_ostream &OS, const SMDiagnostic &Diagnostic,
|
|
|
|
bool ShowColors) const {
|
2010-04-06 02:26:48 +02:00
|
|
|
// Report the message with the diagnostic handler if present.
|
|
|
|
if (DiagHandler) {
|
2011-10-16 07:43:57 +02:00
|
|
|
DiagHandler(Diagnostic, DiagContext);
|
2010-04-06 02:26:48 +02:00
|
|
|
return;
|
|
|
|
}
|
2010-12-09 18:37:32 +01:00
|
|
|
|
2014-06-17 04:15:40 +02:00
|
|
|
if (Diagnostic.getLoc().isValid()) {
|
2014-07-06 12:33:31 +02:00
|
|
|
unsigned CurBuf = FindBufferContainingLoc(Diagnostic.getLoc());
|
|
|
|
assert(CurBuf && "Invalid or unspecified location!");
|
2012-05-06 18:20:49 +02:00
|
|
|
PrintIncludeStack(getBufferInfo(CurBuf).IncludeLoc, OS);
|
|
|
|
}
|
2009-07-03 01:08:13 +02:00
|
|
|
|
2014-04-07 06:17:22 +02:00
|
|
|
Diagnostic.print(nullptr, OS, ShowColors);
|
2009-03-13 08:05:43 +01:00
|
|
|
}
|
2009-07-03 00:24:20 +02:00
|
|
|
|
2014-06-17 04:15:40 +02:00
|
|
|
void SourceMgr::PrintMessage(raw_ostream &OS, SMLoc Loc,
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
SourceMgr::DiagKind Kind, const Twine &Msg,
|
|
|
|
ArrayRef<SMRange> Ranges, ArrayRef<SMFixIt> FixIts,
|
|
|
|
bool ShowColors) const {
|
2014-06-17 04:15:40 +02:00
|
|
|
PrintMessage(OS, GetMessage(Loc, Kind, Msg, Ranges, FixIts), ShowColors);
|
|
|
|
}
|
|
|
|
|
2013-09-27 23:09:25 +02:00
|
|
|
void SourceMgr::PrintMessage(SMLoc Loc, SourceMgr::DiagKind Kind,
|
|
|
|
const Twine &Msg, ArrayRef<SMRange> Ranges,
|
|
|
|
ArrayRef<SMFixIt> FixIts, bool ShowColors) const {
|
2017-02-15 23:17:02 +01:00
|
|
|
PrintMessage(errs(), Loc, Kind, Msg, Ranges, FixIts, ShowColors);
|
2013-09-27 23:09:25 +02:00
|
|
|
}
|
|
|
|
|
2020-04-25 23:39:31 +02:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// SMFixIt Implementation
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
SMFixIt::SMFixIt(SMRange R, const Twine &Replacement)
|
|
|
|
: Range(R), Text(Replacement.str()) {
|
|
|
|
assert(R.isValid());
|
|
|
|
}
|
|
|
|
|
2009-07-03 00:24:20 +02:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// SMDiagnostic Implementation
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2020-01-28 20:23:46 +01:00
|
|
|
SMDiagnostic::SMDiagnostic(const SourceMgr &sm, SMLoc L, StringRef FN, int Line,
|
|
|
|
int Col, SourceMgr::DiagKind Kind, StringRef Msg,
|
|
|
|
StringRef LineStr,
|
|
|
|
ArrayRef<std::pair<unsigned, unsigned>> Ranges,
|
2013-01-10 19:50:15 +01:00
|
|
|
ArrayRef<SMFixIt> Hints)
|
2020-01-28 20:23:46 +01:00
|
|
|
: SM(&sm), Loc(L), Filename(std::string(FN)), LineNo(Line), ColumnNo(Col),
|
2020-12-26 18:53:32 +01:00
|
|
|
Kind(Kind), Message(Msg), LineContents(LineStr), Ranges(Ranges.vec()),
|
|
|
|
FixIts(Hints.begin(), Hints.end()) {
|
llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52573
llvm-svn: 343163
2018-09-27 04:13:45 +02:00
|
|
|
llvm::sort(FixIts);
|
2013-01-10 19:50:15 +01:00
|
|
|
}
|
|
|
|
|
2013-02-15 13:30:38 +01:00
|
|
|
static void buildFixItLine(std::string &CaretLine, std::string &FixItLine,
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
ArrayRef<SMFixIt> FixIts,
|
|
|
|
ArrayRef<char> SourceLine) {
|
2013-01-10 19:50:15 +01:00
|
|
|
if (FixIts.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
const char *LineStart = SourceLine.begin();
|
|
|
|
const char *LineEnd = SourceLine.end();
|
|
|
|
|
|
|
|
size_t PrevHintEndCol = 0;
|
|
|
|
|
2020-12-26 18:53:32 +01:00
|
|
|
for (const llvm::SMFixIt &Fixit : FixIts) {
|
2013-01-10 19:50:15 +01:00
|
|
|
// If the fixit contains a newline or tab, ignore it.
|
2020-12-26 18:53:32 +01:00
|
|
|
if (Fixit.getText().find_first_of("\n\r\t") != StringRef::npos)
|
2013-01-10 19:50:15 +01:00
|
|
|
continue;
|
|
|
|
|
2020-12-26 18:53:32 +01:00
|
|
|
SMRange R = Fixit.getRange();
|
2013-01-10 19:50:15 +01:00
|
|
|
|
|
|
|
// If the line doesn't contain any part of the range, then ignore it.
|
|
|
|
if (R.Start.getPointer() > LineEnd || R.End.getPointer() < LineStart)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Translate from SMLoc to column.
|
|
|
|
// Ignore pieces of the range that go onto other lines.
|
|
|
|
// FIXME: Handle multibyte characters in the source line.
|
|
|
|
unsigned FirstCol;
|
|
|
|
if (R.Start.getPointer() < LineStart)
|
|
|
|
FirstCol = 0;
|
|
|
|
else
|
|
|
|
FirstCol = R.Start.getPointer() - LineStart;
|
|
|
|
|
|
|
|
// If we inserted a long previous hint, push this one forwards, and add
|
|
|
|
// an extra space to show that this is not part of the previous
|
|
|
|
// completion. This is sort of the best we can do when two hints appear
|
|
|
|
// to overlap.
|
|
|
|
//
|
|
|
|
// Note that if this hint is located immediately after the previous
|
|
|
|
// hint, no space will be added, since the location is more important.
|
|
|
|
unsigned HintCol = FirstCol;
|
|
|
|
if (HintCol < PrevHintEndCol)
|
|
|
|
HintCol = PrevHintEndCol + 1;
|
|
|
|
|
|
|
|
// FIXME: This assertion is intended to catch unintended use of multibyte
|
|
|
|
// characters in fixits. If we decide to do this, we'll have to track
|
|
|
|
// separate byte widths for the source and fixit lines.
|
2020-12-26 18:53:32 +01:00
|
|
|
assert((size_t)sys::locale::columnWidth(Fixit.getText()) ==
|
|
|
|
Fixit.getText().size());
|
2013-01-10 19:50:15 +01:00
|
|
|
|
|
|
|
// This relies on one byte per column in our fixit hints.
|
2020-12-26 18:53:32 +01:00
|
|
|
unsigned LastColumnModified = HintCol + Fixit.getText().size();
|
2013-01-10 19:50:15 +01:00
|
|
|
if (LastColumnModified > FixItLine.size())
|
|
|
|
FixItLine.resize(LastColumnModified, ' ');
|
|
|
|
|
2020-12-26 18:53:32 +01:00
|
|
|
llvm::copy(Fixit.getText(), FixItLine.begin() + HintCol);
|
2013-01-10 19:50:15 +01:00
|
|
|
|
|
|
|
PrevHintEndCol = LastColumnModified;
|
|
|
|
|
|
|
|
// For replacements, mark the removal range with '~'.
|
|
|
|
// FIXME: Handle multibyte characters in the source line.
|
|
|
|
unsigned LastCol;
|
|
|
|
if (R.End.getPointer() >= LineEnd)
|
|
|
|
LastCol = LineEnd - LineStart;
|
|
|
|
else
|
|
|
|
LastCol = R.End.getPointer() - LineStart;
|
|
|
|
|
|
|
|
std::fill(&CaretLine[FirstCol], &CaretLine[LastCol], '~');
|
|
|
|
}
|
2011-10-16 07:43:57 +02:00
|
|
|
}
|
2011-10-16 06:47:35 +02:00
|
|
|
|
2013-01-10 19:50:15 +01:00
|
|
|
static void printSourceLine(raw_ostream &S, StringRef LineContents) {
|
|
|
|
// Print out the source line one character at a time, so we can expand tabs.
|
|
|
|
for (unsigned i = 0, e = LineContents.size(), OutCol = 0; i != e; ++i) {
|
[Windows] Convert from UTF-8 to UTF-16 when writing to a Windows console
Summary:
Calling WriteConsoleW is the most reliable way to print Unicode
characters to a Windows console.
If binary data gets printed to the console, attempting to re-encode it
shouldn't be a problem, since garbage in can produce garbage out.
This breaks printing strings in the local codepage, which WriteConsoleA
knows how to handle. For example, this can happen when user source code
is encoded with the local codepage, and an LLVM tool quotes it while
emitting a caret diagnostic. This is unfortunate, but well-behaved tools
should validate that their input is UTF-8 and escape non-UTF-8
characters before sending them to raw_fd_ostream. Clang already does
this, but not all LLVM tools do this.
One drawback to the current implementation is printing a string a byte
at a time doesn't work. Consider this LLVM code:
for (char C : MyStr) outs() << C;
Because outs() is now unbuffered, we wil try to convert each byte to
UTF-16, which will fail. However, this already didn't work, so I think
we may as well update callers that do that as we find them to print
complete portions of strings. You can see a real example of this in my
patch to SourceMgr.cpp
Fixes PR38669 and PR36267.
Reviewers: zturner, efriedma
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D51558
llvm-svn: 341433
2018-09-05 02:08:56 +02:00
|
|
|
size_t NextTab = LineContents.find('\t', i);
|
|
|
|
// If there were no tabs left, print the rest, we are done.
|
|
|
|
if (NextTab == StringRef::npos) {
|
|
|
|
S << LineContents.drop_front(i);
|
|
|
|
break;
|
2013-01-10 19:50:15 +01:00
|
|
|
}
|
|
|
|
|
[Windows] Convert from UTF-8 to UTF-16 when writing to a Windows console
Summary:
Calling WriteConsoleW is the most reliable way to print Unicode
characters to a Windows console.
If binary data gets printed to the console, attempting to re-encode it
shouldn't be a problem, since garbage in can produce garbage out.
This breaks printing strings in the local codepage, which WriteConsoleA
knows how to handle. For example, this can happen when user source code
is encoded with the local codepage, and an LLVM tool quotes it while
emitting a caret diagnostic. This is unfortunate, but well-behaved tools
should validate that their input is UTF-8 and escape non-UTF-8
characters before sending them to raw_fd_ostream. Clang already does
this, but not all LLVM tools do this.
One drawback to the current implementation is printing a string a byte
at a time doesn't work. Consider this LLVM code:
for (char C : MyStr) outs() << C;
Because outs() is now unbuffered, we wil try to convert each byte to
UTF-16, which will fail. However, this already didn't work, so I think
we may as well update callers that do that as we find them to print
complete portions of strings. You can see a real example of this in my
patch to SourceMgr.cpp
Fixes PR38669 and PR36267.
Reviewers: zturner, efriedma
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D51558
llvm-svn: 341433
2018-09-05 02:08:56 +02:00
|
|
|
// Otherwise, print from i to NextTab.
|
|
|
|
S << LineContents.slice(i, NextTab);
|
|
|
|
OutCol += NextTab - i;
|
|
|
|
i = NextTab;
|
|
|
|
|
2013-01-10 19:50:15 +01:00
|
|
|
// If we have a tab, emit at least one space, then round up to 8 columns.
|
|
|
|
do {
|
|
|
|
S << ' ';
|
|
|
|
++OutCol;
|
|
|
|
} while ((OutCol % TabStop) != 0);
|
|
|
|
}
|
|
|
|
S << '\n';
|
|
|
|
}
|
2011-10-16 06:47:35 +02:00
|
|
|
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
static bool isNonASCII(char c) { return c & 0x80; }
|
2013-01-11 03:37:55 +01:00
|
|
|
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
void SMDiagnostic::print(const char *ProgName, raw_ostream &OS, bool ShowColors,
|
|
|
|
bool ShowKindLabel) const {
|
2020-06-08 18:46:34 +02:00
|
|
|
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
|
|
|
|
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
{
|
2020-06-08 18:46:34 +02:00
|
|
|
WithColor S(OS, raw_ostream::SAVEDCOLOR, true, false, Mode);
|
2012-04-18 21:04:15 +02:00
|
|
|
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
if (ProgName && ProgName[0])
|
|
|
|
S << ProgName << ": ";
|
2012-04-18 21:04:15 +02:00
|
|
|
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
if (!Filename.empty()) {
|
|
|
|
if (Filename == "-")
|
|
|
|
S << "<stdin>";
|
|
|
|
else
|
|
|
|
S << Filename;
|
2009-07-03 00:24:20 +02:00
|
|
|
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
if (LineNo != -1) {
|
|
|
|
S << ':' << LineNo;
|
|
|
|
if (ColumnNo != -1)
|
|
|
|
S << ':' << (ColumnNo + 1);
|
|
|
|
}
|
|
|
|
S << ": ";
|
2010-01-21 11:13:27 +01:00
|
|
|
}
|
2009-07-03 00:24:20 +02:00
|
|
|
}
|
2010-01-27 11:13:11 +01:00
|
|
|
|
2015-06-15 22:30:22 +02:00
|
|
|
if (ShowKindLabel) {
|
|
|
|
switch (Kind) {
|
|
|
|
case SourceMgr::DK_Error:
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
WithColor::error(OS, "", !ShowColors);
|
2015-06-15 22:30:22 +02:00
|
|
|
break;
|
|
|
|
case SourceMgr::DK_Warning:
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
WithColor::warning(OS, "", !ShowColors);
|
2015-06-15 22:30:22 +02:00
|
|
|
break;
|
|
|
|
case SourceMgr::DK_Note:
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
WithColor::note(OS, "", !ShowColors);
|
2015-06-15 22:30:22 +02:00
|
|
|
break;
|
2017-10-13 01:56:02 +02:00
|
|
|
case SourceMgr::DK_Remark:
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
WithColor::remark(OS, "", !ShowColors);
|
2017-10-13 01:56:02 +02:00
|
|
|
break;
|
2015-06-15 22:30:22 +02:00
|
|
|
}
|
2012-04-18 21:04:15 +02:00
|
|
|
}
|
|
|
|
|
2020-06-08 18:46:34 +02:00
|
|
|
WithColor(OS, raw_ostream::SAVEDCOLOR, true, false, Mode) << Message << '\n';
|
2012-04-18 21:04:15 +02:00
|
|
|
|
2011-10-16 07:47:55 +02:00
|
|
|
if (LineNo == -1 || ColumnNo == -1)
|
2011-10-16 06:47:35 +02:00
|
|
|
return;
|
2010-01-27 11:13:11 +01:00
|
|
|
|
2013-01-11 03:37:55 +01:00
|
|
|
// FIXME: If there are multibyte or multi-column characters in the source, all
|
|
|
|
// our ranges will be wrong. To do this properly, we'll need a byte-to-column
|
|
|
|
// map like Clang's TextDiagnostic. For now, we'll just handle tabs by
|
|
|
|
// expanding them later, and bail out rather than show incorrect ranges and
|
|
|
|
// misaligned fixits for any other odd characters.
|
2021-01-04 20:42:47 +01:00
|
|
|
if (any_of(LineContents, isNonASCII)) {
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
printSourceLine(OS, LineContents);
|
2013-01-10 19:50:15 +01:00
|
|
|
return;
|
|
|
|
}
|
2013-01-11 03:37:55 +01:00
|
|
|
size_t NumColumns = LineContents.size();
|
2013-01-10 19:50:15 +01:00
|
|
|
|
2011-10-16 06:47:35 +02:00
|
|
|
// Build the line with the caret and ranges.
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
std::string CaretLine(NumColumns + 1, ' ');
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2011-10-16 06:47:35 +02:00
|
|
|
// Expand any ranges.
|
2020-12-26 18:53:32 +01:00
|
|
|
for (const std::pair<unsigned, unsigned> &R : Ranges)
|
2013-01-10 19:50:15 +01:00
|
|
|
std::fill(&CaretLine[R.first],
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
&CaretLine[std::min((size_t)R.second, CaretLine.size())], '~');
|
2013-01-10 19:50:15 +01:00
|
|
|
|
|
|
|
// Add any fix-its.
|
|
|
|
// FIXME: Find the beginning of the line properly for multibyte characters.
|
|
|
|
std::string FixItInsertionLine;
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
buildFixItLine(
|
|
|
|
CaretLine, FixItInsertionLine, FixIts,
|
|
|
|
makeArrayRef(Loc.getPointer() - ColumnNo, LineContents.size()));
|
2013-01-10 19:50:15 +01:00
|
|
|
|
2011-10-16 06:47:35 +02:00
|
|
|
// Finally, plop on the caret.
|
2013-01-10 19:50:15 +01:00
|
|
|
if (unsigned(ColumnNo) <= NumColumns)
|
2011-10-16 06:47:35 +02:00
|
|
|
CaretLine[ColumnNo] = '^';
|
2018-07-30 21:41:25 +02:00
|
|
|
else
|
2013-01-10 19:50:15 +01:00
|
|
|
CaretLine[NumColumns] = '^';
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2011-10-16 06:47:35 +02:00
|
|
|
// ... and remove trailing whitespace so the output doesn't wrap for it. We
|
|
|
|
// know that the line isn't completely empty because it has the caret in it at
|
|
|
|
// least.
|
[SourceMgr/MLIR diagnostics] Introduce a new method to speed things up
Summary:
This introduces a new SourceMgr::FindLocForLineAndColumn method that
uses the OffsetCache in SourceMgr::SrcBuffer to do do a constant time
lookup for the line number (once the cache is populated).
Use this method in MLIR's SourceMgrDiagnosticHandler::convertLocToSMLoc,
replacing the O(n) scanning logic. This resolves a long standing TODO
in MLIR, and makes one of my usecases go dramatically faster (which is
currently producing many diagnostics in a 40MB SourceBuffer).
NFC, this is just a performance speedup and cleanup.
Reviewers: rriddle!, ftynse!
Subscribers: hiraditya, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78868
2020-04-25 21:02:12 +02:00
|
|
|
CaretLine.erase(CaretLine.find_last_not_of(' ') + 1);
|
2018-07-30 21:41:25 +02:00
|
|
|
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
printSourceLine(OS, LineContents);
|
2011-10-16 06:47:35 +02:00
|
|
|
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
{
|
2020-06-08 18:46:34 +02:00
|
|
|
ColorMode Mode = ShowColors ? ColorMode::Auto : ColorMode::Disable;
|
|
|
|
WithColor S(OS, raw_ostream::GREEN, true, false, Mode);
|
2012-04-18 21:04:15 +02:00
|
|
|
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
// Print out the caret line, matching tabs in the source line.
|
|
|
|
for (unsigned i = 0, e = CaretLine.size(), OutCol = 0; i != e; ++i) {
|
|
|
|
if (i >= LineContents.size() || LineContents[i] != '\t') {
|
|
|
|
S << CaretLine[i];
|
|
|
|
++OutCol;
|
|
|
|
continue;
|
|
|
|
}
|
2018-10-22 20:51:29 +02:00
|
|
|
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
// Okay, we have a tab. Insert the appropriate number of characters.
|
|
|
|
do {
|
|
|
|
S << CaretLine[i];
|
|
|
|
++OutCol;
|
|
|
|
} while ((OutCol % TabStop) != 0);
|
|
|
|
}
|
|
|
|
S << '\n';
|
2009-07-03 00:24:20 +02:00
|
|
|
}
|
2013-01-10 19:50:15 +01:00
|
|
|
|
|
|
|
// Print out the replacement line, matching tabs in the source line.
|
|
|
|
if (FixItInsertionLine.empty())
|
|
|
|
return;
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2013-09-27 23:24:36 +02:00
|
|
|
for (size_t i = 0, e = FixItInsertionLine.size(), OutCol = 0; i < e; ++i) {
|
2013-01-10 19:50:15 +01:00
|
|
|
if (i >= LineContents.size() || LineContents[i] != '\t') {
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
OS << FixItInsertionLine[i];
|
2013-01-10 19:50:15 +01:00
|
|
|
++OutCol;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Okay, we have a tab. Insert the appropriate number of characters.
|
|
|
|
do {
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
OS << FixItInsertionLine[i];
|
2013-01-10 19:50:15 +01:00
|
|
|
// FIXME: This is trying not to break up replacements, but then to re-sync
|
|
|
|
// with the tabs between replacements. This will fail, though, if two
|
|
|
|
// fix-it replacements are exactly adjacent, or if a fix-it contains a
|
|
|
|
// space. Really we should be precomputing column widths, which we'll
|
|
|
|
// need anyway for multibyte chars.
|
|
|
|
if (FixItInsertionLine[i] != ' ')
|
|
|
|
++i;
|
|
|
|
++OutCol;
|
|
|
|
} while (((OutCol % TabStop) != 0) && i != e);
|
|
|
|
}
|
[SourceMgr][FileCheck] Obey -color by extending WithColor
(Relands r344930, reverted in r344935, and now hopefully fixed for
Windows.)
While this change specifically targets FileCheck, it affects any tool
using the same SourceMgr facilities.
Previously, -color was documented in FileCheck's -help output, but
-color had no effect. Now, -color obeys its documentation: it forces
colors to be used in FileCheck diagnostics even when stderr is not a
terminal.
-color is especially helpful when combined with FileCheck's -v, which
can produce a long series of diagnostics that you might wish to pipe
to a pager, such as less -R. The WithColor extensions here will also
help to clean up color usage in FileCheck's annotated dump of input,
which is proposed in D52999.
Reviewed By: JDevlieghere, zturner
Differential Revision: https://reviews.llvm.org/D53419
llvm-svn: 345202
2018-10-24 23:46:42 +02:00
|
|
|
OS << '\n';
|
2009-07-03 00:24:20 +02:00
|
|
|
}
|