| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
false positives.
llvm-svn: 96375
|
|
|
|
|
|
|
|
| |
Win32-specific.
Also, fix a test to use FileCheck instead of grepping LLVM IR.
llvm-svn: 96364
|
|
|
|
|
|
| |
arguments of asprintf (<rdar://problem/6657191>).
llvm-svn: 96319
|
|
|
|
| |
llvm-svn: 96311
|
|
|
|
|
|
|
|
|
|
| |
analyze_printf::ArgTypeResult.
Implement printf argument type checking for '%s'.
Fixes <rdar://problem/3065808>.
llvm-svn: 96310
|
|
|
|
|
|
| |
for __builtin_isinf and friends. Part of PR6083.
llvm-svn: 96291
|
|
|
|
| |
llvm-svn: 96054
|
|
|
|
|
|
| |
missing (in c/objc mode). Fixes radar 7528255.
llvm-svn: 96017
|
|
|
|
| |
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
|
|
|
|
|
|
| |
MSVC build.
llvm-svn: 95932
|
|
|
|
| |
llvm-svn: 95893
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
type (-Wswitch), from Michal!
llvm-svn: 95592
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 95291
|
|
|
|
|
|
|
| |
with a function with a prototype, treat parameters of enumeration type
based on the enumeration type's promotion type.
llvm-svn: 95238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:
const int i;
(void)(i + 17);
the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it.
We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
- the left-hand side of a '.' operator
- the left-hand side of an assignment
- a C++ throw expression
- a subscript expression that's subscripting a vector
Making this change exposed two issues with blocks:
- we were deducing const-qualified return types of non-class type
from a block return, which doesn't fit well
- we weren't always setting the known return type of a block when it
was provided with the ^return-type syntax
Fixes the current Clang-on-Clang compile failure and PR6076.
llvm-svn: 95167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WHAT!?!
It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.
In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types
llvm-svn: 95117
|
|
|
|
|
|
|
|
|
| |
type qualifiers and type specifiers in any order. For example,
this is valid: struct x {...} typedef y;
This fixes PR6208.
llvm-svn: 95094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
forgetting a ';' at the end of a struct. For something like:
class c {
}
void foo() {}
we now produce:
t.cc:3:2: error: expected ';' after class
}
^
;
instead of:
t.cc:4:1: error: cannot combine with previous 'class' declaration specifier
void foo() {}
^
t.cc:2:7: error: 'class c' can not be defined in the result type of a function
class c {
^
GCC produces:
t.cc:4: error: new types may not be defined in a return type
t.cc:4: note: (perhaps a semicolon is missing after the definition of ‘c’)
t.cc:4: error: two or more data types in declaration of ‘foo’
I *think* I got the follow set right, but if I forgot anything, we'll start
getting spurious "expected ';' after class" errors, let me know if you see
any.
llvm-svn: 95042
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- In C++, prior to the closing '}', set the type of enumerators
based on the type of their initializer. Don't perform unary
conversions on the enumerator values.
- In C++, handle overflow when an enumerator has no initializer and
its value cannot be represented in the type of the previous
enumerator.
- In C, handle overflow more gracefully, by complaining and then
falling back to the C++ rules.
- In C, if the enumerator value is representable in an int, convert the
expression to the type 'int'.
Fixes PR5854 and PR4515.
llvm-svn: 95031
|
|
|
|
| |
llvm-svn: 95026
|
|
|
|
|
|
|
|
| |
when checking if the format specifier matches the type of the data
argument and the length modifier indicates the data type is 'char' or
'short'.
llvm-svn: 94992
|
|
|
|
|
|
| |
definitions.
llvm-svn: 94972
|
|
|
|
|
|
| |
the lack of documentation, this matches the behavior of GCC.
llvm-svn: 94954
|
|
|
|
| |
llvm-svn: 94894
|
|
|
|
|
|
| |
<rdar://problem/6931734>.
llvm-svn: 94867
|
|
|
|
|
|
| |
arguments. Thanks to Cristian Draghici for his help with this patch!
llvm-svn: 94864
|
|
|
|
|
|
|
| |
the field width and precision of a format specifier instead of just
'int'. This matches GCC, and fixes <rdar://problem/6079850>.
llvm-svn: 94856
|
|
|
|
|
|
|
|
|
| |
checking. It passes all existing tests, and the diagnostics have been
refined to provide better range information (we now highlight
individual format specifiers) and more precise wording in the
diagnostics.
llvm-svn: 94837
|
|
|
|
| |
llvm-svn: 94816
|
|
|
|
| |
llvm-svn: 94685
|
|
|
|
|
|
|
|
|
|
| |
type when that type is 64 bits wide, and the 'long long' type when 'long' is
only 32 bits wide. This fixes PR6108.
Also adds a bunch of test cases to ensure proper conversion between equally
sized standard types and mode-specified types on both 32 and 64 bit targets.
llvm-svn: 94527
|
|
|
|
|
|
| |
"Fixes" rdar://problem/7574870
llvm-svn: 94458
|
|
|
|
|
|
| |
unbalanced.
llvm-svn: 94347
|
|
|
|
| |
llvm-svn: 94326
|
|
|
|
|
|
| |
dead array references.
llvm-svn: 94115
|
|
|
|
| |
llvm-svn: 94094
|
|
|
|
| |
llvm-svn: 94093
|
|
|
|
|
|
| |
assignments.
llvm-svn: 94086
|
|
|
|
|
|
| |
unary operators.
llvm-svn: 94084
|
|
|
|
| |
llvm-svn: 93945
|
|
|
|
|
|
| |
type which was syntactically written. Fixes PR 6080.
llvm-svn: 93933
|
|
|
|
| |
llvm-svn: 93584
|
|
|
|
| |
llvm-svn: 93574
|
|
|
|
| |
llvm-svn: 93503
|
|
|
|
| |
llvm-svn: 93362
|