WebKit, Top-Level Await 버그를 고치기 위해 Safari 모듈 로더를 C++로 전면 재작성

WebKit이 Safari의 Top-Level Await(TLA) 구현을 ECMAScript 명세에 완전히 맞추기 위해 기존 모듈 로더를 사실상 처음부터 다시 작성 기존 구현에서는 특정 상황에서 모듈의 평가가 끝나기 전에 import()가 완료되면서 Cannot access '...' before initialization 오류가 발생할 수 있었음 수정된 모듈 로더는 Safari 27에 포함될 예정이며, 현재 Safari 27 beta와 Safari Technology Preview 251에서 테스트 가능 TLA 버그 패치를 위해 오래된 설계에 기반했던 Safari의 ES Module 실행 기반 자체를 ECMAScript 명세에 맞게 교체한 작업 문제의 근본 원인 Safari의 기존 모듈 로더는 과거 WHATWG Loader 제안을 기반으로 만들어졌음 해당 제안은 2016년 1월에 마지막으로 업데이트되었고, 이후 ECMAScript 표준의 module specification에 의해 사실상 대체됨 초기 ES Module은 동기적으로 실행됐기 때문에 이 구조로도 문제가 없었음 하지만 ECMAScript 2022에서 Top-Level Await가 정식 도입되면서 상황이 달라짐 Safari는 새로운 ECMAScript의 비동기 module evaluation 알고리즘 대신, async/await가 존재하기 전에 설계된 오래된 Loader 모델 위에 TLA를 구현하고 있었음 WebKit은 여러 차례 기존 구현을 수정했지만 수년 동안 미묘한 버그를 완전히 제거하지 못했고, 결국 기반 자체를 다시 만들기로 결정 Top-Level Await가 모듈 실행을 복잡하게 만드는 이유 일반적인 await처럼 모듈에서 Top-Level Await를 만나면 해당 모듈의 실행이 일시 중단됨 이때 그 모듈을 import하는 상위 모듈 역시 평가를 기다려야 함 반면 dependency graph에서 해당 모듈에 의존하지 않는 sibling module은 계속 병렬 실행할 수 있음 따라서 모듈 로더는 단순히 파일을 가져오는 것뿐 아니라 dependency graph 전체의 평가 순서와 비동기 상태를 정확하게 관리해야 함 기존 구현에서 발생하던 버그 WebKit이 소개한 재현 예제에서는 TLA가 포함된 동일 모듈을 import()로 세 번 연속 동적 로딩 정상이라면 첫 번째 module evaluation이 끝난 뒤 각 import()가 순서대...