per Doug's comment.

llvm-svn: 82791

member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.

llvm-svn: 82789

Fixed pr5050.

llvm-svn: 82783

llvm-svn: 82770

llvm-svn: 82757

value-dependent. Audit (and fixed) all calls to
Expr::isNullPointerConstant() to provide the correct behavior with
value-dependent expressions. Fixes PR5041 and a crash in libstdc++
<locale>.

In the same vein, properly compute value- and type-dependence for
ChooseExpr. Fixes PR4996.

llvm-svn: 82748

llvm-svn: 82747

Who would have thought that empty classes were so tricky? Handle cases where an empty virtual base class needs to be moved aside because it conflicts with the first field.

llvm-svn: 82746

llvm-svn: 82744

Fix <rdar://problem/7249327> by allowing silent conversions between signed and unsigned integer values for symbolic values.  This is an intermediate solution (i.e. hack) until we support extension/truncation of symbolic integers.

llvm-svn: 82737

llvm-svn: 82736

complete (or, possibly causing template instantiation).

Test this via some explicit specializations of member functions.

llvm-svn: 82732

first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks

There are many caveats here:
  - We completely and totally drop any explicitly-specified template
  arguments on the floor
  - We don't diagnose any of the extra semantic things that we should
  diagnose. 
  - I haven't looked to see that we're getting the right linkage for
  explicit specializations

On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.

llvm-svn: 82728

llvm-svn: 82726

llvm-svn: 82706

Type hierarchy.  Demote 'volatile' to extended-qualifier status.  Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right;  many more remain.

llvm-svn: 82705

visible in the log.

llvm-svn: 82688

llvm-svn: 82687

Fix crash in RegionStoreManager::Bind() by using 'getAs<PointerType>()' instead of 'cast<PointerType>()' (to handle pointer typedefs).

llvm-svn: 82686

llvm-svn: 82682

handled correctly.
 - <rdar://problem/7247671> Function arguments incorrect when function returns a
   struct on i386 w/ llvm-g++ and clang

llvm-svn: 82681

The issue was a discrepancy between how RegionStoreManager::Bind() and
RegionStoreManager::Retrieve() derived the "key" for the first element
of a symbolic region.

llvm-svn: 82680

llvm-svn: 82679

llvm-svn: 82672

llvm-svn: 82665

initializing a reference class.

llvm-svn: 82664

lookup in a member access expression always start a
nested-name-specifier. Additionally, rank names that start
nested-name-specifiers after other names.

llvm-svn: 82663

It uses a recent API to find inherited conversion functions to do
the initializer to reference lvalue conversion (and removes a FIXME).
It issues the ambiguity diagnostics when multiple conversions are found.
WIP.

llvm-svn: 82649

llvm-svn: 82644

llvm-svn: 82642

llvm-svn: 82628

that there is one more argument (the one following the comma) and make
the candidate non-viable if the function cannot accept any argument in
that position.

llvm-svn: 82625

llvm-svn: 82623

This implements PR5034 and rdar://6836445.

llvm-svn: 82614

GRExprEngine::VisitDeclRefExpr without 'asLValue' being true).

llvm-svn: 82598

resolution failed to select a candidate due to
ambiguity in type conversion function selection.

llvm-svn: 82596

llvm-svn: 82594

signature of the function with the current parameter highlighted as a
placeholder.

llvm-svn: 82593

results for other, textual completion. For call completion, we now
produce enough information to show the function call argument that we
are currently on.

llvm-svn: 82592

the start of a nested-name-specifier, add the "::" after the
nested-name-specifier to the code-completion string.

llvm-svn: 82587