xazax.hun added a comment. At this point, I am a bit wondering about two questions.
- When should something belong to a checker and when should something belong to the engine? Sometimes we model library aspects in the engine and model language constructs in checkers. - What is the checker programming model that we are aiming for? Maximum freedom or more easy checker development? I think if we aim for maximum freedom, we do not need to worry about the potential stress on checkers, and we can introduce abstractions to mitigate that later on. If we want to simplify the API, then maybe it makes more sense to move language construct modeling to the engine when the checker API is not sufficient instead of complicating the API. Right now I have no preference or objections between the alternatives but there are some random thoughts: - Maybe it would be great to have a guideline how to evolve the analyzer and follow it, so it can help us to decide in similar situations - I do care about performance in this case. The reason is that we have a limited performance budget. And I think we should not expect most of the checker writers to add modeling of language constructs. So, in my opinion, it is ok to have less nice/more verbose API for language modeling if we can have better performance this way, since it only needs to be done once, and is done by the framework developers. https://reviews.llvm.org/D35216 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
