Skip to content

wrong-test-order false positive when anonymous >> objects from the main body are floated past tests by vars-float-up #954

Description

@volodya-lombrozo

What happens: The wrong-test-order lint fires on EO files where all tests are correctly placed at the end of the object, but anonymous objects created with >> inside the main body get appended after the tests by the vars-float-up transformation.

Example (ss/filtered.eo in eo-runtime):

[lst func] > filtered
  filteredi > @
    lst
    func item > [item index] >>   ← anonymous object, floated up by vars-float-up

  [] +> tests-simple-filtered
    ...
  [] +> tests-filtered-with-bools
    ...

After vars-float-up, the XMIR becomes:

<o name="filtered">
  <o name="φ">...</o>
  <o name="+tests-simple-filtered">...</o>
  <o name="+tests-filtered-with-bools">...</o>
  <o name="a🌵18-4">...</o>   ← anonymous object appended AFTER the tests
</o>

The lint fires because +tests-filtered-with-bools has a🌵18-4 as its immediately following sibling, which does not start with +. But tests are correctly placed at the end in the EO source — the anonymous object only ends up after them because vars-float-up appends floated objects at the tail of the parent's child list.

This currently produces false positives in 15 objects in eo-runtime: io.input-as-bytes, ss.mappedi, ss.mapped, ss.eachi, ss.withouti, ss.filtered, ss.reduced, ss.range-of-numbers, tt.contains-any, tt.contains-all, tt.up-cased, tt.low-cased, ms.integral, fs.tmpdir, fs.file.

What should happen: The lint should ignore auto-named anonymous objects (those matching the a🌵... naming pattern) when checking whether a test has a non-test following sibling.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions