web-dev-qa-db-fra.com

Devrait-il y avoir un diagnostic du compilateur GCC pour ce code C++ mal formé impliquant l'attribut [[fallthrough]]?

Je testais les fonctionnalités C++ 17 sur la version 7.1.0 du compilateur GCC. Ceci est lié à l'attribut fallthrough et l'exemple suivant ( exemple live ) est adapté de la référence en ligne CPP ici 

#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;
}

Le dernier [[fallthrough]] (pour case 4:) est mal formé. 

La question "Qu'est-ce que le compilateur C++ doit faire avec les programmes mal formés conformément à la norme?" ici a le haut de page réponse indiquant que: 

Donc, pour résumer: si un programme mal formé contient une violation pouvant être diagnostiquée pour laquelle le Standard ne spécifie pas explicitement "aucun diagnostic requis", les implémentations conformes doivent émettre un diagnostic.

J'ai donc consulté la norme (N4713) pour voir si elle indiquait qu'aucun diagnostic n'était requis pour ce problème. Je n'ai pas pu trouver une telle déclaration. 

Fait intéressant, après tout cela, lorsque j'ai ajouté l'instruction suivante après le dernier [[fallthrough]] 

n = n + 40;

le compilateur avertit ( exemple en direct ): 

warning: attribut 'fallthrough' ne précédant pas une étiquette de cas ou une étiquette par défaut

Donc, deux questions ici: 

  1. Le compilateur a-t-il oublié d'émettre un diagnostic ou me manque-t-il quelque chose ici? 
  2. S'il s'agit d'un problème de compilateur, est-il suffisamment grave pour être signalé?
c++gccc++17gcc-warningfall-through
12
P.W
  1. S'il s'agit d'un problème de compilateur, est-il suffisamment grave pour être signalé?

Oui, les bogues de conformité sont des bogues importants, les développeurs s’appuyant sur des compilateurs conformes à la norme (le compilateur peut avoir des modes ne nécessitant pas de conformité stricte bien que c’est-à-dire que gcc nécessite -pedantic pour obtenir tous les diagnostics requis par la norme ) la priorité d'un bogue est une histoire différente, mais le documenter et le faire reconnaître par l'équipe du compilateur comme bogue peut être d'une grande aide pour les futurs développeurs qui rencontrent le bogue.

  1. Est-ce que le compilateur a manqué d'émettre un diagnostic ou est-ce que je manque quelque chose ici? 

Oui, cela est mal formé selon (dcl.attr.fallthrough #] p1 :

... La prochaine instruction qui serait exécutée après une instruction fallthrough doit être une instruction étiquetée dont l'étiquette est une étiquette de cas ou une étiquette par défaut pour la même instruction switch. Le programme est mal formé s'il n'y a pas une telle déclaration.

et le compilateur doit émettre au moins un diagnostic conformément à (intro.compliance] p2.2 :

Si un programme contient une violation d'une règle pouvant être diagnostiquée ou l'occurrence d'une construction décrite dans ce document comme «pris en charge sous condition» lorsque l'implémentation ne prend pas en charge cette construction, une mise en œuvre conforme émettra au moins un message de diagnostic.

9
Shafik Yaghmour

Quelque temps après avoir posté cette question, un bug a été signalé sur la base de la question.
J'ai attendu de voir si cela serait accepté. C'était accepté et attribué, et basé sur ce commentaire dans le rapport de bogue, un correctif va être généré. Donc, cela répond efficacement à mes deux questions. 

Cependant, j'accepterai la réponse donnée par @ShafikYaghmour car elle contient des points importants répondant à mes questions.

3
P.W