that are builtin and those that are aren't. This is a bunch
of API refactoring that will make this possible, but there is
no functionality change yet.
llvm-svn: 44473
After a discussion with Ted, we both came to the conclusion that adding a "HandleTopLevelDeclaration" hook to ASConsumer is far more elegant. The default implementation of HandleTopLevelDeclaration will be responsible for iterating over the ScopedDecl (which has a chain of the decls:-).
TODO: Once Ted adds HandleTopLevelDeclaration, make sure TagDecls are chainged appropriately...
llvm-svn: 44445
be the new hook that ASTStreamer calls to feed top-level Decls to
ASTConsumers.
The difference between "HandleTopLevelDeclaration" and "HandleTopLevelDecl" is
that "HandleTopLevelDecl" is currently called by ASTStreamer for every
top-level declaration, including those that appear within a Decl chain. Using
the new interface, ASTStreamer would only call HandleTopLevelDeclaration for
Decls that appear that the beginning of a Decl chain (i.e., a group of related
decls).
To preserve the behavior that all subclasses of ASTConsumer currently expect,
the default implementation of HandleTopLevelDeclaration simply calls
HandleTopLevelDecl, and for decl chains it calls HandleTopLevelDecl for each
Decl* in a chain of Decls.
The advantage of this interface is that some subclasses of ASTConsumer only
really want the Decl chain, and not each individual Decl passed to them. This
extra level of indirection allows subclasses to override the default behavior
if they so desire.
llvm-svn: 44444
in the middle of a split basic block, create a new live interval starting at
the def. This avoid artifically extending the live interval over a number of
cycles where it is dead. e.g.
bb1:
= vr1204 (use / kill) <= new interval starts and ends here.
...
...
vr1204 = (new def) <= start a new interval here.
= vr1204 (use)
llvm-svn: 44436
both before and after serialization/deserialization. If the CFGs between the pre-
and post- serialized/deserialized ASTs differ, the serialization has failed.
llvm-svn: 44429
floating-point literals that are represented exactly by the APFloat in
FloatingLiteral. For such literals, we do not emit a warning since such checks are
often performed in real code to see if a variable has changed from its original
value. This heuristic clearly can lead to false negatives, but the hope is it will
significantly reduce false positives to help make the compiler flag more useful.
llvm-svn: 44424
the APFloat representing the parsed literal can represent the literal value
exactly. This is useful when performing various semantic checks on the code,
and issuing appropriate warnings to users.
llvm-svn: 44423
converts a parsed literal into an APFloat. We are still performing a copy of the
string, which hopefully will be removed eventually for performance reasons. This
version now is at least safe.
Changed rounding in APFloat construction in NumericLiteralParser from rmTowardsZero
to rmNearestTiesToEven.
llvm-svn: 44422
Evan Cheng