Commit Graph

42 Commits

Author SHA1 Message Date
John McCall a009726ce3 Implement access declarations. Most of the work here is parsing them, which
is difficult because they're so terribly, terribly ambiguous.


We implement access declarations in terms of using declarations, which is
quite reasonable.  However, we should really persist the access/using
distinction in the AST and use the appropriate name in diagnostics.  This
isn't a priority, so I'll just file a PR and hope someone else does it. :)

llvm-svn: 91095
2009-12-11 02:10:03 +00:00
Douglas Gregor a25d65d1b6 Implement C++ [basic.lookup.classref]p3, which states how the type
name 'T' is looked up in the expression

  t.~T()

Previously, we weren't looking into the type of "t", and therefore
would fail when T actually referred to an injected-class-name. Fixes
PR5530.

llvm-svn: 89493
2009-11-20 22:03:38 +00:00
John McCall e61f2ba7e4 Incremental progress on using declarations. Split UnresolvedUsingDecl into
two classes, one for typenames and one for values;  this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard.  Track the location of the 'typename' keyword in a using-typename
decl.  Make a new lookup result for unresolved values and deal with it in
most places.

llvm-svn: 89184
2009-11-18 02:36:19 +00:00
Ted Kremenek a26da8503c Pass source locations of identifiers referenced by @class through Action::ActOnForwardClassDeclaration().
llvm-svn: 89162
2009-11-17 23:12:20 +00:00
Douglas Gregor 220f4277bd Switch parsing of using declarations over to ParseUnqualifiedId.
llvm-svn: 86027
2009-11-04 16:30:06 +00:00
Douglas Gregor 3cf81317e4 Parsing and semantic analysis for template-ids that name overloaded
operators, e.g., 

  operator+<int>

which now works in declarators, id-expressions, and member access
expressions. This commit only implements the non-dependent case, where
we can resolve the template-id to an actual declaration.

llvm-svn: 85966
2009-11-03 23:16:33 +00:00
Mike Stump 11289f4280 Remove tabs, and whitespace cleanups.
llvm-svn: 81346
2009-09-09 15:08:12 +00:00
Douglas Gregor b7bfe79412 Rewrite of our handling of name lookup in C++ member access expressions, e.g.,
x->Base::f

We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.

We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.

I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.

llvm-svn: 80843
2009-09-02 22:59:36 +00:00
Anders Carlsson 7b194b780d Set the access specifier for using decls.
llvm-svn: 80435
2009-08-29 19:54:19 +00:00
Douglas Gregor 5e0962f944 When we know that we are parsing a class-name, implicitly construct a
TypenameType if getTypeName is looking at a member of an unknown
specialization. This allows us to properly parse class templates that
derived from type that could only otherwise be described by a typename type, 
e.g.,

  template<class T> struct X {};
  template<typename T> struct Y : public X<T>::X { }; 

Fixes PR4381.

llvm-svn: 80123
2009-08-26 18:27:52 +00:00
Douglas Gregor e861bac059 Improve support for out-of-line definitions of nested templates and
their members, including member class template, member function
templates, and member classes and functions of member templates.

To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,

  template<typename X> template<typename Y>
  X Outer<X>::Inner1<Y>::foo(Y) {
    return X();
  }

we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.

Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.

llvm-svn: 80044
2009-08-25 22:51:20 +00:00
Anders Carlsson 74d7f0dd65 Make it possible for using decls to point to operators. Fixes PR4441.
llvm-svn: 74362
2009-06-27 00:27:47 +00:00
Douglas Gregor fec52635f0 Parsing and AST support for using declarations, from John Thompson!
llvm-svn: 73812
2009-06-20 00:51:54 +00:00
Chris Lattner a020b07634 teach -parse-noop about int128_t and friends.
llvm-svn: 70547
2009-05-01 16:33:20 +00:00
Douglas Gregor b67535d1b6 Parsing and AST representation for dependent template names that occur
within nested-name-specifiers, e.g., for the "apply" in

  typename MetaFun::template apply<T1, T2>::type

