https://github.com/AaronBallman commented:
I can see the logic, but it seems like there's a fair amount of related checking that perhaps should happen as well. Marking a destructor as try_lock makes even less sense than marking a constructor, so why not prohibit that as well? And since the try_lock attributes specify what a successful return value is, perhaps we should warn when the function declaration returns something other than int or bool. WDYT? That said, I think one possible reason why it makes sense to allow a constructor to be try_lock is exceptions -- the ctor could lock on normal flow control and remain unlocked on exceptional flow control. However, I'm not certain we implement the analysis in an exception-aware way. Also, the documentation (clang/docs/ThreadSafetyAnalysis.rst) should be updated and you should add a release note (clang/docs/ReleaseNotes.rst) so users know about the change. 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
