| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
this is a bugfixe for [[ https://bugs.llvm.org/show_bug.cgi?id=41400 | PR41400 ]]
added nullptr check at the relevent place and test
Reviewers: rsmith, riccibruno
Reviewed By: rsmith
Subscribers: jkooker, jkorous, riccibruno, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60523
llvm-svn: 363360
|
| |
|
|
|
|
| |
UsingDecl (so that redeclaration lookup can find it).
llvm-svn: 269530
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a prior UsingDecl -- those should not even really be found by the lookup
here, except that we use the same lookup results for two different checks, and
the other check needs them.
This happens to work in *almost all* cases, because either the lookup results
list the UsingDecl first (and the NonTag result gets replaced by something
else) or because the problematic declaration is a function (which causes us to
use different logic to detect conflicts). This can also be triggered from a
state only reachable through modules (where the name lookup results can contain
multiple UsingDecls in the same scope).
llvm-svn: 262105
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
declaration. This fixes an issue where we would reject (due to a claimed
ambiguity) a case where lookup finds multiple NamespaceAliasDecls from
different scopes that nominate the same namespace.
The C++ standard doesn't make it clear that such a case is in fact valid (which
I'm working on fixing), but there are no relevant rules that distinguish using
declarations and namespace alias declarations here, so it makes sense to treat
them the same way.
llvm-svn: 256601
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang will now accept this valid C++11 code:
struct A { int field; };
struct B : A {
using A::field;
enum { TheSize = sizeof(field) };
};
Previously we would classify the 'field' reference as something other
than a field, and then forget to apply the C++11 rule to allow
non-static data member references in unevaluated contexts.
This usually arises in class templates that want to reference fields of
a dependent base in an unevaluated context outside of an instance
method. Such contexts do not allow references to 'this', so the only way
to access the field is with a using decl and an implicit member
reference.
llvm-svn: 250839
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
static methods"
This reverts commit r250592.
It has issues around unevaluated contexts, like this:
template <class T> struct A { T i; };
template <class T>
struct B : A<T> {
using A<T>::i;
typedef decltype(i) U;
};
template struct B<int>;
llvm-svn: 250774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
methods
During the initial template parse for this code, 'member' is unresolved
and we don't know anything about it:
struct A { int member };
template <typename T>
struct B : public T {
using T::member;
static void f() {
(void)member; // Could be static or non-static.
}
};
template class B<A>;
The pattern declaration contains an UnresolvedLookupExpr rather than an
UnresolvedMemberExpr because `f` is static, and `member` should never be
a field. However, if the code is invalid, it may become a field, in
which case we should diagnose it.
Reviewers: rjmccall, rsmith
Differential Revision: http://reviews.llvm.org/D6700
llvm-svn: 250592
|
| |
|
|
|
|
|
|
|
|
| |
an existing using shadow declaration if they define entities of the same kind
in different namespaces.
We'd previously check this consistently if the using-declaration came after the
other declaration, but not if it came before.
llvm-svn: 241428
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously we thought the instance member was a function, not a field,
and we'd say something silly like:
t.cpp:4:27: error: call to non-static member function without an object argument
static int f() { return n; }
^
Noticed in PR21923.
llvm-svn: 224480
|
| |
|
|
|
|
|
| |
correction to direct base class members, and recover properly after we apply
such a correction.
llvm-svn: 207731
|
| |
|
|
| |
llvm-svn: 207681
|
| |
|
|
|
|
| |
base classes.
llvm-svn: 207680
|
| |
|
|
|
|
| |
non-member declaration. Patch by Dinesh Dwivedi!
llvm-svn: 207677
|
| |
|
|
|
|
|
|
|
|
|
| |
declaration is not visible. Previously we didn't find hidden friend names in
this redeclaration lookup, because we forgot to treat it as a redeclaration
lookup. Conversely, we did find some local extern names, but those don't
actually conflict with a namespace-scope using declaration, because the only
conflicts we can get are scope conflicts, not conflicts due to the entities
being members of the same namespace.
llvm-svn: 206011
|
| |
|
|
|
|
|
| |
This limits the facility added in r199490 while we seek clarification on the
standard.
llvm-svn: 199531
|
| |
|
|
|
|
|
| |
This valid construct appears in MSVC headers where it's used to provide a
definition for the '::type_info' compiler builtin type.
llvm-svn: 199490
|
| |
|
|
|
|
| |
NestedNameSpecifier that replaces an existing specifier.
llvm-svn: 193019
|
| |
|
|
|
|
| |
Patch courtesy of Luke Zarko <zarko@google.com>
llvm-svn: 186019
|
| |
|
|
|
|
| |
looking in is complete. Fixes PR8756.
llvm-svn: 122323
|
| |
|
|
|
|
| |
Recover from the latter and fail early for the former. Fixes PR8022.
llvm-svn: 118669
|
| |
|
|
|
|
|
|
|
| |
This solution relies on an O(n) scan of redeclarations, which means it might
scale poorly in crazy cases with tons of redeclarations brought in by a ton
of distinct associated namespaces. I believe that avoiding this
is not worth the common-case cost.
llvm-svn: 94530
|
| |
|
|
|
|
| |
about interaction between ADL and default arguments. Shrug shoulders, commit.
llvm-svn: 94524
|
| |
|
|
|
|
|
|
|
|
| |
address resolution. This fixes PR5751.
Also, while we're here, remove logic from ADL which mistakenly included the
definition namespaces of overloaded and/or templated functions whose name or
address is used as an argument.
llvm-svn: 92245
|
| |
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
| |
|
|
|
|
| |
than one heirarchy of classes. John, please review.
llvm-svn: 90948
|
| |
|
|
|
|
|
|
|
| |
set, expand overloaded function declarations. Long-term, this should
actually be done by the name-lookup code rather than here, but this
part of the code (involving using declarations) is getting a makeover
now and the test-case is useful.
llvm-svn: 88846
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions that occur in multiple declaration contexts, e.g., because
some were found via using declarations. Now, isDeclInScope will build
a new overload set (when needed) containing only those declarations
that are actually in scope. This eliminates a problem found with
libstdc++'s <iostream>, where the presence of using
In the longer term, I'd like to eliminate Sema::isDeclInScope in favor
of better handling of the RedeclarationOnly flag in the name-lookup
routines. That way, name lookup only returns the entities that matter,
rather than taking the current two-pass approach of producing too many
results and then filtering our the wrong results. It's not efficient,
and I'm sure that we aren't filtering everywhere we should be.
llvm-svn: 82954
|
|
|
llvm-svn: 74262
|
