irisshaders / glsl-transformer Goto Github PK

The isDeepEnough method could be used to create a maximum-depth feature. Similar features could also be implemented using the existing tree walk stopping methods.

A code coverage approaching 100% is desirable. Related to #10 since testing the the generated code is of questionable usefulness.

• Test SearchTerminals (in progress)
• and all targets (partial)
• Test ParsableASTNode
• Test LifecycleUser and test that lifecycle methods are run correctly on run/walk phases and transformations
• and test the various activation methods and partial activation
• Test early walk-stop mechanisms and related methods throughout various classes
• Test FixedWrappedParameters

Add structures for creating multiple execution plans (through multiple root transformations) for a set of various static parameters. Required: something to hold the execution plans, something to execute on them, something to model a fixed parameter state, something to select execution plans with this state (hash map? record?). Previously this was solved by using multiple transformation mangers and using one of them depending on the fixed parameters. -> make it possible to use subclasses of a job parameter type, somehow.

idea: instead of iterating over all fixed parameters (though that would be possible too), just cache based on the equality of the fixed parameters. use class mechanics to force the implementation of hashCode and equals for the fixed parameter part of the job parameters. then cache based on that and generate an execution plan for each set of job parameters that are value-distinct with regard to the fixed parameter part. activate and deactivate using an activation system that cascades down the dependency chain. figure out how to do this since usually all dependencies of a node are required and can't be deactivated. Maybe make it configurable but active by default? would control which dependencies certain transformations consider as dependencies of their root nodes.

The HandlerTarget class is currently lacking some features and should be extended or abstracted into existing structures so that it also has the usual lifecycle methods. (init, resetState, before/after search, activation checks)

The Tensor class exists but doesn't really have any helpful functionality yet. One idea was to give it functionality for shrinking and widening types and then emitting their types. It's not clear what exactly the use-case for this was but it may be in connection with other AST structure for structs.

Figure out if and how removal of local roots works (nothing needs to be omitted since they are additions, trying to omit them may break. a placeholder still needs to be placed though)

AST helpers for parsing, manipulating and re-inserting structs would be interesting. This could be combined with the general number-type handler Tensor.

There are tests that this works in the global root but none that it also works in newly created local roots.

Have transformation phases tell the current DynamicParseTreeWalker about movements in the child array they caused to avoid inserting placeholder nodes. The the compacting step could be omitted if no placeholder nodes were inserted.

The isDeepEnough method could be used to create a node filter that doesn't walk into the subtrees of nodes found to be uninteresting by all participating walk phases.
It should be tested if this actually helps performance since the nodes need to be asked if they want to continue. That process should probably be accelerated by asking less often or only asking if necessary.

Including them skews the coverage metrics. This requires configuration of the gradle build config but I haven't been able to figure it out. Testing that the grammar works as expected is probably a good idea but looking at the coverage of the generated parser doesn't seem like a good way of ensuring that.

There are some diagrams that document what operations on Transformation do but nothing written. There should be a kind of tutorial explaining how to use glsl-transformer once the API has stabilized. (when 1.0.0 release-stability is reached)

From the current coverage report it looks like the cache hit code is never run. Maybe there's an issue with how the cached interval is checked for compatibility or there's really just never an opportunity for cache hits with the current cache size of 1.

Pattern and xpath matching should work even after the tree has been modified. It should also not be disrupted by placeholders being present and after they have been removed. (since matching may be invoked before cleanup happens)

The following code causes a parsing error:

#if fds /*
fdasfdsa fsa fds
*/

This has to be fixed in the lexer. It has worked in some cases but not always. There is also the issue with gradle somehow weirdly caching the generated parser and refusing to generate a new parser if the lexer changed without a change to the parser.