[PATCH] D123952: [FPEnv] Allow CompoundStmt to keep FP options

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.


================
Comment at: clang/lib/AST/Stmt.cpp:370-371
   setStmts(Stmts);
+  if (hasStoredFPFeatures())
+    setStoredFPFeatures(FPFeatures);
 }
----------------
aaron.ballman wrote:
> rjmccall wrote:
> > aaron.ballman wrote:
> > > There's a part of me that wonders if it's a slightly more clear design to have `setStoredFPFeatures()` set `CompoundStmtBits.HasFPFeatures` to true as needed rather than requiring the caller to do this two-step initialization process. WDYT?
> > `setStoredFPFeatures` is only otherwise used in deserialization, and the node has to be allocated properly to support it.  I think this is the right approach.
> My concern was more with new calls added later -- it seems reasonable that someone would think they could call `setStoredFPFeatures()` and have them stored rather than asserting the object already claims to have stored features.
> 
> That said, I don't feel strongly, so we can always adjust it in the future as new callers are added.
Well, it's private, and there's a comment on it saying that it's only used by serialization.  Because the trailing storage for the features doesn't actually exist unless the node was allocated specially, I think it's probably more important to allow for the safety check that the node was allocated that way than to worry about transient semi-initialized states during deserialization, which already has a lot of potential problems like this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123952/new/

https://reviews.llvm.org/D123952