Generative Compilation: On-the-Fly Compiler Feedback as AI Generates Code

Niels Mündler-Sasahara; Hristo Venev; Dawn Song; Martin Vechev; Jingxuan He

Source-linked AI summary

Generative Compilation: On-the-Fly Compiler Feedback as AI Generates Code

Niels Mündler-Sasahara, Hristo Venev, Dawn Song, Martin Vechev, Jingxuan He

arXiv:2607.13921v22026년 7월 15일cs.PLcs.AIcs.LG

TL;DR

AI가 생성한 Rust 코드는 올바르게 작성하기 어렵고, 기존 compiler feedback은 생성이 끝난 뒤에 도착하거나 constrained decoding 인프라를 요구한다. Generative compilation은 생성 중 표준 compiler 검사를 수행할 수 있도록 partial program을 봉인해, 사후 feedback보다 비컴파일 출력을 줄이고 functional correctness를 향상한다.

문제
AI가 생성한 Rust 코드는 여전히 오류가 많으며, post-generation compiler feedback은 중간 생성 과정을 안내하지 못하고 constrained decoding은 white-box access와 고비용의 semantic reimplementation을 요구한다.
방법
Generative compilation은 partial program을 placeholder가 포함된 complete program으로 봉인해, 표준 compiler가 생성 중 diagnostic feedback을 제공하도록 한다.
결과
Generative compilation은 post-generation feedback과 비교해 대부분의 model-task configuration에서 비컴파일 출력을 줄이고 functional correctness를 향상한다.
시사점 및 한계
Generative compilation은 black-box와 호환되는 compiler diagnostics를 중간 코드 생성에 도입해, 오류를 더 일찍 그리고 오류의 원인에 더 가깝게 탐지한다.
시사점 및 한계
형식적 보장은 verdict를 다루지만, 반환된 diagnostics가 실제 결함을 설명하는지 아니면 sealing artifact를 설명하는지는 formalize하지 않는다.

Abstract

from arXiv · show

Languages with rich static semantics, such as Rust, provide stronger guarantees for AI-generated code, but their strictness makes generation more difficult. Off-the-shelf compilers can provide useful feedback post-generation, but does not guide intermediate generation steps, such as those during autoregressive LLM decoding. Constrained decoding intervenes earlier by rejecting invalid tokens during sampling, but requires white-box model access and costly reimplementation for semantic constraints. We introduce generative compilation, the first approach to obtaining compiler feedback on partial programs during generation. The core technical device is a sealor: a lightweight, mostly syntax-guided transformation that converts partial programs into complete ones that standard compilers can diagnose. It is designed such that possible-to-complete partial programs are never rejected, while preserving enough code context to catch genuine dead ends early. We construct such a sealor on a core Rust-like calculus and prove that it satisfies these properties, all mechanized in Lean. We extend it to the first partial-program checker for real Rust. We evaluate our method on challenging repository-level Rust coding tasks, across both frontier black-box and open-weight models. We show that generative compilation reduces non-compiling outputs and improves functional correctness, relative to standard post-generation feedback. It does so by detecting a broad range of errors close to their source and early during generation, thereby reducing errors cascades and enabling focused diagnostics. More broadly, generative compilation is a step toward making compilers a first-class citizen of AI-assisted programming active during generation, rather than a separate post-generation check.

1 서론

Generative compilation은 partial program을 검사해 compiler 스타일 피드백을 code generation에 도입하며, post-generation feedback과 constrained decoding을 연결한다. 이 방법의 sealor transformation은 기존 compiler가 partial program을 진단할 수 있게 하면서 formal guarantee와 Rust task 평가를 지원한다.

