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
