PowerShell / PowerShell/PSScriptAnalyzer

New Rule Suggestion: unreachable code,

Ouverte
#395 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Issue - New Rule Up-for-Grabs
Langage dominant
C#
Étoiles
2.2k
Forks
414
Merge moyen
13 h 1 min
PR mergées (30 j)
2

Description

Normally, anything after a break or return is unreachable code.

However, it's also possible to have a label after a break, but if you make a mistake typing it, then it's just treated as "anything after a break" and therefore doesn't cause an error.

For example, see this example code full of problems:

:first foreach($i in 0..10) {
    $i *= 10
    Write-Verbose "Imagine we did stuff with $i"
    :mid foreach($j in 0..9) {
        Write-Verbose "Imagine we did stuff with $($i+$j)"
        :inner foreach($k in 0..9) {
            Write-Verbose "Imagine we did stuff with $($i+$j).$k"

            if($k -eq $j) {
                Write-Warning "Peaked at $($i+$j).$k"
                break :mid  # common mistake, will cause no error, acts like a break with no label
                this code is unreachable
            }

           if($k -gt $i) {
                Write-Warning "Ended at $($i+$j).$k"
                break top # uncommon mistake, also no error, breaks out of all loops
           }
       }
    }
}

return

Since this code never runs...
You could write anything that parses like a command and get no errors.

So, my suggestion:

First of all, flag unreachable code.

If there's code after a break or continue or return ... that merits a warning (or information, or something).

Most importantly, flag possible bad labels.

Any time break is followed on the same line by something that is not a comment ... that something should match the name of one of the labels, sans-punctuation.of any sort.

It's possible you could write break top without a corresponding :top label, but it's a bad idea.

Other than that, there's no valid reason why someone would exploit the inconsistency of the language parser here and use punctuation or something like break -this is a comment ...

This should be an error I think, because it's almost guaranteed to be a mistake.

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Utilisez les exemples PowerShell de l’issue comme cas de comportement : les instructions inatteignables après break, continue ou return doivent être signalées, et les labels qui suivent break doivent être validés par rapport aux labels déclarés. Examinez les points d’entrée des règles et les tests existants de l’analyseur afin de déterminer où doivent se situer le contrôle de flux et la gestion des labels ; le travail est terminé lorsque les deux types d’erreur reçoivent le diagnostic attendu sans faux positifs.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
powershell
Domaine
devtools
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
Plutôt claire
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.