class C {
static const int number = 50;
static int arr[number];
};
Here's how it worked:
-GetTypeForDeclarator was called from both Sema::ActOnCXXMemberDeclarator and Sema::ActOnDeclarator.
-VariableArrayTypes are not uniqued so two VariableArrayTypes were created with the same DeclRefExpr.
-On exit they both tried to destroy that one DeclRefExpr.
The fix is not to use GetTypeForDeclarator from the Sema::ActOnCXXMemberDeclarator.
Steve Naroff [Wed, 8 Oct 2008 18:44:00 +0000 (18:44 +0000)]
Instantiate the BlockDecl in ActOnBlockStart() so we can use it as a DeclContext.
This required changes to attach the compound statement later on (like we do for functions).
Steve Naroff [Wed, 8 Oct 2008 17:01:13 +0000 (17:01 +0000)]
- Add BlockDecl AST node.
- Modify BlockExpr to reference the BlockDecl.
This is "cleanup" necessary to improve our lookup semantics for blocks (to fix <rdar://problem/6272905> clang block rewriter: parameter to function not imported into block?).
Still some follow-up work to finish this (forthcoming).
Zhongxing Xu [Wed, 8 Oct 2008 02:50:44 +0000 (02:50 +0000)]
This is the first step to implement a field-sensitive store model. Other things are simplified: no heap shape assumption, no parameter alias assumption, etc.
Ted Kremenek [Tue, 7 Oct 2008 23:09:49 +0000 (23:09 +0000)]
Migrate DeclStmt over to using a DeclGroup instead of a pointer to a ScopedDecl*.
This also removes the ugly hack needed in CFG.cpp for subclassing DeclStmt to create a DeclStmt with one Decl*.
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
Simplify handling of direct initializers by letting Sema::AddInitializerToDecl handle conversions, instead of using Sema::ActOnCXXTypeConstructExpr.
Additional benefit is that diagnostics are the same for both direct-initialization and copy-initialization.
In the case of "int x( expression );":
-The Init expression of VarDecl 'x' will be the expression inside the parentheses.
-VarDecl::hasCXXDirectInitializer for VarDecl 'x' will return true to let clients distinguish from "int x = expression ;".
Ted Kremenek [Mon, 6 Oct 2008 22:45:07 +0000 (22:45 +0000)]
Explicitly access the first Decl* referenced by a DeclStmt instead of using "getDecl()." Added a FIXME indicating that the call to RewriteObjCQualifiedInterfaceTypes() is meant to modifying the type-specifier; hopefully this will be a little more clean once DeclGroups contain type specifiers.
Ted Kremenek [Mon, 6 Oct 2008 22:17:16 +0000 (22:17 +0000)]
Modified DeclGroupRef to always load/store the internal pointer value as Decl*. This hopefully will obviate any concerns with violating strict type-aliasing issues.
Ted Kremenek [Mon, 6 Oct 2008 20:58:11 +0000 (20:58 +0000)]
When processing Objective-C foreach statements, first check to see if the statement has a DeclStmt with a single Decl. Afterwards, use DeclStmt::getSolitaryDecl() to access that Decl (thus avoiding an assertion being triggered). These changes remove an unneeded use of ScopedDecl::getNextDeclarator() and DeclStmt::getDecl().
Ted Kremenek [Mon, 6 Oct 2008 18:47:09 +0000 (18:47 +0000)]
In RewriteFunctionBody, using DeclStmt::decl_iterator to rewrite the Decls in a DeclStmt instead of using getDecl() to fetch the first Decl.
Steve: Please review this patch. 'make test' passes, and my cursory scan of the rewriter leads me to believe this doesn't break anything, but I'm not sure.
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.
Chris Lattner [Mon, 6 Oct 2008 07:26:43 +0000 (07:26 +0000)]
Make sema and codegen allow __builtin___CFStringMakeConstantString as a valid
constant lvalue. Implement this in codegen by moving the code out of CGBuiltin
into EmitConstantExpr.
Chris Lattner [Mon, 6 Oct 2008 06:56:41 +0000 (06:56 +0000)]
always try to fold a builtin before emitting it. In the future
it is possible that a builtin could sometimes be folded (e.g. __builtin_clz)
if it's operand is a constant.
Chris Lattner [Mon, 6 Oct 2008 06:51:12 +0000 (06:51 +0000)]
Remove the 'C' / isConstantExpr flag on builtins. Code should never
depend on the value of this flag, it should depend on whether
tryEvaluate is able to *actually* fold a builtin.
Chris Lattner [Mon, 6 Oct 2008 06:49:02 +0000 (06:49 +0000)]
Add a Expr::isEvaluatable method, eliminate isBuiltinConstantExpr
which is checking for something that can be inconsistent with
what we can constant fold.
Chris Lattner [Mon, 6 Oct 2008 06:09:18 +0000 (06:09 +0000)]
remove some code where CGBuiltin folds constants, and use tryEvaluate to
do it instead. We should still handle __builtin_nan etc, but don't yet.
This fixes incorrect evaluation of __builtin_constant_p, a FIXME.
Chris Lattner [Mon, 6 Oct 2008 05:59:01 +0000 (05:59 +0000)]
instead of making codegen try to know about all of the builtins to generate
constants for them, just use the constant evaluator to do the job. This
also fixes crashes on 'unknown constant builtins'.
Chris Lattner [Mon, 6 Oct 2008 05:42:39 +0000 (05:42 +0000)]
"Enhance" CheckArithmeticConstantExpression to accept ?: with a constant
condition as a constant even if the unevaluated side is a not a constant.
We don't do this when extensions are off, and we emit a warning when this
happens:
t.c:22:11: warning: expression is not a constant, but is accepted as one by GNU extensions
short t = __builtin_constant_p(5353) ? 42 : somefunc();
^ ~~~~~~~~~~
suggestions for improvement are welcome. This is obviously horrible, but
is required for real-world code.
Chris Lattner [Mon, 6 Oct 2008 05:28:25 +0000 (05:28 +0000)]
Add a comment that describes tryEvaluate. Make tryEvaluate fold
__builtin_constant_p properly, and add some scaffolding for
FloatExprEvaluator to eventually handle huge_val and inf.
Chris Lattner [Sun, 5 Oct 2008 20:06:37 +0000 (20:06 +0000)]
move a bunch more integer sizing out of target-specific code into
target indep code.
Note that this changes functionality on PIC16: it defines __INT_MAX__
correctly for it, and it changes sizeof(long) to 16-bits (to match
the size of pointer).
Found a subtle bug caused by an implicit enum-to-bool conversion (of the TentativeParsingResult enum).
This was the motivation of the following changes:
-'TentativeParsingResult' enum is replaced by a 'TPResult' class that basically encapsulates the enum.
-TPR_true, TPR_false, TPR_ambiguous, and TPR_error enum constants are replaced by TPResult::True(), TPResult::False(), etc. calls that return a TPResult object.
-Also fixed the subtle bug in Parser::isCXXFunctionDeclarator (caught by the above changes as a compilation error).
projects / clang / log