On 31.03.19 00:57, Paul King wrote:
The other "interim" fix would be to try to have more AST xforms run before stub generation. This would not be about trying to do stub generation later but running (some) xforms during a first phase and then rolling back phases and proceeding normally. This isn't a general solution but could cover some more cases.
My feeling is that this is going to be messy and error prone
We would perhaps mark xforms with a marker interface if they were amenable to such processing, e.g. if they are idempotent by nature or can be made so by storing some state in node metadata to indicate they have already been run. We also need to look at which bits of the current compiler could be run during that first phase and then pick xforms that are compatible with this (potentially) limited processing. We'd obviously not want to make the compiler significantly slower nor break existing xforms, nor make IDE support significantly harder, so I imagine there would be just some specific cases that we would try to support and numerous limitations.
that's what we did in the past for the most part. Maybe some xforms could be split into an early and late step.. but something almost essential we cannot do really.. run class resolving multiple times. Because it is too slow - afaik bye Jochen