erichkeane accepted this revision. erichkeane added a comment. This revision is now accepted and ready to land.
I think I'm Ok with this as a 1st step for the cleanup. I think we should probably evaluate what amount of work is necessary to extract the ExtInfo out into trailing storage, depending on whether it saves us room in the FunctionProtoType and FunctionNoProtoType types. ================ Comment at: clang/include/clang/AST/Type.h:4103 bool hasExtraBitfields() const { - return hasExtraBitfields(getExceptionSpecType()); + assert((getExceptionSpecType() != EST_Dynamic || + FunctionTypeBits.HasExtraBitfields) && ---------------- sdesmalen wrote: > sdesmalen wrote: > > erichkeane wrote: > > > Why is asking if we DO have extra bitfields an assert here? I would > > > think this is a valid question... > > > > > > Why would 'dynamic' and extra-bitfields be exclusive here? > > This assert is merely confirming that HasExtraBitfields **must** be true if > > the ExceptionSpecType is `EST_Dynamic`, because that was the old behaviour > > (and I wanted to avoid introducing failures if some code still assumed that > > hasExtraBitfields == true, but for some reason HasExtraBitfields had not > > yet been set to `true`). > I've marked the comment as done hoping that my above explanation clarified > it, but let me know if you're not happy with it. Ah, that makes sense, thanks. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126642/new/ https://reviews.llvm.org/D126642 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits