Thank you Eric and Paul. I used line/col numbers to prevent duplicates. This probably is good enough for now
To answer some questions, Eric, I am not able to do this before instruction selection because I want the static compile to finish its resolutions and I use the metadata gathered in that stage to inform my data collector about types, methods, etc used. Paul, I am essentially gathering the results of the static compile into a dictionary that I use to simplify my server side compile. The product is a hosted DSL that allows developers to integrate with their Java data models. The first compile collects all information about the data models into a dictionary, the second compile uses this dictionary and converts the groovy script into wire format manipulations instead of pojo gets/set. At runtime the bytecode is exclusively run as a wire format manipulator without any of the original dependencies. So I have a need to understand names of properties set/read, methods called etc ... I would love your (and other groovy gurus) feed back on some of this, but I am not sure if you will have the time or means to connect regards Saravanan On Tue, Apr 4, 2023 at 2:02 AM Paul King <pa...@asert.com.au> wrote: > Good suggestions from Eric. Another is that you can "drop some > breadcrumbs", i.e. place a "seen" node metadata marker and skip the next > time around. This falls into the category of a workaround rather than a fix > for your expectation, but we do legitimately walk the tree multiple times > in a few places. We make sure our transforms are idempotent in that case. > It doesn't mean there might not be a bug somewhere and we walk more than > needed for some edge case. Perhaps you could expand your example and we can > check further. > > Cheers, Paul. > > On Mon, Apr 3, 2023 at 11:23 PM Milles, Eric (TR Technology) via dev < > dev@groovy.apache.org> wrote: > >> You can try visiting at an earlier compile phase (maybe before >> instruction selection) to see the AST before some SC transforms are >> applied. Otherwise, I have used the source location as a key to understand >> if something is coming in again. Often generated methods will include some >> of the source elements again. >> >> >> >> Here is an example of an AST visitor that deals with a number of the >> idiosyncrasies of the tree. >> https://github.com/groovy/groovy-eclipse/blob/master/base/org.eclipse.jdt.groovy.core/src/org/eclipse/jdt/groovy/core/util/DepthFirstVisitor.java >> >> >> >> *From:* Saravanan Palanichamy <chava...@gmail.com> >> *Sent:* Saturday, April 1, 2023 1:35 AM >> *To:* dev@groovy.apache.org >> *Subject:* [EXT] Duplicate visits to expressions defined in RHS of a >> setter >> >> >> >> *External Email:* Use caution with links and attachments. >> >> >> >> Hello Groovy Devs >> >> - I have a class defined MyTestClass in java/kotlin (does not matter) >> - I have a groovy class defined MyClassDefinedInGroovy >> - I have code in a groovy function that is creating these classes and >> setting a variable in the object. I compile this with static compilation >> turned on >> - I visit this class using a simple visitor that prints all constants >> visited (I have attached both code and groovy file in this email) >> >> For the class defined in java >> >> - In 3.0.16, all constants are visited twice. This is not what I >> would expect but at least it is consistent >> - In 3.0.5, the setters with a property based LHS are visited twice, >> but those with a variable based LHS, only one visit as expected >> >> For the class defined in Groovy, In both 3.0.5 and 3.0.16, all constants >> are visited only once. This is what I would expect >> >> >> >> Multiple visits to the same code is causing an issue for me because I >> collect metadata about the code for use elsewhere and I end up getting >> duplicates that cannot be cleanly ignored (because its not just variables, >> its anything on the RHS, closures, method calls, etc) >> >> >> >> I debugged this a bit and found out that for classes imported from Java, >> the compiler seems to be using PoppingMethodCallExpression and >> PoppingListOfExpressionsExpression. The latter has code that initializes >> the parent with two expressions, the tmp variable and the method call. The >> method call also includes the tmp variable which I think is causing this >> duplicate visit. >> >> >> >> public PoppingListOfExpressionsExpression(final TemporaryVariableExpression >> tmp, final PoppingMethodCallExpression call) { >> >> // This array initialization with tmp and call is a problem because call >> also holds tmp and visits it >> >> super(Arrays.asList(tmp, call)); >> this.tmp = tmp; >> this.call = call; >> } >> >> >> >> What are my options if I dont want to handle the duplicate visit? This >> problem exists in some scenarios in 3.0.5 and is consistently a problem in >> 3.0.16 >> >> >> >> regards >> >> Saravanan >> >
