doslang-mirror/TODO.md

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