[clang] Clang tooling generated visibility macros for Clang (PR #109702)

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 20 04:26:55 PST 2024


AaronBallman wrote:

> The default behaviour of `ids` is to assume that anything declared in the header is public and it will ensure that anything added in the headers is annotated properly to say it is exposed, making something private would be an explicit decision that the developer need to take.

Is this the correct default though? It seems to me that usual best practices is to limit the visibility unless there's an opt in saying something is public (aka, the `class` model in C++ rather than the `struct` model which is rooted in C compatibility). I would have thought we'd do an initial pass to make everything public that needs to be public, and then require explicit opt-in rather than explicit opt-out, mostly because anything we list as being opted in is something someone, somewhere is likely to take as a promise that we'll always support it because it's part of the public interface.

>From what I'm seeing on the PR, it sounds like most of the outstanding concerns are around how to keep these annotations up to date. There have been a few requests for something like precommit CI or a github action. I think we should try to come to a decision on what we feel comfortable with there. (I tend to lean on the side of a github action that's run once a day as suggested by @tstellar 

https://github.com/llvm/llvm-project/pull/109702


More information about the cfe-commits mailing list