failures that involve malformed types, e.g., "typename X::foo" where
"foo" isn't a type, or "std::vector<void>" that doens't instantiate
properly.
Similarly, be a bit smarter in our handling of ambiguities that occur
in Sema::getTypeName, to eliminate duplicate error messages about
ambiguous name lookup.
This eliminates two XFAILs in test/SemaCXX, one of which was crying
out to us, trying to tell us that we were producing repeated error
messages.
llvm-svn: 68251
- Finish up support for converting UTF8->UTF16 to support ObjC @"string" constants.
Remove warning from CheckObjCString.
As the FIXME in the test case indicates, I still have a bug to work out (apparently with \u handling).
llvm-svn: 68245
heuristics to determine when it's useful to desugar a type for display
to the user. Introduce two C++-specific heuristics:
- For a qualified type (like "foo::bar"), only produce a new
desugred type if desugaring the qualified type ("bar", in this
case) produces something interesting. For example, if "foo::bar"
refers to a class named "bar", don't desugar. However, if
"foo::bar" refers to a typedef of something else, desugar to that
something else. This gives some useful desugaring such as
"foo::bar (aka 'int')".
- Don't desugar class template specialization types like
"basic_string<char>" down to their underlying "class
basic_string<char, char_traits<char>, allocator<char>>, etc.";
it's better just to leave such types alone.
Update diagnostics.html with some discussion and examples of type
preservation in C++, showing qualified names and class template
specialization types.
llvm-svn: 68207
template template parameters and dependent template names. For
example, the oft-mentioned
typename MetaFun::template apply<T1, T2>::type
can now be instantiated, with the appropriate name lookup for "apply".
llvm-svn: 68128
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
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
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
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
LHS type and the computation result type; this encodes information into
the AST which is otherwise non-obvious. Fix Sema to always come up with the
right answer for both of these types. Fix IRGen and the analyzer to
account for these changes. This fixes PR2601. The approach is inspired
by PR2601 comment 2.
Note that this changes real *= complex in CodeGen from a silent
miscompilation to an explicit error.
I'm not really sure that the analyzer changes are correct, or how to
test them... someone more familiar with the analyzer should check those
changes.
llvm-svn: 67889
instantiation for C++ typename-specifiers such as
typename T::type
The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,
typename T::template apply<U, V>
Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.
Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples.
llvm-svn: 67875
uniqued representation that should both save some memory and make it
far easier to properly build canonical types for types involving
dependent nested-name-specifiers, e.g., "typename T::Nested::type".
This approach will greatly simplify the representation of
CXXScopeSpec. That'll be next.
llvm-svn: 67799
const DiagnosticBuilder &operator<<(const DiagnosticBuilder &DB,
AccessSpecifier AS);
so we can easily add access specifiers to diagnostics.
llvm-svn: 67795
Treat @package the same as @public. The documentation for @package says it is analogous to private_extern for variables/functions. Fully implementing this requires some kind of linker support (so access is denied to code outside the classes executable image). I don't believe GCC fully implements this semantic. Will discuss with Fariborz offline.
llvm-svn: 67755
specializations can be treated as a template. Finally, we can parse
and process the first implementation of Fibonacci I wrote!
Note that this code does not handle all of the cases where
injected-class-names can be treated as templates. In particular,
there's an ambiguity case that we should be able to handle (but
can't), e.g.,
template <class T> struct Base { };
template <class T> struct Derived : Base<int>, Base<char> {
typename Derived::Base b; // error: ambiguous
typename Derived::Base<double> d; // OK
};
llvm-svn: 67720
templates, including in-class initializers. For example:
template<typename T, T Divisor>
class X {
public:
static const T value = 10 / Divisor;
};
instantiated with, e.g.,
X<int, 5>::value
to get the value '2'.
llvm-svn: 67715
the declarations of member classes are instantiated when the owning
class template is instantiated. The definitions of such member classes
are instantiated when a complete type is required.
This change also introduces the injected-class-name into a class
template specialization.
llvm-svn: 67707
class C {
C() { }
int a;
};
C::C() : a(10) { }
We also diagnose when initializers are used on declarations that aren't constructors:
t.cpp:1:10: error: only constructors take base initializers
void f() : a(10) { }
^
Doug and/or Sebastian: I'd appreciate a review, especially the nested-name-spec test results (from the looks of it we now match gcc in that test.)
llvm-svn: 67672
failure to perform a declaration. Instead, explicitly note semantic
failures that occur during template parsing with a DeclResult. Fixes
PR3872.
llvm-svn: 67659
of "object type" rather than the C definition of "object type". The
difference is that C's "object type" excludes incomplete types such as
struct X;
However, C's definition also makes it far too easy to use isObjectType
as a means to detect incomplete types when in fact we should use other
means (e.g., Sema::RequireCompleteType) that cope with C++ semantics,
including template instantiation.
I've already audited every use of isObjectType and isIncompleteType to
ensure that they are doing the right thing for both C and C++, so this
is patch does not change any functionality.
llvm-svn: 67648
class C {
void g(C c);
virtual void f() = 0;
};
In this case, C is not known to be abstract when doing semantic analysis on g. This is done by recursively traversing the abstract class and checking the types of member functions.
llvm-svn: 67594
Chris Lattner