| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
references.
llvm-svn: 94964
|
| |
|
|
| |
llvm-svn: 94963
|
| |
|
|
|
|
|
|
|
| |
change.
PS: I'm under the impression formatting-only patches don't need pre-commit
review, but feel free to yell at me if I should post these first! =D
llvm-svn: 94956
|
| |
|
|
|
|
| |
the lack of documentation, this matches the behavior of GCC.
llvm-svn: 94954
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
arguments. This both prevents meaningless checks on these arguments and ensures
that they are represented as an expression by the instantiation.
Cleaned up and added standard text to the relevant test case. Also started
adding tests for *rejected* cases. At least one FIXME here where (I think) we
allow something we shouldn't. More to come in the area of rejecting crazy
arguments with decent diagnostics. Suggestions welcome for still better
diagnostics on these errors!
llvm-svn: 94953
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(necessarily simultaneous) changes:
- CXXBaseOrMemberInitializer now contains only a single initializer
rather than a set of initialiation arguments + a constructor. The
single initializer covers all aspects of initialization, including
constructor calls as necessary but also cleanup of temporaries
created by the initializer (which we never handled
before!).
- Rework + simplify code generation for CXXBaseOrMemberInitializers,
since we can now just emit the initializer as an initializer.
- Switched base and member initialization over to the new
initialization code (InitializationSequence), so that it
- Improved diagnostics for the new initialization code when
initializing bases and members, to match the diagnostics produced
by the previous (special-purpose) code.
- Simplify the representation of type-checked constructor initializers in
templates; instead of keeping the fully-type-checked AST, which is
rather hard to undo at template instantiation time, throw away the
type-checked AST and store the raw expressions in the AST. This
simplifies instantiation, but loses a little but of information in
the AST.
- When type-checking implicit base or member initializers within a
dependent context, don't add the generated initializers into the
AST, because they'll look like they were explicit.
- Record in CXXConstructExpr when the constructor call is to
initialize a base class, so that CodeGen does not have to infer it
from context. This ensures that we call the right kind of
constructor.
There are also a few "opportunity" fixes here that were needed to not
regress, for example:
- Diagnose default-initialization of a const-qualified class that
does not have a user-declared default constructor. We had this
diagnostic specifically for bases and members, but missed it for
variables. That's fixed now.
- When defining the implicit constructors, destructor, and
copy-assignment operator, set the CurContext to that constructor
when we're defining the body.
llvm-svn: 94952
|
| |
|
|
| |
llvm-svn: 94951
|
| |
|
|
|
|
| |
when implicitly supplied to the injected class name.
llvm-svn: 94948
|
| |
|
|
|
|
|
| |
explicit '&' by introducing an address-of operator prior to checking the
argument's type.
llvm-svn: 94947
|
| |
|
|
|
|
| |
offset, we don't need to null check the input pointer. Fixes PR5965.
llvm-svn: 94942
|
| |
|
|
|
|
| |
value if the class offset is 0.
llvm-svn: 94939
|
| |
|
|
| |
llvm-svn: 94938
|
| |
|
|
| |
llvm-svn: 94929
|
| |
|
|
| |
llvm-svn: 94926
|
| |
|
|
| |
llvm-svn: 94925
|
| |
|
|
|
|
|
|
|
| |
live as long as the ASTUnit. This is useful for clients which want to maintain
pointers to the LangOptions object which ultimately lives in the
CompilerInvocation, although it would be nice to make all of this ownership
stuff more explicit and obvious.
llvm-svn: 94924
|
| |
|
|
|
|
|
|
| |
This allows clients to install their own CompilerInvocation object, which is
important for clients that may wish to create references to things like
LangOptions whose lifetime will extend past that of the CompilerInstance.
llvm-svn: 94923
|