Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Inferred array elements omit Partial evidence applications

Đang mở
#610 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
58/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, node.js, rust
Lĩnh vực
compilers, testing-qa

Hướng nghiên cứu

Start in compiler-frontend/checking/src/source/terms/collections.rs, especially array_core in ArrayMode::Infer, then inspect expression-aware instantiation or subtyping and the evidence handling in forms.rs. Reproduce the issue with the described temporary fixture using just t compiler 1790461440 --verbose and the Node assertion. Done means inferred array elements no longer retain an extra Partial dictionary and the runtime coverage passes without removing the #605 abstractions.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Problem

A runtime regression discovered while independently reviewing #605: inferred array elements retain a dictionary abstraction without applying its evidence. This is distinct from Granite’s duplicate-Partial inline finding on that PR.

Confirmed on PR #605 head ef33df090. The PR is currently open; this report does not claim the regression is present on main or in a released version.

Minimal reproducer

module Main where

data Choice = Chosen Int | Other

fs = [\(Chosen value) -> value]

Iris infers:

fs :: Partial => Array (Choice -> Int)

Against freshly generated output, this Node assertion fails:

import { strictEqual } from "node:assert/strict";
import * as Main from "./output/Main/index.js";

strictEqual(Main.fs({})[0](Main.Chosen(17)), 17);

Expected: 17.

Actual on the PR head:

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
+ actual - expected

+ [Function: $closure$1]
- 17

The semantic tree exposes the missing application:

fs = \{partialDict} -> [\{partialDict1} -> \(Chosen value) -> value]

There is one external Partial dictionary, but each array element incorrectly still expects another dictionary before accepting its Choice argument.

Verification and isolation

I created a temporary compiler fixture with the source above and a verify.mjs containing the assertion, then ran:

just t compiler 1790461440 --verbose
  • PR head: Node verification fails with the function-versus-17 assertion above.
  • With only the six added lines in compiler-frontend/checking/src/source/terms/forms.rs restored to their pre-fix version: the identical fixture passes (1 passed, no pending snapshots).

This isolates the regression to the new evidence abstractions interacting with array-element elaboration. The PR head was restored afterward. The temporary investigation fixture was removed; the timestamp above records the executed command, not a fixture currently committed to the repository.

Cause and proposed direction

In compiler-frontend/checking/src/source/terms/collections.rs, array_core in ArrayMode::Infer infers each expression, calls type-only unification::subtype, and retains the original expression. Constraint handling at the type level does not add an EvidenceApplication to that expression.

Before #605, an inferred partial lambda lacked its required abstraction and happened to work in this path. After #605 correctly supplies that abstraction, the array path leaves it unapplied.

Investigate expression-aware instantiation/subtyping for inferred array elements and add compiler-fixture runtime coverage. Do not remove the evidence abstractions from #605: that would restore the original unsafePartial case-section crash.

Reference result from purs 0.15.15

Compiled the exact five-line Main.purs above with the official Linux release of purs 0.15.15, with no library dependencies:

purs --version
# 0.15.15
purs compile Main.purs --output output

Compilation succeeds. Its only warning is MissingTypeDeclaration, reporting the same inferred type:

Partial => Array (Choice -> Int)

Actual generated fs from output/Main/index.js:

var fs = function (dictPartial) {
    return [ function (v) {
        if (v instanceof Chosen) {
            return v.value0;
        };
        throw new Error("Failed pattern match at Main (line 5, column 7 - line 5, column 31): " + [ v.constructor.name ]);
    } ];
};

The array element accepts Choice directly; it has no extra dictionary parameter. Executed with Node.js v22.23.2:

node --input-type=module -e '
import { strictEqual } from "node:assert/strict";
import * as Main from "./output/Main/index.js";
const result = Main.fs({})[0](new Main.Chosen(17));
strictEqual(result, 17);
console.log(result);
'

Actual stdout is 17; exit status is 0. The constructor call uses purs’s own representation (new Main.Chosen(17)), rather than Iris’s Main.Chosen(17), so neither runtime receives a value from the other compiler’s representation.

Investigation: https://ampcode.com/threads/T-01a0df1f-526b-71ab-a932-9dac42222d89

Ngôn ngữ chính
Rust
Star
117
Fork
11
Merge trung bình
4 giờ 27 phút
Pull request đã merge (30 ngày)
123

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của purefunctor/purescript-iris

Tất cả issue của purefunctor/purescript-iris

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.