The major benefit to "tool is part of the compiler" is that vastly more people will use it and maybe fix the errors. There's a Google paper from 2018 (https://m

The major benefit to "tool is part of the compiler" is that vastly more people will use it and maybe fix the errors. There's a Google paper from 2018 (https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-building-static-analysis-tools-at-google/fulltext https://m-cacm.acm.org/magazines/2018/4/226371-lessons-from-...) about their experience with static analysis tools, and what they found was that the better the analysis was integrated with the existing developer workflow and the earlier the issues were noted, the more likely they were to actually be fixed. So "existing compiler reports the errors" is better than "tooling reports the errors as comments in the existing code review system" is better than "tooling files bugs in the existing bug tracking system after new code is already committed" is better than "tooling has its own separate dashboard that nobody looks at". I don't care whether under the hood the implementation is fully part of one big "compiler" engine or not, in the same way I don't care that when I run 'gcc' it's really running a compiler, assembler and linker which are all self-contained programs -- I do care that when I say "build my code" in the usual way that that is when analysis happens.