of a binary expression, continue on and parse the right-hand side of
the binary expression anyway, but don't call the semantic actions to
type-check. Previously, we would see the error and then, effectively,
skip tokens until the end of the statement.
The result should be more useful recovery, both in the normal case
(we'll actually see errors beyond the first one in a statement), but
it also helps code completion do a much better job, because we do
"real" code completion on the right-hand side of an invalid binary
expression rather than completing with the recovery completion. For
example, given
x = p->y
if there is no variable named "x", we can still complete after the p->
as a member expression. Along the recovery path, we would have
completed after the "->" as if we were in an expression context, which
is mostly useless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114225 91177308-0d34-0410-b5e6-96231b3b80d8
"used", at the time that the default argument itself is used, also
mark destructors that will be called by this expression. This fixes a
regression that I introduced in r113700, which broke WebKit, and fixes
<rdar://problem/8427926>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113883 91177308-0d34-0410-b5e6-96231b3b80d8
error to a warning if we're in a case that would be allowed in
C++0x. This "fixes" PR8084 by making Clang accept more code than GCC
and (non-strict) EDG do.
Also, add the missing test case for the C++0x semantics, which should
have been in r113717.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113718 91177308-0d34-0410-b5e6-96231b3b80d8
declarations in potentially-evaluated subexpressions, about
recursion. Fixes the release-mode self-host failure I introduced in
r113700.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113708 91177308-0d34-0410-b5e6-96231b3b80d8
used in the default function argument as "used". Instead, when we
actually use the default argument, make another pass over the
expression to mark any used declarations as "used" at that point. This
addresses two kinds of related problems:
1) We were marking some declarations "used" that shouldn't be,
because we were marking them too eagerly.
2) We were failing to mark some declarations as "used" when we
should, if the first time it was instantiated happened to be an
unevaluated context, we wouldn't mark them again at a later point.
I've also added a potentially-handy visitor class template
EvaluatedExprVisitor, which only visits the potentially-evaluated
subexpressions of an expression. I bet this would have been useful for
noexcept...
Fixes PR5810 and PR8127.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113700 91177308-0d34-0410-b5e6-96231b3b80d8
Windows GetTempPath() function, and be sure to create the directory in
which the precompiled preamble will reside before creating the
temporary file itself.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113695 91177308-0d34-0410-b5e6-96231b3b80d8
which is should have done from the beginning. As usual, the most
fun with this sort of change is updating all the testcases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113090 91177308-0d34-0410-b5e6-96231b3b80d8
of that parameter, reduce the level by the number of active template
argument lists rather than by 1. The number of active template
argument lists is only > 1 when we have a class template partial
specialization of a member template of a class template that itself is
a member template of another class template.
... and Boost.MSM does this. Fixes PR7669.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112551 91177308-0d34-0410-b5e6-96231b3b80d8
namely when the friend function prototype is already used
at the point of the template definition that is supposed
to inject the friend function. Testcase verifies four
scenarios.
I would like receive some code review for this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112524 91177308-0d34-0410-b5e6-96231b3b80d8
when we're taking the address of a unresolvable value, it might be an
implicit member access. Fixes some Boost.Spirit regressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112487 91177308-0d34-0410-b5e6-96231b3b80d8
properly account for the possibility that certain opaque types
might be more qualified than they appear. Fixes PR7708.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112390 91177308-0d34-0410-b5e6-96231b3b80d8
this is still failing, need to come up with a fix
(but we are in good company as the first gcc version
pass this test will be v4.6)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112369 91177308-0d34-0410-b5e6-96231b3b80d8
dependent in ActOnIdExpression. (This issue only shows up with member
operators because an operator is never a type.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110486 91177308-0d34-0410-b5e6-96231b3b80d8
a template-argument-list. When template template parameters are
involved, we won't already have checked the template-argument-list (it
may not be known yet!). Fixes PR7807.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110444 91177308-0d34-0410-b5e6-96231b3b80d8
(e.g. due to a broken template argument) following template parameters.
Fixes rdar://problem/8254267
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109853 91177308-0d34-0410-b5e6-96231b3b80d8
rebuilder, i.e., remove a silly short-sighted hack from long
ago. Thanks to Abramo Bagnara for the test case/bug report!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109583 91177308-0d34-0410-b5e6-96231b3b80d8
dependent bases, construct a dependent nested-name-specifier rather
than complaining that the name could not be found within the current
instantiation itself. Fixes PR7725.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109582 91177308-0d34-0410-b5e6-96231b3b80d8
expression such as the "foo" in "this->blah.foo<1, 2>", and we can't
look into the type of "this->blah" (e.g., because it is dependent),
look into the local scope of a template of the same name. Fixes
<rdar://problem/8198511>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108531 91177308-0d34-0410-b5e6-96231b3b80d8
definition, we're likely going to end up breaking the invariants of
the template system, e.g., that the depths of template parameter lists
match up with the nesting template of the template. So, make sure we
mark such ill-formed declarations as invalid or don't even build them
at all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108372 91177308-0d34-0410-b5e6-96231b3b80d8
This flag and warning match GCC semantics. Also, move it to -Wextra as this is
a largely cosmetic issue and doesn't seem to mask problems. Subsequent fixes to
the tests which no longer by default emit the warning. Added explicit test
cases for both C and C++ behavior with the warning turned on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108325 91177308-0d34-0410-b5e6-96231b3b80d8
don't include the nested-name-specifier or template arguments: they
were only relevant when resolving the declaration. Fixes PR7460.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108235 91177308-0d34-0410-b5e6-96231b3b80d8
strip cv-qualifiers from the expression's type when the language calls
for it: in C, that's all the time, while C++ only does it for
non-class types.
Centralized the computation of the call expression type in
QualType::getCallResultType() and some helper functions in other nodes
(FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
callers of getResultType() to getCallResultType().
Fixes PR7598 and PR7463, along with a bunch of getResultType() call
sites that weren't stripping references off the result type (nothing
stripped cv-qualifiers properly before this change).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108234 91177308-0d34-0410-b5e6-96231b3b80d8
class templates within class scope (which is ill-formed), and recover
by dropping the explicit specialization entirely. Fixes the infinite
loop in PR7622.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108217 91177308-0d34-0410-b5e6-96231b3b80d8
default arguments to template parameters don't have a DeclContext when
instantiated, and so we can't detect that we're in an instantiation context as
opposed to the definition context. However, it fixes the more commonly-occuring
cases in TMP code that use devolve to this type of tautology after
substitution.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108044 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
Abramo Bagnara
John McCall
Chris Lattner
Chandler Carruth
Gabor Greif
Nick Lewycky
Eli Friedman