| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 111314
|
|
|
|
| |
llvm-svn: 111105
|
|
|
|
| |
llvm-svn: 111091
|
|
|
|
| |
llvm-svn: 111084
|
|
|
|
|
|
| |
will apply all fixes even when there were other errors in the file.
llvm-svn: 111020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).
Also, smoosh the CastKind into the bitfield from Expr.
Drops two words of storage from Expr in the common case of expressions
which don't need inheritance paths. Avoids a separate allocation and
another word of overhead in cases needing inheritance paths. Also has
the advantage of not leaking memory, since destructors for AST nodes are
never run.
llvm-svn: 110507
|
|
|
|
|
|
|
| |
block's synthesized constructor initalizer list.
Fixes radar 8240371.
llvm-svn: 109698
|
|
|
|
|
|
|
| |
a copy initialization. Back out hack in objc rewriter.
fixes radar 8213998.
llvm-svn: 109024
|
|
|
|
|
|
|
| |
Constructor Initialization which computes Source Location
differently now. Fixes radar 8213998.
llvm-svn: 109018
|
|
|
|
| |
llvm-svn: 108807
|
|
|
|
| |
llvm-svn: 108633
|
|
|
|
| |
llvm-svn: 108375
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
llvm-svn: 108234
|
|
|
|
|
|
|
|
| |
This has 2 (slight) advantages:
-Make explicit at getBody()'s callsite that we expect/handle only CompoundStmt and not CXXTryStmt.
-Better tracking of Decl::getBody()'s callsites.
llvm-svn: 107771
|
|
|
|
|
|
| |
constructed one -- this is necessary to ensure types get printed correctly.
llvm-svn: 107312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to use them instead of SourceRange. CharSourceRange is just a SourceRange
plus a bool that indicates whether the range has the end character resolved
or whether the end location is the start of the end token. While most of
the compiler wants to think of ranges that have ends that are the start of
the end token, the printf diagnostic stuff wants to highlight ranges within
tokens.
This is transparent to the diagnostic stuff. To start taking advantage of
the new capabilities, you can do something like this:
Diag(..) << CharSourceRange::getCharRange(Begin,End)
llvm-svn: 106338
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
library configuration
Currently, all AST consumers are located in the Frontend library,
meaning that in a shared library configuration, Frontend has a
dependency on Rewrite, Checker and CodeGen. This is suboptimal for
clients which only wish to make use of the frontend. CodeGen in
particular introduces a large number of unwanted dependencies.
This patch breaks the dependency by moving all AST consumers with
dependencies on Rewrite, Checker and/or CodeGen to their respective
libraries. The patch therefore introduces dependencies in the other
direction (i.e. from Rewrite, Checker and CodeGen to Frontend).
After applying this patch, Clang builds correctly using CMake and
shared libraries ("cmake -DBUILD_SHARED_LIBS=ON").
N.B. This patch includes file renames which are indicated in the
patch body.
Changes in this revision of the patch:
- Fixed some copy-paste mistakes in the header files
- Modified certain aspects of the coding to comply with the LLVM
Coding Standards
llvm-svn: 106010
|
|
|
|
|
|
|
|
|
|
|
|
| |
Decl.cpp:716:28: warning: initialization of pointer of type 'clang::VarDecl *' from literal 'false' [-Wbool-conversions]
VarDecl *LastTentative = false;
^
RewriteRope.cpp:535:12: warning: initialization of pointer of type '<anonymous>::RopePieceBTreeNode *' from literal 'false'
[-Wbool-conversions]
return false;
^
llvm-svn: 105946
|
|
|
|
|
|
| |
scattered throughout the project Makefiles.
llvm-svn: 105638
|
|
|
|
|
|
| |
- This eliminates most dependencies on how Clang is installed relative to LLVM.
llvm-svn: 105637
|
|
|
|
|
|
|
| |
implementation today but is the right place if we want to make it faster some
day.
llvm-svn: 101521
|
|
|
|
|
|
| |
when avoiding paste. Patch by David Peixotto!
llvm-svn: 101218
|
|
|
|
|
|
| |
const char*.
llvm-svn: 98630
|
|
|
|
|
|
| |
and start simplifying the interfaces in SourceManager that can fail.
llvm-svn: 98594
|
|
|
|
| |
llvm-svn: 98591
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceManager's getBuffer() (and similar) operations. This abstract
can be used to force callers to cope with errors in getBuffer(), such
as missing files and changed files. Fix a bunch of callers to use the
new interface.
Add some very basic checks for file consistency (file size,
modification time) into ContentCache::getBuffer(), although these
checks don't help much until we've updated the main callers (e.g.,
SourceManager::getSpelling()).
llvm-svn: 98585
|
|
|
|
|
| |
Tested: make CPPFLAGS=-m64 CXXFLAGS=-m64 -j8 && (cd tools/clang;make test)
llvm-svn: 98399
|
|
|
|
|
|
| |
my recent changes.
llvm-svn: 95391
|
|
|
|
|
|
| |
(Radar 7583971).
llvm-svn: 94724
|
|
|
|
| |
llvm-svn: 94379
|
|
|
|
| |
llvm-svn: 94009
|
|
|
|
| |
llvm-svn: 92922
|
|
|
|
|
|
|
|
|
|
| |
stat a file but where mmaping it fails. In this case, we emit an
error like:
t.c:1:10: fatal error: error opening file '../../foo.h'
instead of "cannot find file".
llvm-svn: 90110
|
|
|
|
|
|
| |
ambiguity here
llvm-svn: 89054
|
|
|
|
|
|
|
|
|
| |
This is conceptually correct, but adds a huge hack to HighlightMacros which is
in fact doing all sorts of mutation to the Preprocessor. See FIXME.
Chris, please review.
llvm-svn: 86107
|
|
|
|
| |
llvm-svn: 86076
|
|
|
|
|
|
|
|
| |
counts of the bufffers referened by the RopePieces in
RopePieceBTreeLeaf. This (I believe) corrently fixes the leak I meant
to fix in r84601 (which ended up causing an overrelease).
llvm-svn: 84615
|
|
|
|
| |
llvm-svn: 84610
|
|
|
|
|
|
|
| |
This was causing a ton of memory to be leaked when using HTML
diagnostics with the static analyzer (on large files with many errors).
llvm-svn: 84601
|
|
|
|
| |
llvm-svn: 83582
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
| |
llvm-svn: 79824
|
|
|
|
| |
llvm-svn: 79460
|
|
|
|
|
|
|
| |
- Please accept my sincere apologies for the gratuitous elimination of code
duplication, manual string length counting, unnecessary strlen calls, etc.
llvm-svn: 79448
|
|
|
|
| |
llvm-svn: 79444
|
|
|
|
| |
llvm-svn: 79236
|
|
|
|
|
|
|
|
| |
in the HTMLRewriter.
This fixes PR 4602.
llvm-svn: 76647
|
|
|
|
| |
llvm-svn: 75832
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 74493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 72000
|