[clang] Don't segfault on incorrect using directive (PR41400)

Summary:
this is a bugfixe for [[ https://bugs.llvm.org/show_bug.cgi?id=41400 | PR41400 ]]

added nullptr check at the relevent place an

[clang] Don't segfault on incorrect using directive (PR41400)

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

show more ...

When typo-correcting a using-declaration, actually correct the name of the
UsingDecl (so that redeclaration lookup can find it).

llvm-svn: 269530

Fix bug in using shadow decl checking: a using shadow decl should not conflict
with a prior UsingDecl -- those should not even really be found by the lookup
here, except that we use the same lookup r

Fix bug in using shadow decl checking: a using shadow decl should not conflict
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

show more ...

Model NamespaceAliasDecls as having their nominated namespace as an underlying
declaration. This fixes an issue where we would reject (due to a claimed
ambiguity) a case where lookup finds multiple N

Model NamespaceAliasDecls as having their nominated namespace as an underlying
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

show more ...

Look through using decls when classifying implicit member access

Clang will now accept this valid C++11 code:
struct A { int field; };
struct B : A {
using A::field;
enum { TheSize = siz

Look through using decls when classifying implicit member access

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

show more ...

Revert "Diagnose UnresolvedLookupExprs that resolve to instance members in static methods"

This reverts commit r250592.

It has issues around unevaluated contexts, like this:
template <class T> st

Revert "Diagnose UnresolvedLookupExprs that resolve to instance members in 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

show more ...

Diagnose UnresolvedLookupExprs that resolve to instance members in static methods

During the initial template parse for this code, 'member' is unresolved
and we don't know anything about it:

stru

Diagnose UnresolvedLookupExprs that resolve to instance members in static 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

show more ...

PR24030, PR24033: Consistently check whether a new declaration conflicts with
an existing using shadow declaration if they define entities of the same kind
in different namespaces.

We'd previously c

PR24030, PR24033: Consistently check whether a new declaration conflicts with
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

show more ...

Fix diagnostic for static methods referencing fields from using decls

Previously we thought the instance member was a function, not a field,
and we'd say something silly like:
t.cpp:4:27: error: c

Fix diagnostic for static methods referencing fields from using decls

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

show more ...

Make typo-correction of inheriting constructors work a bit better. Limit
correction to direct base class members, and recover properly after we apply
such a correction.

llvm-svn: 207731

When typo-correcting a member using declaration, don't exclude member templates.

llvm-svn: 207681

When typo-correcting a member using-declaration, only consider members of base classes.

llvm-svn: 207680

Fix crash if typo correction corrects a member using-declaration to a
non-member declaration. Patch by Dinesh Dwivedi!

llvm-svn: 207677

Fix handling of redeclaration lookup for using declarations, where the prior
declaration is not visible. Previously we didn't find hidden friend names in
this redeclaration lookup, because we forgot

Fix handling of redeclaration lookup for using declarations, where the prior
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

show more ...

Restrict redeclaration of tags introduced by using decls to MSVCCompat

This limits the facility added in r199490 while we seek clarification on the
standard.

llvm-svn: 199531

Permit redeclaration of tags introduced by using decls

This valid construct appears in MSVC headers where it's used to provide a
definition for the '::type_info' compiler builtin type.

llvm-svn: 19

Permit redeclaration of tags introduced by using decls

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

show more ...

Be smarter about deciding to add a leading '::' to a
NestedNameSpecifier that replaces an existing specifier.

llvm-svn: 193019

Offer typo suggestions for 'using' declarations.

Patch courtesy of Luke Zarko <[email protected]>

llvm-svn: 186019

When checking a using declaration, make sure that the context we're
looking in is complete. Fixes PR8756.

llvm-svn: 122323

Diagnose attempst to template using declarations and using directives.
Recover from the latter and fail early for the former. Fixes PR8022.

llvm-svn: 118669

Handle redeclarations found by ADL deterministically and reasonably.

This solution relies on an O(n) scan of redeclarations, which means it might
scale poorly in crazy cases with tons of redeclarati

Handle redeclarations found by ADL deterministically and reasonably.

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

show more ...

Allow ADL to find functions imported by using decls. Leave wordy comment
about interaction between ADL and default arguments. Shrug shoulders, commit.

llvm-svn: 94524

Handle using declarations in overloaded and template functions during ADL and
address resolution. This fixes PR5751.

Also, while we're here, remove logic from ADL which mistakenly included the
defin

Handle using declarations in overloaded and template functions during ADL and
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

show more ...

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead o

Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- 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

show more ...

In CXXRecordDecl::forallBases, add the base to the "queue", so we walk more than one heirarchy of classes. John, please review.

llvm-svn: 90948