Jint: 예기치 않은 Promise.all 동작

보고해 주셔서 감사합니다. 조사를 더 쉽게 할 수 있도록 실패한 단위 테스트 사례를 작성해 주시겠습니까?

보고해 주셔서 감사합니다. 조사를 더 쉽게 할 수 있도록 실패한 단위 테스트 사례를 작성해 주시겠습니까?

물론 입니다 .

도움이 되기를 바라며 훌륭한 작업에 감사드립니다.

@shestakov 이것은 약간 이상 합니다. 테스트 사례를 기반으로 기준선을 만들었지만 작동합니까?

@shestakov 이것은 약간 이상 합니다. 테스트 사례를 기반으로 기준선을 만들었지만 작동합니까?

@lahma 죄송합니다. 나는 예시로 몇 가지 _passing_ 테스트를 만들었습니다. 여기 에서 단 하나의 실패한 테스트로 교체했습니다.

감사합니다. https://github.com/sebastienros/jint/pull/911 에서 이 문제를 해결해야 합니다.

감사합니다. #911이 이 문제를 해결해야 합니다.

@lamhma 정말 감사합니다!

추가한 해결 방법을 확인했습니다.

그 휴리스틱( one , two )이 존재하는 이유를 간단히(간단히 설명할 수 있다면) 설명해 주시겠습니까?

다음에는 더 도움이 될 수 있을 것 같아요.

new Array(myClrObject) 를 호출할 수 있고 때때로 값 열거로 변환해야 하므로 상호 운용성을 위한 것입니다. 다음은 이 경로에 해당하는 테스트 사례입니다.

public void ArrayFromShouldConvertIEnumerable()
{
    var enumerable = new []
    {
        new Person {Name = "Mike"},
        new Person {Name = "Mika"}
    }.Select(x => x);

    _engine.SetValue("a", enumerable);

    RunTest(@"
        var arr = new Array(a);
        assert(arr.length === 2);
        assert(arr[0].Name === 'Mike');
        assert(arr[1].Name === 'Mika');
    ");

    RunTest(@"
        var arr = Array.from(a);
        assert(arr.length === 2);
        assert(arr[0].Name === 'Mike');
        assert(arr[1].Name === 'Mika');
    ");
}

일반적으로 엔진 내부에서 어떤 종류의 배열을 생성해야 하는지 알면 사물을 번역하고 JS 사양을 따르는 공개 API 사용을 건너뛸 수 있습니다. CLR interop은 일반적으로 믹스에 약간의 추가 향신료를 추가하고 일반 논리/사양에서 약간의 편차를 일으킵니다.

@lahma 는 ArrayConstructor.Construct 를 살펴보았습니다. 버그가 더 깊은 문제를 발견한 것 같습니다.

필수 사전(IEnumerable을 상속함) 배열과 유사한 객체로 취급될 수 있습니다(KeyValuePair 유형의 항목 포함)), 아니면 항상 객체와 같은 것으로 취급되어 항상 특별한 방식으로 처리되어야 합니까?

의미가 있습니다. 누군가가 실제로 왜 interop와 같은 배열이어야 하는지에 대한 반례를 제시할 때까지 사전에 대한 배열 유사성을 제거했습니다.

@lahma 다시 한 번 정말 감사합니다!