| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
initializers. Fixes about ~2000 clang/LLVM tests in the clang-on-clang build.
llvm-svn: 95116
|
| |
|
|
| |
llvm-svn: 95110
|
| |
|
|
| |
llvm-svn: 95106
|
| |
|
|
| |
llvm-svn: 95104
|
| |
|
|
|
|
| |
without an initializer in C++ and thus fixes PR5451.
llvm-svn: 95098
|
| |
|
|
|
|
| |
Fixes radar 7589414.
llvm-svn: 95097
|
| |
|
|
| |
llvm-svn: 95096
|
| |
|
|
|
|
|
|
|
| |
type qualifiers and type specifiers in any order. For example,
this is valid: struct x {...} typedef y;
This fixes PR6208.
llvm-svn: 95094
|
| |
|
|
|
|
| |
this is still a popular thing to do.
llvm-svn: 95093
|
| |
|
|
|
|
| |
unused variable warning.
llvm-svn: 95085
|
| |
|
|
| |
llvm-svn: 95079
|
| |
|
|
|
|
| |
magnitude clearer.
llvm-svn: 95078
|
| |
|
|
|
|
| |
Eliminates a lot of spurious global initializers, fixing PR6205.
llvm-svn: 95077
|
| |
|
|
| |
llvm-svn: 95076
|
| |
|
|
|
|
| |
UnresolvedMemberExpr and employ it in a few places where it's useful.
llvm-svn: 95072
|
| |
|
|
| |
llvm-svn: 95066
|
| |
|
|
|
|
| |
CGExprConstant. Fixes PR5674.
llvm-svn: 95063
|
| |
|
|
|
|
| |
as an argument during overload resolution.
llvm-svn: 95057
|
| |
|
|
|
|
|
|
|
|
| |
arguments. Fix a bug where incomplete explicit specializations were being
passed through as legitimate. Fix a bug where the absence of an explicit
specialization in an overload set was causing overall deduction to fail.
Fixes PR6191.
llvm-svn: 95052
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to address a serious performance problem observed when running
'clang -fsyntax-only' on really broken source files. In one case,
repeatedly calling CorrectTypo() caused one source file to be rejected
after 2 minutes instead of 1 second.
This patch causes typo correction to take neglible time on that file
while still providing correction results for the first 20 cases. I
felt this was a reasonable number for moderately broken source files.
I don't claim this is the best solution. Comments welcome. It is
necessary for us to address this issue because it is a serious
performance problem.
llvm-svn: 95049
|
| |
|
|
|
|
|
| |
'Pred' to 'Dst' for cases we currently don't handle. This fixes
<rdar://problem/7593875>.
llvm-svn: 95048
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
t.cc:4:3: error: expected ';' at end of declaration list
int y;
^
t.cc:6:1: error: expected ';' at end of declaration list
};
^
After:
t.cc:3:8: error: expected ';' at end of declaration list
int x
^
;
t.cc:5:8: error: expected ';' at end of declaration list
int z
^
;
llvm-svn: 95039
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
t.c:4:3: error: expected ';' at end of declaration list
int y;
^
t.c:4:8: warning: extra ';' inside a struct or union
int y;
^
t.c:6:1: warning: expected ';' at end of declaration list
};
^
After:
t.c:3:8: error: expected ';' at end of declaration list
int x // expected-error {{expected ';' at end of declaration list}}
^
;
t.c:5:8: warning: expected ';' at end of declaration list
int z
^
;
llvm-svn: 95038
|
| |
|
|
|
|
| |
method. No functionality change.
llvm-svn: 95037
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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: 95030
|
| |
|
|
| |
llvm-svn: 95029
|
| |
|
|
| |
llvm-svn: 95026
|
| |
|
|
| |
llvm-svn: 95023
|
| |
|
|
| |
llvm-svn: 95016
|
| |
|
|
| |
llvm-svn: 95010
|
| |
|
|
| |
llvm-svn: 95009
|
| |
|
|
| |
llvm-svn: 95008
|
| |
|
|
| |
llvm-svn: 95006
|
| |
|
|
| |
llvm-svn: 95005
|
| |
|
|
| |
llvm-svn: 95004
|
| |
|
|
|
|
|
|
|
|
| |
by setting the section of the generated global. This is an
optimization done by the code generator, and the code being
removed didn't handle the case when the string contained an
embedded nul (which the code generator does correctly
handle). This is rdar://7589850
llvm-svn: 95003
|
| |
|
|
|
|
| |
definition. With that in mind, rename getDefinition to getAnyInitializer (to distinguish it from getInit) and reimplement it in terms of isThisDeclarationADefinition. Update all code to use this new function.
llvm-svn: 94999
|
| |
|
|
|
|
| |
emmintrin looks ok.
llvm-svn: 94998
|
| |
|
|
| |
llvm-svn: 94994
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 94991
|
| |
|
|
|
|
|
| |
deduction failed. Right now there's a very vague diagnostic for most cases
and a good diagnostic for incomplete deduction.
llvm-svn: 94988
|
| |
|
|
|
|
| |
definitions.
llvm-svn: 94972
|
| |
|
|
| |
llvm-svn: 94971
|
| |
|
|
|
|
| |
logic for when a variable declaration is a (possibly tentativ) definition. Add a few functions building on this, and shift C tentative definition handling over to this new functionality. This shift also kills the Sema::TentativeDefinitions map and instead simply stores all declarations in the renamed list. The correct handling for multiple tentative definitions is instead shifted to the final walk of the list.
llvm-svn: 94968
|
| |
|
|
|
|
|
| |
not quite sure what we want to do about the AST representation; comments
welcome.
llvm-svn: 94967
|
| |
|
|
| |
llvm-svn: 94965
|