void func() {
int xx = xx; // incorrectly diagnosed 'xx' as an undeclared identifier.
}
This smallish bug resulted in a largish fix. Here are some highlights:
- Needed to make sure ParseDeclarator is called *before* parsing any
initializer. Removed the "Init" argument to ParseDeclarator.
- Added AddInitializerToDecl() to the Action & Sema classes.
In Sema, this hook is responsible for validating the initializer and
installing it into the respective decl.
- Moved several semantic checks from ParseDeclarator() to
FinalizeDeclaratorGroup(). Previously, this hook was only responsible for
reversing a list. Now it plays a much larger semantic role.
All of the above changes ended up simplifying ParseDeclarator(), which
is goodness...
llvm-svn: 41877
This method is used to determine if an expression contains implicit
control-flow, and thus appears in a distinct statement slot in the CFG.
For example:
(1) x = ... ? ... ? ...
logically becomes:
(1) ... ? ... : ... (a unique statement slot for the ternary ?)
(2) x = [E1] (where E1 is actually the ConditionalOperator*)
A client of the CFG, when walking the statement at (2), will encounter
E1. In this case, hasImplicitControlFlow(E1) == true, and the client
will know that the expression E1 is explicitly placed into its own statement
slot to capture the implicit control-flow it has.
llvm-svn: 41868
where not reversing the order of their subexpression blocks.
Added feature where CallExprs are placed in their own statement slot in
a CFGBlock. Thus we have a designated "return site" within a CFGBlock when
reasoning about function calls.
llvm-svn: 41866
- Instantiate the node in Sema::ParseField(), based on the type of the TagDecl.
- Add Sema::ObjcAddInstanceVariable(), responsible for adorning/adding the ObjcIvarDecl.
llvm-svn: 41864
access to bits). Use them in place of float and
double interfaces where appropriate.
First bits of x86 long double constants handling
(untested, probably does not work).
llvm-svn: 41858
if the assigned value is a constant expression, e.g.:
int x = 0;
We then check to see if "x" is ever reassigned later. If so, we don't
emit a warning. This is because programmers frequently use defensive
programming to make sure a variable has a defined value.
llvm-svn: 41853
of their elements do not yield the same ParamAttrsList,
though they should. On the other hand, everyone seems
to pass such vectors with elements ordered by increasing
index, so rather than sorting the elements simply assert
that the elements are ordered in this way.
llvm-svn: 41845
Fariborz Jahanian