This cleans up the code somewhat and allows us conditionally to act on
different types of nodes depending on their context. E.g., if we're
checking for an ICE in a constant context.
Details
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 24822 Build 24821: arc lint + arc unit
Event Timeline
Can you explain more about the justification for this? The code today has a covered switch, which is useful for maintainability -- anyone adding a new Expr node gets told they need to think about and update this code. Are there any cases where we check for an ICE and aren't in a constant context? I would have expected that the fact we're asking implies that we are in a constant context (at least when the answer is "yes").
This code is called in over 90 places, so it's hard to tell if they all are in a constant context. Though I suppose that what this code is supposed to check for would work the same in a constant context as without one. I can revert this if you want, but to be honest the original function was terrible--it's huge and hard to understand what's going on. As for adding new expressions, this isn't the only place where a StmtVisitor is used. One still needs to go through all of those visitors to see if they need to add their expression.
Oh, I see, you want to temporarily set "IsConstantContext" to true while evaluating the subexpression of a ConstantExpr. I think that's unnecessary, because anywhere we ask "is this syntactically an ICE?", we always want to evaluate as if in a constant context (unlike places where we run the evaluator on an expression, where that doesn't necessarily imply anything in particular about the nature of the expression.)
Thinking about this some more: in the case where adding a new Stmt node without considering this code is likely to result in a silent and initially-unnoticed bug, I think it's useful to use one of our covered-switch-like patterns. But I don't think this actually is such a case; the C ICE rules are pretty conservative in what they allow, and new Stmt nodes should nearly always be treated as non-ICE. Thank you!
I don't think we necessarily need the change in the other patch that's based on this one, but I still think this refactoring is an improvement :)
This isn't necessary. We can assume it's in a constant context because it's checking for an ICE.
Thanks. I can resurrect this after these changes go in. This will keep the resulting changes small. :-)