Здравствуйте, Loislo, Вы писали:

L>Попробовал для начала просто пронаследовать RCompileUnit от RNamespace, почикал дубликаты ф-ий. Попатчил еще cs.atg в районе CS() дабы другая структура получалась. В принципе заработало. Но во первых правильнее как ты написал через RNamespaceBase сделать, во вторых возможно где-то в другом месте что-то отвалилось, Юнит тестов нет, фиг узнаешь.

Загрузи тот же RSParser и процентов 70 тестов тебе гарантировано. Погляди на результат рендеренга кода по АСТ (менял ты ведь только RCompileUnit и RNamespace, вот ни них и смотри).

L>Мои ощущения были такие что, каждый элемент дерева построен парсером из куска кода и все непосредственные дети этого элемента покрывают собой этот кусок кода но не пересекаются между собой. это мое ощущение и было нарушено .

AST не совсем отражение кода. Это отражение объектной модели кода. А она несколько более хитра нежели внешнее представление кода. К этому нужно привыкнуть.

L>Правильно я понимаю что:

L>для второго пункта надо иметь деревообразное пространство всего проекта

Правильно. Это уже делается в RSharp.Compiler/rsc и в CodeAnalyzer (если загружать проект, а не отдельный файл).

L>и импортированых в него сущностей

Правильно. Но это еще не делается. Хотя список внешних сборок получается.

L>(не знаю как это назвать)

Внешние сборки на которые ссылается проект.

L> и бегать по нему снизу вверх в поисках нужных ссылок.

Неправльно. Бегать нужно только от корня вниз. Если я не ошибаюсь, разрешение имен может быть сделано за 1 объход AST.

L> Алгоритм очевидно будет более сложный в силу множественности мест откуда могут приезжать типы и переменные и т.д.

Алгоритм осложняется только множественностью пространств имен.

L> Дерево проекта уже есть осталось только дерево импортированых сущностей и бегать.

Сложность в том чтобы написать правильный и в тоже время быстрый алгоритм объода.

L>для первого видимо нужна какая то другая структура где каждая переменная будет содержать список ссылок на места где она используется

Это называется областью видимости (scope). Где-то в форуме _Obelisk_ уже описывал примерный алогоритм.

L>либо каждый раз бегать по дереву и генерировать этот список.

Это медленно. Сейчас примерно так и делается. Причем разрешаются только типы описанные в проекте и только для заданного метса (где производится ссылка на тип).

L> Т.е. бегать придется всегда а вот сохранять или не сохранять?

Даже сейчас кое-что сохраняется. А надо сделать так чтобы после объхода вся информация была доступна с минимальными затратами.