Pawn compiler (3.10)

[truescripter]

Когда уже компилятор обновят? Есть инфа какая-нибудь? Столько исправлений на гите уже, почему они тянут?

[Daniel_Cortez]

Когда уже компилятор обновят? Есть инфа какая-нибудь? Столько исправлений на гите уже, почему они тянут?

Пока что от мейнтейнеров проекта не было никаких официальных заявлений на счёт нового релиза. Как я уже говорил раньше, можете потерроризировать их этим вопросом в репо на GitHub :)

[vvw]

Пока что от мейнтейнеров проекта не было никаких официальных заявлений на счёт нового релиза. Как я уже говорил раньше, можете потерроризировать их этим вопросом в репо на GitHub :)

Просто все мейнтейнеры заняты Advent Of Code. Забавная, кстати, штука.

[Daniel_Cortez]

Просто все мейнтейнеры заняты Advent Of Code. Забавная, кстати, штука.

Заняты прямо настолько, чтобы последние несколько месяцев не было возможности оставить комментарии в нескольких простых issue или даже просто расставить в них теги? Нет, что-то здесь не стыкуется.

Как бы то ни было, я создал новый PR, в котором исправлен недочёт с отсутствием проверки на несоответствие тегов между значениями в switch и case (ибо если в тернарных выражениях компилятор может жаловаться на несоответствие тегов, то чем switch/case хуже?). Но готов поспорить, ситуацию это ничуть не изменит и в ближайшие несколько месяцев от мейнтейнеров будет ноль внимания.

[Daniel_Cortez]

Предновогодний "неофициальный" релиз 3.10.9+ с исправлением багов.

Новые изменения (с момента предыдущего неоф. релиза):

• Исправлена проблема с неявным игнорированием тегов в анонимных enum (#454).
  Отдельная благодарность m1n1vv за то, что сообщил о баге (разбор проблемы: 1, 2).
  
  
• Устранён недочёт с отсутствием проверки на несовпадение тегов между выражениями в switch и case (#475).
  Если в тернарных выражениях компилятор жалуется, когда у значений под "?" и ":" разные теги, то чем switch хуже?
  
  
• Немного ускорен процесс компиляции за счёт упрощения алгоритма отсеивания неиспользуемых переменных/констант/функций.

Скачать: https://www.dropbox.com/s/3fa3ak5ewf...fixed.zip?dl=0
Исходный код: https://github.com/Daniel-Cortez/paw...e/master-fixes

[Kovshevoy]

http://prntscr.com/qiew1j
Шо за прыколы
update: fixed http://prntscr.com/qif4g3

[Daniel_Cortez]

update: fixed http://prntscr.com/qif4g3

На самом деле там, по-хорошему, гораздо больше исправлять нужно: https://github.com/Open-GTO/mdialog/...ment-570578335
На выходных, если будет время, попробую подготовить фикс, но ничего обещать не могу.

[vvw]

Так и сделал ты свой форк. =) Для меня твой вариант компилятора становится приоритетнее варианта от Zeex.

[Pa4enka]

Интересно, а возможно ли расширить функционал компилятора до возможности определять повторяющиеся присвоения переменной в определенном блоке кода? Данное предложения похоже на warning 210, ибо так же анализирует код с его логической стороны.

В двух словах о предложении:

stock SetPlayerDefaultInfo(playerid){    // some code     PlayerInfo[playerid][pAdmin] = 0;    PlayerInfo[playerid][pSpawn] = 0;    PlayerInfo[playerid][pLogin] = false;     // ...........     PlayerInfo[playerid][pSpawn] = 1;     return true;}

Как видим, переменной изначально было присвоено правильное значение, а позже, по ошибке разработчика pSpawn установилось значения 1. Согласитесь, в этой ситуации играет людской фактор. Но хорошо, когда разработчик заметит эту ошибку в процессе тестирования. А если же нет? В обоих случаях придется лезть в код и производить дебаг. Это лишнее время и лишние действия. Было бы круто, если компилятор умел видеть и такие ошибки, ведь:

Такой базовый механизм предотвращения ошибок есть во многих других языках. Во многих, но только не в Pawn - языке с максимальным контролем над ошибками, созданном специально для новичков!

[DeimoS]

Интересно, а возможно ли расширить функционал компилятора до возможности определять повторяющиеся присвоения переменной в определенном блоке кода? Данное предложения похоже на warning 210, ибо так же анализирует код с его логической стороны.

В двух словах о предложении:

stock SetPlayerDefaultInfo(playerid){    // some code     PlayerInfo[playerid][pAdmin] = 0;    PlayerInfo[playerid][pSpawn] = 0;    PlayerInfo[playerid][pLogin] = false;     // ...........     PlayerInfo[playerid][pSpawn] = 1;     return true;}

Как видим, переменной изначально было присвоено правильное значение, а позже, по ошибке разработчика pSpawn установилось значения 1. Согласитесь, в этой ситуации играет людской фактор. Но хорошо, когда разработчик заметит эту ошибку в процессе тестирования. А если же нет? В обоих случаях придется лезть в код и производить дебаг. Это лишнее время и лишние действия. Было бы круто, если компилятор умел видеть и такие ошибки, ведь:

А как компилятор должен определять "правильное" значение? Ведь значением по умолчанию не обязательно "0" может быть.