배경 및 관련 연구: Post-generation feedback은 완전한 파일이 생성될 때까지 기다리므로, 처음 복구 불가능한 오류 이후의 token이 낭비될 수 있고 누적된 진단이 처리가 어려운 batch로 제시될 수 있다.Constrained decoding은 더 일찍 개입하지만, 표현력 있는 static semantics를 위해 상당한 language-specific 재구현이 필요하다.
본 연구: Generative Compilation: Generative compilation은 generation 중 partial program을 검사하고 compiler 스타일 진단을 제공해, intermediate feedback과 off-the-shelf compiler의 guarantee를 결합한다.이는 post-generation feedback과 constrained decoding 사이의 중간 지점에 해당한다.
본 연구: Generative Compilation: sealor는 누락된 syntax와 well-typed placeholder로 partial program을 완성해 기존 compiler가 이를 검사할 수 있게 한다.핵심 과제는 충실한 feedback을 보존하면서 compiler의 거부가 partial program을 완성할 수 없다는 실제 불가능성을 반영하도록 보장하는 것이다.
본 연구: Generative Compilation: 경량의, 대부분 syntax-guided 방식인 sealor는 target type system을 재구현하지 않으며, Featherweight Rust에서 보장을 증명하고 Lean으로 완전히 mechanize했다.이 방법론은 이후 real Rust로 확장된다.
평가: seven frontier black-box and open-weight LLMs와 두 repository-level Rust task에서, generative compilation은 대부분의 model-task configuration에서 compiler error를 줄이고 functional correctness를 향상한다.task는 C-to-Rust translation과 최근 업데이트된 library API를 대상으로 한 generation이다.

2 Generative Compilation의 동기

기존 compiler feedback은 완료된 program만 검사하는 반면, constrained decoding은 generation 중에 작동하지만 비현실적인 prefix-checking infrastructure가 필요하고 좋지 않은 continuation을 조용히 강제할 수 있다. Generative compilation은 partial program을 compilable한 program으로 sealing하여 partial-program intervention과 textual compiler diagnostics를 결합하고, 실행 예시에서 관련 feedback을 네 줄 반 더 일찍 제공한다.

Post-Generation Compiler Feedback: Post-generation compiler feedback은 full program이 생성된 뒤에야 language membership을 보장하며, checking이 실패하면 compiler diagnostic과 함께 retry하도록 model에 요청한다.Compiler는 Boolean verdict와 textual diagnostic을 반환하며, failed type checks와 possible fixes에 대한 설명을 포함한다.
Constrained Decoding: Constrained decoding은 partial output을 valid program으로 확장할 수 없는 token을 거부하여, 생성되는 모든 prefix가 어떤 valid program으로든 확장 가능하도록 보장한다.완성된 program을 기다리는 대신 prefix checker를 통해 autoregressive decoding 중에 개입한다.
Constrained Decoding: Prefix checking이 어려운 이유는 partial program에 대해 reasoning해야 하고, conventional compiler 인프라를 직접 재사용할 수 없으며, general-purpose language를 위해 language semantics를 재구현해야 하는 경우가 많기 때문이다.General-purpose programming language에서 full compiler의 동작을 prefix checking에 맞추는 일은 비현실적인 것으로 설명된다.
Constrained Decoding: Constrained decoding은 거부된 token을 조용히 필터링하고, 거부 이유를 설명하거나 기존 prefix를 수정할 수 없으며, global generation quality를 저하시키는 low-probability continuation을 강제할 수 있다.Running example에서는 token .을 거부하면 use-before-definition 경로가 유일한 진행 방법으로 남는다.
실행 예시에서의 Generative Compilation: Generative compilation은 partial program을 complete program으로 sealing해 conventional compilation을 수행하고, diagnostics를 partial source로 다시 매핑하며, post-generation feedback보다 관련 feedback을 네 줄 반 더 일찍 제공한다.model은 sealed program이 아니라 partial program과 매핑된 diagnostic을 보고, post-generation feedback과 동일한 repaired program을 생성한다.

3 생성 컴파일

