Transformation setup clean-up - Part I#312
Transformation setup clean-up - Part I#312bettinaheim merged 22 commits intofeatures/transformationSetupfrom
Conversation
…tructor on subtransformations
…check IdentifierReferences transformation!
src/QsCompiler/Tests.Compiler/TestCases/ExecutionTests/LoggingBasedTests.qs
Show resolved
Hide resolved
alan-geller
left a comment
There was a problem hiding this comment.
I agree, this is much cleaner. The one comment I have is about naming -- having QsSyntaxTreeTransformation, but just NamespaceTransformation, StatementTransformation, etc., is a bit hard to remember. I assume this is because you have the existing SyntaxTreeTransformation that is really a NamespaceTransformation; while it will be a breaking change, I suggest renaming the existing SyntaxTreeTransformation class as part of this PR.
It also might be nice to have QsSyntaxTreeTransformation have a Transform method that takes a SyntaxTree as input and returns a new SyntaxTree as output...
ScottCarda-MS
left a comment
There was a problem hiding this comment.
Please remove trailing whitespace in the files added/modified. A regular expression search/replace can make it quick and painless.
I'm not sure about VS2019, but there's a "Trim Trailing Whitespace" command in the VS Code palette that's pretty handy for that. |
Yes, I agree on all of that, I just haven't gotten around to cleaning it all up - hence the PR against a feature branch opposed to into master. Right now this also mostly strictly adds code, but the ultimate goal is to replace the old setup, and remove a good junk of code that was needed to deal with internal state in the old setup. This refactoring should thus result in an overall negative code contribution (reducing the amount of source code). Once we've migrated all the transformation we can go ahead and remove the code that is no longer needed, and clean up the subtransformations (there is still no separation between the recursion/walker logic and the actual action/transformation on the node itself). Going over everything and renaming as appropriate seems like a good thing to do as a final step before merging to master. |
Thanks, @cgranade! |
I added a revised setup for the transformations provided in the Core project. The idea is to build all transformations on top of this setup, which in particular eliminates the C# wrapper in the transformation project.
A syntax tree transformation is structured into the same subtransformations as now, but the shared internal state is now handled much cleaner, eliminating the need for the rather cumbersome type parametrizations on construction. Right now the actual transformation on individual nodes is still the same, with the idea to revise that slightly in a subsequent step.
What is also still missing is a neat way to disable certain subtransformations.
So far I've migrated the transformations in SearchAndReplace, and I'll see that I can migrate some more.