================
@@ -1981,21 +1981,35 @@ class FunctionDecl : public DeclaratorDecl,
};
- /// Stashed information about a defaulted function definition whose body has
- /// not yet been lazily generated.
- class DefaultedFunctionInfo final
- : llvm::TrailingObjects<DefaultedFunctionInfo, DeclAccessPair> {
+ /// Stashed information about a defaulted/deleted function body.
+ class DefaultedOrDeletedFunctionInfo final
+ : llvm::TrailingObjects<DefaultedOrDeletedFunctionInfo, DeclAccessPair,
+ StringLiteral *> {
friend TrailingObjects;
unsigned NumLookups;
+ bool HasDeletedMessage;
----------------
Sirraide wrote:
> The alignment is likely to go from 32 to 64, isn't it?
It would normally, but from what I can tell, because it’s inheriting from
`TrailingObjects`, the alignment is set to the maximum of the alignment of what
the type would normally have and the alignment of each of the trailing objects
(by an `alignas` on `TralingObjectsBase`), and since the maximum alignment of
the latter is `64`, that ends up being the alignment of the overall struct as
well and thus also its size.
Printing out `sizeof(DefaultedOrDeletedFunctionInfo)` shows `8` in both cases
(w/ and w/o the bitfield). I also don’t have a strong opinion on this
personally; I just didn’t want to make it a bitfield when there’s space
available anyway because this way, it’s at least obvious that we have more
space left if we need to add more flags later.
https://github.com/llvm/llvm-project/pull/86526
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
