No need to pass CheckedScopeSpecifier around in SemaBounds.cpp

[mgrang]

After #1142 we can get the CheckedScopeSpecifier (CSS) for every statement by invoking S->getCheckedScopeSpecifier().

In SemaBounds.cpp we pass CSS around to functions. This should no longer be needed.

[kkjeer]

Will this work for all subexpressions in a statement?

For example, if we have:

void f(_Array_ptr<int> p : count(1), _Array_ptr<int> q : count(2)) {
  _Checked {
    p = q, p++;
  }
}

At the assignment p = q (subexpression of the statement p = q, p++, we call CheckBinaryOperator(e, ..., CSS), where e is the binary operator expression p = q. Can we tell that p = q is in a checked scope without passing the CSS argument to CheckBinaryOperator?

[mgrang]

Checked Scope Specifiers (CSS) are set per statement. Sub-expressions do not have CSS. So p = q, p++ would have a CSS, not the subexpression p = q. The CSS for a subexpression should be the same as its containing statement. So I guess you could determine which statement a nested sub-expression belongs to and use its CSS.

[sulekhark]

This is a good reason to reconsider the following (review comment in PR #1142):
The field CSS is added as a sibling field of sClass in the class StmtBitfields - i.e. it is present for every "Stmt". The field sClass is initialized in the constructor for Stmt at line 1200 (in AST/Stmt.h on master branch). It is also possible to initialize the field CSS in the same constructor because GetCheckedScopeInfo (which reads CheckingKind that stores the currently applicable value of the checked scope specification) is a Sema function. This will avoid looping over the statements in the body of a compound statement, which may be unavoidable if the CSS field is set in ActOnCompoundStmt.

It may not be a good idea to have to figure out the statement which contains the subexpression for which the CSS value is required, each time.