생성 컴파일은 부분 프로그램을 완전한 프로그램으로 봉합해 기존 compiler가 진단하도록 함으로써, compiler 진단을 유지하면서 부분 프로그램이 유효한 완성을 가질 수 있는지 검사한다. 설계에서는 completeness를 우선하며, black-box autoregressive generation과 통합되고, 진단에 기반한 수정을 사용한다.

Generative Compilers: 정의: Generative compiler는 부분 프로그램이 유효한 완성을 가지는지 검사하고, Boolean 판정과 텍스트 형식의 compiler diagnostic을 반환한다.Constrained decoding과 달리, 거부된 prefix에 대한 compiler diagnostic을 유지한다.
Sealors: 정의: Sealor는 미완성 구조를 가볍게 닫아 기존 compiler가 부분 프로그램을 처리할 수 있게 하며, semantic checking의 비용이 큰 재구현을 피한다.유도된 generative compiler는 GC,S(c) = C(S(c))이다. 진단은 sealed-program span에서 원래 prefix로 매핑할 수 있다.
Sealors: Completeness와 Soundness: 기반 compiler가 exact할 때 sealor의 completeness와 soundness는 유도된 generative compiler에도 확장된다. 즉, 유효한 continuation은 거부되지 않고 dead end는 수락되지 않는다.Completeness는 모든 extendable prefix를 유효한 프로그램으로 봉합할 것을 요구하며, soundness는 유효한 sealed program이 유효한 continuation을 가질 것을 요구한다.
Target Guarantees: Global Completeness와 Selective Soundness: Generative compilation은 soundness보다 completeness를 우선한다. extendable prefix를 거부하면 generation을 혼란스럽게 할 수 있지만, 거부는 diagnostic-guided revision을 가능하게 한다.정확한 prefix checking에는 두 global property가 모두 필요하며, 표현력이 높은 semantic constraint에서는 일반적으로 판정 불가능하다 [34].
LLM Integration: 시스템은 prefix를 concurrent generative compiler로 스트리밍하고, 이 compiler는 거부된 prefix와 진단을 augmented prompt로 반환한다. 따라서 black-box LLM과는 plain-text communication만 필요하다.거부되면 generation을 재시작하며, latest-wins validation은 prefix를 병합하고 concurrency는 token sampling의 차단을 방지한다.

4 FR: Rust를 위한 핵심 계산법

이 논문은 Featherweight Rust(FR)를 Rust의 핵심 소유권 및 borrowing 기능을 유지하면서 generative compilation을 형식적으로 정의하고 분석하기 위한 간결하고 소스 구문에 가까운 계산법으로 사용한다. FR은 syntactic move, lexical lifetime, flow-sensitive typing을 통해 metatheory를 단순화하면서도 soundness 보장을 보존한다.

핵심 계산법이 필요한 이유: FR은 주요 언어 기능을 포착하면서도 소스 구문에 가까운 간결한 Rust 형식화라는 요구를 충족한다.기존 형식화는 이 목적에 비해 지나치게 추상적이거나 정교하다. FR은 간결하고 sound한 대안을 제공한다 [15].
FR이 필요한 이유: FR은 copy 및 move semantics, mutable 및 immutable borrow, lexical lifetime을 보존하면서 간결한 type-soundness 논증을 지원한다.현대 Rust의 non-lexical lifetime과 달리, FR에서는 enclosing lexical block에 따라 borrow가 종료된다. 따라서 soundness를 유지하면서 metatheory를 단순화할 수 있다.
구문: FR은 copy와 move를 구문적으로 구분하므로 operational semantics를 type-independent하게 유지할 수 있으며, typing은 copy expression을 copyable type으로 제한한다.mechanization에서는 unit, integer, shared borrow가 copyable인 반면 mutable borrow와 box는 copyable하지 않다.
구문: FR은 lexical lifetime을 명시적으로 나타내고 reference type에서 차용된 각 lval에 이름을 부여하여, lifetime nesting과 lval overlap 또는 conflict 추적을 통해 borrow checking을 수행한다.reference type은 shared borrow와 mutable borrow를 구분하며, 대상을 단일 lval로 제한하여 cycle-freedom을 지원한다.
Typing: FR의 주요 typing judgment는 input에서 output으로 environment를 전달하면서 moved-out slot을 표시하고, declaration, assignment, lifetime validity, partial-type shape check를 반영한다.이 flow-sensitive 구조는 moved value의 이후 사용을 거부하며, lval, well-formedness, shape compatibility를 위한 auxiliary judgment에 의존한다. 규칙은 Fig. 8에 요약되어 있다.

