[c] GCC 및 Clang 파서는 실제로 손으로 작성됩니까?

이상한 대답!

C / C ++ 문법은 문맥이 자유롭지 않습니다. Foo * 막대 때문에 문맥에 민감합니다. 모호. Foo가 유형인지 아닌지 알기 위해 typedef 목록을 작성해야합니다.

Ira Baxter : 당신의 GLR에 대한 요점이 보이지 않습니다. 모호성을 포함하는 구문 분석 트리를 만드는 이유. 구문 분석은 모호성을 해결하고 구문 트리를 구축하는 것을 의미합니다. 두 번째 단계에서 이러한 모호성을 해결하므로 덜 추하지 않습니다. 나를 위해 그것은 훨씬 더 추합니다 …

Yacc는 LR (1) 파서 생성기 (또는 LALR (1))이지만 상황에 맞게 쉽게 수정할 수 있습니다. 그리고 그 안에 못생긴 것은 없습니다. Yacc / Bison은 C 언어 구문 분석을 돕기 위해 만들어 졌으므로 아마도 C 구문 분석기를 생성하는 가장 못된 도구는 아닐 것입니다.

GCC 3.x까지 C 구문 분석기는 yacc / bison에 의해 생성되며 구문 분석 중에 typedefs 테이블이 작성됩니다. “in parse”typedefs 테이블 빌드를 사용하면 C 문법이 로컬 컨텍스트에서 자유 로워지고 더욱 “로컬 LR (1)”이됩니다.

이제 Gcc 4.x에서는 재귀 하강 파서입니다. Gcc 3.x에서와 똑같은 파서이며 여전히 LR (1)이며 동일한 문법 규칙을 가지고 있습니다. 차이점은 yacc 파서가 수작업으로 다시 작성되었으며 시프트 / 리 듀스가 이제 호출 스택에 숨겨져 있으며 gcc 3.x yacc 에서처럼 “state454 : if (nextsym == ‘(‘) goto state398″이 없다는 것입니다. parser를 사용하면 패치, 오류 처리 및 더 좋은 메시지를 인쇄하고 구문 분석 중에 다음 컴파일 단계를 수행하는 것이 더 쉽습니다. gcc noob에 대한 “읽기 쉬운”코드가 훨씬 적습니다.

왜 그들은 yacc에서 재귀 하강으로 전환 했습니까? C ++를 구문 분석하기 위해 yacc를 피해야하고 GCC가 다국어 컴파일러를 꿈꾸기 때문에 컴파일 할 수있는 다른 언어간에 최대 코드를 공유하기 때문입니다. 이것이 C ++와 C 파서가 같은 방식으로 작성된 이유입니다.

C ++는 C와 같이 “로컬”LR (1)이 아니고 LR (k)도 아니기 때문에 C보다 파싱하기가 더 어렵습니다. 봐가에 func<4 > 2>있는 즉, 4> 2 인스턴스화 템플릿 함수 func<4 > 2>
로 읽을 수있다 func<1>. 이것은 확실히 LR (1)이 아닙니다. 이제 func<4 > 2 > 1 > 3 > 3 > 8 > 9 > 8 > 7 > 8>. 이것은 재귀 하강이 몇 가지 추가 함수 호출의 대가로 모호성을 쉽게 해결할 수있는 곳입니다 (parse_template_parameter는 모호한 파서 함수입니다. parse_template_parameter (17tokens)가 실패하면 parse_template_parameter (15tokens), parse_template_parameter (13tokens) …까지 다시 시도하십시오. 효과가있다).

yacc / bison 재귀 하위 문법에 추가 할 수없는 이유를 모르겠습니다. 아마도 이것이 gcc / GNU 파서 개발의 다음 단계가 될까요?