At present, we can't instantiate these nested-name-specifiers, so our
testing is sketchy.

llvm-svn: 68081
2009-03-31 00:43:58 +00:00
Douglas Gregor dc572a3266 Improve the representation of template names in the AST. This
representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").

One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as

  std::(vector<int>)

we represent it as

  (std::vector)<int>

which more closely follows the C++ grammar. 

Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.

llvm-svn: 68074
2009-03-30 22:58:21 +00:00
Chris Lattner 5bbb3c8ad9 Push DeclGroup much farther throughout the compiler. Now the various
productions (except the already broken ObjC cases like @class X,Y;) in 
the parser that can produce more than one Decl return a DeclGroup instead
of a Decl, etc.

This allows elimination of the Decl::NextDeclarator field, and exposes
various clients that should look at all decls in a group, but which were
only looking at one (such as the dumper, printer, etc).  These have been
fixed.

Still TODO:

1) there are some FIXME's in the code about potentially using
DeclGroup for better location info.
2) ParseObjCAtDirectives should return a DeclGroup due to @class etc.
3) I'm not sure what is going on with StmtIterator.cpp, or if it can
   be radically simplified now.
4) I put a truly horrible hack in ParseTemplate.cpp.

I plan to bring up #3/4 on the mailing list, but don't plan to tackle
#1/2 in the short term.

llvm-svn: 68002
2009-03-29 16:50:03 +00:00
Chris Lattner 83f095cc7e Introduce a new OpaquePtr<N> struct type, which is a simple POD wrapper for a
pointer.  Its purpose in life is to be a glorified void*, but which does not
implicitly convert to void* or other OpaquePtr's with a different UID.

Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>.  Change the 
entire parser/sema interface to use DeclPtrTy instead of DeclTy*.  This
makes the C++ compiler enforce that these aren't convertible to other opaque
types.

We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
but I don't plan to do that in the short term.

The one outstanding known problem with this patch is that we lose the 
bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
bitmangle the success bit into the low bit of DeclPtrTy.  I will rectify
this with a subsequent patch.

llvm-svn: 67952
2009-03-28 19:18:32 +00:00
Chris Lattner deab7250fb fix "Comment#1" from PR3872
llvm-svn: 67625
2009-03-24 17:05:27 +00:00
Sebastian Redl 6d4256c3c1 Convert a bunch of actions to smart pointers, and also bring PrintParserCallbacks a bit more in line with reality.
llvm-svn: 67029
2009-03-15 17:47:39 +00:00
Chris Lattner eae6cb6154 rename PrettyStackTraceDecl -> PrettyStackTraceActionsDecl.
Introduce a new PrettyStackTraceDecl.
Use it to add the top level LLVM IR generation stuff in 
Backend.cpp to stack traces.  We now get crashes like:

Stack dump:
0.	Program arguments: clang t.c -emit-llvm 
1.	<eof> parser at end of file
2.	t.c:1:5: LLVM IR generation of declaration 'a'
Abort

for IR generation crashes.

llvm-svn: 66153
2009-03-05 08:00:35 +00:00
Chris Lattner bcfe4f7b7b When the parser is live, print out the location and spelling of its current token.
For example:

Stack dump:
0.	Program arguments: clang t.cpp 
1.	t.cpp:4:8: current parser token: ';'
2.	t.cpp:3:1: parsing struct/union/class body 'x'
Abort

It is weird that the parser is always "underneath" any parse context 
actions, but the parser is created first.

llvm-svn: 66148
2009-03-05 07:24:28 +00:00
Chris Lattner 03b5394da7 When parsing a function body, add it to the crash stack, giving us something
like:

Stack dump:
0.	t.c:5:10: in compound statement ('{}')
1.	t.c:3:12: in compound statement ('{}')
2.	t.c:3:12: parsing function body 'foo'
3.	clang t.c 
Abort