5 FR에서 Generative Compilation 구체화

이 절에서는 구현과 증명이 Lean으로 기계화된 경량의 syntax-guided sealor SFR을 사용해 FR에 generative compilation을 구체화한다. SFR은 전역적으로 complete하며 statement boundary에서 sound하므로, 해당 경계에서는 exactness를 얻는다.

Partial syntax와 realization: Partial syntax는 완전한 FR term, lvalue 또는 value 중 한 구성요소가 부분적으로 생성된 상태로 남을 수 있게 하여 autoregressive prefix를 모델링한다.Realization은 이러한 prefix를 미완성 frontier를 확장하되 앞서 생성된 텍스트는 수정하지 않고 얻을 수 있는 complete program과 연결한다.
Sealor construction: SFR은 partial FR term에서 full term으로 가는 total syntax-guided transformation을 정의하며, 유용한 typing obligation을 드러내는 경우 생성된 구조를 보존하고 미해결 obligation은 추상화한다.여전히 모호하거나 정보가 충분하지 않은 미완성 fragment는 unit value ε로 seal될 수 있지만, recursive case에서는 관련 subterm을 보존한다.
Completeness proof: Completeness proof는 partial term이 well-typed program을 realize할 때마다 이를 SFR로 sealing해도 well-typed term이 산출됨을 보인다.이 정리는 임의의 typing environment, store typing, lifetime에 대해 서술되므로 더 큰 program 내부의 intermediate term에 적용할 수 있다.
Global completeness: SFR은 임의의 input string을 포함해 FR에 대해 globally complete하며, 이는 generative compiler GFR의 completeness로 확장된다.이 결과는 SFR의 completeness와 exact FR compiler로부터 따른다.
Statement-boundary soundness: Statement boundary에서 SFR은 FR에 대해 sound하므로 exact하며, 동일한 exactness guarantee가 GFR에도 성립한다.이는 완성된 statement가 다음 generation frontier보다 앞에 있는 partial program에 적용된다.

6 FR에서 실제 Rust로

Rust sealor인 SRS는 FR의 경량 syntax-guided sealing 방법론을 실제 Rust로 옮기면서 Rust의 더 큰 문법과 typing 동작에 맞게 조정한다. context-sensitive placeholder, future-aware error handling, diagnostic projection을 사용해 완결성을 보존하고 partial program에 유용한 피드백을 제공한다.

