BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.

The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.

One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.

This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.

llvm-svn: 181868

llvm-svn: 175264

Right now, only OS X has a way to determine the column width of a string
(PR14910). Until we have a good way to deal with this, we just won't
print carets, source ranges, or fixits for SMDiagnostic if the source line
has multibyte characters in it.

llvm-svn: 172164

Like Clang's FixItHint, SMFixIt represents an insertion, replacement, or
removal of source text. One or more fix-its can be emitted as part of
a diagnostic, and will be printed below the source range line to show the
user how they can fix their code.

Currently, the only client of SMFixIt is clang-tblgen; thus, the tests for
this behavior live in clang/test/TableGen/tg-fixits.td. If/when SMFixIt is
adopted within LLVM itself, those tests should be moved to the LLVM suite.

llvm-svn: 172086

This is necessary not only for representing empty ranges, but for handling
multibyte characters in the input. (If the end pointer in a range refers to
a multibyte character, should it point to the beginning or the end of the
character in a char array?) Some of the code in the asm parsers was already
assuming this anyway.

llvm-svn: 171765

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

color.

llvm-svn: 160559

Fixes a -Woverflow warning from gcc when building for 32-bit platforms.

llvm-svn: 156313

llvm-svn: 156260

of work for a drive-by fix :)

llvm-svn: 156246

llvm-svn: 156245

refactor some code to expose column numbers more and make diagnostic printing slightly more efficient.

llvm-svn: 156243

Same color scheme as clang uses. The colors are only enabled if the output is a tty.

llvm-svn: 155035

Removing unused default switch cases in switches over enums that already account for all enumeration values explicitly.

(This time I believe I've checked all the -Wreturn-type warnings from GCC & added the couple of llvm_unreachables necessary to silence them. If I've missed any, I'll happily fix them as soon as I know about them)

llvm-svn: 148262

llvm-svn: 142108

string, pass it around as an enum.

llvm-svn: 142107

the X86 asmparser to produce ranges in the one case that was annoying me, for example:

test.s:10:15: error: invalid operand for instruction
movl 0(%rax), 0(%edx)
              ^~~~~~~

It should be straight-forward to enhance filecheck, tblgen, and/or the .ll parser to use 
ranges where appropriate if someone is interested.

llvm-svn: 142106

llvm-svn: 132395

llvm-svn: 121958

llvm-svn: 121382

llvm-svn: 121379

cookie argument to the SourceMgr diagnostic stuff.  This cleanly separates
LLVMContext's inlineasm handler from the sourcemgr error handling 
definition, increasing type safety and cleaning things up.

llvm-svn: 119486

llvm-svn: 114847

Add a simplified constructor for clients that don't have locations
like "file not found" errors.

llvm-svn: 100538

llvm-svn: 100504

diagnostic handler.

llvm-svn: 100503

llvm-svn: 94672

llvm-svn: 94671

llvm-svn: 94071

llvm-svn: 89627

FindLineNumber much faster when in sequence.

llvm-svn: 78693

llvm-svn: 74735

it to print them.  This gives us column numbers in the diag line.  Before:

t.s:4: error: unexpected token in argument list
 mov %eax %edx
          ^

now:
t.s:4:11: error: unexpected token in argument list
 mov %eax %edx
          ^

llvm-svn: 74732

 - Don't print "Parsing" in front of every message.

 - Take additional "type" argument which is prepended to the message (with ": ")
   if given.

 - Update clients to print errors (warnings) as:
<filename>:<line number>: error(warning): ...

llvm-svn: 74489

llvm-svn: 73861

llvm-svn: 73845

llvm-svn: 73844

llvm-svn: 73843

llvm-svn: 73842

llvm-svn: 67758