= bar() + ... + bar() + ...
clang keeps track of column numbers, so we could put location entries for all subexpressions but that will significantly bloat debug info in general, but a location for call expression is helpful here.
llvm-svn: 127018
DependentTemplateSpecializationType during tree transformation, retain
the NestedNameSpecifierLoc as it was used to translate the template
name, rather than reconstructing it from the template name.
Fixes PR9401.
llvm-svn: 127015
DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.
Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).
How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?
I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.
llvm-svn: 127004
template <class T> void foo();
template <> void foo<int>(); /* Spec 1 */
template <> void foo<int>(); /* Spec 2 */
If we look at the main location of the first explicit specialization (Spec 1) it can be seen that it points to the name of the *second* explicit specialization (Spec 2), which is a redeclaration of Spec1.
Hence, the source range obtained for Spec1 is not only inaccurate, but also invalid (the end location comes before the start location).
llvm-svn: 127002
computing for a nested decl with explicit visibility. This is all part
of the general philosophy of explicit visibility attributes, where
any information that was obviously available at the attribute site
should probably be ignored. Fixes PR9371.
llvm-svn: 126992
1) When we do an instantiation of the injected-class-name type,
provide a proper source location. This is just plain good hygiene.
2) When we're building a NestedNameSpecifierLoc from a CXXScopeSpec,
only return an empty NestedNameSpecifierLoc if there's no
representation.
Both problems contributed to the horrible test case in PR9390 that I
couldn't reduce down to something palatable.
llvm-svn: 126961
parameter, save the instantiated default template arguments along with
the explicitly-specified template argument list. That way, we prefer
the default template template arguments corresponding to the template
template parameter rather than those of its template template argument.
This addresses the likely direction of C++ core issue 150, and fixes
PR9353/<rdar://problem/9069136>, bringing us closer to the behavior of
EDG and GCC.
llvm-svn: 126920
Douglas Gregor