설계 원칙: SRS는 생성된 구조를 보존하고 partial frontier를 재귀적으로 sealing하며, Rust 고유 구문을 처리하면서 selective soundness를 적용해 global completeness를 목표로 한다.FR과 달리 SRS는 FR에 대응하는 요소가 없는 구문을 다루며, mechanized proof 대신 feature별 비형식 논증을 사용한다.
설계 원칙: SRS는 statement sealor와 expression sealor를 분리해 사용하며, context에서 type을 추론할 수 있으면 expression sealor를 선택하고 그렇지 않으면 statement sealor를 선택한다.statement sealor는 partial statement를 statement list로 닫고, expression sealor는 제약되지 않은 type을 갖는 expression을 생성한다.
Placeholder: holediv()는 발산하는 control-flow branch에 대해서도 completeness를 보존하고, holeval()은 never-type fallback error를 노출하지 않으면서 context에서 추론된 value를 제공한다.holediv()는 panic!()으로 구현되며 type !을 갖고, holeval()은 call의 inferred return type이 T가 되는 generic helper를 사용한다.
Diagnostic: SRS는 이후 생성될 code에 의존할 수 있는 error를 억제하고, sealed program에서 발생한 rustc diagnostic을 원래 partial program으로 projection한다.이는 불완전한 trait implementation, 이후 선언되는 function, 모호한 expression type과 같은 경우를 처리하며, positional map은 다시 렌더링되는 diagnostic의 대응 관계를 보존한다.
Expression 및 statement 규칙: conditional의 경우 SRS는 재귀적으로 sealing된 branch가 completeness를 상속하고 추가된 holediv()가 branch-type obligation을 도입하지 않으므로 complete하다.holediv()는 발산하므로 rustc는 branch-type merging에서 이를 제외하며, 따라서 live branch를 제약할 수 없다.

7 실험 평가

7개 coding model과 2개 repository-level Rust task에 대한 평가에서 generative compilation은 compiler error와 runtime을 줄이고, 복구 불가능한 오류를 조기에 탐지하며 진단을 원인에 집중시킨다.

Model과 Agent Harness: 이 연구는 결정론적 harness를 사용해 Translation과 UpdatedAPI에서 task별로 7개 coding model을 두 차례 평가하고, compiler error rate와 functional correctness를 보고한다.Translation에서는 20개의 복잡한 CRUST-Bench instance를 사용하고, UpdatedAPI에서는 최근 변경된 Rust library API에 대한 적응을 평가한다.
한계: 알려진 Rust constrained decoding 구현이 없으므로 이를 비교 대상으로 삼을 수 없으며, GC의 global-completeness guarantee는 constrained decoding의 global-soundness requirement를 충족하지 않는다.실제 Rust를 위한 constrained decoder를 구축하는 일은 매우 복잡하고 비용이 많이 든다.
Runtime 감소: GC는 post-generation feedback 사용 시 LLM 대비 평균 runtime overhead가 233 seconds (+283%)였던 것을 135 seconds (+170%)로 낮춘다.Translation에서 Qwen 9B의 경우 sample당 runtime이 879 seconds에서 357 seconds로 감소한다.
오류 Snowball 완화: GC는 early-feedback phase 내에서 task의 55.4%를 올바르게 해결하며, 85.3%는 post-generation feedback으로 되돌아가지 않고 완료된다.첫 번째 복구 불가능한 오류에서 중단하면 더욱 집중된 report도 얻을 수 있다. 65%는 서로 다른 diagnostic을 한두 개만 포함하고, message당 diagnostic은 평균 5.5개다.
File Completion보다 훨씬 앞서 오류 탐지: GC는 file generation의 평균 33.3% 지점에서 오류를 탐지해 timing-free upper bound인 32.7%에 거의 근접하며, 복구 불가능한 output의 나머지 66.7%를 방지한다.median detection delay는 최종 오류의 primary span 이후 3 lines로, GCfn의 14 lines와 post-generation feedback의 89 lines보다 짧다.

8 논의 및 향후 연구

논의에서는 진단 모델링과 수작업 sealor 구성의 한계를 짚고, generative compilation을 고정된 호출 루프에서 분리할 수 있는 가능성을 제시한다. 현재 구현은 모델이 rustc 형식에 가장 익숙하다고 가정하기 때문에 피드백을 rustc 형식으로 렌더링한다.