llvm-svn: 66118
2009-03-05 01:25:28 +00:00
Douglas Gregor 7f74112756 Implement parsing of nested-name-specifiers that involve template-ids, e.g.,
std::vector<int>::allocator_type

When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:

  template<> class Outer::Inner<int> { ... };

We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.

Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.

llvm-svn: 65467
2009-02-25 19:37:18 +00:00
Douglas Gregor 8bf4205c70 Start processing template-ids as types when the template-name refers
to a class template. For example, the template-id 'vector<int>' now
has a nice, sugary type in the type system. What we can do now:

  - Parse template-ids like 'vector<int>' (where 'vector' names a
    class template) and form proper types for them in the type system.
  - Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly,
    using (sadly) a bool in the parser to tell it whether '>' should
    be treated as an operator or not.

This is a baby-step, with major problems and limitations:
  - There are currently two ways that we handle template arguments
  (whether they are types or expressions). These will be merged, and,
  most likely, TemplateArg will disappear.
  - We don't have any notion of the declaration of class template
  specializations or of template instantiations, so all template-ids
  are fancy names for 'int' :)

llvm-svn: 64153
2009-02-09 18:46:07 +00:00
Douglas Gregor 8a6be5ec64 Diagnose ambiguities in getTypeName. Fixes http://llvm.org/bugs/show_bug.cgi?id=3475
llvm-svn: 63737
2009-02-04 17:00:24 +00:00
Steve Naroff 16c8e598ae Name change (isTypeName->getTypeName).
Since it doesn't return a bool, is shouldn't be prefixed with 'is'.

llvm-svn: 63226
2009-01-28 19:39:02 +00:00
Chris Lattner c671e061eb Switch MinimalAction from new/delete'ing its TypeNameInfo to
allocating them from a recycling bump pointer allocator.  This 
reduces malloc/free traffic of parse-noop (but no other mode),
which makes sharking -parse-noop more meaningful.

llvm-svn: 62460
2009-01-18 09:39:41 +00:00
Douglas Gregor 55ad91fecb Ultrasimplistic sketch for the parsing of C++ template-ids. This won't
become useful or correct until we (1) parse template arguments
correctly, (2) have some way to turn template-ids into types,
declarators, etc., and (3) have a real representation of templates.

llvm-svn: 61208
2008-12-18 19:37:40 +00:00
Douglas Gregor ae2fbad373 Updated IdentifierResolver to deal with DeclarationNames. The names of
C++ constructors, destructors, and conversion functions now have a
FETokenInfo field that IdentifierResolver can access, so that these
special names are handled just like ordinary identifiers. A few other
Sema routines now use DeclarationNames instead of IdentifierInfo*'s.

To validate this design, this code also implements parsing and
semantic analysis for id-expressions that name conversion functions,
e.g.,

  return operator bool();

The new parser action ActOnConversionFunctionExpr takes the result of
parsing "operator type-id" and turning it into an expression, using
the IdentifierResolver with the DeclarationName of the conversion
function. ActOnDeclarator pushes those conversion function names into
scope so that the IdentifierResolver can find them, of course.

llvm-svn: 59462
2008-11-17 20:34:05 +00:00
Argyrios Kyrtzidis 32a0379575 Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side.
No Sema functionality change, just the signatures of the Action/Sema methods.

llvm-svn: 58913
2008-11-08 16:45:02 +00:00
Douglas Gregor 61956c460a Add support for parsing and representing C++ constructor declarations.
Notes:
  - Constructors are never found by name lookup, so they'll never get
    pushed into any scope. Instead, they are stored as an 
    OverloadedFunctionDecl in CXXRecordDecl for easy overloading.
  - There's a new action isCurrentClassName that determines whether an
    identifier is the name of the innermost class currently being defined;
    we use this to identify the declarator-id grammar rule that refers to 
    a type-name. 
  - MinimalAction does *not* support parsing constructors.
  - We now handle virtual and explicit function specifiers.

