[Qt-creator] Parse macro arguments for Spell Checking

Nikolai Kosjar nikolai.kosjar at theqtcompany.com
Mon Feb 1 12:16:58 CET 2016


On 01/26/2016 09:03 PM, Carel Combrink wrote:
>     } else {
>          // Read source code from disk...
>     }
> The above works well, thank you. Regarding the "Read source code from
> disk... " comment, when will it happen that the editor documents would
> not be open? From my understanding the model manager will open the
> document with a call to CppTools::CppModelManager::updateSourceFiles().
> If this is correct then I do not need to worry about this case.

There are no editor documents (and thus no unpreprocessed source code) 
if you e.g. open a project. All files of a project and all their 
includes are indexed and CppModelManager::documentUpdated() is emitted 
for each, but no editor is opened automatically (except when you use 
sessions or the wizards).

If your plugin operates only on opened documents, don't worry.

(Side note: CppModelManager::updateSourceFiles() will just re-index the 
given files, there is no relation to editor documents).

>     To convert to line/column,
>     document->translationUnit()->getPosition(...) should help you.
> ...
> Am I doing something wrong?

No, that's me, sorry! TranslationUnit::getPosition() and friends should 
be used for positions coming from the unpreprocessed code, e.g. AST 
nodes, but that's not the case for the macro uses.

I see two options:

a) Live with what Document::MacroUse provides. Scan the line (and maybe 
the next) for literals yourself. You might need to count the '(', ')' 
etc. to determine when the macro invocation ends. Note that '(' could be 
eaten by a macro.

b) Use Snapshot::preprocessedDocument(), which makes use of the 
FastPreprocessor. In the resulting document macro function invocations 
look like function calls so that you can use an ASTVisitor to find the 
call and inspect it argument (expressions). Or as a more general 
approach, don't look for the MacroUse at all and try to find all 
StringLiteralASTs in the AST from the document of 
Snapshot::preprocessedDocument(). If you go this way, avoid calling 
Snapshot::preprocessedDocument() in the main/gui thread since it might 
take a while for bigger documents.

>     Note that we are focusing on the clang code model, so in the long
>     run the code we are speaking about here will vanish or be replaced.
> I am assuming that even though the code model is planned to be replaced
> with the clang code model there would still be an interface into the
> model. Regarding my SpellChecker plugin, if this move happens I want to
> still be able to allow for picking up spelling mistakes, thus I would
> then need to interface to the code model that the clang processor built
> up. Do you have any suggestions or comments around this and where I
> might start to look if I want to start porting my plugin to make use of
> this?

Currently there is no infrastructure to support your use case, but I can 
think of two options:

a) Your could create a plugin for clang itself which then reports spell 
checking issues as normal diagnostics. The clang code model will pick 
them up automatically. Maybe there is already such a plugin for clang 
out there? Haven't googled.

But...we use libclang, which does not load other clang plugins in its 
current version. But...I saw a patch somewhere on the llvm code review 
to change that.

b) If we will have a data base for the symbols (and literals) you could 
query it.

As you see, that's all still up in the air...

> As mentioned, I was hoping to start with the process to integrate my
> plugin into Qt Creator once the above issue is solved, what is your
> recommendations around this? Should I wait for the clang code model
> before I attempt this or would it still be a good idea to start the
> integration using the old code model?

See above, it can take a while. Also, for the time being, parts of the 
built-in code mode still run if the clang code model is active. So your 
plugin might be already valuable also for clang code model users. And 
you also don't add/expose new API for your plugin, so I'm fine if it get 
integrated as soon as you have resolved that bug.


More information about the Qt-creator mailing list