| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 104990
|
|
|
|
|
|
|
|
|
|
|
|
| |
the x86-64 __va_list_tag with this attribute. The attribute causes the
affected type to behave like a fundamental type when considered by ADL.
(x86-64 is the only target we currently provide with a struct-based
__builtin_va_list)
Fixes PR6762.
llvm-svn: 104941
|
|
|
|
| |
llvm-svn: 104939
|
|
|
|
|
|
|
| |
expression, "forget" about the object type; only the
nested-name-specifier matters for name lookup purposes. Fixes PR7239.
llvm-svn: 104834
|
|
|
|
| |
llvm-svn: 102695
|
|
|
|
|
|
| |
two bugfixes which fix selfhost and (hopefully) the nightly tests.
llvm-svn: 102198
|
|
|
|
|
|
| |
same", which seems to break most C++ nightly test apps.
llvm-svn: 102174
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
way that C does. Among other differences, elaborated type specifiers
are defined to skip "non-types", which, as you might imagine, does not
include typedefs. Rework our use of IDNS masks to capture the semantics
of different kinds of declarations better, and remove most current lookup
filters. Removing the last remaining filter is more complicated and will
happen in a separate patch.
Fixes PR 6885 as well some spectrum of unfiled bugs.
llvm-svn: 102164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:
t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
type 'int *' [-pedantic]
f(long_ptr);
^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
^
llvm-svn: 102038
|
|
|
|
|
|
|
| |
parameter, explicitly ask the user to give it arguments. We used to
complain that it wasn't a type and expect the user to figure it out.
llvm-svn: 100729
|
|
|
|
|
|
| |
lexical context. This is required for ADL to work properly; fixes PR6716.
llvm-svn: 99665
|
|
|
|
|
|
|
|
|
|
| |
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
llvm-svn: 98149
|
|
|
|
|
|
|
|
|
|
| |
C++98/03 and C++0x, since the '0x semantics break valid C++98/03
code. This new mess is tracked by core issue 399, which is still
unresolved.
Fixes PR6358 and PR6359.
llvm-svn: 96836
|
|
|
|
|
|
| |
soon.
llvm-svn: 94565
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that name constructors, the endless joys of out-of-line constructor
definitions, and various other corner cases that the previous hack
never imagined. Fixes PR5688 and tightens up semantic analysis for
constructor names.
Additionally, fixed a problem where we wouldn't properly enter the
declarator scope of a parenthesized declarator. We were entering the
scope, then leaving it when we saw the ")"; now, we re-enter the
declarator scope before parsing the parameter list.
Note that we are forced to perform some tentative parsing within a
class (call it C) to tell the difference between
C(int); // constructor
and
C (f)(int); // member function
which is rather unfortunate. And, although it isn't necessary for
correctness, we use the same tentative-parsing mechanism for
out-of-line constructors to improve diagnostics in icky cases like:
C::C C::f(int); // error: C::C refers to the constructor name, but
// we complain nicely and recover by treating it as
// a type.
llvm-svn: 93322
|
|
|
|
| |
llvm-svn: 91927
|
|
|
|
|
|
| |
for copy-initialization.
llvm-svn: 91909
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because of the rules of base-class lookup* and the restrictions on typedefs, it
was actually impossible for this to cause any problems more serious than the
spurious acceptance of
template <class T> class A : B<A> { ... };
instead of
template <class T> class A : B<A<T> > { ... };
but I'm sure we can all agree that that is a very important restriction which
is well worth making another Parser->Sema call for.
(*) n.b. clang++ does not implement these rules correctly; we are not ignoring
non-type names
llvm-svn: 91792
|
|
|
|
|
|
|
|
|
| |
Clang reasonably adds all the base specifiers in one pass; this is now required
for correctness to prevent lookup from going mad. But this has the advantage of
establishing the correct context when looking up base specifiers, which will be
important for access control.
llvm-svn: 91791
|
|
|
|
|
|
| |
quite right; I'll come back to it later. It does fix PR 5741.
llvm-svn: 91789
|
|
|
|
|
|
|
| |
Magically fixes all the terrible lookup problems associated with not pushing
a new scope. Resolves an ancient xfail and an LLVM misparse.
llvm-svn: 91769
|
|
|
|
|
|
|
|
|
| |
used as expressions). In dependent contexts, try to recover by doing a lookup
in previously-dependent base classes. We get better diagnostics out, but
unfortunately the recovery fails: we need to turn it into a method call
expression, not a bare call expression. Thus this is still a WIP.
llvm-svn: 91525
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
| |
that this was causing a problem, but it could have.
llvm-svn: 90343
|
|
|
|
| |
llvm-svn: 89875
|
|
|
|
|
|
| |
lack of viable convesion functions.
llvm-svn: 89216
|
|
|
|
| |
llvm-svn: 86674
|
|
|
|
| |
llvm-svn: 85880
|
|
|
|
|
|
|
| |
Split the various ambiguous result enumerators into their own enum. Tests
for most of C++ [namespace.qual].
llvm-svn: 83700
|
|
|
|
|
|
|
|
|
|
| |
from its location. Initialize appropriately.
When implicitly creating a declaration of a class template specialization
after encountering the first reference to it, use the pattern class's
location instead of the location of the first reference.
llvm-svn: 81515
|
|
|
|
| |
llvm-svn: 81504
|
|
|
|
|
|
| |
friends.
llvm-svn: 80977
|
|
|
|
|
|
|
|
|
|
|
|
| |
FriendFunctionDecl, and create instances as appropriate.
The design of FriendFunctionDecl is still somewhat up in the air; you can
befriend arbitrary types of functions --- methods, constructors, etc. ---
and it's not clear that this representation captures that very well.
We'll have a better picture when we start consuming this data in access
control.
llvm-svn: 78653
|
|
|
|
| |
llvm-svn: 78274
|
|
|
|
| |
llvm-svn: 74999
|
|
|
|
|
|
|
| |
namespaces based on the template arguments of a class template
specialization type.
llvm-svn: 74993
|
|
|
|
|
|
|
|
| |
data member.
Fixes "test/CXX/basic/basic.lookup/basic.lookup.unqual/p13.cpp" test case.
llvm-svn: 73652
|
|
|
|
|
|
| |
- p13 and p14 are important failures.
llvm-svn: 73392
|
|
- Failing, at least in part, because lookup in parser is finding a friend
function where it shouldn't.
llvm-svn: 73388
|