Replies: 3 comments
-
I'm interested in this, but would need more concrete usage intent to understand the overall design in terms of things like how this could be used across the tools. |
Beta Was this translation helpful? Give feedback.
0 replies
-
We'll probably need more use cases for such architectural changes. As for |
Beta Was this translation helpful? Give feedback.
0 replies
-
Closing as not planned. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Initially, this would be useful for the linter, although likely for other tools like the minifier too.
The pass manager would basically allow rules to depend on other rules as well as to register multiple dependent passes. The passes would be stored in a computation DAG and then broken into layers which would end up being the physical passes that are done. For example:
1 - semantics pass 1 (including CFG generation)
2 - semantics pass 2 (additional analysis that requires the CFG to be built)
3 - no_this_before_super lint - pass 1 (note CFG blocks for nodes containing local uses of this before super and which blocks contain super. store this in the rule struct)
4 - no_this_before_super lint - pass 2 for constructor function nodes, walk their CFG to find out which local violations are actual violations or if super was called in a previous block.
Pass DAG:
This DAG would be broken into 3 layers:
I'm curious what others think of this idea, and if it seems desirable, I'll start a more formal RFC.
Beta Was this translation helpful? Give feedback.
All reactions