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

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 29 08:55:47 PDT 2022

rjmccall added inline comments.

Comment at: clang/lib/AST/Stmt.cpp:370-371
+  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.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list