Компилятор C # не сообщает обо всех ошибках сразу при каждой компиляции?

Question

Когда я компилирую этот проект, в окне списка ошибок отображается более 400 ошибок, затем я захожу на сайты с ошибками, исправляю некоторые из них, и число переходит к 120+ ошибкам, а затем после исправления некоторых ошибок Следующие отчеты компиляции, как 400+ снова. Я вижу, что в окне списка ошибок появляются разные файлы, поэтому я думаю, что компилятор прерывает работу после определенного числа ошибок?

Если так, то в чем причина? Разве не предполагается собрать все ошибки, присутствующие в проекте, даже если они превышают 10K +?

Answer 1

Я хотел написать статью об этом в блоге.

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

Существует много эвристик в компиляторе командной строки и компиляторе IDE, которые пытаются управлять сообщениями об ошибках. И для того, чтобы он был управляемым для пользователя, и для повышения надежности компилятора.

Вкратце, компилятор работает так, как он пытается пройти программу через серию этапов, о которых вы можете прочитать здесь:

http://blogs.msdn.com/b/ericlippert/archive/2010/02/04/how-many-passes.aspx

Идея состоит в том, что если на ранней стадии возникнет ошибка, мы не сможем успешно завершить более позднюю стадию без (1) перехода в бесконечный цикл, (2) сбоя или (3) сообщения о сумасшедшем «каскадировании» ошибки. Итак, что происходит, вы получаете одну ошибку, исправляете ее, а затем неожиданно запускается следующий этап компиляции, и он обнаруживает еще кучу ошибок.

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

Положительным моментом этого дизайна является то, что (1) вы получаете ошибки, которые являются наиболее «фундаментальными», во-первых, без большого количества шумных, сумасшедших каскадных ошибок, и (2) компилятор более устойчив, потому что он не Я должен попытаться провести анализ программ, в которых нарушены основные инварианты языка. Обратной стороной, конечно, является ваш сценарий: у вас пятьдесят ошибок, вы исправляете их все, и внезапно появляются еще пятьдесят ошибок.

Answer 2

Конечно, это остановится в какой-то момент.

Даже после 1 ошибки все остальное в лучшем случае сомнительно. Компилятор попытается восстановить силы, но это не гарантирует успеха.

Так что в любом нетривиальном проекте это практическое решение между остановкой на первой ошибке (теоретически лучшее, что нужно сделать) и вспашкой в ​​ненадежном состоянии.

Наиболее правильным действием будет остановка после 1 ошибки, но это приведет к утомительной ситуации «исправить 1 за один раз». Таким образом, компилятор пытается выполнить повторную синхронизацию с известным состоянием и сообщить о следующем. Но ошибка может привести к ложным ошибкам в правильном коде, который следует за ним, поэтому в какой-то момент он перестает быть разумным.

Обратитесь к вашему собственному случаю: 400+ переходит к 120 после нескольких исправлений.

Answer 3

Настраивается в соответствии с MSDN

По умолчанию максимальное число составляет 200 ошибок и предупреждений.