complete (or, possibly causing template instantiation).
Test this via some explicit specializations of member functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82732 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82728 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82705 91177308-0d34-0410-b5e6-96231b3b80d8
have the iterators and operator[] handle the traversal of statements, as they
are stored in reverse order. Tests show this has no real performance impact, but
it does simply the CFG construction logic and will make it slightly easier to
change the allocation strategy for CFGBlocks (as we have fewer copies).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82702 91177308-0d34-0410-b5e6-96231b3b80d8
handled correctly.
- <rdar://problem/7247671> Function arguments incorrect when function returns a
struct on i386 w/ llvm-g++ and clang
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82681 91177308-0d34-0410-b5e6-96231b3b80d8
The issue was a discrepancy between how RegionStoreManager::Bind() and
RegionStoreManager::Retrieve() derived the "key" for the first element
of a symbolic region.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82680 91177308-0d34-0410-b5e6-96231b3b80d8
lookup in a member access expression always start a
nested-name-specifier. Additionally, rank names that start
nested-name-specifiers after other names.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82663 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82649 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82625 91177308-0d34-0410-b5e6-96231b3b80d8
results for other, textual completion. For call completion, we now
produce enough information to show the function call argument that we
are currently on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82592 91177308-0d34-0410-b5e6-96231b3b80d8
the start of a nested-name-specifier, add the "::" after the
nested-name-specifier to the code-completion string.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82587 91177308-0d34-0410-b5e6-96231b3b80d8
members found in base classes have the same ranking as members found
in derived classes. However, we will introduce an informative note for
members found in base classes, showing (as a nested-name-specifier)
the qualification to name the base class, to make it clear which
members are from bases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82586 91177308-0d34-0410-b5e6-96231b3b80d8