История изменений
Исправление tp_for_my_bunghole, (текущая версия) :
Короче.
Когда пишешь компилятор, вот этот storage_class_specifier, надо определять что это псевдоним типа как где-то было указано в typedef кода. Лексер должен сформировать токен именно такого типа TYPEDEF_NAME. Но лексер по идее не обладает контекстной информацией, он же просто сканирует текст образуя терминальные символы(токены) для парсера.
Простое решение это собирать в свой массив все встреченные typedef. Лексер видит слово, и ищет его в этом массиве, если оно там есть, значит это typedef, и формирует токен TYPEDEF_NAME. А собирает все эти typedef в массив парсер, лексер просто проверяет. Такая связь жесткая получается, нет разделения.
CLang откладывает это на отдельную семантическую фазу как я понимаю. После прохода по всей программе, он начинает сопоставлять все эти storage_class_specifier и искать их в базе всех typedef.
Проблема здесь также в том что в C нет никакой информации как компилируется программа, зависимости между файлами. Ивестно только что файлы используют цепочки headers как интерфейс, и в этих цепочках много нондетерминизма(ifdef) который зависит от последовательности включения этих файлов, которая может быть разной в отдельных файлах. Вся информация о проекте содержится только в сторонней системе сборки, Makefile.
Как-то полноценно работать с кодом можно только в компиляторе, если у компилятора есть система плагинов и она реализована так что можно всякие дела делать.
Исправление tp_for_my_bunghole, :
Короче.
Когда пишешь компилятор, вот этот storage_class_specifier, надо определять что это псевдоним типа как где-то было указано в typedef кода. Лексер должен сформировать токен именно такого типа TYPEDEF_NAME. Но лексер по идее не обладает контекстной информацией, он же просто сканирует текст образуя терминальные символы(токены) для парсера.
Простое решение это собирать в свой массив все встреченные typedef. Лексер видит слово, и ищет его в этом массиве, если оно там есть, значит это typedef, и формирует токен TYPEDEF_NAME. А собирает все эти typedef в массив парсер, лексер просто проверяет. Такая связь жесткая получается, нет разделения.
CLang откладывает это на отдельную семантическую фазу как я понимаю. После прохода по всей программе, он начинает сопоставлять все эти storage_class_specifier и искать их в базе всех typedef.
Проблема здесь также в том что в C нет никакой информации как компилируется программа, зависимости между файлами. Ивестно только что файлы используют цепочки headers как интерфейс. Вся информация о проекте содержится только в сторонней системе сборки, Makefile.
Как-то полноценно работать с кодом можно только в компиляторе, если у компилятора есть система плагинов и она реализована так что можно всякие дела делать.
Исходная версия tp_for_my_bunghole, :
Короче.
Когда пишешь компилятор, вот этот storage_class_specifier, надо определять что это псевдоним типа как где-то было указано в typedef кода. Лексер должен сформировать токен именно такого типа TYPEDEF_NAME. Но лексер по идее не обладает контекстной информацией, он же просто сканирует текст образуя терминальные символы(токены) для парсера.
Простое решение это собирать в свой массив все встреченные typedef. Лексер видит слово, и ищет его в этом массиве, если оно там есть, значит это typedef, и формирует токен TYPEDEF_NAME. А собирает все эти typedef в массив парсер, лексер просто проверяет. Такая связь жесткая получается, нет разделения.
CLang откладывает это на отдельную семантическую фазу как я понимаю. После прохода по всей программе, он начинает сопоставлять все эти storage_class_specifier и искать их в базе всех typedef.
Проблема здесь также в том что в C нет никакой информации как компилируется программа, зависимости между файлами. Ивестно только что файлы используют цепочки headers как интерфейс. Вся информация о проекте содержится только в системе сборке, Makefile.
Как-то полноценно работать с кодом можно только в компиляторе, если у компилятора есть система плагинов и она реализована так что можно всякие дела делать.