misc: Fix the way --split-input-file is handled

[AntonLydike]

Make --split-input-file only split on // ----- if it's the first thing on a line (modulo whitespace)

[AntonLydike]

We can now CHECK for these markers!

[PapyChacal]

Yes, this annoyed me so many times 🤩

Why the modulo whitespace btw? Unless clear reason (or over complex implementation), I would also not split if preceding whitespace

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.91%. Comparing base (73c893c) to head (b72b25d).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2820      +/-   ##
==========================================
+ Coverage   89.85%   89.91%   +0.05%     
==========================================
  Files         399      400       +1     
  Lines       50179    50313     +134     
  Branches     7755     7776      +21     
==========================================
+ Hits        45088    45238     +150     
+ Misses       3860     3847      -13     
+ Partials     1231     1228       -3     

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

[math-fehr]

How do we handle this for non-.mlir files? For instance the frontend python files we still have?
I think it's common to write something like # // ----- for splitting these, why can we not CHECK: ----- for checking splits?

[AntonLydike]

Yes, this annoyed me so many times 🤩

Why the modulo whitespace btw? Unless clear reason (or over complex implementation), I would also not split if preceding whitespace

I found a bunch of tests that had indented splits, and I found that it's quite irritating to debug why the file wasn't split at a certain point if the split is indented by a single whitespace^^

Also, MLIR also allows indented splits, so yeah.

[AntonLydike]

How do we handle this for non-.mlir files? For instance the frontend python files we still have? I think it's common to write something like # // ----- for splitting these, why can we not CHECK: ----- for checking splits?

Seems weird that the tests pass... But good point!

Looking at MLIR, it just splits on any line containing // ----- anywhere, and deletes the whole line. Maybe we copy that?

[superlopuh]

fantastic

[math-fehr]

How do we handle this for non-.mlir files? For instance the frontend python files we still have? I think it's common to write something like # // ----- for splitting these, why can we not CHECK: ----- for checking splits?

Seems weird that the tests pass... But good point!

Looking at MLIR, it just splits on any line containing // ----- anywhere, and deletes the whole line. Maybe we copy that?

To me we should copy that yes, but what's currently implemented then? I thought it was already that

[AntonLydike]

How do we handle this for non-.mlir files? For instance the frontend python files we still have? I think it's common to write something like # // ----- for splitting these, why can we not CHECK: ----- for checking splits?

Seems weird that the tests pass... But good point!
Looking at MLIR, it just splits on any line containing // ----- anywhere, and deletes the whole line. Maybe we copy that?

To me we should copy that yes, but what's currently implemented then? I thought it was already that

We currently split on // ----- anywhere, but keep the remaining bits of the lines

I fixed it to eat the whole line.

[AntonLydike]

Wait, I was wrong. Current behaviour mimics MLIRs, so we are good!