Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[core] Abstract away optional AST traversals (first step) #1426
First PR for 7.0.0!
Basically this is a first step to simplify the way we handle optional AST traversals like typeresolution or symbol table. It's necessary to detect XPath dependencies automatically, and globally will make our life easier.
Why we need a change
Type resolution, DFA, etc. all use a visitor that runs on the AST, wrapped in not-so-useful "façades" and provided by a LanguageVersionHandler. At the moment:
AST processing stages all have in common that:
This forms a basis for abstracting them.
What's in this PR
What's not in this PR
Some general thoughts:
Fully agree. We have also some unit tests, that manually call the parser and if they need typeres, they then manually need the different facades - and they need to call them in the correct order (e.g. qname before typeres). And it is definitely a language implementation detail.
Do we need this detail? If the language handler knows all the stages, it should also know the order, in which they are executed. If an AstProcessingStage depends on another stage, maybe we shouldn't have it separated at all?
This would allow to have maybe some performance improvements if (and only if) you are only executing rules, that don't need all stages. I would argue for removing this feature:
The changes you proposed make sense. I'll look into the code now. Thanks!