Skip to content

build(codegen): main fails cargo check --all-targets — two ImportedClass test initializers miss constructor_has_synthetic_arguments #10655

Closed

Description

@proggeramlug

What happened

cargo check --workspace --all-targets does not compile on origin/main (6092204, merge train 218 / v0.5.1596), before any branch is applied. Lint gate 83, "warnings: rustc warnings (host-compatible, all targets)", fails for every branch that validates against main.

error[E0063]: missing field `constructor_has_synthetic_arguments` in initializer of `ImportedClass`
  --> crates/perry-codegen/src/expr/instanceof_imported_rhs_tests.rs:46:5
error[E0063]: missing field `constructor_has_synthetic_arguments` in initializer of `ImportedClass`
   --> crates/perry-codegen/src/lower_call/new_builtin_shadow_tests.rs:118:32
error: could not compile `perry-codegen` (lib test) due to 2 previous errors

Cause

016e8ecf9 ("fix(hir,codegen,runtime): make arguments in class constructors reflect the call site") added pub constructor_has_synthetic_arguments: bool to ImportedClass (crates/perry-codegen/src/codegen/opts.rs:576).

It updated two of the four test initializers of that struct:

  • crates/perry-codegen/src/expr/readonly_collection_tests.rs:185 — constructor_has_synthetic_arguments: false,
  • crates/perry-codegen/src/lower_call/typed_shape_bake_tests.rs:495 — constructor_has_synthetic_arguments: false,

and missed the two named in the errors.

Suggested fix

Add the same line to both remaining initializers, matching what that commit already did for its siblings:

constructor_has_synthetic_arguments: false,

Why it got through the train

It only appears under --all-targets. cargo build, cargo build --release and cargo test -p perry-runtime --lib are all clean on main — I ran all three — so nothing in an ordinary build or a targeted test run surfaces it. scripts/run_lint_gates.sh catches it, and validate-017.sh reports it as one of its 83 gates.

Not mine

Found while validating an unrelated regex branch whose entire diff is 19 lines in crates/perry-runtime/src/regex/perex_replace_storage.rs, which cannot reach perry-codegen. Reproduced on pristine origin/main at the same commit with no changes applied.

Separately, and longer-standing: the gate "Public benchmark evidence freshness" (python3 benchmarks/ci_public_baseline_check.py) also fails on pristine main — public artifact benchmark inputs changed; regenerate it with ./benchmarks/run_public_baseline.sh. That one has been red for at least a day and is a different problem; mentioning it so the two are not confused when someone runs the gates and sees 2 of 83 failing.

Activity

  1. proggeramlug commented on Sep 19, 2026

    @proggeramlug
    ContributorAuthor

    Already fixed on main by #10682 ("fix(test): unbreak the perry-codegen lib-test build on main (-D warnings --all-targets)"), which is merged.

    Verified by content on origin/main @ 4715bc2fa — both initializers named in the error now set the field:

    crates/perry-codegen/src/expr/instanceof_imported_rhs_tests.rs    constructor_has_synthetic_arguments present
    crates/perry-codegen/src/lower_call/new_builtin_shadow_tests.rs   constructor_has_synthetic_arguments present
    changelog.d/10682-codegen-testbuild-missing-field.md              present
    

    I came at this from the other direction: an agent of mine independently hit the same broken build while working on #10689, wrote the identical two-line fix, and I was about to open a PR for it. Re-checking main first is what caught that #10682 had already landed it — so there is nothing to push.

    Scope check, since I am closing someone else's issue: this issue names exactly those two initializers as its cause and suggested fix, and both are now fixed, so its content is fully addressed. What I have not done is re-run cargo check --workspace --all-targets on current main to prove the whole gate is green — that is a long workspace build and the box is busy. If lint gate 83 is still failing for a different missing initializer, that is a new instance rather than this one, and reopening is the right call.

    Closing as fixed by #10682.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions