https://github.com/Sirraide commented:
> The LLVM cleanup was more surprising: I discovered that we have an [old > policy](https://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers) > about including out-of-line virtual functions in every class with a vtable, > even final ones. This means our codebase has many virtual "anchor" functions > which do nothing except control where the vtable is emitted, and which > trigger the warning. I looked into alternatives to satisfy the policy, such > as using destructors instead of introducing a new function, but it wasn't > clear if they had larger implications. I wonder if we could somehow add an escape hatch for this somehow—maybe don’t fire the warning on the first virtual function that is declared out-of-line if there’s an easy way of doing that, but that feels like a hack. We could also add an attribute instead to surpress the warning, but is adding an attribute for a single diagnostic really worth it? Alternatively, we could ‘fix’ our codebase instead by introducing an `LLVM_VIRTUAL_ANCHOR` macro or sth like that which disables the diagnostic for that one declaration—I guess this probably depends how common this pattern is elsewhere; if there are a lot of people who do this then the attribute might be easier to use. https://github.com/llvm/llvm-project/pull/138741 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
