Commit Graph

13 Commits

Author SHA1 Message Date
John McCall fd0b2f8fe4 Improve the diagnostics used to report implicitly-generated class members
as parts of overload sets.  Also, refer to constructors as 'constructors'
rather than functions.

Adjust a lot of tests.

llvm-svn: 92832
2010-01-06 09:43:14 +00:00
Douglas Gregor b6ea60872d Switch Sema::AddCXXDirectInitializerToDecl over to InitializationSequence
llvm-svn: 91927
2009-12-22 22:17:25 +00:00
Douglas Gregor 39c778b443 Switch default-initialization of variables of class type (or array thereof) over to InitializationSequence. I could swear that this fixes a PR somewhere, but I couldn't figure out which one
llvm-svn: 91796
2009-12-20 22:01:25 +00:00
Eli Friedman 7827520ce8 Initialization improvements: addition of string initialization and a few
small bug fixes in SemaInit, switch over SemaDecl to use it more often, and
change a bunch of diagnostics which are different with the new initialization
code.

llvm-svn: 91767
2009-12-19 08:11:05 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- 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
2009-12-15 20:14:24 +00:00
Fariborz Jahanian adcea10410 1) don't do overload resolution in selecting conversion
to pointer function for delete expression. 2)
Treat type conversion function and its 'const' version
as identical in building the visible conversion list.

llvm-svn: 81930
2009-09-15 22:15:23 +00:00
Fariborz Jahanian 3e6b57e593 Issue good diagnostics when initialization failes due to
ambiguity in type conversion function selection.

llvm-svn: 81898
2009-09-15 19:12:21 +00:00
Daniel Dunbar a45cf5b6b0 Rename clang to clang-cc.
Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602
2009-03-24 02:24:46 +00:00
Douglas Gregor ec8806e8ec Removed the warning
warning: statement was disambiguated as declaration

because it is currently firing in cases where the declaration would
not actually parse as a statement. We'd love to bring this warning
back if we can make it more accurate.

llvm-svn: 61137
2008-12-17 16:19:15 +00:00
Douglas Gregor 6f5431543a Implement C++ copy-initialization for declarations. There is now some
duplication in the handling of copy-initialization by constructor,
which occurs both for initialization of a declaration and for
overloading. The initialization code is due for some refactoring.

llvm-svn: 58756
2008-11-05 15:29:30 +00:00
Douglas Gregor c28b57d703 Implicit support for direct initialization of objects of class type, e.g.,
X x(5, 7);

llvm-svn: 58641
2008-11-03 20:45:27 +00:00
Argyrios Kyrtzidis 8ae3684aa9 In ParseParenDeclarator match "D.setGroupingParens(true);" with another setGroupingParens call after the ')' is parsed.
Fixes this bug:
  int (x)(0); // error, expected function declarator where the '(0)' initializer is

llvm-svn: 57241
2008-10-07 10:21:57 +00:00
Argyrios Kyrtzidis 9a1191c047 Implement support for C++ direct initializers in declarations, e.g. "int x(1);".
This is how this kind of initializers appear in the AST:
-The Init expression of the VarDecl is a functional type construction (of the VarDecl's type).
-The new VarDecl::hasCXXDirectInitializer() returns true.

e.g, for "int x(1);":
-VarDecl 'x' has Init with expression "int(1)" (CXXFunctionalCastExpr).
-hasCXXDirectInitializer() of VarDecl 'x' returns true.

A major benefit is that clients that don't particularly care about which exactly form was the initializer can handle both cases without special case code.
Note that codegening works now for "int x(1);" without any changes to CodeGen.

llvm-svn: 57178
2008-10-06 17:10:33 +00:00