Make C++ classes track the POD property (C++ [class]p4)
Track the existence of a copy assignment operator.
Implicitly declare the copy assignment operator if none is provided.
Implement most of the parsing job for the G++ type traits extension.
Fully implement the low-hanging fruit of the type traits:
__is_pod: Whether a type is a POD.
__is_class: Whether a type is a (non-union) class.
__is_union: Whether a type is a union.
__is_enum: Whether a type is an enum.
__is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1).
llvm-svn: 61746
DeclContexts whose members are visible from enclosing DeclContexts up
to (and including) the innermost enclosing non-transparent
DeclContexts. Transparent DeclContexts unify the mechanism to be used
for various language features, including C enumerations, anonymous
unions, C++0x inline namespaces, and C++ linkage
specifications. Please refer to the documentation in the Clang
internals manual for more information.
Only enumerations and linkage specifications currently use transparent
DeclContexts.
Still to do: use transparent DeclContexts to implement anonymous
unions and GCC's anonymous structs extension, and, later, the C++0x
features. We also need to tighten up the DeclContext/ScopedDecl link
to ensure that every ScopedDecl is in a single DeclContext, which
will ensure that we can then enforce ownership and reduce the memory
footprint of DeclContext.
llvm-svn: 61735
semantics and improve our handling of default arguments. Specifically,
we follow this order:
- As soon as the see the '}' in the class definition, the class is
complete and we add any implicit declarations (default constructor,
copy constructor, etc.) to the class.
- If there are any default function arguments, parse them
- If there were any inline member function definitions, parse them
As part of this change, we now keep track of the the fact that we've
seen unparsed default function arguments within the AST. See the new
ParmVarDecl::hasUnparsedDefaultArg member. This allows us to properly
cope with calls inside default function arguments to other functions
where we're making use of the default arguments.
Made some C++ error messages regarding failed initializations more
specific.
llvm-svn: 61406
attached to an identifier. Instead, all overloaded functions will be
pushed into scope, and we'll synthesize an OverloadedFunctionDecl on
the fly when we need it.
llvm-svn: 61386
DeclContext. Instead, just keep the list of currently-active
declarations and only build the OverloadedFunctionDecl when we
absolutely need it.
This is a half-step toward eliminating the need to explicitly build
OverloadedFunctionDecls that store sets of overloaded
functions. This was suggested by Argiris a while back, and it's a good
thing for several reasons: first, it eliminates the messy logic that
currently tries to keep the OverloadedFunctionDecl in sync with the
declarations that are being added. Second, it will (eventually)
eliminate the need to allocate memory for overload sets, which could
help performance. Finally, it helps set us up for when name lookup can
return multiple (possibly ambiguous) results, as can happen with
lookup of class members in C++.
Next steps: make the IdentifierResolver store overloads as separate
entries in its list rather than replacing them with an
OverloadedFunctionDecl now, then see how far we can go toward
eliminating OverloadedFunctionDecl entirely.
llvm-svn: 61357
- Overloading has to cope with having both static and non-static
member functions in the overload set.
- The call may or may not have an implicit object argument,
depending on the syntax (x.f() vs. f()) and the context (static
vs. non-static member function).
- We now generate MemberExprs for implicit member access expression.
- We now cope with mutable whenever we're building MemberExprs.
llvm-svn: 61329
which can refer to static data members, enumerators, and member
functions as well as to non-static data members.
Implement correct lvalue computation for member references in C++.
Compute the result type of non-static data members of reference type properly.
llvm-svn: 61294
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
is completely defined (C++ [class.mem]p2).
Reverse the order in which we process the definitions of member
functions specified inline. This way, we'll get diagnostics in the
order in which the member functions were declared in the class.
llvm-svn: 61103
N::X only skips those entities specified in C++ [basic.lookup.qual]p1.
Note that both EDG and GCC currently get this wrong. EDG has confirmed
that the bug will be fixed in a future version.
llvm-svn: 61079
specifiers. Specifically:
* Determine when an out-of-line function definition does not match
any declaration within the class or namespace (including coping
with overloaded functions).
* Complain about typedefs and parameters that have scope specifiers.
* Complain about out-of-line declarations that aren't also
definitions.
* Complain about non-static data members being declared out-of-line.
* Allow cv-qualifiers on out-of-line member function definitions.
llvm-svn: 61058
just like all other members, and remove the special variables in
CXXRecordDecl to store them. This eliminates a lot of special-case
code for constructors and destructors, including
ActOnConstructor/ActOnDeclarator and special lookup rules in
LookupDecl. The result is far more uniform and manageable.
Diagnose the redeclaration of member functions.
llvm-svn: 61048
the type of the enumeration once the enumeration has been defined.
Fix the overloading test-case to properly create enums that promote
the way we want them to.
Implement C++0x promotions from enumeration types to long
long/unsigned long long. We're using these promotions in Carbon.h
(since long long is a common extension).
Fixes PR clang/2954: http://llvm.org/bugs/show_bug.cgi?id=2954
llvm-svn: 60917
and separates lexical name lookup from qualified name lookup. In
particular:
* Make DeclContext the central data structure for storing and
looking up declarations within existing declarations, e.g., members
of structs/unions/classes, enumerators in C++0x enums, members of
C++ namespaces, and (later) members of Objective-C
interfaces/implementations. DeclContext uses a lazily-constructed
data structure optimized for fast lookup (array for small contexts,
hash table for larger contexts).
* Implement C++ qualified name lookup in terms of lookup into
DeclContext.
* Implement C++ unqualified name lookup in terms of
qualified+unqualified name lookup (since unqualified lookup is not
purely lexical in C++!)
* Limit the use of the chains of declarations stored in
IdentifierInfo to those names declared lexically.
* Eliminate CXXFieldDecl, collapsing its behavior into
FieldDecl. (FieldDecl is now a ScopedDecl).
* Make RecordDecl into a DeclContext and eliminates its
Members/NumMembers fields (since one can just iterate through the
DeclContext to get the fields).
llvm-svn: 60878
"else" clause, e.g.,
if (int X = foo()) {
} else {
if (X) { // warning: X is always zero in this context
}
}
Fixes rdar://6425550 and lets me think about something other than
DeclContext.
llvm-svn: 60858
This fixes <rdar://problem/6424064> checker on xcode: (possible bad AST) can the type of a method parameter really have "isFunctionType() == true"?
and http://llvm.org/bugs/show_bug.cgi?id=2997.
llvm-svn: 60781
template<typename T> void f(T x) {
g(x); // g is a dependent name, so don't even bother to look it up
g(); // error: g is not a dependent name
}
Note that when we see "g(", we build a CXXDependentNameExpr. However,
if none of the call arguments are type-dependent, we will force the
resolution of the name "g" and replace the CXXDependentNameExpr with
its result.
GCC actually produces a nice error message when you make this
mistake, and even offers to compile your code with -fpermissive. I'll
do the former next, but I don't plan to do the latter.
llvm-svn: 60618
expressions, and value-dependent expressions. This permits us to parse
some template definitions.
This is not a complete solution; we're missing type- and
value-dependent computations for most of the expression types, and
we're missing checks for dependent types and type-dependent
expressions throughout Sema.
llvm-svn: 60615
property. It also checks for duplicate use of the same ivar
in two different iproperty implementations. It also caught
an error for a test case used in CodeGen :).
llvm-svn: 60610
Daniel Dunbar