| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 95894
|
| |
|
|
| |
llvm-svn: 95893
|
| |
|
|
| |
llvm-svn: 95888
|
| |
|
|
|
|
| |
complete function type of the member functions (using PredefinedExpr::ComputeName.
llvm-svn: 95887
|
| |
|
|
| |
llvm-svn: 95886
|
| |
|
|
| |
llvm-svn: 95876
|
| |
|
|
| |
llvm-svn: 95874
|
| |
|
|
| |
llvm-svn: 95872
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
their spelling location. This prevents warnings from being swallowed just
because the caret is on the first parenthesis in, say, NULL.
This is an experiment; the risk is that there might be a substantial number
of system headers which #define symbols to expressions which inherently cause
warnings. My theory is that that's rare enough that it can be worked
around case-by-case, and that producing useful warnings around NULL is worth
it. But I'm willing to accept that I might be empirically wrong.
llvm-svn: 95870
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Enhance the printf format string checking when using the format
specifier flags ' ', '0', '+' with the 'p' or 's' conversions (since
they are nonsensical and undefined). This is similar to GCC's
checking.
Also warning when a precision is used with the 'p' conversin
specifier, since it has no meaning.
llvm-svn: 95869
|
| |
|
|
|
|
|
|
| |
Right now, it's off by default but can be tested by passing -fdump-vtable-layouts to clang -cc1. This option will cause all vtables that will normally be emitted as part of codegen to also be dumped using the new layout code.
I've also added a very simple new vtable layout test case.
llvm-svn: 95865
|
| |
|
|
| |
llvm-svn: 95864
|
| |
|
|
|
|
|
|
| |
array associated with NonNullAttr. This fixes yet another leak when
ASTContext uses a BumpPtrAllocator.
Fixes: <rdar://problem/7637150>
llvm-svn: 95863
|
| |
|
|
|
|
|
|
|
| |
storing the set of StoredDeclsMaps in an internal vector of void*.
This isn't an ideal solution, but for the time being this fixes a
major memory leak with these DenseMaps not being freed.
Fixes: <rdar://problem/7634755>
llvm-svn: 95861
|
| |
|
|
|
|
|
|
|
| |
array allocated using the allocator in ASTContext. This addresses
these strings getting leaked when using a BumpPtrAllocator (in
ASTContext).
Fixes: <rdar://problem/7636765>
llvm-svn: 95853
|
| |
|
|
| |
llvm-svn: 95849
|
| |
|
|
| |
llvm-svn: 95848
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we would just leak them all over the place, with no clear ownership of
these objects at all. AttributeList objects would get leaked on both
error and non-error paths.
Note: I introduced the usage of llvm::OwningPtr<AttributeList> to
manage these objects, which is particularly useful for methods with
multiple return sites. In at least one method I used them even when
they weren't strictly necessary because it clarified the ownership
semantics and made the code easier to read. Should the excessive
'take()' and 'reset()' calls become a performance issue we can always
re-evaluate.
Note+1: I believe I have not introduced any double-frees, but it would
be nice for someone to review this.
This fixes <rdar://problem/7635046>.
llvm-svn: 95847
|
| |
|
|
|
|
|
| |
template explicit specialization. Complete an apparently stalled refactor
towards using CheckSpecializationInstantiationRedecl().
llvm-svn: 95845
|
| |
|
|
| |
llvm-svn: 95843
|
| |
|
|
|
|
| |
Decl subclasses. No functionality change.
llvm-svn: 95841
|
| |
|
|
|
|
| |
using property dot-syntax. Fixes radar 7628953.
llvm-svn: 95838
|
| |
|
|
|
|
|
| |
and CXXRecordDecl::getDefinition(); it's totally unnecessary. No
functionality change.
llvm-svn: 95836
|
| |
|
|
|
|
| |
BumpPtrAllocator. Previously they were not getting freed. Fixes <rdar://problem/7635663>.
llvm-svn: 95834
|
| |
|
|
| |
llvm-svn: 95833
|
| |
|
|
|
|
| |
a __weak block. Fixes radar 7628591.
llvm-svn: 95822
|
| |
|
|
|
|
| |
Thanks, Anton!
llvm-svn: 95821
|
| |
|
|
|
|
|
|
| |
attribute, so it uses Anton's new target-specific attribute support. It's
supposed to ensure that the stack is 16-byte aligned, but since necessary
support is lacking from LLVM, this is a no-op for now.
llvm-svn: 95820
|
| |
|
|
| |
llvm-svn: 95812
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 95805
|
| |
|
|
| |
llvm-svn: 95800
|
| |
|
|
|
|
| |
Fixes radar 7630551
llvm-svn: 95796
|
| |
|
|
|
|
| |
translation units.
llvm-svn: 95794
|
| |
|
|
|
|
| |
in a declaration statement. Fixes radar 7628153.
llvm-svn: 95788
|
| |
|
|
|
|
|
| |
calls to the UnwindResumeOrRethrow function for C++/Obj-C exception handling,
for Darwin ARM.
llvm-svn: 95787
|
| |
|
|
| |
llvm-svn: 95786
|
| |
|
|
| |
llvm-svn: 95785
|
| |
|
|
|
|
| |
lame implementation for importing TypeSourceInfos.
llvm-svn: 95783
|
| |
|
|
|
|
|
|
| |
merged with variables of constant array types. Also, make sure that we
call DiagnosticClient's BeginSourceFile/EndSourceFile, so that it has
a LangOptions to work with.
llvm-svn: 95782
|
| |
|
|
|
|
|
| |
conversions. Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path. Prepare for friends.
llvm-svn: 95775
|
| |
|
|
| |
llvm-svn: 95772
|
| |
|
|
| |
llvm-svn: 95756
|
| |
|
|
| |
llvm-svn: 95755
|
| |
|
|
| |
llvm-svn: 95751
|
| |
|
|
|
|
| |
Fixes radar 7630636.
llvm-svn: 95744
|
| |
|
|
|
|
| |
self, _cmd etc.
llvm-svn: 95743
|
| |
|
|
|
|
| |
I don't have time to refix it for now.
llvm-svn: 95733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into another AST, including their include history. Here's an example
error that involves a conflict merging a variable with different types
in two translation units (diagnosed in the third AST context into
which everything is merged).
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var2.c:3:5:
error: external variable 'x2' declared with incompatible types in
different translation units ('int' vs. 'double')
int x2;
^
In file included from
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.c:3:
/Volumes/Data/dgregor/Projects/llvm/tools/clang/test/ASTMerge/Inputs/var1.h:1:8:
note: declared here with type 'double'
double x2;
^
Although we maintain include history, we do not maintain macro
instantiation history across a merge. Instead, we map down to the
spelling location (for now!).
llvm-svn: 95732
|
| |
|
|
| |
llvm-svn: 95726
|
| |
|
|
| |
llvm-svn: 95725
|