| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 151407
|
| |
|
|
| |
llvm-svn: 151405
|
| |
|
|
|
|
|
| |
enumeration type with a fixed underlying type is complete. Fixes
<rdar://problem/10916155>.
llvm-svn: 151403
|
| |
|
|
|
|
| |
__keywords or none of them.
llvm-svn: 151401
|
| |
|
|
| |
llvm-svn: 151400
|
| |
|
|
|
|
|
| |
the declaration, not at the type of the DeclRefExpr, since within a lambda the
DeclRefExpr can be more const than the declaration is.
llvm-svn: 151399
|
| |
|
|
|
|
| |
against a large project.
llvm-svn: 151395
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A defaulted default constructor for a class X is defined as deleted if [...]
- X is a union and all of its variant members are of const-qualified type.
A pedantic reading therefore says that
union X { };
has a deleted default constructor, which is both silly and almost
certainly unintended. Pretend as if this this read
- X is a union with one or more variant members, and all of its
variant members are of const-qualified type.
llvm-svn: 151394
|
| |
|
|
| |
llvm-svn: 151389
|
| |
|
|
| |
llvm-svn: 151387
|
| |
|
|
| |
llvm-svn: 151386
|
| |
|
|
|
|
|
| |
"C++0x". Use "C++98" to refer to C++98, not "C++". Add heading for C++98
support section.
llvm-svn: 151381
|
| |
|
|
|
|
|
|
|
|
| |
agreed on IRC, any remaining issues are best dealt with as bugs.
We have no __has_feature check for this; please shout if you'd like one. This
feature seems too small to be worth its own release notes bullet (again, please
shout if you disagree).
llvm-svn: 151380
|
| |
|
|
| |
llvm-svn: 151378
|
| |
|
|
| |
llvm-svn: 151377
|
| |
|
|
| |
llvm-svn: 151376
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Make sure that the block expression is instantiation-dependent if the
block is in a dependent context
- Make sure that the C++ 'this' expression gets captured even if we
don't rebuild the AST node during template instantiation. This would
also have manifested as a bug for lambdas.
Fixes <rdar://problem/10832617>.
llvm-svn: 151372
|
| |
|
|
| |
llvm-svn: 151371
|
| |
|
|
|
|
|
| |
This ensures that we report the bugs associated with symbols going
out of scope in the correct function context.
llvm-svn: 151369
|
| |
|
|
|
|
|
|
|
| |
visiting 'return;' statement!
This most likely caused us to skip a bunch of code when analyzing with
inlining.
llvm-svn: 151368
|
| |
|
|
|
|
| |
the default for clang for some time now and can handle compiler-rt.
llvm-svn: 151367
|
| |
|
|
| |
llvm-svn: 151359
|
| |
|
|
|
|
| |
uninitialized. While there, restyle this function! No functionality change.
llvm-svn: 151357
|
| |
|
|
| |
llvm-svn: 151356
|
| |
|
|
|
|
| |
hasTrivialMoveConstructor().
llvm-svn: 151354
|
| |
|
|
| |
llvm-svn: 151353
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
llvm-svn: 151352
|
| |
|
|
|
|
| |
fixing a bug in the inlining diagnostics where the wrong location could be used.
llvm-svn: 151349
|
| |
|
|
| |
llvm-svn: 151347
|
| |
|
|
|
|
|
|
| |
into account the nested structure. Also fix a problem with how
inlining impacted Plist diagnostics, and adjust some ranges in the Plist output due to richer information.
llvm-svn: 151346
|
| |
|
|
| |
llvm-svn: 151343
|
| |
|
|
| |
llvm-svn: 151338
|
| |
|
|
|
|
|
|
| |
make sure we don't mistake ParmVarDecls for top-level decls.
Fixes rdar://10920009.
llvm-svn: 151330
|
| |
|
|
|
|
| |
PathDiagnosticCallPiece.
llvm-svn: 151317
|
| |
|
|
| |
llvm-svn: 151316
|
| |
|
|
| |
llvm-svn: 151314
|
| |
|
|
|
|
| |
test case that only runs on debug builds.
llvm-svn: 151311
|
| |
|
|
|
|
|
|
| |
pack" to use the same handling that gcc does. Fixes <rdar://problem/10871094> and <rdar://problem/10893316>.
(Hopefully, common usage of these pragmas isn't irregular enough to break our current handling. Doug has ideas for a more crazy approach if necessary.)
llvm-svn: 151307
|
| |
|
|
|
|
| |
functional change.
llvm-svn: 151298
|
| |
|
|
|
|
| |
(Very similar to the previous change in malloc.)
llvm-svn: 151297
|
| |
|
|
|
|
| |
// rdar://10907410
llvm-svn: 151296
|
| |
|
|
|
|
| |
MS compatibility mode.
llvm-svn: 151295
|
| |
|
|
|
|
| |
that we can correctly compute value-dependence of the OVE.
llvm-svn: 151291
|
| |
|
|
| |
llvm-svn: 151290
|
| |
|
|
| |
llvm-svn: 151288
|
| |
|
|
|
|
|
|
|
| |
When we find two leak reports with the same allocation site, report only
one of them.
Provide a helper method to BugReporter to facilitate this.
llvm-svn: 151287
|
| |
|
|
| |
llvm-svn: 151286
|
| |
|
|
|
|
|
|
| |
marked as such.
Previously we missed tag declarations; fixes rdar://10902015
llvm-svn: 151283
|
| |
|
|
| |
llvm-svn: 151280
|
| |
|
|
| |
llvm-svn: 151277
|