Stale codegen/runtime tests failing on main: native_root_coverage::array_birth, ic_fast_split, barrier_stem_census
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- compilers, testing-qa
Research direction
Start by reading the failing native_root_coverage::array_birth, ic_fast_split, and barrier_stem_census tests, plus the referenced inline_birth.rs and array_birth.rs changes. Compare the closure birth expectations with the current entry points, then run the affected tests on main to confirm the failures. Done means the expectations match current behavior and the reported test failures are resolved or clearly tracked.
Written by the indexing model from the issue text.
Description
Found while verifying #12480. These fail on main and on #12480 alike. They test stale expectations, not live regressions (from the verification run; not root-caused beyond this):
perry-codegennative_root_coverage::array_birth: expects closures to be born throughjs_closure_alloc, which stopped being true with d602c7b80 (fixed-layout closure births). The expectation needs to follow the current closure birth entry points. #12480 already updated thejs_object_alloc→js_object_alloc_plaincallee names ininline_birth.rsandarray_birth.rs; the closure one remains.ic_fast_splittests: fail on main.barrier_stem_censustests: fail on main.
Also from the same run: after #12480 the perry-runtime suite (--release --test-threads=1) completes with 15 failures. 12 of them fail alone on main's test binary as well; 3 pass alone on both builds and are order-dependent.
Not being fixed right now; filed so they are tracked.
- Dominant language
- Rust
- Stars
- 4.9k
- Forks
- 166
- Avg merge
- 3h 23m
- Merged PRs (30d)
- 911
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PerryTS/perry
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 76/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
yologdev/yoyo-evolve#1053 ·
-
bug lompi security sev-9
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
area:config area:security bug good first issue platform:linux platform:windows priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
niravpatidar37/mcpsum#80 ·
Maintainers usually reply within 1 day