Error Message 모델링: 형식적 completeness 및 soundness 결과는 ok verdict만 다루며, err가 sealing artifact가 아니라 실제 결함을 반영하는지는 다루지 않는다.저자들은 이 동작을 경험적으로 관찰하고 sealing artifact를 억제했다고 보고하지만, 해당 속성을 형식화하지는 않는다.
Error Message 모델링: 현재 렌더링은 저자들이 모델이 training corpus를 통해 이러한 피드백에 가장 익숙하다고 가정하기 때문에 rustc diagnostic formatting을 따른다.이는 프로그래머에게 사용되는 기존 formatting 과 최근 AI coding agents에 사용되는 formatting [21]을 따른 것이다.
Generative Compilation을 언제, 어떻게 호출할 것인가: Generative compilation은 현재 각 completed check 이후에 호출되며, rejection이 발생하면 prompt augmentation과 generation restart가 실행된다.Concurrent validation은 적은 overhead로 token generation과 동시에 실행할 수 있어 이 루프를 실용적으로 만든다. 이를 분리하면 alternative invocation strategies가 가능해질 수 있다.
Sealor Construction 자동화: FR (§5)과 Rust (§6) 모두에서 sealor construction은 hand-written으로 이루어져 있어, language specification이나 reference implementation으로부터의 synthesis가 필요하다.자동화는 complete하면서도 strongly sound한 규칙을 탐색해야 한다.

9 관련 연구

기존 연구는 compiler feedback, constrained decoding, syntax와 types, typed holes를 활용해 program generation 또는 completion을 지원한다. Generative compilation은 sampling restrictions나 language extensions에 의존하지 않고, 불완전한 LLM-generated programs에 compiler-oriented reasoning을 적용한다는 점에서 다르다.

Compiler Feedback: Compiler feedback은 memory safety 와 information-flow security 를 포함한 보장과, error messages 를 통한 수정 지침을 모두 제공한다.
Constrained Decoding: Constrained decoding은 sampling 중 next-token choices를 제한해 autoregressive generation 중에 programs를 검사하는 반면, generative compilation은 partial programs에 compiler feedback을 사용한다.Local token-level constraints는 최종 programs를 손상시킬 수 있지만 [4], global constraints도 여전히 sampling level에서 작동한다 [12] [25].
Constrained Decoding: Syntax를 넘어 constrained decoding은 significant reimplementation을 요구하며 [31] [34], 불완전한 language subsets는 성능을 저하시킬 수 있어 [6], Rust의 borrow 및 lifetime properties에 상응하는 기법은 존재하지 않는다.
Syntax- and Type-Guided Program Construction: Syntax- 및 type-guided program construction은 특히 formal specifications로부터의 synthesis를 중심으로 오랫동안 search를 지원해 왔지만, 본 연구는 LLM-based code generation을 대상으로 한다.
Typed Holes: Typed holes 는 incomplete programs를 well-typed로 만들어 static type contexts를 추출할 수 있게 하지만 [7], language extension을 통해 holes를 first-class citizens로 만들어야 한다.Generative compilation은 대신 FR (§5.2)에는 𝜀, Rust (§6.1)에는 holediv()와 holeval() 같은 placeholders를 사용한다.

10 결론

Generative compilation은 부분 프로그램을 compiler가 검사할 수 있는 완전한 프로그램으로 봉합하여, 중간 LLM 코드 생성 단계에 compiler 피드백을 도입한다. 형식화와 평가 결과는 이 접근법이 Rust에서 sound prefix checking을 지원하고, 조기 진단을 통해 생성 결과를 개선함을 보여준다.

Generative compilation은 부분 프로그램을 standard compiler가 검사할 수 있는 완전한 프로그램으로 봉합함으로써, black-box model, 실제 compiler, 풍부한 오류 메시지를 활용한 중간 피드백을 가능하게 한다.
Sealor는 Featherweight Rust에서 기계화된 completeness 및 soundness 보장으로 이 접근법을 형식화하고, Rust 고유의 구조 처리를 통해 실제 Rust로 확장한다.실제 Rust용 prefix checker는 expression과 statement 구조, control flow, placeholder, future-dependent compiler error를 처리한다.
Generative compilation은 파일 생성이 완료되기 전에 type, borrow-check, lifetime 오류를 발생 지점 가까이에서 탐지하여, standard post-hoc feedback보다 비컴파일 출력은 줄이고 functional correctness는 향상한다.

