Я где то раз в месяц ловлю ошибку отсутствия доступа, но появляется она только при компиляции после спящего режима или когда вся оперативка забита. То есть проблема скорее в кривой многопоточности…
Для проверки какая программа блокирует файл - могу порекомендовать IOBitUnlocker. Однако вряд ли это поможет, потому что следующая компиляция после ошибки доступа - никогда не даёт ту же ошибку.
Вообще, детерменированности никакой. Ошибки доступа к файлу не могу получить. В частности из-за этого дальнейшая разработка невозможна. Также, возникали проблемы с переименованием, благодаря которому сломались многие написанные мною модули (а именно: то удалялась ;, то название типа превращалось в какую-то кашу, то ломались интерполированные строки). В результате я отказался от структуризации кода разделением его на модули (поскольку в противном случае пришлось бы править почти все модули снова вручную).
Да, переименование плюс модули - там конечно не всё доделано. Но и непонятно, как переименовывать если это модуль стандартный например. Модули - это не единый проект в C#.
Возможно, переименование типов и остальных сущностей системного модуля стоит запретить. У Вас есть маркер системного модуля __IS_SYSTEM_MODULE, возможно, его стоит использовать для проверки возможности переименования сущностей модуля (если данная константа равна true, то переименование невозможно, иначе возможно). Только остаётся решить вопрос с теми модулями, в которых нет данной константы: разрешать ли переименование в них или нет. Лично я бы разрешал. Вам слово.
P.S. Стоит заметить, что в Visual Studio (тестировалось на примере C#) невозможно переименовать типы, определённые в метаданных.
В данном случае, по моему, не нужно мудрить с содержимым модуля. Надо запретить переименования всех имён, описанных в модуле из LibSource в ProgramFiles, а так же всех имён из библиотек.
Проблема вот какая. Пусть есть модуль Unit1, которым пользуются 5 программ. То есть, у каждой программы есть uses Unit1; И мы в одной программе переименовываем имя из модуля. Если это разрешить, то остальные 4 программы лягут.
Точнее, это сугубо техническая проблема? Всё-таки, не совсем понимаю, почему так произойдёт. В моём представлении предполагалось, что переименование произойдёт во всех программах (однако, их может быть много, и здесь проблема производительности).
А по моему проблема надуманная. Достаточно открыть тексты всех программ в IDE и они все переименуются сразу. А то что вхождения имени не переименовываются в закрытых файлах - не повод обрезать полезную фичу.
Нет, это наивное предложение. Кто-то для сравнения открыл мой проект (а другая программа - это именно другой проект) - и тут бах - и в нем всё переименовалось.
Правильнее будет не переименовывать в модуле вообще.
В проекте использующем модули - обычно большинство расходных имён (к примеру множественных наследников 1 класса, каждый из которых может понадобится переименовать в любой момент чтоб освободить имя) оказывается как раз в модулях, поэтому вы таким образом обрежете большую часть фичи. Ничего правильного в этом нет.
Вообще, если не переименовывать автоматически везде в связанных программах при переименовании из модуля, то они могут перестать компилироваться, поскольку не будут знать как называется какой-то функционал по новому. Что означает, что потребуется проделывать лишние переименования в программах. Но, я в душе не чаю как сделано в других IDE для Паскаля. Было бы хорошо узнать как сделано в них.
Как это происходит в Delphi. Переименовывается только в текущем файле, в модуле не переименуется вообще. Наступает рассогласование. Но они пишут что то вроде “мы же вас предупреждали”.
Так, как Вы планируете поступить с PascalABC.NET? С одной стороны - возможность, которой нет в Delphi - хорошо, с другой - возможно, на то были причины, что так поступили разработчики Delphi.