- Please accept my sincere apologies for the gratuitous elimination of code
duplication, manual string length counting, unnecessary strlen calls, etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79448 91177308-0d34-0410-b5e6-96231b3b80d8
This is simple enough, but then I thought it would be nice to make PrintingPolicy
get a LangOptions so that various things can key off "bool" and "C++" independently.
This spiraled out of control. There are many fixme's, but I think things are slightly
better than they were before.
One thing that can be improved: CFG should probably have an ASTContext pointer in it,
which would simplify its clients.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74493 91177308-0d34-0410-b5e6-96231b3b80d8
delta tree.
The issue is roughly a conflict in ReplaceText between two kinds of
uses. One, it should be possible to replace a replacement: for example, the
ObjC rewriter calls ReplaceStmt for an expression, then replaces the resulting
expression with another expression. Two, it should be possible to
replace text that already has text inserted before it: for example, the
HTML rewriter inserts a bunch of tags at the beginning of the line, then
tries to escape the first character on the line. This patch
distinguishes the two cases by storing the deltas separately;
essentially, replacements and insertions no longer interfere with
each other.
Another possibility would be to add some sort of flag to ReplaceText, but
this seems a bit more intuitive and flexible.
There are a few downsides to the current solution: one is that there isn't
any way to remove/replace an insertion without touching additional
surrounding text; if such an operation turns out to be useful, an
additional method or flag can be added. Another is that an insertion
and replacing a string of length zero are distinct operations; I'm not
sure how to resolve this, or whether it will be confusing in practice.
This is relatively sensitive code, so please test and tell me if
anything breaks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72000 91177308-0d34-0410-b5e6-96231b3b80d8
This allows it to accurately measure tokens, so that we get:
t.cpp:8:13: error: unknown type name 'X'
static foo::X P;
~~~~~^
instead of the woefully inferior:
t.cpp:8:13: error: unknown type name 'X'
static foo::X P;
~~~~ ^
Most of this is just plumbing to push the reference around.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69099 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostics. This builds on the patch that Sebastian committed and
then revert. Major differences are:
- We don't remove or use the current ".def" files. Instead, for now,
we just make sure that we're building the ".inc" files.
- Fixed CMake makefiles to run TableGen and build the ".inc" files
when needed. Tested with both the Xcode and Makefile generators
provided by CMake, so it should be solid.
- Fixed normal makefiles to handle out-of-source builds that involve
the ".inc" files.
I'll send a separate patch to the list with Sebastian's changes that
eliminate the use of the .def files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67058 91177308-0d34-0410-b5e6-96231b3b80d8
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
makes -emit-html do nice things for code like:
#define FOO(X) y
int FOO(4
);
highlighting the FOO instance as well as the ) on the next line properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64710 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation, which highlights the arguments of a function like macro
as well as its identifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64607 91177308-0d34-0410-b5e6-96231b3b80d8
wine sources. This was happening because HighlightMacros was
calling EnterMainFile multiple times on the same preprocessor
object and getting an assert due to the new #line stuff (the
file in question was bison output with #line directives).
The fix for this is to not reenter the file. Instead,
relex the tokens in raw mode, swizzle them a bit and repreprocess
the token stream. An added bonus of this is that rewrite macros
will now hilight the macro definition as well as its uses. Woo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64480 91177308-0d34-0410-b5e6-96231b3b80d8
only insert spaces between tokens if the code had them or if they
are actually required to avoid pasting. This reuses the same
logic as -E mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64421 91177308-0d34-0410-b5e6-96231b3b80d8
Token now has a class of kinds for "literals", which include
numeric constants, strings, etc. These tokens can optionally have
a pointer to the start of the token in the lexer buffer. This
makes it faster to get spelling and do other gymnastics, because we
don't have to go through source locations.
This change is performance neutral, but will make other changes
more feasible down the road.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63028 91177308-0d34-0410-b5e6-96231b3b80d8
ground work for implementing #line, and fixes the "out of macro ID's"
problem.
There is nothing particularly tricky about the code, other than the
very performance sensitive SourceManager::getFileID() method.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62978 91177308-0d34-0410-b5e6-96231b3b80d8
"FileID" a concept that is now enforced by the compiler's type checker
instead of yet-another-random-unsigned floating around.
This is an important distinction from the "FileID" currently tracked by
SourceLocation. *That* FileID may refer to the start of a file or to a
chunk within it. The new FileID *only* refers to the file (and its
#include stack and eventually #line data), it cannot refer to a chunk.
FileID is a completely opaque datatype to all clients, only SourceManager
is allowed to poke and prod it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62407 91177308-0d34-0410-b5e6-96231b3b80d8
using LexRawToken, create one and use LexFromRawLexer. This avoids
twiddling the RawLexer flag around and simplifies some code (even
speeding raw lexing up a tiny bit).
This change also improves the token paster to use a Lexer on the stack
instead of new/deleting it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57393 91177308-0d34-0410-b5e6-96231b3b80d8
"Here is a patch what replaces std::ostream with llvm::raw_ostream. This patch
covers the AST library, but ignores Analysis lib."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@56185 91177308-0d34-0410-b5e6-96231b3b80d8