OberonCore

Тут главное - определить, что является нормой, а что выходит за рамки нормального. Если:
1. 99% кода не использует рекурсию, SYSTEM.GET для процедурных указателей и проч;
2. а 1% кода вынужден использовать TRACE с рекурсивным обеганием,
то вполне можно использовать ограничительную семантику с RESTRICT для 1 случая. А вот случай 2 будет ненормальным, без ограничений, стало быть, программист отдает себе отчет, что наворотил более сложные алгоритмы. И да, программист готов доказывать, что защита для TRACE им дважды проверена и работает. Случай 1 доказывать не надо, там и так все работает.

А вот если усложнение кода является нормой, то RESTRICT уже не поможет. Вместо усложнения компилятора для анализа неоднозначного кода лучше стимулировать разработчика писать ясный код.

Надо, чтобы 0% кода могли использовать такую рекурсию, потому что движок просто на неё не рассчитан (я уже выяснил, что дело в попытке повторно получить уже полученную блокировку, которая такого использования не подразумевает). Но при этом трассировка без рекурсии нужна почти везде. На самом деле конкретно в данной ситуации уже разобрался на уровне динамики. Просто на самом-то деле, при попытке войти в блокировку падает ASSERT, но для вывода ему тоже нужна эта же блокировка. Я просто убрал оттуда ASSERT и вместо этого завершаю приложение (это режим приложения, а не ОС). Получается, что, совершив свою ошибку, я наступил на заранее подложенные грабли. Впрочем, это тоже означает, что неплохо бы запретить такую рекурсию на уровне компилятора.

Но проблема в том, что запретить её прямо для целых модулей будет не особо хорошо, потому что она там нужна. Она нужна, но при условии отсутствии рекурсии. На самом деле _была_ нужна, раз мне удалось научить систему падать более внятно, то теперь этой проблемы больше нет, от неё осталось только ментальное упражнение не совсем понятной ценности, так что можно и свернуть обсуждение.