| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 95357
|
| |
|
|
|
|
| |
spread GRState* everywhere.
llvm-svn: 95354
|
| |
|
|
| |
llvm-svn: 95348
|
| |
|
|
|
|
| |
'-analyzer-check-objc-missing-dealloc'.
llvm-svn: 95347
|
| |
|
|
| |
llvm-svn: 95346
|
| |
|
|
|
|
| |
'-analyzer-check-objc-unused-ivars'.
llvm-svn: 95345
|
| |
|
|
| |
llvm-svn: 95343
|
| |
|
|
|
|
| |
'-analyzer-check-security-syntactic'.
llvm-svn: 95342
|
| |
|
|
|
|
| |
(Fixes radar 7607605).
llvm-svn: 95341
|
| |
|
|
|
|
| |
Fixes latent and not-so-latent objc++ and blocks++ bugs.
llvm-svn: 95340
|
| |
|
|
| |
llvm-svn: 95335
|
| |
|
|
|
|
|
| |
category implementation, which showed up during (attempted) typo
correction. Fixes <rdar://problem/7605289>.
llvm-svn: 95334
|
| |
|
|
|
|
|
|
| |
of a C++ record. Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition. Also cuts down on memory usage.
llvm-svn: 95330
|
| |
|
|
|
|
| |
analyze_printf namespace.
llvm-svn: 95324
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ton of potential crashes of the same kind. The fundamental problem is
that type creation was following a dangerous pattern when using its
FoldingSets:
1) Use FindNodeOrInsertPos to see if the type is available
2) If not, and we aren't looking at a canonical type, build the
canonical type
3) Build and insert the new node into the FoldingSet
The problem here is that building the canonical type can, in very rare
circumstances, force the hash table inside the FoldingSet to
reallocate. That invalidates the insertion position we computed in
step 1, and in step 3 we end up inserting the new node into the wrong
place. BOOM!
I've audited all of ASTContext, fixing this problem everywhere I found
it. The vast majority of wrong code was C++-specific (and *ahem*
written by me), so I also audited other major folding sets in the C++
code (e.g., template specializations), but found no other instances of
this problem.
llvm-svn: 95315
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
With this fix, and the other fixes committed today a make check-all with a clang-built LLVM now gives:
Expected Passes : 6933
Expected Failures : 46
Unsupported Tests : 40
Unexpected Failures: 27
which means that we pass 99.96% of all tests :) The resulting 27 tests are all LLVMC tests and seem to be because of differences in the clang and gcc drivers.
llvm-svn: 95313
|
| |
|
|
|
|
| |
conditional operator as an lvalue.
llvm-svn: 95311
|
| |
|
|
|
|
|
|
|
| |
template parameter, perform array/function decay (if needed), take the
address of the argument (if needed), perform qualification conversions
(if needed), and remove any top-level cv-qualifiers from the resulting
expression. Fixes PR6226.
llvm-svn: 95309
|
| |
|
|
|
|
| |
BeginConditionalBranch/EndConditionalBranch.
llvm-svn: 95308
|
| |
|
|
|
|
| |
call a virtual member function.
llvm-svn: 95307
|
| |
|
|
| |
llvm-svn: 95305
|
| |
|
|
| |
llvm-svn: 95291
|
| |
|
|
| |
llvm-svn: 95290
|
| |
|
|
| |
llvm-svn: 95287
|
| |
|
|
| |
llvm-svn: 95286
|
| |
|
|
| |
llvm-svn: 95284
|
| |
|
|
| |
llvm-svn: 95279
|
| |
|
|
| |
llvm-svn: 95275
|
| |
|
|
|
|
| |
float literals, and unresolved lookups (which required hand-wavey extensions).
llvm-svn: 95273
|
| |
|
|
|
|
|
|
| |
a different return type. While we don't emit any errors (yet), at
least we avoid cases where we might crash because of an assertion
failure later on (when the return type differs from what is expected).
llvm-svn: 95268
|
| |
|
|
|
|
| |
the rewriter. (Fixes radar 7607781).
llvm-svn: 95267
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
side-effect of always folding the expression to the default argument of the parameter. For example:
void f(int a = 10) {
return a;
}
would always return 10, regardless of the passed in argument.
This fixes another 600 test failures. We're now down to only 137 failures!
llvm-svn: 95262
|
| |
|
|
|
|
| |
(Fixes radar 7607413).
llvm-svn: 95257
|
| |
|
|
|
|
| |
to ParseClassSpecifier, to make its decision easier. Fixes PR6200.
llvm-svn: 95255
|
| |
|
|
|
|
|
|
|
| |
doing so invalidates the file guard optimization and is not
in the spirit of "#if 0" because it is supposed to completely
skip everything, even if it isn't lexically valid. Patch by
Abramo Bagnara!
llvm-svn: 95253
|
| |
|
|
|
|
|
| |
remove some age-old FIXMEs and C++ workarounds within the
type-compatibility logic.
llvm-svn: 95249
|
| |
|
|
| |
llvm-svn: 95246
|
| |
|
|
|
|
| |
(partial fix for radar 7591784).
llvm-svn: 95245
|
| |
|
|
|
|
| |
working code, for no apparent reason.
llvm-svn: 95244
|
| |
|
|
| |
llvm-svn: 95239
|
| |
|
|
|
|
|
| |
with a function with a prototype, treat parameters of enumeration type
based on the enumeration type's promotion type.
llvm-svn: 95238
|
| |
|
|
| |
llvm-svn: 95235
|
| |
|
|
| |
llvm-svn: 95232
|
| |
|
|
| |
llvm-svn: 95228
|
| |
|
|
| |
llvm-svn: 95226
|
| |
|
|
|
|
| |
for the reference binding bug that is preventing self-hosting.
llvm-svn: 95223
|
| |
|
|
|
|
|
|
| |
constructed, GC flag not set.
Please don't try using this yet - the runtime support is still very immature and your code will almost certainly crash if you do.
llvm-svn: 95222
|
| |
|
|
|
|
|
|
|
|
|
| |
prevent a crash on templates when looking for an existing declaration of the
predefined global operators. This fixes PR5918.
Added an easy test case for the overload handling, but testing the crash is
a bit trickier. Created a new test that can use multiple runs with a define to
trigger which test case is used so we can test this type of issue.
llvm-svn: 95220
|
| |
|
|
|
|
|
| |
reference template arguments. Adds test cases for the cv-quals of reference
arguments.
llvm-svn: 95217
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that is in an anonymous namespace, give that function or variable
internal linkage.
This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:
- Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
when the declaration is in an anonymous namespace.
- Added Type::getLinkage() to determine the linkage of a type, which
is defined as the minimum linkage of the types (when we're dealing
with a compound type that is not a struct/class/union).
- Extended NamedDecl::getLinkage() to consider the linkage of the
template arguments and template parameters of function template
specializations and class template specializations.
- Taught code generation to rely on NamedDecl::getLinkage() when
determining the linkage of variables and functions, also
considering the linkage of the types of those variables and
functions (C++ only). Map UniqueExternalLinkage to internal
linkage, taking out the explicit checks for
isInAnonymousNamespace().
This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:
LLVM:
Expected Passes : 4006
Expected Failures : 32
Unsupported Tests : 40
Unexpected Failures: 736
Clang:
Expected Passes : 1903
Expected Failures : 14
Unexpected Failures: 75
Overall:
Expected Passes : 5909
Expected Failures : 46
Unsupported Tests : 40
Unexpected Failures: 811
Still to do:
- Improve testing
- Check whether we should allow the presence of types with
InternalLinkage (in addition to UniqueExternalLinkage) given
variables/functions internal linkage in C++, as mentioned in
PR5792.
- Determine how expensive the getLinkage() calls are in practice;
consider caching the result in NamedDecl.
- Assess the feasibility of Chris's idea in comment #1 of PR5792.
llvm-svn: 95216
|