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
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
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
array associated with NonNullAttr. This fixes yet another leak when
ASTContext uses a BumpPtrAllocator.
Fixes: <rdar://problem/7637150>
llvm-svn: 95863
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
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
conversions. Fix an access-control bug where privileges were not considered
at intermediate points along the inheritance path. Prepare for friends.
llvm-svn: 95775
This is a non-fragile-abi feature only. Since it
breaks existing code, it is currently placed under
-fobjc-nonfragile-abi2 option for test purposes only
until further notice. WIP.
llvm-svn: 95685
Sema::ActOnUninitializedDecl over to InitializationSequence (with
default initialization), eliminating redundancy. More importantly, we
now check that a const definition in C++ has an initilizer, which was
an #if 0'd code for many, many months. A few other tweaks were needed
to get everything working again:
- Fix all of the places in the testsuite where we defined const
objects without initializers (now that we diagnose this issue)
- Teach instantiation of static data members to find the previous
declaration, so that we build proper redeclaration
chains. Previously, we had the redeclaration chain but built it
too late to be useful, because...
- Teach instantiation of static data member definitions not to try
to check an initializer if a previous declaration already had an
initializer. This makes sure that we don't complain about static
const data members with in-class initializers and out-of-line
definitions.
- Move all of the incomplete-type checking logic out of
Sema::FinalizeDeclaratorGroup; it makes more sense in
ActOnUnitializedDecl.
There may still be a few places where we can improve these
diagnostics. I'll address that as a separate commit.
llvm-svn: 95657
non-type template parameter that has reference type, augment the
qualifiers of the non-type template argument with those of the
referenced type. Fixes PR6250.
llvm-svn: 95607
deduction. This requires refactoring the deduction to have access to the Sema
object instead of merely the ASTContext. Still leaves something to be desired
due to poor source location.
Fixes PR6257 and half of PR6259.
llvm-svn: 95528
params. Don't insert addrof operations when matching against a pointer;
array/function conversions should take care of this for us, assuming the
argument type-checked in the first place. Add a fixme where we seem to be
using a less-restrictive reference type than we should.
Fixes PR 6249.
llvm-svn: 95495
type-checking within a template definition. In this case, the
"instantiated" declaration is just the declaration itself, found
within the current instantiation. Fixes PR6239.
llvm-svn: 95442
follows (as conservatively as possible) gcc's current behavior: attributes
written on return types that don't apply there are applied to the function
instead, etc. Only parse CC attributes as type attributes, not as decl attributes;
don't accepet noreturn as a decl attribute on ValueDecls, either (it still
needs to apply to other decls, like blocks). Consistently consume CC/noreturn
information throughout codegen; enforce this by removing their default values
in CodeGenTypes::getFunctionInfo().
llvm-svn: 95436
Fariborz Jahanian