This time, I went with the first approach from
http://reviews.llvm.org/D6700, where clang actually attempts to form an
implicit member reference from an UnresolvedLookupExpr. We know that
there are only two possible outcomes at this point, a DeclRefExpr of the
FieldDecl or an error, but its safer to reuse the existing machinery for
this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250856 91177308-0d34-0410-b5e6-96231b3b80d8
We previously mishandled UnresolvedUsingValueDecls in
NamedDecl::declarationReplaces, which caused us to forget decls
when there are multiple dependent using decls for the same name.
Fixes PR16936.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188737 91177308-0d34-0410-b5e6-96231b3b80d8
Remove -faccess-control from -cc1; add -fno-access-control.
Make the driver pass -fno-access-control by default.
Update a bunch of tests to be correct under access control.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100880 91177308-0d34-0410-b5e6-96231b3b80d8
- 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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
results in them (which we were doing intentionally as a stopgap). Fix
an DeclContext lookup-table ordering problem which was causing UsingDecls to
show up incorrectly when looking for ordinary results. And oh hey
Clang-Code-Syntax passes now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90367 91177308-0d34-0410-b5e6-96231b3b80d8
Also, make the "don't know how to instantiate a particular kind of
declaration" diagnostic nicer, so we don't have to trap Clang in a
debugger to figure out what went wrong.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89050 91177308-0d34-0410-b5e6-96231b3b80d8
Reid Kleckner