| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
worth asserting about in this code: 1) if the source range
is bogus (begin loc after end loc), and 2) if the client
is trying to highlight a range that is purely whitespace.
It is possible to just silently ignore #2, but it seems like
it is always a bug, so lets keep asserting on this condition,
but with a better assert message.
llvm-svn: 95998
|
| |
|
|
| |
llvm-svn: 95994
|
| |
|
|
|
|
|
| |
with block-pointer-type as one or more of its
arguments. Fixes radar 7638400.
llvm-svn: 95992
|
| |
|
|
|
|
| |
within the declarator of another declaration, from Enea Zaffanella!
llvm-svn: 95991
|
| |
|
|
| |
llvm-svn: 95990
|
| |
|
|
|
|
| |
Daniel's suggestion.
llvm-svn: 95987
|
| |
|
|
|
|
| |
ASTContext::getFunctionType with the wrong set of arguments.
llvm-svn: 95986
|
| |
|
|
| |
llvm-svn: 95985
|
| |
|
|
| |
llvm-svn: 95984
|
| |
|
|
|
|
|
|
| |
guard macro is already defined for the first occurrence of the
header. If it is, the body will be skipped and not be properly
analyzed for the include guard optimization.
llvm-svn: 95972
|
| |
|
|
|
|
| |
to dump multiple address points for a single offset.
llvm-svn: 95970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
headers, where malloc (and many other libc functions) are declared
with empty throw specifications, e.g.,
extern void *malloc (__SIZE_TYPE__ __size) throw () __attribute__
((__malloc__)) ;
The C++ standard doesn't seem to allow this, and redeclaring malloc as
the standard permits (as follows) resulted in Clang (rightfully!)
complaining about mis-matched exception specifications.
void *malloc(size_t size);
We work around this by silently propagating an empty throw
specification "throw()" from a function with C linkage declared in a
system header to a redeclaration that has no throw specifier.
Ick.
llvm-svn: 95969
|
| |
|
|
|
|
| |
an overriden type only by reduced qualification.
llvm-svn: 95968
|
| |
|
|
|
|
|
|
| |
::__builtin_va_copy
Fixes one of the Firefox issues in PR5511.
llvm-svn: 95966
|
| |
|
|
| |
llvm-svn: 95965
|
| |
|
|
|
|
| |
in a single byte-load rather than some crazy bitmunging operation.
llvm-svn: 95964
|
| |
|
|
| |
llvm-svn: 95963
|
| |
|
|
| |
llvm-svn: 95954
|
| |
|
|
| |
llvm-svn: 95953
|
| |
|
|
| |
llvm-svn: 95952
|
| |
|
|
| |
llvm-svn: 95941
|
| |
|
|
| |
llvm-svn: 95940
|
| |
|
|
|
|
|
| |
pointer. If you don't like the new warning, you can turn it off with
-Wno-force-align-arg-pointer.
llvm-svn: 95939
|
| |
|
|
|
|
|
|
|
|
| |
not match
order of constructor arguments (all block API specific). This was exposed only in
a large block literal expression in a large file where PtrSet container size
execceded its limit and required reallocation. Fixes radar 7638294
llvm-svn: 95936
|
| |
|
|
|
|
|
|
| |
variable type, we can (and should) still check for completeness of the
variable's type. Do so, to work around an assertion that shows up in
Boost's shared_ptr.
llvm-svn: 95934
|
| |
|
|
|
|
| |
using 'new[]' instead of the allocator associated with ASTContext.
llvm-svn: 95933
|
| |
|
|
|
|
| |
assosciated with ASTContext.
llvm-svn: 95931
|
| |
|
|
|
|
| |
associated with ASTContext. This fixes yet another leak (<rdar://problem/7639260>).
llvm-svn: 95930
|
| |
|
|
| |
llvm-svn: 95922
|
| |
|
|
|
|
| |
this).
llvm-svn: 95911
|
| |
|
|
| |
llvm-svn: 95908
|
| |
|
|
| |
llvm-svn: 95906
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
incompatibility and show where the structural differences are. For
example:
struct1.c:36:8: warning: type 'struct S7' has incompatible definitions
in different translation units
struct S7 { int i : 8; unsigned j : 8; } x7;
^
struct1.c:36:33: note: bit-field 'j' with type 'unsigned int' and length 8 here
struct S7 { int i : 8; unsigned j : 8; } x7;
^
struct2.c:33:33: note: bit-field 'j' with type 'unsigned int' and length 16 here
struct S7 { int i : 8; unsigned j : 16; } x7;
^
There are a few changes to make this work:
- ASTImporter now has only a single Diagnostic object, not multiple
diagnostic objects. Otherwise, having a warning/error printed via
one Diagnostic and its note printed on the other Diagnostic could
cause the note to be suppressed.
- Implemented import functionality for IntegerLiteral (along with
general support for statements and expressions)
llvm-svn: 95900
|
| |
|
|
|
|
| |
complete function type of the member functions (using PredefinedExpr::ComputeName.
llvm-svn: 95887
|
| |
|
|
| |
llvm-svn: 95876
|
| |
|
|
| |
llvm-svn: 95874
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|