llvm-svn: 58499
2008-10-31 09:07:45 +00:00
Daniel Dunbar f8362f9e5d "One" line fix for -parse-noop failure, "id" and several other things
were being treated as type names for non-Objective-C files.
 - Other lines are just because MinimalAction didn't have access to
   the LangOptions.

llvm-svn: 58498
2008-10-31 08:56:51 +00:00
Daniel Dunbar 1ff1d1fd51 Move AsmLabel into Declarator instead of just a parameter to
ActOnDeclarator.

llvm-svn: 54353
2008-08-05 16:28:08 +00:00
Daniel Dunbar 4983df37a7 Add more Parser/Sema support for GCC asm-label extension.
- ActOnDeclarator now takes an additional parameter which is the
   AsmLabel if used. Its unfortunate that this bubbles up this high,
   but we cannot just lump it in as an attribute without mistakenly
   *accepting* it as an attribute.
 - The actual asm-label itself is, however, encoded as an AsmLabelAttr
   on the FunctionDecl.
 - Slightly improved parser error recovery on malformed asm-labels.
 - CodeGen support still missing...

llvm-svn: 54339
2008-08-05 01:35:17 +00:00
Ted Kremenek be9b33bf0f Nico Weber:
"the attached patch fixes some typos, 80 cols violations, etc. in comments."

llvm-svn: 54328
2008-08-04 22:51:42 +00:00
Argyrios Kyrtzidis 25d05e88a5 Wherever a type is used/returned from the Action module, use TypeTy instead of DeclTy or void.
No functionality change.

llvm-svn: 54265
2008-08-01 10:35:27 +00:00
Chris Lattner df59f5aa3c Pull protocol resolution of out ActOnStartClassInterface, this is also the
last client of the old ParseObjCProtocolReferences, so it also removes it.

llvm-svn: 54094
2008-07-26 04:13:19 +00:00
Chris Lattner d7352d6801 minor cleanup to the actions interface to pass around SmallVectorImpl instead
of a specific smallvector size.

Fix protocol lists to pass down proper location info, so we get diagnostics
like this:

t.m:3:35: error: cannot find protocol definition for 'NSCopying', referenced by 'NSWhatever'
@interface NSWhatever : NSObject <NSCopying>
                                  ^

instead of this:

t.m:3:44: error: cannot find protocol definition for 'NSCopying', referenced by 'NSWhatever'
@interface NSWhatever : NSObject <NSCopying>
                                           ^


Add a new IdentifierLocPair typedef which is just a pair<IdentifierInfo*, SourceLocation>

llvm-svn: 53883
2008-07-21 22:17:28 +00:00
Chris Lattner 046485640d fix typo
llvm-svn: 53848
2008-07-21 07:13:18 +00:00
Steve Naroff 2fc93f5c43 Two changes to Sema::LookupDecl() interface.
(1) Remove IdLoc (it's never used). 
(2) Add a bool to enable/disable lazy builtin creaation (defaults to true).

This enables us to use LookupDecl() in Sema::isTypeName(), which is also part of this commit.

To make this work, I changed isTypeName() to be a non-const member function. I'm not happy with this, however I fiddled with making LookupDecl() and friends const and it got ugly pretty quickly. We can certainly add it back if/when someone has time to fiddle with it. For now, I thought this simplification was more important than retaining the const-ness. 

llvm-svn: 49087
2008-04-02 14:35:35 +00:00
Chris Lattner 7a51313d8a Make a major restructuring of the clang tree: introduce a top-level
lib dir and move all the libraries into it.  This follows the main
llvm tree, and allows the libraries to be built in parallel.  The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in.  This speeds
up parallel builds, particularly incremental ones.

llvm-svn: 48402
2008-03-15 23:59:48 +00:00