A 실험 세부사항 · A.1 UpdatedAPI 구축 · A.2 Translation 구축

실험 데이터셋은 API evolution과 어려운 C-to-Rust translation 설정에서의 Rust coding을 대상으로 한다. UpdatedAPI는 public API changes가 발생한 최근 version-bumped crate를 샘플링하고, Translation은 해결되지 않은 CRUST-Bench task에 집중해 repository context에서 file-level translation을 평가한다.

A.1 UpdatedAPI 구축: UpdatedAPI는 직전 6개월 동안 minor 또는 major version bump가 있었던 가장 많이 다운로드된 Rust crate 100개를 샘플링한다.샘플링은 논문 작성 시점에 수행되었다.
A.1 UpdatedAPI 구축: GPT 5.3을 사용한 Codex는 version bump 동안 public-facing API changes가 발생한 샘플 패키지를 필터링한다.
A.2 Translation 구축: Translation은 100개의 C-to-Rust translation task를 포함하는 CRUST-Bench benchmark [20]을 사용한다.
A.2 Translation 구축: GPT 5.3과 Claude Opus 4.8은 compiler feedback 없이 zero-shot으로 약 80개의 CRUST-Bench task를 해결하고, 20개 task를 집중 평가 대상으로 남긴다.
A.2 Translation 구축: 선정된 각 translation task는 원래 library 전체를 다루지만, library file별 separate task로 나뉜다.
A.2 Translation 구축: 최종 평가는 생성된 각 file을 독립적으로 평가하지 않고 repository에 삽입한다.

A.3 실험 설정 세부사항

실험에서는 생성 중 type-inference 정보를 노출하기 위해 최소한으로 패치한 Rust 1.95.0 compiler를 사용한다. 모델은 provider별 API를 통해 호출하며, temperature는 0.6으로 설정한다. 단, Claude Opus 4.8은 해당 endpoint에서 temperature 제어를 허용하지 않는다.

Rust 구현: Rust 1.95.0 구현에는 type inference에서 정의된 식별자, 사용 가능한 함수와 메서드, 예상 parameter 수를 노출하는 최소한의 compiler patch가 추가되어 있다.변경 사항은 구현을 포함한 code patch로 제공된다.
Hyperparameters: Qwen 3.5, GLM 5.2, Kimi K2.7은 OpenRouter를 사용하고, Gemini 3.5 Flash, GPT 5.3 Codex, Claude Opus 4.8은 provider별 API를 사용한다.Gemini는 Google Vertex를, GPT 5.3 Codex는 OpenAI responses API를, Claude Opus 4.8은 Anthropic의 API를 사용한다.
Hyperparameters: Claude Opus 4.8을 제외한 모든 모델은 temperature 0.6을 사용한다. Opus는 API endpoint가 temperature 설정을 지원하지 않으므로 temperature를 생략한다.UpdatedAPI task의 최대 출력은 20,000 tokens이다.

A.4 탐지된 오류 종류 상세 분석 · A.5 재시작 예산과 토큰 한도

분석 결과 rollback 오류는 type mismatch가 대부분을 차지했으며, restart budget 결과는 초기에 빠르게 향상된 뒤 평탄화되는 양상을 보여, 평가한 budget이 달성 가능한 compilability 개선의 대부분을 포착함을 시사한다.

