Попытался было исправить баг 1229 а также попробовать решить проблему с выбором констроктора атрибутов (сейчас например нельзя навесить атрибут System.ComponentModel.DefaultValueAttribute).
В обоих случаях проблемный код не использует стандартный алгоритм выбора перегрузок (тот что сворачивает список экземпляорв OverloadPossibility).
В случае с выбором op_Implicit сворачивается список IMethod-ов (GetBestOverloads1) и не контролируются ограничения на генерики, а в случае конструктора атрибутов вообще написан какой-то костыль непонятный.

Внимание, вопрос: как связаны между собой Solver и OverloadPossibility?

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

H>Попытался было исправить баг 1229 а также попробовать решить проблему с выбором констроктора атрибутов (сейчас например нельзя навесить атрибут System.ComponentModel.DefaultValueAttribute).
H>В обоих случаях проблемный код не использует стандартный алгоритм выбора перегрузок (тот что сворачивает список экземпляорв OverloadPossibility).
H>В случае с выбором op_Implicit сворачивается список IMethod-ов (GetBestOverloads1) и не контролируются ограничения на генерики, а в случае конструктора атрибутов вообще написан какой-то костыль непонятный.

H>Внимание, вопрос: как связаны между собой Solver и OverloadPossibility?

Как-то из предисловия не следует вопрос. Да и ответить на этот вопрос не очень просто. Это все равно как задать вопрос "Как связан класс string и Form?".

Solver — это класс который отвечает за хранение графа выводимых типов и его версионность. OverloadPossibility — это класс описывающий список перегрузок методов.

Сказать, что они как-то связаны трудно. Хотя несомненно используются совместно.

Тут уж скорее нужно говорить об описании самомого процесса разрешения перегрузок, отложенной типизации и вывода типов. Это весьма связанные вопросы. Но их в двух словах не опишешь.

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

VD>Тут уж скорее нужно говорить об описании самомого процесса разрешения перегрузок, отложенной типизации и вывода типов. Это весьма связанные вопросы. Но их в двух словах не опишешь.

Я так понял, что список возможных перегрузок фильтруется в рамках текущей версии в Solver-е (я не понял как это вообще происходит). Я не понял что нужно сделать с рашетелем, чтобы решить означенные проблемы. Как Solver определяет какая перегрузка — лучшая?

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

H>Я так понял, что список возможных перегрузок фильтруется в рамках текущей версии в Solver-е (я не понял как это вообще происходит). Я не понял что нужно сделать с рашетелем, чтобы решить означенные проблемы. Как Solver определяет какая перегрузка — лучшая?

Солвер не работает с перегрузками. Он работает с грфом типов. Он обеспечивает вресионный механизм его изменения.

Перегрузками заведует тайпер (Typer) и DelayedTyping (что является частью тайпера).

Солвер используется тайпером для управления этим графом.

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

VD>Перегрузками заведует тайпер (Typer) и DelayedTyping (что является частью тайпера).

Ага, уже понял. Спасибо за r8894 — странно, что я не нашел этот метод (ResolveOverload) раньше

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

H>Ага, уже понял. Спасибо за r8894 — странно, что я не нашел этот метод (ResolveOverload) раньше

Вот только применять его нельзя. Проблема в том, что получится неконтролируемая рекурсия, так как приведение типа используется внутри ResolveOverload.

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

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

H>>Ага, уже понял. Спасибо за r8894 — странно, что я не нашел этот метод (ResolveOverload) раньше

VD>Вот только применять его нельзя. Проблема в том, что получится неконтролируемая рекурсия, так как приведение типа используется внутри ResolveOverload.

Угу. Уже сообразил, сейчас вот играюсь.

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

H>Угу. Уже сообразил, сейчас вот играюсь.

Давай я там сам все поправлю. Там нужно поменять код чтобы он использовал штатный вариант GetBestOverloads(). Не уверен, но возможно еще и OverloadPossibility.OnlyPossible().

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

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

H>>Угу. Уже сообразил, сейчас вот играюсь.

VD>Давай я там сам все поправлю. Там нужно поменять код чтобы он использовал штатный вариант GetBestOverloads(). Не уверен, но возможно еще и OverloadPossibility.OnlyPossible().

Ок (попробовал — не вышло). Тогда я поковыряюсь с атрибутами.

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

H>Попытался было исправить баг 1229

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

Я просто поправил метод GetBestOverloads1 добавив в него правило отбрасывания дженерик-методов, если есть хотя бы один не дженерик. Кроме того я переименовал его в GetBestOverloadsWithoutImplicitConversions, чтобы была ясна его суть.

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

H>Ок (попробовал — не вышло). Тогда я поковыряюсь с атрибутами.

Давай. Вот там как раз нужно попробовать использовать стандартную перегрузку.

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

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

H>>Ок (попробовал — не вышло). Тогда я поковыряюсь с атрибутами.

VD>Давай. Вот там как раз нужно попробовать использовать стандартную перегрузку.

Сломал мозги и борду , но таки кое-что сделал.
Просьба произвести код-ревью, так как пришлось добавить дополнительный конструктор для Typer-а.

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

H>Просьба произвести код-ревью, так как пришлось добавить дополнительный конструктор для Typer-а.

Насколько я понял, урезанный Тайпер (ну, сконструированный новым конструктором) можно использовать вне контекста метода?

*шёпотом* Ну, например, чтобы выводить типы приватных полей классов.

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

H>Сломал мозги и борду , но таки кое-что сделал.
H>Просьба произвести код-ревью, так как пришлось добавить дополнительный конструктор для Typer-а.

Из того что беглым взглядом выхватил — можно вместо формирования TExpr.DefaultValue(ty) использовать реальное выражение полученное раньше. Только при этом его нужно не в object складывать.

В остальном на глаз все более менее корректно. Но такие вещи на глаз проверять очень сложно. В общем, раз тесты проходят и компилятор сам себя собирает, значит пока все ОК. Ну, а появятся проблемы — будем решать.

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

VD>Из того что беглым взглядом выхватил — можно вместо формирования TExpr.DefaultValue(ty) использовать реальное выражение полученное раньше. Только при этом его нужно не в object складывать.

Я так и хотел сперва, да только существующий код не изготавливает TExpr , а переписывать еще и его как-то не хотелось.

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

C>Насколько я понял, урезанный Тайпер (ну, сконструированный новым конструктором) можно использовать вне контекста метода?

Боюсь что этот конструктор граничит с хаком, так как я не ручаюсь за функционал такого тайпера окромя выбора перегрузок.

Здравствуйте, Аноним, Вы писали:

А>Я так и хотел сперва, да только существующий код не изготавливает TExpr , а переписывать еще и его как-то не хотелось.

Ладно. Работает, и ладно. Если есть время лучше займись типизацией при разборе макросов. Там тоже хардкодинга хватате. Народ не раз нарывался на проблемы связанные с этим.