audit: SPEC-파서 괴리 일곱을 정리한다
구현 셋, SPEC 다섯. 어느 쪽이 틀렸는지는 항목마다 따로 판정했다. 구현: - ~ 를 넣었다. ^ 는 xor 과 .^ 가 가져가서 비트 NOT 이 자기 철자를 못 갖고 있었다. 렉서·파서·검사·lowering(전부 1 과의 xor). - 전역 static/var 는 타입을 적는다. 다른 유닛이 읽는 링커 심볼이라 초기값의 생김새에 타입을 맡기면 그쪽이 보는 것이 달라진다. const 는 그대로 추론한다. - error code 는 정수 리터럴 하나다. 식이면 중복도 예약된 0 도 검사할 수 없다. SPEC: - 최상위 comptime if 를 뺐다. comptime 조건은 타입 술어뿐인데(§7.5) 유닛 바깥에는 바인딩된 타입 파라미터가 없어 물어볼 것이 없다. §11 v0.2. - 타입 이름은 [binding.]Name 이다. import 가 마지막 segment 를 바인딩하므로 점 둘 이상은 만들어질 수 없는데 문법이 unit_path 를 쓰고 있었다. - catch 의 EBNF 가 §4.6 보다 넓었다. 값을 주는 짧은 형태와 에러를 받는 블록 형태 둘로 나눠 적었다. - | 와 ^ 를 한 단계로 둔 것을 쪼갰다. 합치면 a | b ^ c 가 좌결합으로 (a|b)^c 가 되어 C 에서 온 사람을 속인다. 구현이 C 순서로 옳았다. - 마지막 필드 쉼표 생략을 명세에 적었다. enum 은 이미 허용하고 있었다. 그리고 tests/run.py 가 마커를 진단 스트림에만 맞춘다. --dump-ast 모드에서는 AST 덤프가 stdout 으로 먼저 나와서 parse/ fixture 는 마커를 쓸 수 없었다. 249/249, 39/39.
This commit is contained in:
@@ -11,6 +11,7 @@ DOS/Windows용 시스템 프로그래밍 언어 Ferro와 그 컴파일러 `fec`.
|
||||
| `IR.md` | 중간 표현. 프론트엔드와 기계 사이 |
|
||||
| `TODO.md` | 남은 작업과 정해진 것. 언어 규칙은 `SPEC.md` 를 가리키기만 한다 |
|
||||
| `fec/tests/*/README.md` | 각 fixture 디렉터리가 무엇을 검사하는지 |
|
||||
| `audits/<날짜>-<주제>.md` | 그때 조사해보니 어땠는지. 불변 기록 |
|
||||
|
||||
## 파이프라인
|
||||
|
||||
@@ -59,6 +60,19 @@ uv run python tests/build.py <프로그램.fe> # 하나만 빌드해서 돌려
|
||||
줄 범위로 자르고 -- 주제별로 묶는 것보다 정확하다, 한 줄도 잃거나 겹치지 않으니 --
|
||||
공유하는 것은 비공개 헤더(`checkpri.h`, `lowerpri.h`)에 모은다.
|
||||
|
||||
## 조사 기록
|
||||
|
||||
한 번 조사하고 끝나는 것 -- 명세와 구현의 대조, 진단 증거 수집, 외부 감사 --
|
||||
은 `audits/<날짜>-<주제>.md`에 남긴다. 날짜와 기준 커밋을 적는다. 조사에서
|
||||
나온 **결론**은 `SPEC.md`나 `TODO.md`로 옮기고, audit 자체는 그때 무엇을
|
||||
봤는지의 기록으로 둔다.
|
||||
|
||||
본문은 고치지 않는다. 다만 해결되면 맨 위에 **해결 줄 하나**를 붙인다 --
|
||||
어느 커밋에서 어떻게 정리됐는지. 그것 없이는 읽는 사람이 아직 살아있는
|
||||
문제인지 알 수 없다.
|
||||
|
||||
계획 문서는 두지 않는다 -- 끝난 계획은 git log 다.
|
||||
|
||||
## 작업 흐름
|
||||
|
||||
- 명세 판단이 바뀌면 `SPEC.md`를 즉시 갱신한다. 구현이 명세와 다르면 둘 중 하나가
|
||||
|
||||
Reference in New Issue
Block a user