Add support for _Return_value #205
Comments
A_Return_value expression allows programmers to name the value returned by a function in a return bounds declaration. This changes extends the clang IR to represent _Return_value expressions and _Current_expr_value expressions. It also adds lexing, parsing, and type system support for _Return_value expressions. This addresses the first part of issue #205. We create a new expression class BoundsValueExpr to represent these expressions. This class is modelled on CXXThisExpr. Constructing a_Return_value expression requires knowing the return type of the function that the return bounds is associated with. We must have the _Return_value expression constructed before we can build the function type, since function types incorporate the return bounds expressions. Unfortunately, we don't know the function return type until the middle of GetFullTypeForDeclarator in SemaType.cpp. Because clang intertwines AST building, type checking, and other static semantic checking, we have to "defer parse" return bounds expressions. "Defer parse" means that the compiler recognize the tokens that make up a return bounds expression, saves them, and parses them later to build the IR for the return bounds expressions. To allow parsing of the return bounds to happen in the middle of SemaType.cpp, we introduce a callback from semantic checking to the parser. This lets us preserve the interface between the two. We have to bring the parameters into scope, since they've already gone out of scope by the time GetFullTypeForDeclarator runs. We aren't the first people to have to do this. Other parsing phases such as parsing of attributes have to do this too. After parsing the return bounds expression, we attach it to the declarator whose type is being constructed. This lets us get the line number information right for error messages involving redeclarations with conflicting return bounds. (Long explanation: memoization of function types also memoizes bounds expressions embedded in types. It does this by ignoring line numbers and abstracting function parameters to parameter locations. The end result is that line numbers for expressions embedded in types are meaningless. Clang has a complicated mechanism for tracking source line information for types called TypeSourceInfo, but we haven't implemented support for embedded expressions in types and are not likely to anytime soon. This change also contains some unrelated clean up: 1. Fix the line ending for the test case for bug526 to be line feeds. 2. Delete identifiers for _Dynamic_bounds_cast and _Assume_bounds_cast. These are keywords, so we don't need identifiers. Testing: - There will be a separate pull request to the Checked C repo for parsing and typechecking tests for_Return_value. - Added clang tests for AST dumping and checking of bounds declarations. The checking of bounds declarations involving _Return_value doesn't work yet, so the tests document this. - Passes automated Checked C and clang testing with these changes.
|
I am replacing _Current_expr_value with expression temporaries. This leads to a cleaner, more efficient semantics. With _Current_expr_value, we had to adjust uses of it when inferring bounds expressions. The adjustment had to to offset the change between a subexpression value and the parent expression value. With expression temporaries, we no longer have to make this adjustment. An expression temporary is a temporary variable inserted by the compiler. The point at which assignment of a value to a temporary variable happens can be controlled precisely This is unlike C semantics for nested assignments to source-level variables. which informally says that "the assignments have to happen at some point before the evaluation of the expression is complete" (more precisely, happen in an order that respects sequence points). |
|
This issue got automatically closed by mistake: GitHub closed issue number N in the |
Uh oh!
There was an error while loading. Please reload this page.
Checked C allows return bounds expression for functions to use the keyword
_Return_valueto denote the return value of a function. It can be used in bounds expressions and bounds can be declared for it.The proposed work items are:
Note that I need the IR representation for _Current_expr_value soon (in the next few days), so if anyone picks this up soon, they should coordinate the IR work me.
The text was updated successfully, but these errors were encountered: