core: add replacement arg_values to inline_block_before

[superlopuh]

Slightly modifies the semantics of inlining, bringing it in line with MLIR's behaviour, in my understanding. Currently, xDSL empties the block when inlining it to a different block, but does not erase it. With this PR, this behaviour is changed to erasing the block, potentially leaving an empty region.

[codecov]

Codecov Report

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

Comparison is base (9633775) 90.04% compared to head (d8011e0) 90.04%.
Report is 2 commits behind head on main.

Files	Patch %	Lines
tests/pattern_rewriter/test_pattern_rewriter.py	92.30%	0 Missing and 1 partial ⚠️
xdsl/rewriter.py	90.90%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2061   +/-   ##
=======================================
  Coverage   90.04%   90.04%           
=======================================
  Files         292      292           
  Lines       36436    36498   +62     
  Branches     5406     5415    +9     
=======================================
+ Hits        32807    32865   +58     
+ Misses       2858     2857    -1     
- Partials      771      776    +5     

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

[compor]

Is this ready? I see commented code and TODOs.
Can you also please link where that behaviour occurs in MLIR? It saves a bit of time in regexing the codebase?

Thanks

[superlopuh]

This is ready, there's just behaviour that we can currently not replicate due to lack of successor/predecessor accessors on Blocks in xDSL. I can add more comments to the commented code? I'll add the link to MLIR implementation.

[compor]

This is ready, there's just behaviour that we can currently not replicate due to lack of successor/predecessor accessors on Blocks in xDSL. I can add more comments to the commented code? I'll add the link to MLIR implementation.

OK, I'll have a look then, is it worth tracking the TODOs as issues?

[math-fehr]

Looks good to me, but I have a question about it.
Why do we want to check for the correctness of successors after inlining?
If we do multiple rewrites at once, I would expect to only verify the correctness of successors at the end of the sequence of rewrites?
Is it what MLIR does?

[superlopuh]

Yeah that's fully lifted from the MLIR code base. I'm not 100% sure what all the reasons behind it are, but it feels reasonable for me to leave the commented stubs in so that we have something to go from when we hit a bug in a rewrite that leverages this.