interactive: add functions that make xdsl-gui add rewrite functionality to tool (4/4)

[dshaaban01]

PR 4 out of 4. Broke the last one, had to re-pr.

In this final PR, we add functions that compute the list of "current_possible_rewrites" (i.e. rewrites that apply to our input text). these rewrites are added to the "list view", and we adapt the function to correctly update the pass_pipeline if a rewrite is selected to applied in a way that leverages the "Individual Rewrite" pass that we created previously.

We have thus been able to reuse the pass infrastructure for rewrites.

[codecov]

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (7972c6b) 90.18% compared to head (a65424c) 90.19%.

Files	Patch %	Lines
xdsl/interactive/app.py	84.84%	5 Missing ⚠️

Additional details and impacted files

@@                    Coverage Diff                    @@
##           dalia/interactive/oopsie    #2131   +/-   ##
=========================================================
  Coverage                     90.18%   90.19%           
=========================================================
  Files                           307      307           
  Lines                         37090    37126   +36     
  Branches                       5521     5524    +3     
=========================================================
+ Hits                          33451    33487   +36     
- Misses                         2860     2861    +1     
+ Partials                        779      778    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[math-fehr]

Really nice!
I want to say though, we should change the way we test this at some point.
Right now, we are testing that the condense button will return a set of passes that we are expecting. But once people are adding new passes, or new rewrites, they will need to change these tests as well.
I don't think that's good design, so I'm wondering how else should we do this (in another PR).

Probably, we should check that the resulting passes all have an effect, and that the passes that were not added had no effects.
But to be honest, maybe we don't really have to test this at all, because that might be more annoying than not to test the condense button.

[dshaaban01]

Really nice! I want to say though, we should change the way we test this at some point. Right now, we are testing that the condense button will return a set of passes that we are expecting. But once people are adding new passes, or new rewrites, they will need to change these tests as well. I don't think that's good design, so I'm wondering how else should we do this (in another PR).

Probably, we should check that the resulting passes all have an effect, and that the passes that were not added had no effects. But to be honest, maybe we don't really have to test this at all, because that might be more annoying than not to test the condense button.

we can discuss it in our next weekly

[webmiche]

Probably, we should check that the resulting passes all have an effect, and that the passes that were not added had no effects. But to be honest, maybe we don't really have to test this at all, because that might be more annoying than not to test the condense button.

Or instead of doing this for all passes in xDSL, we implement two trivial passes, one with changes, one without, and check that it condenses the list of those two properly.