Groovy is all geared up to make it easy for you to do whatever pre-processing you might like as an AST transform and in that scenario it automatically corrects line numbering as needed (your AST transform may have to play its part in making that work). So, in that scenario you'd move whatever you do in CPP land into Groovy. The advantage of this approach is that if you ever used things like coverage tools etc., they would also be showing correct info and wouldn't become one more place to fix.
If doing everything as an AST really can't be done, you can change just the line number info in an AST transform but it could be a little brittle. I am not 100% sure, but my suspicion is that if you only changed part of the line numbering info and some of that info was now out of order with line info in other places which you didn't touch, there could be problems. Cheers, Paul. On Tue, May 19, 2020 at 12:19 PM OCsite <o...@ocs.cz> wrote: > There's another thing I'd like to ask for a help with. > > Some of my groovy sources are actually pre-processed (in a way remotely > similar to the well-known CPP, i.e., before *groovyc* is called, a > temporary groovy source is generated from one or more original sources; > it's the generated temp file which then gets compiled by *groovyc* and is > turned to an appropriate .class). > > Currently, I am fixing the file names and source line numbers externally, > i.e., I am > (a) catching the issues the compiler reports, and re-write the file name > and line number as needed before sending it up to Xcode to show them in its > issue list; > (b) before displaying a stack trace in my code, I am fixing the file names > and line numbers similarly, based on the information from the preprocessor, > which I store as a resource in my application JAR. > > That does work, but is a bit at the complex, error-prone and ugly side. > > I wonder: couldn't I write an ASTT which would fix the file names and line > numbers directly in the compiled .class, so that all the reported issues > from the compiler, just as all the runtime thrown exceptions etc., would > not need to be fixed anymore, for that would all properly address the > original sources and their line numbers? > > I have actually tried to do that at the *CompilePhase.INITIALIZATION* > time, with no real success. It does not seem I am able to change the source > files node-based, only a *SourceUnit* seems to allow that — whilst a > pre-processed file actually contains result of more different original > source files, oops. What's even worse, whilst I can override > *configureAST* in my own ParserPlugin subclass to fix the line numbers > there (haven't found any other place to do that), it fails in a number of > ways even in the simplest case of a pre-processed file containing result of > only one original source (e.g., at the moment when an issue is reported > there seems to be no way to know whether the appropriate node has already > been processed and its line numbers fixed or not). > > Is there now with antlr4-based Parrot a decent and reliable solution of > this problem ASTT-level, or should I rather stick with my external > solutions with Groovy 3+? > > Thanks again, > OC > >
