| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
external ASTs, and the ASTUnit fails to load.
Also, move getLocationFromExpr outside extern "C" block.
llvm-svn: 95065
|
| |
|
|
| |
llvm-svn: 95064
|
| |
|
|
|
|
| |
CGExprConstant. Fixes PR5674.
llvm-svn: 95063
|
| |
|
|
| |
llvm-svn: 95062
|
| |
|
|
| |
llvm-svn: 95061
|
| |
|
|
| |
llvm-svn: 95060
|
| |
|
|
| |
llvm-svn: 95059
|
| |
|
|
|
|
|
| |
for vectors. Codegen is generating awful code or segfaulting
in various cases (e.g. PR6204).
llvm-svn: 95058
|
| |
|
|
|
|
| |
as an argument during overload resolution.
llvm-svn: 95057
|
| |
|
|
| |
llvm-svn: 95056
|
| |
|
|
| |
llvm-svn: 95055
|
| |
|
|
| |
llvm-svn: 95054
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
where callee's arguments are already in the caller's own caller's stack and
they line up perfectly. e.g.
extern int foo(int a, int b, int c);
int bar(int a, int b, int c) {
return foo(a, b, c);
}
llvm-svn: 95053
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
implementation. Also made sure that the register maps
were created during disassembler initialization.
llvm-svn: 95051
|
| |
|
|
|
|
|
| |
as output. Needed for (functional) correctness in inline asm,
and should be generally beneficial. 7361612.
llvm-svn: 95050
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
any other member.
llvm-svn: 95047
|
| |
|
|
|
|
| |
when the cast is extending.
llvm-svn: 95046
|
| |
|
|
|
|
| |
generalize it to handle more cases.
llvm-svn: 95045
|
| |
|
|
| |
llvm-svn: 95044
|
| |
|
|
| |
llvm-svn: 95043
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 95041
|
| |
|
|
|
|
| |
don't use TargetData here.
llvm-svn: 95040
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 95036
|
| |
|
|
| |
llvm-svn: 95035
|
| |
|
|
|
|
|
|
|
|
| |
merely stubs out the blocks-based disassembly functions
if the library wasn't built with blocks, which allows a
constant .exports file and also properly deals with
situations in which the compiler used to build a client
is different from the compiler used to build the library.
llvm-svn: 95034
|
| |
|
|
|
|
| |
The MCStreamer based assemblers will take over for this functionality.
llvm-svn: 95033
|
| |
|
|
|
|
|
| |
a test for access declarations and remove a (broken) test for removal
of default arguments.
llvm-svn: 95032
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
| |
directories (like, oh, say, any multistage build)
llvm-svn: 95028
|
| |
|
|
| |
llvm-svn: 95027
|
| |
|
|
| |
llvm-svn: 95026
|
| |
|
|
|
|
| |
Rn operand.
llvm-svn: 95025
|
| |
|
|
|
|
|
| |
target platform, depending on whether the target
supports the blocks API or not
llvm-svn: 95024
|
| |
|
|
| |
llvm-svn: 95023
|
| |
|
|
| |
llvm-svn: 95022
|
| |
|
|
| |
llvm-svn: 95021
|
| |
|
|
| |
llvm-svn: 95018
|
| |
|
|
| |
llvm-svn: 95017
|
| |
|
|
| |
llvm-svn: 95016
|
| |
|
|
| |
llvm-svn: 95014
|
| |
|
|
| |
llvm-svn: 95012
|