AaronBallman wrote: > * A handful of functions in the parsing tests return `void` and yet are > annotated as trylock functions. I don't believe this is a valid use case. > What does `EXCLUSIVE_TRYLOCK_FUNCTION` mean when it's impossible to return a > value? I think the solution is to just change `void` to `bool` for trylock > functions in tests.
Agreed > * This next failure is tricker... I was really surprised to see a trylock > method that returns a pointer! Confusingly, the "success" parameter to the > attribute is `1`. I think the semantics work out so that returning a > non-`nullptr` value indicates successful mutex acquisition. Oof, that's an odd one, but I can see the logic behind supporting it. I think it would be good for us to call out support for this explicitly in the documentation. > I'm not quite sure what to do here. Maybe we should be lenient and only > enforce that the return type is boolean, integer, or pointer? We definitely need to support integer return types because of how often integers or enumerations are used to indicate errors. I think we should continue to support the pointer behavior given that it works already today. https://github.com/llvm/llvm-project/pull/95290 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