A.4 탐지된 오류 종류 상세 분석: Rollback 진단에는 syntax error, type violation, borrow-check 및 lifetime violation, 그리고 관련 error code가 없는 기타 보고가 포함된다.그 결과로 얻은 error-kind 분포는 Fig. 13에 dataset별로 제시되어 있다.
A.4 탐지된 오류 종류 상세 분석: Type mismatch (E0308)는 두 dataset 모두에서 가장 빈번한 rollback 오류로, Translation 보고의 38.2%, UpdatedAPI 보고의 37.4%를 차지한다.오류 taxonomy는 syntax, type, borrow-check 및 lifetime, 기타 오류를 포괄한다.
A.4 탐지된 오류 종류 상세 분석: Translation에서는 unknown-field access가 9.5% (E0609)로 그다음으로 많이 보고된 오류 category이며, 이는 C data layout을 Rust skeleton으로 포팅하는 데 따르는 어려움을 반영한다.이는 E0308 type mismatch가 차지하는 38.2% 다음에 해당한다.
A.4 탐지된 오류 종류 상세 분석: UpdatedAPI에서는 wrong-argument-count call이 18.1% (E0061)를 차지하고, 그다음으로 wrong generic-argument count가 7.2%를 차지한다.이는 UpdatedAPI에서 E0308 mismatch 이후에 보고된 후속 오류다.
A.5 재시작 예산과 토큰 한도: 모든 generation을 pool하여 보면, 두 method 모두 처음 몇 번의 restart 동안 compilable output이 가파르게 증가한 뒤 개선 폭이 평탄화된다.분석에서는 두 dataset에 대해 평가한 모든 model을 pool하고, 주어진 restart count 이내에 달성 가능한 compilability를 측정한다.
A.5 재시작 예산과 토큰 한도: restart budget을 15에서 20으로 늘리면 compilable output의 비율이 증가하며, UpdatedAPI에는 15회 restart, Translation에는 20회 restart의 budget을 설정했다.보고된 token limit은 UpdatedAPI에서 20,000, Translation에서 30,000이다.

B 종단 간 예시 · C 추론 프롬프트

종단 간 예시는 Generative Compilation이 Rust lifetime 오류를 조기에 포착하고 올바른 수정을 가능하게 하는 과정을 보여준다. 추론 프롬프트는 Generative Compilation과 Post Compilation 모두에 대해 채점 접두사, 과제별 입력, 진단 피드백을 지정한다.

B 종단 간 예시: 두 방법의 컴파일 가능한 출력 비율은 20회 재시작보다 훨씬 전에 평탄화되는 반면, 생성된 출력 길이는 토큰 한도보다 훨씬 짧게 유지된다.
C 추론 프롬프트: 추론은 데이터셋 프롬프트를 포함한 하나의 user message를 전송하며, grading prefix는 open-weight 모델의 경우 미리 채워 넣고 black-box 모델의 경우 명시적으로 요청한다.
C.1 일반 추론 래퍼: Generative Compilation이 부분 출력을 거부하면, 프롬프트 이력에 이를 assistant message로 추가하고 렌더링된 compiler diagnostics를 포함한 user message를 덧붙인 뒤 생성을 재시작한다.
C.2 UpdatedAPI: UpdatedAPI 프롬프트는 crate 파일, 테스트, 주석을 제공하면서 모델이 불완전한 interface 파일만 구현하도록 요청하며, 이 파일은 src/lib.rs로 인스턴스화된다.
C.3 Translation: Translation 프롬프트는 대상 파일의 C 소스와 불완전한 Rust interface를 제공하고, black-box 추론을 위해 필요한 prefix 지시를 덧붙인다.
B 종단 간 예시: Generative Compilation은 32줄 함수의 line 4에서 임시 borrow를 E0716과 함께 거부하며, 이후 Claude Opus 4.8은 더 오래 유지되는 binding을 도입해 의미적으로 유효한 코드를 생성한다.이 예시는 rustls-webpki의 UpdatedAPI 과제를 다루며, 조기 피드백이 상당한 불필요한 생성을 방지하는 과정을 보여준다.
C.3 Translation: 반면 Post Compilation은 거부된 완성 출력과 렌더링된 diagnostics를 프롬프트 이력에 추가한 다음, 재검사 전에 전체 대체 파일, 패치 또는 둘 다를 허용한다.