lebedev.ri added a comment. In D67253#1670704 <https://reviews.llvm.org/D67253#1670704>, @paulkirth wrote:
> In D67253#1670681 <https://reviews.llvm.org/D67253#1670681>, @lebedev.ri > wrote: > > > Re concurrency - you had standalone `LLVMContext` for each thread, right? > > > I believe there was, but this is just whatever happens when libtooling > creates and executes a compiler invocation. It seems to me that there is some > global state that ends up being shared between threads. I wasn’t able to > fully trace the issue, but it at least partly involves the processing of > backend options. I believe there is more, that needs to be addressed but this > is probably a good place for me to start. Thanks for the suggestion. Ah yes, i don't think this can work given existing interface. >> In D67253#1670667 <https://reviews.llvm.org/D67253#1670667>, @paulkirth >> wrote: >> >>> In D67253#1670569 <https://reviews.llvm.org/D67253#1670569>, @lebedev.ri >>> wrote: >>> >>> > Layering feels weird here. >>> > Can this be implemented as/limited to just a >>> > `run-clang-misexpect.py` wrapper over clang itself? >>> > That would be best IMHO. >>> >>> >>> I discussed the concurrency issue with some folks who work on libTooling, >>> notably Sam McCall & Dmitri Gribenko. This was the approach they suggested >>> I follow. LibTooling also provides some nice mechanisms for curating >>> compiler options, which is possible, but less than ideal to reimplement in >>> a python script. There are probably more benefits that escape me at the >>> moment, but that was the first one I thought of. >>> >>> Out of curiosity, if the concurrency issue was fixed in the compiler and >>> the python script was removed/deprecated, would you still feel the same way? >> >> >> I was actually talking/thinking about the opposite direction, only having >> the .py wrapper, no standalone tool; >> so the opposite solution (no .py, only the tool) is tangential/has >> different direction. > > Right, I was asking if you still see this as an issue if the python script > wasn’t necessary. I take from this comment that it would not make you feel > differently. Right. Not really a blocker, just seems counter-general - there already is a similar script to run clang-tidy on compilation database, and this script/tool will have the same purpose - to just ran `clang -Wmisexpect`+profile on compilation database. It really seems like some generalization is missing. > I think ultimately keeping the implementation in c++ makes the most sense and > can evolve with the rest of libtooling. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67253/new/ https://reviews.llvm.org/D67253 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
