Я часто слышу, что при компиляции программ на C и C ++ я должен «всегда включать предупреждения компилятора». Почему это необходимо? Как я могу это сделать?

Иногда я также слышу, что я должен «воспринимать предупреждения как ошибки». Нужно ли мне? Как я могу это сделать?

Зачем включать предупреждения?

Компиляторы C и C ++, как известно, плохо по умолчанию сообщают о некоторых распространенных ошибках программиста , таких как:

• забыв инициализировать переменную
• забывать returnзначение из функции
• аргументы printfи scanfсемейства, не соответствующие строке формата
• функция используется без предварительного объявления (только C)

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

Как включить предупреждения?

Это зависит от вашего компилятора.

Microsoft C и C ++ компиляторы понимать переключатели нравится /W1, /W2, /W3, /W4и /Wall. Используйте по крайней мере /W3. /W4и /Wallможет выдавать ложные предупреждения для системных заголовочных файлов, но если ваш проект корректно компилируется с помощью одного из этих параметров, сделайте это. Эти параметры являются взаимоисключающими.

Большинство других компиляторов понимают такие опции , как -Wall, -Wpedanticи -Wextra. -Wallявляется необходимым, и все остальные рекомендуются (обратите внимание, что, несмотря на его название, -Wallвключает только самые важные предупреждения, а не все ). Эти параметры можно использовать отдельно или все вместе.

Ваша IDE может иметь возможность включить их из пользовательского интерфейса.

Зачем воспринимать предупреждения как ошибки? Это просто предупреждения!

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

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

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

Как воспринимать предупреждения как ошибки?

Это снова сделано с переключателями компилятора. /WXдля Microsoft, большинство других используют -Werror. В любом случае компиляция не удастся, если появятся какие-либо предупреждения.

C, как известно, является языком довольно низкого уровня, как и HLL. C ++, хотя может показаться, что это язык значительно более высокого уровня, чем C, все же разделяет ряд своих особенностей. И одна из этих черт заключается в том, что языки были разработаны программистами для программистов - и, в частности, программистов, которые знали, что они делают.

[В остальной части этого ответа я собираюсь сосредоточиться на C. Большая часть того, что я скажу, также относится к C ++, хотя, возможно, не так сильно. Хотя, как сказал Бьярн Страуструп, «С позволяет легко выстрелить себе в ногу; С ++ делает это тяжелее, но когда вы делаете это, вырываете ногу целиком». ]

Если вы знаете, что делаете - действительно знаете, что делаете - иногда вам, возможно, придется «нарушать правила». Но большую часть времени большинство из нас согласятся с тем, что благие намерения не дают нам всех проблем, и что бессмысленное нарушение этих правил все время является плохой идеей.

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

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

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

Получается, что в большинстве случаев предупреждения - хорошая идея. Даже опытные программисты узнали (на самом деле, это « особенно опытные программисты узнали»), что в целом предупреждения имеют тенденцию приносить больше пользы, чем вреда. Каждый раз, когда вы умышленно что-то делали неправильно, а предупреждение было неприятным, вероятно, вы, по крайней мере, десять раз делали что-то неправильно, и предупреждение спасало вас от дальнейших неприятностей. И большинство предупреждений можно отключить или обойти для тех немногих случаев, когда вы действительно хотите сделать «не то».

(Классический пример такой «ошибка» является тестом if(a = b)Большой части времени, это ошибка, поэтому большинство компиляторов этих дней предупредят об этом. -. Некоторые даже по умолчанию Но если вы действительно хотели как правопреемник bк aи испытанию В результате вы можете отключить предупреждение, набрав if((a = b)).)

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

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

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

Предупреждения состоят из лучших советов, которые некоторые из наиболее опытных разработчиков C ++ могут испечь в приложении. Их стоит держать рядом.

C ++, будучи полным языком Тьюринга, имеет множество случаев, когда компилятор должен просто поверить, что вы знали, что делаете. Однако во многих случаях компилятор может понять, что вы, вероятно, не намеревались писать то, что написали. Классическим примером являются коды printf (), которые не соответствуют аргументам, или std :: strings, переданные в printf (не то, что когда-либо случалось со мной!). В этих случаях написанный вами код не является ошибкой. Это допустимое выражение C ++ с допустимой интерпретацией для действия компилятора. Но у компилятора есть сильное предчувствие, что вы просто пропустили что-то, что легко обнаруживается современным компилятором. Это предупреждения. Это те вещи, которые очевидны для компилятора, использующего все строгие правила С ++, которые вы могли бы игнорировать.

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

«Рассматривать предупреждения как ошибки» - крайняя версия этой философии. Идея заключается в том, что вы разрешаете каждое предупреждение, которое дает вам компилятор - вы слушаете каждый бесплатный совет и действуете в соответствии с ним. Является ли это хорошей моделью для развития, зависит от команды и от того, над каким продуктом вы работаете. Это аскетический подход, который мог бы иметь монах. Для некоторых это прекрасно работает. Для других это не так.

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

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

Используйте правильный тип, верните это значение, оцените это возвращаемое значение. Потратьте время и подумайте: «Действительно ли это правильный тип в этом контексте?» "Мне нужно вернуть это?" И важная персона; «Будет ли этот код переносимым на следующие 10 лет?»

Привыкайте писать код без предупреждения.

Другие ответы превосходны, и я не хочу повторять то, что они сказали.

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

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

Взять, к примеру, предупреждение лязг -Wswitch-enum . Это вызывает предупреждение, если вы используете переключатель enum и пропускаете одно из возможных значений enum. Вы можете подумать, что это будет маловероятной ошибкой: вы, по крайней мере, смотрели на список значений enum, когда писали оператор switch. У вас может даже быть IDE, которая генерирует параметры переключения для вас, не оставляя места для человеческой ошибки.

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

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

Нефиксированные предупреждения рано или поздно приведут к ошибкам в вашем коде .

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

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

Исправление предупреждения приводит к решению проблемы. Классика!

Демонстрация вышесказанного. Рассмотрим следующий код:

#include <stdio.h>

int main(void) {
  char* str = "Hello world!";
  int idx;

  // Colossal amount of code here, irrelevant to 'idx'

  printf("%c\n", str[idx]);

  return 0;
}

который при компиляции с флагом "Wextra" передается в GCC, дает:

main.c: In function 'main':
main.c:9:21: warning: 'idx' is used uninitialized in this function [-Wuninitialized]
    9 |   printf("%c\n", str[idx]);
      |                     ^

который я мог проигнорировать и выполнить код в любом случае ... И тогда я был бы свидетелем "грандиозной" ошибки сегментации, как говаривал мой профессор IP-эпикура:

Ошибка сегментации

Чтобы отладить это в сценарии реального мира, нужно начать со строки, которая вызывает ошибку сегментации, и попытаться выяснить, в чем причина. Они должны будут искать то, что случилось, iиstr этим колоссальным количеством внутри него. кода там ...

Пока однажды они не оказались в ситуации, когда они обнаруживают, что idx используется неинициализированный, то есть он имеет мусорное значение, что приводит к индексации строки (пути) за ее пределами, что приводит к ошибке сегментации.

Если бы только они не проигнорировали предупреждение, они бы сразу нашли ошибку!

Рассматривать предупреждения как ошибки - это всего лишь средство самодисциплины: вы составляли программу для тестирования этой блестящей новой функции, но не можете, пока не исправите неаккуратные детали. Дополнительной информации нет Werror, просто очень четко расставлены приоритеты:

Не добавляйте новый код, пока не исправите проблемы в существующем коде

На самом деле важно мышление, а не инструменты. Вывод диагностики компилятора является инструментом. MISRA (для встроенного C) - еще один инструмент. Неважно, какой из них вы используете, но, возможно, предупреждения компилятора - это самый простой инструмент, который вы можете получить (это только один флаг для установки), а отношение сигнал / шум очень высокое. Так что нет причин не использовать его.

Ни один инструмент не является непогрешимым. Если вы напишите const float pi = 3.14;, большинство инструментов не скажут вам, что вы определили π с плохой точностью, что может привести к проблемам в будущем. Большинство инструментов не вызывают удивления if(tmp < 42), даже если общеизвестно, что присвоение переменных бессмысленным именам и использование магических чисел - это путь к катастрофе в больших проектах. Вы должны понимать, что любой код «быстрого тестирования», который вы пишете, - это просто тест, и вы должны получить его прямо перед тем, как переходить к другим задачам, в то время как вы по-прежнему видите его недостатки. Если вы оставите эти коды как есть, отладка, если по истечении двух месяцев добавление новых функций будет значительно сложнее.

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

Как человек, работающий с унаследованным встроенным кодом C, включение предупреждений компилятора помогло выявить множество недостатков и областей, которые необходимо изучить при предложении исправлений. В GCC использование -Wallи -Wextraдаже -Wshadowстали жизненно важными. Я не собираюсь вдаваться в каждую опасность, но перечислю несколько всплывающих, которые помогли показать проблемы с кодом.

Переменные, оставленные позади

Это можно легко указать на незавершенную работу и области, которые могут не использовать все переданные переменные, которые могут быть проблемой. Давайте посмотрим на простую функцию, которая может вызвать это:

int foo(int a, int b)
{
   int c = 0;

   if (a > 0)
   {
        return a;
   }
   return 0;
}

Просто компилирование без -Wall или -Wextra не возвращает никаких проблем. -Все скажет вам, хотя это cникогда не используется:

foo.c: в функции 'foo':

foo.c: 9: 20: предупреждение: неиспользуемая переменная 'c' [-Wunused-variable]

-Wextra также скажет вам, что ваш параметр b ничего не делает:

foo.c: в функции 'foo':

foo.c: 9: 20: предупреждение: неиспользуемая переменная 'c' [-Wunused-variable]

foo.c: 7: 20: предупреждение: неиспользуемый параметр 'b' [-Wunused-параметр] int foo (int a, int b)

Затенение глобальной переменной

Это немного сложно и не показывалось, пока не -Wshadowбыло использовано. Давайте изменим приведенный выше пример, добавив его, но в результате получается глобальный объект с тем же именем, что и локальный, что вызывает путаницу при попытке использовать оба варианта.

int c = 7;

int foo(int a, int b)
{
   int c = a + b;
   return c;
}

Когда -Wshadow был включен, легко обнаружить эту проблему.

foo.c: 11: 9: предупреждение: объявление 'c' затеняет глобальное объявление [-Wshadow]

foo.c: 1: 5: note: теневое объявление здесь

Формат строки

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

void foo(const char * str)
{
    printf("str = %d\n", str);
}

Это не печатает строку, так как флаг форматирования неверен, и gcc с радостью скажет вам, что это, вероятно, не то, что вы хотели:

foo.c: в функции 'foo':

foo.c: 10: 12: предупреждение: формат «% d» ожидает аргумент типа «int», но аргумент 2 имеет тип «const char *» [-Wformat =]

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

Это конкретный ответ для C, и почему это гораздо важнее для C, чем для чего-либо еще.

#include <stdio.h>
int main()
{
   FILE *fp = "some string";
}

Этот код компилируется с предупреждением . То, что есть и должно быть ошибками практически во всех других языках на планете (за исключением языка ассемблера), является предупреждением на C. Предупреждения на C почти всегда являются замаскированными ошибками. Предупреждения должны быть исправлены, а не подавлены.

С gcc, мы делаем это как gcc -Wall -Werror.

Это также стало причиной высокой вероятности некоторых предупреждений небезопасных API MS. Большинство людей, программирующих на C, научились жестко относиться к предупреждениям как к ошибкам, и казалось, что это не совсем то же самое, и им нужны непереносимые исправления.

ПРЕДУПРЕЖДЕНИЯ КОМПИЛЕРА - ВАШ ДРУГ (не кричите, прописные буквы для акцента).

Я работаю на устаревших системах Fortran-77. Компилятор говорит мне ценные вещи: несоответствие типа данных аргумента при вызове подпрограммы с использованием локальной переменной до того, как значение было установлено в переменную, если у меня есть переменная или аргумент подпрограммы, которые не используются. Это почти всегда ошибки.

Избегайте длинных постов: когда мой код компилируется правильно, 97% работает. Другой парень, с которым я работаю, компилирует все предупреждения, проводит часы или дни в отладчике, а затем просит меня помочь. Я просто скомпилировал его код с предупреждениями и сказал ему, что нужно исправить.

Вы должны всегда включать предупреждения компилятора, потому что компилятор часто может сказать вам, что не так с вашим кодом. Для этого вы переходите -Wall -Wextraк компилятору.

Обычно вы должны воспринимать предупреждения как ошибки, потому что предупреждения обычно означают, что с вашим кодом что-то не так. Однако часто очень легко игнорировать эти ошибки. Поэтому обработка их как ошибок приведет к сбою сборки, поэтому вы не сможете игнорировать ошибки. Чтобы воспринимать предупреждения как ошибки, перейдите -Werrorк компилятору.

Предупреждения компилятора в C ++ очень полезны по ряду причин.

1 - Это позволяет показать вам, где вы могли совершить ошибку, которая может повлиять на конечный результат вашей работы. Например, если вы не инициализировали переменную или вы поставили «=» вместо «==» (есть только примеры)

2 - Позволяет также показать вам, где ваш код не соответствует стандарту C ++. Это полезно, потому что, если код соответствует действующему стандарту, будет легко переместить код, например, в другую табличную форму.

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

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

Однажды я работал в крупной (Fortune 50) компании, которая производила электронное испытательное оборудование.

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

Это ужасный кошмар, когда появляются ошибки.

После этой должности мне посчастливилось быть первым разработчиком в новом стартапе.

Я рекомендовал политику «без предупреждения» для всех сборок, когда уровни предупреждений компилятора были довольно шумными.

Наша практика заключалась в том, чтобы использовать предупреждение #pragma - push / disable / pop для кода, который был уверен, что разработчик был действительно хорош, вместе с оператором log на уровне отладки, на всякий случай.

Эта практика хорошо сработала для нас.

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

Существует только одна проблема с обработкой предупреждений как с ошибками: когда вы используете код, поступающий из других источников (например, микро $ ** t-библиотек, проектов с открытым исходным кодом), они не справились со своей работой правильно, а компиляция их кода генерирует тонны предупреждений.

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

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

Некоторое предупреждение может означать возможную семантическую ошибку в коде или возможный UB. Например, ;после if(), неиспользуемая переменная, глобальная переменная, маскируемая локальным, или сравнение со знаком и без знака. Многие предупреждения связаны со статическим анализатором кода в компиляторе или с нарушениями стандарта ISO, обнаруживаемыми во время компиляции, которые «требуют диагностики». Хотя эти случаи могут быть законными в одном конкретном случае, в большинстве случаев они будут результатом проблем проектирования.

Некоторые компиляторы, например, gcc, имеют опцию командной строки для активации режима «предупреждения как ошибки», это хороший, хотя и жестокий инструмент для обучения начинающих программистов.

Тот факт, что компиляторы C ++ принимают код компиляции, который, очевидно, приводит к неопределенному поведению вообще является основным недостатком в составителей. Причина, по которой они этого не исправляют, заключается в том, что это может привести к поломке некоторых полезных сборок.

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

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

-> инициализация переменной будет забыта -> вернуть значение из функции пропущено -> простые аргументы в семействах printf и scanf, не соответствующие строке формата, которую функция использует без предварительного объявления, хотя это происходит только в c

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

Полегче: вам не нужно, это не нужно. -Wall и -Werror были разработаны маньяками-рефакторингами кода для себя: они были изобретены разработчиками компилятора, чтобы избежать разрушения существующих сборок после обновления компилятора на стороне пользователя . Особенностью является ничто, но все о решении сломать или не сломать сборку.

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