Skip to content

t27b: refuse signed % on an untyped local, as the reference does (verify_multitarget) #6593

Closed as not planned

Description

@gHashTag

After #6584, verify_multitarget.t27 compiles under t27b and fails, while the reference (t27c gen-zig + zig test) refuses it, because of a signed % on an untyped local. t27b should refuse it at the same stage, so the verdicts agree.

Refs #6063.

Success Criteria

  • A conformance spec under specs/tri/t27b/conformance/ with a signed % on an untyped local is refused by t27b with a typed reason.
  • verify_multitarget moves from fail to blocked in the lab, and reference_disagree stays 0.

Boundary

  • specs/port/tools/verify_multitarget.t27

User Scenarios

  • Given a t27 spec containing a signed % operation on an untyped local variable, when t27b compiles it, then t27b refuses compilation with a typed reason at the same stage as the reference compiler.

Requirements

  • FR-001: t27b MUST reject a signed % on an untyped local during type checking with a typed diagnostic.
  • FR-002: The rejection MUST occur at the same compilation stage as the reference (t27c gen-zig + zig test) so that verdicts agree.

Success Criteria

  • t27b specs/port/tools/verify_multitarget.t27 exits with non-zero and emits a typed error about signed % on untyped local.
  • A new conformance spec under specs/tri/t27b/conformance/ containing a signed % on an untyped local is refused by t27b with a typed reason (exit 0 for the test runner asserting refusal).
  • verify_multitarget moves from fail to blocked in the lab, and reference_disagree stays 0 (measured by lab metrics).

Activity

  1. added
    needs-boundaryNo '## Boundary' section, so the Queen can reserve nothing for it and no bee can take it
    and removed
    needs-boundaryNo '## Boundary' section, so the Queen can reserve nothing for it and no bee can take it
    on Oct 6, 2026
  2. github-actions commented on Oct 11, 2026

    @github-actions
    Contributor

    Re-filed as #9048.

    An attempt claimed this issue on 2026-10-06 and left an empty branch. A dispatch row that has spent its retry ceiling is released once and then keeps its issue for good, which is the right rule for a third identical failure and the wrong outcome for an issue nobody ever attempted twice. The new issue carries the same work, the same boundary, and today's brief.

    Closing this one so the swarm can take the work again.

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

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions