I think the "the compiler is not a static analysis tool" is a viewpoint that is fighting against the in-practice user-experience that reporting of problems in t

I think the "the compiler is not a static analysis tool" is a viewpoint that is fighting against the in-practice user-experience that reporting of problems in the code is more effective the earlier in the feedback loop it happens and the more guaranteed it is that the issues are noticed [X]. So having an automated static analysis report delivered as comments into a code-review system is better than after-the-fact offline static analysis, but "the compiler tells you about the problem as soon as you try to build the code" is better still. Lots of people don't run static analyzers, but everybody runs the compiler. (This doesn't mean that you need to structure the compiler internally to do everything at the same time rather than as separate compile and analyse passes -- just that the command your users use to compile should include the production of static-analysis type issues at the same time and in the same error-message format as it would for stuff like syntax errors.) [X] for a reference backing this up see the part of Facebook's ACM article on static analysis https://cacm.acm.org/magazines/2019/8/238344-scaling-static-analyses-at-facebook/fulltext https://cacm.acm.org/magazines/2019/8/238344-scaling-static-... in the section titled "Human factors"; there they compare "after-the-fact offline analysis" with "in the code-review system", and I think the same reasoning applies to comparing "in the compiler immediately" against "later in the code-review system".