| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 65097
|
| |
|
|
|
|
|
|
| |
where there is exactly one existing declaration. This is common.
this speeds up clang about 3% on cocoa.h for me 0.165 -> 0.160s
llvm-svn: 65096
|
| |
|
|
| |
llvm-svn: 65095
|
| |
|
|
| |
llvm-svn: 65094
|
| |
|
|
| |
llvm-svn: 65093
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
(no ranges on the second diagnostics)
After:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
~~~ ^ ~~~
(ranges!)
llvm-svn: 65090
|
| |
|
|
| |
llvm-svn: 65089
|
| |
|
|
|
|
| |
DiagnosticInfo.
llvm-svn: 65088
|
| |
|
|
|
|
| |
receiver alias if the return type is a location.
llvm-svn: 65084
|
| |
|
|
|
|
| |
use Blocks for our callbacks ;-)
llvm-svn: 65083
|
| |
|
|
|
|
|
|
| |
transitions and then generate a subsequent node that removes the dead symbol
bindings. This should drastically improve caching in the simulation graph when
retain-counted objects are being tracked.
llvm-svn: 65082
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
information about types. We often print diagnostics where we say
"foo_t" is bad, but the user doesn't know how foo_t is declared
(because it is a typedef). Fix this by expanding sugar when present
in a diagnostic (and not one of a few special cases, like vectors).
Before:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' and 'typeof(F)')
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
After:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
llvm-svn: 65081
|
| |
|
|
|
|
|
| |
PostStmt program point. This allows clients to pass in PostStmtCustom program
points.
llvm-svn: 65080
|
| |
|
|
|
|
| |
attribute.
llvm-svn: 65078
|
| |
|
|
| |
llvm-svn: 65077
|
| |
|
|
| |
llvm-svn: 65076
|
| |
|
|
|
|
|
|
|
|
| |
- PR3463, PR3398, <rdar://problem/6553401> crash on relocatable
symbol addresses as constants in static locals.
- There are many more scenarious we could handle (like arithmetic on
such an int) but this is the main use case.
llvm-svn: 65074
|
| |
|
|
| |
llvm-svn: 65073
|
| |
|
|
| |
llvm-svn: 65072
|
| |
|
|
| |
llvm-svn: 65071
|
| |
|
|
|
|
|
| |
appear to be constant. I'll probably redo this and throw it all away
later once we have codegen for BlockDeclRefExprs.
llvm-svn: 65070
|
| |
|
|
|
|
|
|
|
| |
only occur for pointer types; they are also possible for integer types
now.
- No intended functionality change, IntExprEvaluate doesn't return
LValue results yet.
llvm-svn: 65066
|
| |
|
|
|
|
| |
- Prep for handling lvalues, no intended functionality change.
llvm-svn: 65063
|
| |
|
|
|
|
| |
- <rdar://problem/6094103> sema fails to promote type arguments to __builtin_isgreater (and friends)
llvm-svn: 65059
|
| |
|
|
| |
llvm-svn: 65056
|
| |
|
|
| |
llvm-svn: 65055
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
manual setting of the Result.
- Idiom now enforces that result will always have correct width and
type; this exposed three new bugs:
o Enum constant decl value can have different width than type
(PR3173).
o EvaluateInteger should not run an IntExprEvaluator over
non-integral expressions.
o FloatExprEvaluate was not handling casts correctly (it was
evaluating the cast in the IntExprEvaluator!).
llvm-svn: 65053
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
t.c:1:10: error: missing terminating '>' character
#include <stdio.h
^
instead of:
t.c:1:10: error: missing terminating " character
#include <stdio.h
^
llvm-svn: 65052
|
| |
|
|
| |
llvm-svn: 65051
|
| |
|
|
|
|
| |
expression that allocates an object.
llvm-svn: 65047
|
| |
|
|
|
|
| |
uniquing array types.
llvm-svn: 65046
|
| |
|
|
| |
llvm-svn: 65041
|
| |
|
|
|
|
|
|
|
|
|
| |
- Handles assignment to Result with appropriate type.
- Simplifies & encapsulates most direct handling of the Result value;
prep for allowing IntExprEvaluator to deal with LValue APValues.
- No intended functionality change.
llvm-svn: 65038
|
| |
|
|
|
|
|
| |
that this problem arises from time to time. We should find a fundamental
solution for it.
llvm-svn: 65035
|
| |
|
|
|
|
| |
- <rdar://problem/6584606> clang/x86-64 - too many reg saves
llvm-svn: 65032
|
| |
|
|
| |
llvm-svn: 65031
|
| |
|
|
|
|
| |
already an entry and one to insert).
llvm-svn: 65030
|
| |
|
|
| |
llvm-svn: 65029
|
| |
|
|
| |
llvm-svn: 65028
|
| |
|
|
|
|
|
|
| |
"after" group instead of the system group makes it so #include <limits.h>
picks up the *system* limits.h file before clang's. This causes a failure
on linux and is definitely not what we want.
llvm-svn: 65026
|
| |
|
|
| |
llvm-svn: 65024
|
| |
|
|
|
|
| |
negative value.
llvm-svn: 65023
|
| |
|
|
|
|
|
| |
zero expression arguments. This eliminates 2579 1-byte
mallocs when parsing Cocoa.h.
llvm-svn: 65022
|
| |
|
|
|
|
|
|
|
|
|
| |
situation where a tentative decl was emitted *after* the actual
initialization. This occurs in some rare situations with static decls.
- PR3613.
- I'm not particularly happy with this fix, but I don't see a simpler
or more elegant solution yet.
llvm-svn: 65018
|
| |
|
|
|
|
| |
expressions as well.
llvm-svn: 65013
|
| |
|
|
|
|
| |
mapped path, not the requested path.
llvm-svn: 65009
|
| |
|
|
| |
llvm-svn: 65006
|
| |
|
|
|
|
|
| |
message expression is nil and the return type is struct then the returned value
is undefined or potentially garbage.
llvm-svn: 65003
|
| |
|
|
| |
llvm-svn: 65000
|
| |
|
|
| |
llvm-svn: 64998
|