VD>Мы можем:
VD>1. Выдать сообщение вроде "В процессе распознавания комментария обнаружен неожиданный конец файла" и записать вес от "/*" и до конца файла в тело комментария.

VD>2. Выдать сообщение "Обнаружена некорреткная последовательность '/*'" и продолжить парсить код так как будто "/*" не было вовсе.

3. Выдать сообщение "Обнаружена некорреткная последовательность '/*'" и продолжить парсить код так как будто "/*" не было вовсе. И в в самом конце зафэйлить компиляцию. Профит — сразу обнаружим все (или большинство) синтаксические ошибки..

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

Z>>Для начала лучше всего будет самый простой и предсказуемый вариант. Переделать по сложному никогда не поздно. Дополнительные эвристики могут потом начать вылазить в самых неожиданных местах самым неожиданным образом.

VD>С точки зрения сложности разницы нет. Это вопрос интерпретации/алгоритма.

Как сказать. Одна поставленная непарная скобка может заставить парсер игнорировать совершенно невинную скобку в другом конце файла, что может привести к неразберихе. Мы ведь точно можем только сказать, что они не парные, а какой скобке нет пары могут быть разные предположения.

Здравствуйте, VladD2, Вы писали:
VD>Большинство компиляторов скажут что в конце файла ожидается "*/", т.е. комментарий не закрыт.
VD>Но в принципе тут можно восстановиться записав "/*" в грязь (т.е. проигнорировать начало комментария).
VD>Какой вариант по вашему лучше? И какие подводные грабли тут могут возникнуть?
я когда был маленький, то думал, что компилятор должен сам уметь за меня ошибки исправлять. типа я понапишу че-нить, он мне сам все поправит чтобы корректно было и у меня все заработает
но когда я вырос я понял, что единственное что мне надо от компилятора это указание места ошибки. мне даже текста не нужно, и так сразу все бывает понятно.
не должен компилятор самодеятельностью заниматься.

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

Z>Как сказать. Одна поставленная непарная скобка может заставить парсер игнорировать совершенно невинную скобку в другом конце файла, что может привести к неразберихе. Мы ведь точно можем только сказать, что они не парные, а какой скобке нет пары могут быть разные предположения.

Мы на уровне скобок не оперируем. Но думаю, что удастся создать очень приличную систему автоматического восстановления после ошибок.

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

__>но когда я вырос я понял, что единственное что мне надо от компилятора это указание места ошибки. мне даже текста не нужно, и так сразу все бывает понятно.
С этим согласен.
Но нужно не забывать, что от точности восстановления зависит правильность ошибки.

__>не должен компилятор самодеятельностью заниматься.
Есть такой недокомпилятор, IDE называется. Так вот, он должен.

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

VD>У нас просто есть такая возможность. Наш генератор парсеров генерирует безлексерные парсеры и мы можем восстанавливать парсер сильно хитрее чем это делают лексерные парсеры. Но стоит ли это делать?

В конкретном исходном примере с многострочным комментарием в си-подобном коде — IMHO не стоит. Мало ли, что там было закоментировано и ко скольким еще левым ошибкам парсинга это приведет. Особенно, если в комментарии будет нечто, влияющее на процесс парсинга (синтаксический макрос, например или там, pragma какая-нибудь). В общем же случае, это сделать стоит, но исключительно в качестве опциональной фичи генерируемых парсеров. Пример языков, где это совершенно точно будет к месту — любое подмножество SGML, например.

Про парсинг в режиме IDE уже сказали выше.

P.S: А если эту фичу можно будет еще и включать/выключать только для определенных правил грамматики — будет совсем здорово (для моих задач )

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

VD>Большинство компиляторов скажут что в конце файла ожидается "*/", т.е. комментарий не закрыт.

VD>Какой вариант по вашему лучше? И какие подводные грабли тут могут возникнуть?

Самое гуманное — показать проблему в месте её возникновения — т.е. там где коментарий открывается.

Иначе получишь JavaScript в котором compiler делает semicolon insertion автоматически.
В результате получается токой вот кунштюк:

return
  a + b;
 
// Returns undefined. Treated as:
//   return;
//     a + b;

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

CS>Самое гуманное — показать проблему в месте её возникновения — т.е. там где коментарий открывается.

Согласен. Сообщение по любому будет на "/*".

CS>Иначе получишь JavaScript в котором compiler делает semicolon insertion автоматически.
CS>В результате получается токой вот кунштюк:
CS>

CS>return
CS>  a + b;
CS>

Да. Смешно. Но это уже область ответственности авторов языка. Мы только предоставляем механизм автоматического восстановления. А в данном случае код корректен.

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

VD> /*
VD>Большинство компиляторов скажут что в конце файла ожидается "*/", т.е. комментарий не закрыт.
VD>Но в принципе тут можно восстановиться записав "/*" в грязь (т.е. проигнорировать начало комментария).

Я всё равно не понял какие ещё могут быть альтернативы. Если коммент не закрыт, парсер должен ткнуть юзера в ОТКРЫВАЮЩИЙ тег и остановиться с ошибкой. Что помимо этого можно придумать??

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

VD>Мы можем:
VD>1. Выдать сообщение вроде "В процессе распознавания комментария обнаружен неожиданный конец файла" и записать вес от "/*" и до конца файла в тело комментария.

VD>2. Выдать сообщение "Обнаружена некорреткная последовательность '/*'" и продолжить парсить код так как будто "/*" не было вовсе.

