Должна ли быть диагностика от компилятора GCC для этого плохо сформированного кода C++ с использованием атрибута [[fallout]]?

Я тестировал функции C++ 17 в компиляторе GCC версии 7.1.0. Это связано с атрибутом fallthrough и следующий пример (живой пример) адаптирован из онлайн-ссылки CPP здесь

#include "iostream"
using namespace std;

int f(int n) {

  switch (n) {
    case 1:
    case 2:
      n = n + 20;
     [[fallthrough]];
    case 3: // no warning on fallthrough      
      n = n + 30;
    case 4: // compiler may warn on fallthrough      
      [[fallthrough]]; // ill­formed, not before a case label
      //n = n + 40;  //commented out to test if compiler will warn.
  }
  return n;
}    

int main()
{
    cout << f(1) << endl;
    cout << f(2) << endl;
    cout << f(3) << endl;
    cout << f(4) << endl;
    return 0;
}

Последний [[fallthrough]] (для case 4: [[fallthrough]] плохо сформирован.

Вопрос о том, "Что компилятор C++ должен делать с плохо сформированными программами в соответствии со стандартом?" здесь есть главный ответ, в котором говорится, что:

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

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

Интересно, что после всего этого, когда я добавил следующий оператор после последнего [[fallthrough]]

n = n + 40;

компилятор предупреждает (живой пример):

warning: атрибут 'fallthrough', не предшествующий ярлыку case или метке по умолчанию

Итак, два вопроса:

  1. Прокомментировал ли компилятор диагностику, или я что-то упустил?
  2. Если это проблема с компилятором, достаточно ли этого достаточно для сообщения?

Ответы

Ответ 1

  1. Если это проблема с компилятором, достаточно ли этого достаточно для сообщения?

Да, ошибки соответствия являются важными ошибками, разработчики полагаются на компиляторы, соответствующие стандарту (у компилятора могут быть режимы, которые не требуют строгого соответствия, хотя, например, gcc требует -pedantic для получения всех диагностических данных, требуемых стандартом). В какой приоритете возникает ошибка другая история, но только документирование ошибки и наличие команды компилятора признают ее как ошибку, может быть огромной помощью для будущих разработчиков, которые сталкиваются с ошибкой.

  1. Прокомментировал ли компилятор диагностику, или я что-то упустил?

Да, это плохо сформировано в соответствии с [dcl.attr.fallthrough #] p1:

... Следующее утверждение, которое будет выполняться после инструкции fallthrough, должно быть обозначенным оператором, ярлыком которого является метка case или метка по умолчанию для одного и того же оператора switch. Программа плохо сформирована, если такого утверждения нет.

и компилятор должен выдавать по крайней мере диагностику в соответствии с [intro.compliance] p2.2:

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

Ответ 2

Когда-то после того, как я опубликовал этот вопрос, ошибка была сообщена по этому вопросу.
Я ждал, будет ли это принято. Он был принят и назначен, и на основе этого комментария в отчете об ошибке будет создан патч. Так что это эффективно отвечает на мои вопросы.

Тем не менее, я согласен с ответом, данным @ShafikYaghmour, потому что он содержит важные моменты, касающиеся моих вопросов.