Douglas Gregor [Thu, 4 Feb 2010 18:10:26 +0000 (18:10 +0000)]
Fix an obscure crash found in the Boost.MPL test suite, along with a
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.
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.
Douglas Gregor [Thu, 4 Feb 2010 17:21:48 +0000 (17:21 +0000)]
When substituting the template argument for a pointer non-type
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.
Ted Kremenek [Thu, 4 Feb 2010 07:27:39 +0000 (07:27 +0000)]
Convert flags in FormatSpecifier to be bitfields instead of doing
direct bit manipulation. This is is less error prone, and fixes a bug
in the handling of the LeadingZeroes flag as pointed out by Cristian
Draghici.
Ted Kremenek [Thu, 4 Feb 2010 00:47:48 +0000 (00:47 +0000)]
static analyzer: handle casts of a function to a function pointer with
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).
Anders Carlsson [Wed, 3 Feb 2010 21:58:41 +0000 (21:58 +0000)]
Don't try to fold DeclRefExprs that point to ParmVarDecls. This had the 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!
Chris Lattner [Wed, 3 Feb 2010 21:06:21 +0000 (21:06 +0000)]
don't inform comment handlers about comments in #if 0 blocks,
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!
Douglas Gregor [Wed, 3 Feb 2010 21:02:30 +0000 (21:02 +0000)]
Define two types to be "compatible" in C++ if they are the same, and
remove some age-old FIXMEs and C++ workarounds within the
type-compatibility logic.
Douglas Gregor [Wed, 3 Feb 2010 19:27:29 +0000 (19:27 +0000)]
When determining whether a function without a prototype is compatible
with a function with a prototype, treat parameters of enumeration type
based on the enumeration type's promotion type.
Teach the allocation function overload handling to deal with templates, and
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.
Fix PR6149 by looking at the qualifiers on the referred to type for non-type
reference template arguments. Adds test cases for the cv-quals of reference
arguments.
Douglas Gregor [Wed, 3 Feb 2010 09:33:45 +0000 (09:33 +0000)]
When a function or variable somehow depends on a type or declaration
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:
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.
Ted Kremenek [Wed, 3 Feb 2010 04:16:00 +0000 (04:16 +0000)]
Fix regression in RegionStore due to recent changes in
RegionStoreManager::InvalidateRegions() by adjusting the worklist to
iterate over BindingKeys instead of MemRegions. We also only need to
do the actual invalidation work on base regions, and for non-base
regions just blow away their bindings.
Ted Kremenek [Wed, 3 Feb 2010 03:06:46 +0000 (03:06 +0000)]
Rework RegionStoreManager's implementation of InvalidateRegions() to
not build a subregion map and instead do a single scan of the store.
This is done by building "region clusters" that represent the
collection of regions that have the same base region. Invalidating
any region in a cluster means that they all should get invalidated.
This change brought out a point that Zhongxing mentioned to me
offline: the flattened memory binding has issues distinguishing
between direct and default bindings. For example, setting the default
value for an entire struct is the same as binding to the first
element. To address this problem, I moved the binding "tag" (Direct
or Default) from BindingVal to BdingKey (and removed BindingVal
entirely). This requires us to do double lookups in some cases; and
there is still much more cleanup that can be done.
This change produced a noticeable speedup when analyzing sqlite3 (a
reduction of 4% in running time).
Douglas Gregor [Wed, 3 Feb 2010 03:01:57 +0000 (03:01 +0000)]
Provide a real fix for PR6199, reverting the old workaround. Here, we
realize that CXXConstructExpr is always implicit, so we should just
return its argument (if there is only one) rather than directly
invoking the constructor.
David Chisnall [Wed, 3 Feb 2010 02:09:30 +0000 (02:09 +0000)]
Numerous changes to selector handling:
- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon. This also simplifies the code generated by the GNU runtime a bit.
- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.
- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants. These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.
- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector. This is needed for generating typed selectors from @selector() expressions (as GCC does). Ideally, this information should be stored in the Selector, but that would be an invasive change. We should eventually add checks for common uses of @selector() expressions. Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:
Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature. We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.
- Made @selector() expressions emit type info if available and the runtime supports it.
Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac. This currently just assert()s.
Douglas Gregor [Wed, 3 Feb 2010 00:27:59 +0000 (00:27 +0000)]
Implement the lvalue-to-rvalue conversion where needed. The
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:
const int i;
(void)(i + 17);
the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it.
We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
- the left-hand side of a '.' operator
- the left-hand side of an assignment
- a C++ throw expression
- a subscript expression that's subscripting a vector
Making this change exposed two issues with blocks:
- we were deducing const-qualified return types of non-class type
from a block return, which doesn't fit well
- we weren't always setting the known return type of a block when it
was provided with the ^return-type syntax
Fixes the current Clang-on-Clang compile failure and PR6076.
Ted Kremenek [Tue, 2 Feb 2010 22:38:47 +0000 (22:38 +0000)]
Remove RegionStoreSubRegionMap::iterator and RegionStoreSubRegionMap::begin_end(). This is a precursor to using DenseSet to represent region sets instead of ImmutableSet.
Douglas Gregor [Tue, 2 Feb 2010 20:10:50 +0000 (20:10 +0000)]
Implement promotion for enumeration types.
WHAT!?!
It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.
In this commit:
- Enum types with a promotion type of "int" or "unsigned int" are
promotable.
- Tweaked the computation of promotable types for enums
- For all of the ABIs, treat enum types the same way as their
underlying types (*not* their promotion types) for argument passing
and return values
- Extend the ABI tester with support for enumeration types
Chris Lattner [Tue, 2 Feb 2010 17:32:27 +0000 (17:32 +0000)]
the declspec of a declaration can have storage-class specifiers,
type qualifiers and type specifiers in any order. For example,
this is valid: struct x {...} typedef y;
Daniel Dunbar [Tue, 2 Feb 2010 05:41:30 +0000 (05:41 +0000)]
XFAIL two tests on Win32 until some cares to investigate... the problem on
dyncast is just due to \r\n newline interaction w/ regexps. The remap-load.c
failure is a bit stranger (the end of the extent is on the next line), but I
don't care to investigate.
Daniel Dunbar [Tue, 2 Feb 2010 05:19:57 +0000 (05:19 +0000)]
CIndex: Respect TMPDIR/TEMP/TMP when making temporary files for remapping. As a
side effect, this also fixes some cases on Windows where the file would end up
on a different drive, because tmpnam doesn't include the drive component. PR3837
strikes again.
John McCall [Tue, 2 Feb 2010 02:21:27 +0000 (02:21 +0000)]
Implement C++ [temp.deduct.call]p6, template argument deduction for overloaded
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.
Ted Kremenek [Tue, 2 Feb 2010 02:07:01 +0000 (02:07 +0000)]
Add a stop gap to Sema::CorrectTypo() to correct only up to 20 typos.
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.
Ted Kremenek [Tue, 2 Feb 2010 02:01:51 +0000 (02:01 +0000)]
Fix bug in GRExprEngine::VisitSizeOfAlignOfExpr() where we do not add
'Pred' to 'Dst' for cases we currently don't handle. This fixes
<rdar://problem/7593875>.
Chris Lattner [Tue, 2 Feb 2010 01:23:29 +0000 (01:23 +0000)]
Implement PR6180, substantially improving the diagnostics we get from
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.
Chris Lattner [Tue, 2 Feb 2010 00:37:27 +0000 (00:37 +0000)]
improve diagnostics on missing ; in a struct. Before:
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
^
;
projects / clang / log