| Re: [cdt-dev] Language plugin extending Scanner |
Sorry for the top-post, but Lotus Notes (I'm stuck with it) doesn't seem to let me compose an email otherwise.
I don't actually care about the assembly code. I just want to skip it like CDT does for GNU assembly. This is how CDT works with GNU C: Once the GNU parser finds the "asm" keyword, it consumes all the tokens until it comes to the closing parenthesis. While it's searching for the closing paren, it concatenates the assembly code together with a StringBuilder. Once that's done the parser hands that string buffer off to the default AST node factory by calling nodeFactory.newASMDeclaration(). The node factory is then responsible for syntax highlighting?
My issue is getting the scanner (CPreprocessor) to tell the parser where the assembly starts and stops. In the GNU case, it's easy since the "asm" keyword is a language construct and isn't consumed by the preprocessor. In my case $pragma asm and #asm are both consumed by the preprocessor.
Regarding question #3 in my original email, I think I found a way to hack around the access issue. I'm using the same method that Alexander Kitaev used in his language extension for Cosmic C:
https://github.com/kitaev/cosmic/blob/master/org.tmatesoft.cdt.cosmic/src/org/tmatesoft/cdt/cosmic/CosmicLanguage.java
He replaces the scanner when CDT calls createParser() on his language. He makes the original scanner a delegate of his own scanner (he's using the Adapter Pattern?). Very tricky!
So this means I have access to tokens through IScanner.nextToken(). I'm not sure how to best use this to my advantage yet, though.
-Peter
From: Alena Laskavaia <elaskavaia.cdt@xxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>,
Date: 10/26/2014 04:12 PM
Subject: Re: [cdt-dev] Language plugin extending Scanner
Sent by: cdt-dev-bounces@xxxxxxxxxxx
Re: #2
- Why do you need your parser to see these assembly instructions? Are you creating a real parser to produce the code? CDT would not usually care about assembly
for indexer except not choking on it, because for indexer info it does not matter, there is too many assembly languages to know its syntax or semantics.
If you really care about it you can inject it into whatever structure you building after the parser stage by correlating code positions.
(Disclaimer: I don't actual know how it is done in CDT but just from generic view)