Rust 메타데이터 조기 방출로 빌드와 검사가 최대 2배 빨라진 프로토타입 공개

메인라인 컴파일러에 들어갈 경로가 있는지 궁금하네.

컴파일러 팀이랑 지금 얘기 중임! 근데 이 변경 셋은 안 들어감. LLM이 쓴 거고 전체 설계를 깊이 고민한 흔적이 없음. 비슷한 게 언젠가 들어오면 좋겠음.

개선 폭이 크다!

쉬운 승리 같은데 왜 아무도 안 했는지 궁금함. Rust AI 정책 때문에 누군가 손으로 다시 구현해야겠지만, 좋은 아이디어라는 건 증명된 셈임.

Rust는 몇 년째 이 방향으로 가고 있음. 2019년 eager metadata emission으로 파이프라이닝을 처음 넣었고, 이후 메타데이터를 덜 장황하게 만들고 압축도 실험했음. 더 eager하게 만들자는 건 오래 눈여겨봤는데, 추측으로 승인한 크레이트에서 에러가 났을 때 어떻게 할지가 아직 결정 안 됨.

이거 캐시 같은 거임? turborepo랑 비슷한 개념인가?

내가 이해한 건 함수 외부 API를 믿고 다운스트림 작업을 병렬로 돌리는 것임. 본문 타입체크가 실패하면 컴파일을 중단하고 헛수고한 셈이지만 그런 경우는 드묾.

zulip에 쓴 거 복붙하면, .early-rmeta 파일이 생기고 인자와 반환값 타입체크 결과가 들어감. -Zearly-metadata가 rustc 플래그고, 나중에 진짜 메타데이터가 오면 교체하는 법도 필요했음. rustc가 특정 지점에서 멈췄다 재개하고 cargo가 그걸 찾아 반응해야 함. 프로세스를 죽이는 게 아니라 기다리게 하는 거라 슬롯을 낭비하지 않음.

빌드 단위의 더 깊은 파이프라이닝임. CPU 파이프라이닝처럼. Rust에 원래 파이프라인 빌드가 있었는데 이게 더 밀어붙인 것.

이 기법의 단점까지 다룬 스레드가 며칠 전 'How to speed up the Rust compiler in September 2026' 제출에 있음. 링크 타고 가보면 좋음.

거기 댓글 단 사람이 이 글 올린 사람임.

이미 되고 있는 줄 알았는데 더 이른 단계인가 봄. 제네릭 메서드를 인스턴스화하지 않고 기대하는 심볼만 적어두고 별도 빌드 프로세스가 그걸 듣게 하면 어떨까 하는 생각도 해봤음.

이미 되고 있음. 크레이트를 빌드할 때 cargo는 의존성이 전부 끝날 때까지 기다릴 필요 없이 메타데이터만 나오면 됨. 이 프로토타입은 완전한 타입체크 전에 메타데이터를 더 일찍 쓰게 하는 것. 코어가 이미 꽉 차 있으면 이득이 없음.

저장소를 체크인된 패치 더미로 만든 건 좀 우스움. Git이 이미 버전 관리인데 버전 관리 안에서 버전 관리를 할 필요는 없지.

한 저장소에 다 넣고 싶었고 이게 잘 작동했음. 컴파일러 팀에 보여줄 때는 포크해서 리뷰용 브랜치를 만들었음.