melver wrote: > Yes, concretely it was driven by encountering this pattern in the linux > kernel source code here, so it would require this PR to be able to annotate > that function definition correctly: > > https://github.com/torvalds/linux/blob/fc02acf6ac0ccde0c805c2daa9148683cdd01ba8/include/linux/kref.h#L103-L105
Does it work if 'lock' is reordered before the function pointer? > Abstractly, the incentive was that a program's API and ABI shouldn't be > driven by the need of the clang to parse them correctly--that's why C has > forward references in the first place. Right. I agree this is desirable. On one hand I'd like this to work, too, but on the other hand if the use-cases are the tail 1%, we're making parsing slower for all. There are 2 specific questions I'd have: 1. Are you able to compare compile-times with/without? Say on the latest Linux kernel rc + perhaps another project that enables -Wthread-safety. The Linux kernel may not be entirely representative because it only enables -Wthread-safety for a subset of TUs, so analyzing some large TU only might be sufficient. 2. What's the stability risk? The feature is still marked "experimental", and I'm unfamiliar with how far it is from becoming stable. Anyone else have a tracking issue? https://github.com/llvm/llvm-project/pull/212615 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