А второй подход ничего не даст, т.к. за "/*" обычно следует собственно коментарий, парсинг которого приведет к миллиону неиформативных сообщений об ошибках, ковыряться в которох не самое приятное занятие. Т.е. программист все равно исправит отсутствие "*/" и перезапустит компиляцию.

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

ML>А второй подход ничего не даст, т.к. за "/*" обычно следует собственно коментарий, парсинг которого приведет к миллиону неиформативных сообщений об ошибках, ковыряться в которох не самое приятное занятие. Т.е. программист все равно исправит отсутствие "*/" и перезапустит компиляцию.

В некоторых случаях за /* будет вполне корректный код, так как комментарий вписывается в корректный код. Но, согласен, част будет случай когда смысла у идущего следом кода не будет.

VD>В некоторых случаях за /* будет вполне корректный код, так как комментарий вписывается в корректный код. Но, согласен, част будет случай когда смысла у идущего следом кода не будет.

Может посмотреть в сторону TagSoup для HTML? Нагородить эвристик что где должно закрываться и выдавать мягкие подсказки. В данном случае компилятор может предположить что комментарий в большинстве случаев закрывается перед определением функции, и если его таки закрыть — то получается валидный код — значит можно выдать не только ошибку, но и подсказку.

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


VD>Большинство компиляторов скажут что в конце файла ожидается "*/", т.е. комментарий не закрыт.
То есть, дойдут до конца файла и завершат работу.

VD>Но в принципе тут можно восстановиться записав "/*" в грязь (т.е. проигнорировать начало комментария).
Но тогда нужен еще один проход?

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

VD>Большинство компиляторов скажут что в конце файла ожидается "*/", т.е. комментарий не закрыт.
VD>Но в принципе тут можно восстановиться записав "/*" в грязь (т.е. проигнорировать начало комментария).
VD>Какой вариант по вашему лучше? И какие подводные грабли тут могут возникнуть?

Для именно данной конкретной ошибки дополнительные эвристики особо не нужны, т.к. не сильно помогут. Подсветка кода тебе и так сразу покажет, что у тебя не так. Если же пытаться игнорировать /* и компилировать все, что после него, то, скорее всего, дело закончится кучей ошибок, которые возникнут при попытке скомпилировать комментарии. Зачем?

Лучше делать хорошие умные эвристики на незакрытые скобочки.

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

VD>>Но в принципе тут можно восстановиться записав "/*" в грязь (т.е. проигнорировать начало комментария).
_>Но тогда нужен еще один проход?

Нет. Не нужен. Просто чуть-чуть иной алгоритм. Когда мы доходим до этого места, то парсер падает на всех имеющихся правилах. Далее мы тупо пропускаем по одному символу и пытаемся парситься дальше. После пропуска двух символов мы встречаем разумное продолжение и продолжаем парсинг. В итогде /* записываются в мусор и как бы игнорируются парсером.

VD>Какой вариант по вашему лучше? И какие подводные грабли тут могут возникнуть?
В описании синтаксиса языка комментарии должны быть закрыты. А компилятор должен соответствовать описанию. Так что надо выдавать ошибку.
В идеале, он должен сообщить в ошибке не только что ждет в конце файла закрытия комментария. Хорошо бы дополнить сообщением местом, где он открыт.

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


VD>

VD>class A
VD>{
VD>  /*
VD>  void Foo()
VD>  {
VD>  }
VD>}
VD>

VD>Какой вариант по вашему лучше? И какие подводные грабли тут могут возникнуть?

компилер должен ткнуть в открывающий комментарий и остальное не парсить.
в случае IDE, всё, что после начала комментария распознавать как комментарий

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

VD>Всем привет.

VD>Предположим у нас есть следующий код:

VD>

VD>class A
VD>{
VD>  /*
VD>  void Foo()
VD>  {
VD>  }
VD>}
VD>

VD>Большинство компиляторов скажут что в конце файла ожидается "*/", т.е. комментарий не закрыт.

VD>Но в принципе тут можно восстановиться записав "/*" в грязь (т.е. проигнорировать начало комментария).

VD>Какой вариант по вашему лучше? И какие подводные грабли тут могут возникнуть?

Означает ли первый вариант реализации, что после незакрытого комментария сломается расцветка кода и автокомплит? Если это относится только к незакрытому комментарию, то фиг с ним, пусть ломается — так даже проще будет найти строчку с ошибкой. Но если автокомплит будет ломаться после любой строчки с недописанным кодом, то мне будет неудобно. Поэтому наверное стоит рассмотреть как можно больше конкретных ситуаций и выбрать поведение для каждого из них.

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

MTD>Мне — человеку, проще чтобы меня ткнули носом в незакрытый комментарий, чем выдали 100 наведенных ошибок из которых мне самому пришлось бы делать вывод, что нужно сделать.

У турбо-паскаля было именно такое поведение: тыкал носом в первую встреченную ошибку, а не выдавал 100 наведённых.
Офигительно "удобно", сто попыток перекомпиляции, пока каждую ошибку не исправишь.

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

TSP>В описании синтаксиса языка комментарии должны быть закрыты. А компилятор должен соответствовать описанию. Так что надо выдавать ошибку.

Он её и выдаст, в виде exitcode 1, так что билд-система (make, vcbuid, ant, etc.) остановятся.
Но это интерфейс к билд-системе. А речь идёт об интерфейсе к человеку.