By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler. It's a bit different for clang, which is modular and provides libraries that tool writers can use, but gcc is intentionally monolithic.
> By the time you write a linter, you've done more than half of the work of a compiler, at which point you might as well just ship it as a compiler.
Does depend on what kind of lint you want to catch but something like this 'just' needs some lexing and parsing to give a usable AST that's reasonably clean so it's not too hard to write lint rules against it. (Not trivial for C & C++ hence 'just')
Building the full compiler is much more work, especially if you want a decent optimizing compiler.
It's not just nontrivial for C++, you need a full template engine just to properly parse it [1]. Same thing for languages with a lisp-like macro system. Or languages that allow dynamic redefinition od symbols [2].
The back end is a lot of work, but so is the front end in a language like C++.
In fact most of the essential complexity is in the front end; you make do with a simple back end, but the front end is irreducibly complex if you want it to actually compile the language to spec.
And you need the front end to lint, especially if you want to avoid false positives, the bane of linting tools.
And better hope you didn't put in any bugs that GCC does or doesn't have, then you're left helpless as linter and compiler engage in epic battle on who is right.
