Clang как средство статического анализа: обработка только указанных файлов?

Спасибо за наводку на плагин для Sublime

Диагностика пока печается руками в llvm::errs() или посредством dump-методов в телах методов наследников ASTConsumer и RecursiveASTVisitor<>

Если я всё правильно понял, тебе нужно (в таком случае) тебе нужно для каждой конструкции (для которой ты хочешь вывести диагностику) брать её SourceLocation с помощью метода типа такого:
getLocation, с помощью SourceManager'а определять файл, в котором находится эта локация, и если это не «твой» файл, то не выводить никакой диагностики.

Вы не могли бы в двух словах обрисовать, как пойти путем создания собственного DiagnosticRender'а? Куда копать, какие статьи, может быть встречающиеся в чьих-то блогах посмотреть? Никак не удается подружить Clang с системными заголовочниками, то ему GCC-шные __float128 не нравятся, то он, встретив в limits строку #include_next не может этот самый next найти, то еще что-то (под что-то иногда может пониматься вообще неожиданный SegFault). + Медленно работает. Подход с пропуском «срабатываний» Visitor'а и Consumer'а не очень хорош как по соображениям производительности, так и по соображениям удобства создания новых «чекеров» тех или иных свойств — нужно предпринимать усилия по поводу этого самого пропуска. Конечно, можно все обернуть как надо, но было бы лучше, если бы Clang лазал в заголовочники только за тем, чтобы понять, какие имена что есть (за объявлениями, то есть), а Consumer'а натравливал бы только на пользовательскую часть кода. Как этого добиться?

Замечательные вещи, описанные выше, умеет делать clang-c (сишный интерфейс кланга) Возможно, имеет смысл прочесть, как это реализовано через C++ API

Ну, как он это делает — посмотреть не сложно. Достаточно залезть в исходники clang-c. Если работа ведётся через C++ API, то, как я уже говорил, для каждого (ну или почти каждого) элемента AST-деверва можно получить его позицию в файле.

О! Замечательно. Спасибо.