Наше текущее AST в трансляторе VHDL спроектировано изменяемым. Сперва создаётся объект через new ASTObject(tree и тп) и заполняется через вызовы методов и установку свойств. Обоснование изначально было "если мы не сможем создать объект полностью, так хоть частично его заполним и вернём".
Поскольку надо сигнализировать об ошибке, практически всюду и везде возвращается null. Частично созданный объект никогда не возвращается.
VHDL язык с недетерминизмом в проверке типов - если у нас есть "оператор" function "AND"(a,b:integer) return integer и function "AND" (a,b:integer) return bit_vector, то проверка типов должна попробовать оба-два варианта для выражения 1 AND x. Большую часть времени возвращаемый тип ограничен сверху, но иногда не ограничен - при преобразовании подтипов-массивов (подробности, право слово, ещё ужасней). Поэтому естественным подходом к проверке типов был бы "создаём все варианты, а потом отбросим ненужные", однако проверка типов сопряжена с созданием объектов AST (и это верно, ибо x(a) может быть вызовом функции или взятием элемента массива), а они, как я уже объяснил, сперва создаются, потом заполняются и меняются в процессе. Поэтому правильный подход затруднён, если учесть размер функций преобразования - в районе 50-600 строк, медиана сотня строк.
Но и это ещё не всё.
В данный момент все файлы транслируются каждый раз перед запуском. Причина проста - запомнить состояние проекта невозможно, ибо, бахама мама, AST может быть изменено! Да и система поиска прошита в AST так, что отделить её от самой AST труднее, чем сиамских близнецов, сросшихся сердцами. А при компиляции изменённых файлов надо же ещё перекомпилировать файлы, которые зависели от содержимого изменившихся!
Опять же, если бы 1) использовались неизменные данные (readonly на все поля) и 2) система поиска была бы отвязана от AST и делалась бы
атрибутными грамматиками (точнее, атрибутными деревьями - деревья AST, дополненные атрибутами), то обе вышеописанные проблемы были бы не то, что решаемы, а имели бы тривиальное решение.
Но я живу в мире, который мне дан в ощущениях (а не выбран мной), поэтому я буду лопатить тонны кода, преобразуя сие чудо техники в нечто нормальное, пока ответственный за всё это рисует платы в нашем CAD.
А вот мои читатели, надеюсь, учтут эти ошибки и смогут их обойти.
PS
Мой опыт говорит, что наибольший опыт приобретается после переписывания программы в третий раз. Не ленитесь, не будьте похожи на руководителя нашей группы.
