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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61137 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@58756 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes this bug:
int (x)(0); // error, expected function declarator where the '(0)' initializer is
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57241 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@57178 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Dunbar
Douglas Gregor
Argyrios Kyrtzidis