Currently, to my understanding, Sema analyses the source code to build the AST. Much of its methods are non-const, and a friend into the AST building process. This is not a problem in itself, as a semantic error will hard-break the compilation process.
However, Clang has evolved into something much much more than just a simple compiler, and there are several potential checks that naturally could belong to Sema only during "AST building time". Still, we would benefit if we could call them from front-end code. For example, static analysis, Tidy, project-wide visualisations, metrics, refactoring suggestions - a plethora of developer tooling armed (potentially) with the ASTImporter could explore more options in these efforts.
(My side-step idea is to just manually create C++ code and spawn another compiler and somehow fetch diagnostic results, but that's way too much work for something that should(?) be easily accessible.)
The most striking example that's on top of my mind's stack is checking whether a type A expr could be implicit-converted to a type B value. While of course, everyone could reimplement the logic based on the standard... it would be better if we used the same logic as per which the compilation breaks in case someone wants to compile an expression that can't be converted. (And then language dialects and releases would be "implicitly" respected.)
So, given this particular example, I might be looking for a function with a signature as follows:
/** True if 'LHSVariableType Var = (RHSExprType)foo;' is legit, according to the current standard being used. **/