Когда уже компилятор обновят? Есть инфа какая-нибудь? Столько исправлений на гите уже, почему они тянут?
Вид для печати
Когда уже компилятор обновят? Есть инфа какая-нибудь? Столько исправлений на гите уже, почему они тянут?
Пока что от мейнтейнеров проекта не было никаких официальных заявлений на счёт нового релиза. Как я уже говорил раньше, можете потерроризировать их этим вопросом в репо на GitHub :)
Заняты прямо настолько, чтобы последние несколько месяцев не было возможности оставить комментарии в нескольких простых issue или даже просто расставить в них теги? Нет, что-то здесь не стыкуется.
Как бы то ни было, я создал новый PR, в котором исправлен недочёт с отсутствием проверки на несоответствие тегов между значениями в switch и case (ибо если в тернарных выражениях компилятор может жаловаться на несоответствие тегов, то чем switch/case хуже?). Но готов поспорить, ситуацию это ничуть не изменит и в ближайшие несколько месяцев от мейнтейнеров будет ноль внимания.
Предновогодний "неофициальный" релиз 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
http://prntscr.com/qiew1j
Шо за прыколы
update: fixed http://prntscr.com/qif4g3
На самом деле там, по-хорошему, гораздо больше исправлять нужно: https://github.com/Open-GTO/mdialog/...ment-570578335
На выходных, если будет время, попробую подготовить фикс, но ничего обещать не могу.
Так и сделал ты свой форк. =) Для меня твой вариант компилятора становится приоритетнее варианта от Zeex.
Интересно, а возможно ли расширить функционал компилятора до возможности определять повторяющиеся присвоения переменной в определенном блоке кода? Данное предложения похоже на 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. Согласитесь, в этой ситуации играет людской фактор. Но хорошо, когда разработчик заметит эту ошибку в процессе тестирования. А если же нет? В обоих случаях придется лезть в код и производить дебаг. Это лишнее время и лишние действия. Было бы круто, если компилятор умел видеть и такие ошибки, ведь: