I’ve written a lib tool which consumes via
clang::tooling::CompilationDatabase::loadFromDirectory a codebase and
performs code transformations through the idiom of assigning to some
ast_matchers some child classes of MatchCallback which generate
AtomicChanges which, through convertChangeToFileReplaces, become file
I’ve noticed that, for largish codebases, after a few hundred code
transformations, the SourceLocation for matched nodes as reported by
(node->sourceRange.begin()).printToString(*sourceManager) are radically
different from the spellingLoc actually used by AtomicChange. In particular,
the SourceLocation will be the correct location within the codebase, while
the SpellingLoc will be within some included library header.
I’ve noticed a recent mailing list thread titled “Understanding Source
Locatiosn” describing a similar problem fixed by using a different part of
the API to load and construct the AST. Am I using the wrong part of the API?
Is this phenomenon otherwise familiar to anyone?
thanks in advance,