Re: [cdt-dev] Language plugin extending Scanner

["Peter Watkins" <peter.watkins@xxxxxxxxxxxxx>]

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)