# TODO

현재: **150/188** (`uv run python tests/run.py`)

컴파일러는 프론트엔드뿐이다. IR·lowering·백엔드는 없다.

---

## 프론트엔드 마무리

| # | 일 | 규모 | fixture | 비고 |
|---|---|---|---|---|
| 1 | cross-unit 이름 해석 | 중 | units 8 | `util.answer()` 가 다른 유닛 선언을 보게. `check.c` 가 import binding 을 심볼로 알아야 함 |
| 2 | 가시성 `pub`/private | 중 | units 4 | `privfn` `privfld` `dotpriv` `pubpriv` |
| 3 | nominal error identity | 중 | units 3 | `errsame` `errdet` `errnom` |
| 4 | **제네릭 실체화** | 대 | generic 25 | worklist 엔진. **IR 설계에 직접 영향 — 분기점** |
| 5 | 마커 없는 fixture 37개 판정 | 중 | — | 개당 판단 필요. 아래 참조 |

## 백엔드

| # | 일 | 규모 | 비고 |
|---|---|---|---|
| 6 | IR 정의 | 중 | 초안 있음. 4번이 정해져야 확정 |
| 7 | **lowering** | 대 | `try`/`catch`/`defer`/drop/`for`/메서드/경계검사 전개. **프로젝트 무게중심** |
| 8 | i386 백엔드 | 대 | IR → x86 asm → `wasm` → `wlink`. W11 에서 실행 검증 |
| 9 | 런타임 최소 세트 | 소~중 | 시작 스텁, `fe_trap`, `malloc`/`free` |
| 10 | `pending-backend/` 3개 복귀 | 소 | bounds trap, `--no-checks` 차등, 소유권 drop |

## 그 이후

| # | 일 | 규모 | 비고 |
|---|---|---|---|
| 11 | stdlib | 대 | 현재 49줄, 본문 있는 함수 2개. `List`/`Map` 은 4번에 의존 |
| 12 | bits16 백엔드 | 대 | `DX:AX` 32비트 산술, 세그먼트. 제일 어려움. 마지막 |
| 13 | 타깃 의존 구문 | 중 | `far` `asm` `interrupt` `atomic` `critical` `shared` — 파싱만 되고 의미 없음. fixture 도 없음 |

---

## 미결 결정

| | 내용 | 언제 |
|---|---|---|
| 덩어리 전달 규약 | 정함 (전부 주소로). 8번 착수 전 재확인 | 8 전 |
| `extern` C 상호운용 | 위 규약이 C ABI 와 안 맞음. 경계 변환 필요 | 8 전 |
| 주 타깃 | i386/W11 로 기울었으나 SPEC §1.2 는 아직 "640KB 셀프호스팅" | 아무 때나 |
| stdlib 명세 | SPEC §10 이 플레이스홀더. 시그니처·오류·경계 동작 미정 | 11 전 |
| `far` 의 거취 | IR 에 안 두기로 함. 언어에서 뺄지 bits16 전용으로 둘지는 미정 | 12 전 |

---

## 순서

```
1 → 2 → 3        프론트엔드 유닛 완성
4                제네릭.  ← 여기서 IR 형태가 결정됨
6 → 7            IR + lowering
8 → 9 → 10       i386 백엔드, 실행 검증 복귀
11               stdlib
12 → 13          DOS 고유
```

5번은 독립적이라 아무 때나 끼워 넣는다.

---

## 위임 정책

**위임 가능** — 결과가 자명하고 판단이 없는 것

- fixture 이름 개선, README 갱신, 문서 정합
- 파일 목록을 **명시적으로 열거해서** 줄 것. "찾아서 하라" 는 약함
- 기준선 두 숫자(`N/188`, `M pin`)를 주고 **변하면 안 된다**고 못박을 것

**위임 불가** — 언어 의미론 판단이 섞인 것

- 마커 판정, cross-unit 해석, 가시성, 제네릭, IR/lowering/백엔드

---

## 5번에 대하여 (마커 없는 fixture 37개)

거부 fixture 76개 중 **37개에 `// ERROR:` 마커가 없다.** 마커가 없으면 러너는
"거부되기만 하면 통과" 로 판정한다. 즉 **엉뚱한 이유로 거부돼도 초록이다.**

```
format  10    own  8    types  19
```

마커를 붙이려면 fixture 마다 "지금 나오는 진단이 옳은가" 를 판정해야 하고,
그 판정은 세 갈래로 갈린다. 오늘 5건을 조사했을 때 실제로 셋 다 나왔다:

| 결론 | 예 | 조치 |
|---|---|---|
| 마커가 틀렸다 | `badbrmov` 한 줄 밀림 | 마커 수정 |
| 마커가 언어를 오해했다 | `badloop` — 루프 안에서 이미 걸림 | 마커 수정 |
| **진단이 부실하다** | `badweak` — "type mismatch" 로만 나옴 | **컴파일러 수정** |

세 번째 때문에 위임이 위험하다. 실제 출력을 마커에 그대로 베끼면 전부 초록이
되지만 **컴파일러가 틀린 곳까지 정답으로 굳는다.**

### 병렬화

판정 자체는 **fixture 간 독립**이라 병렬 가능하다. 다만 **판정을 위임하면 안 된다.**
쓸 수 있는 형태는 증거 수집과 판정을 나누는 것이다:

```
위임:  fixture 를 열고 → fec 를 돌리고 → 다음을 보고
         파일 경로 / 검사하려는 것으로 보이는 규칙 / 실제 진단 전문(줄·문구)
       마커는 만들지 않는다

직접:  보고를 읽고 세 갈래 중 무엇인지 판정 → 마커를 쓰거나 컴파일러를 고침
```

이러면 37개를 디렉터리별로 병렬로 뿌려 증거를 모으고, 판정만 직접 하면 된다.
느린 부분(파일 읽기·실행·정리)이 병렬화되고 위험한 부분은 남는다.