Jshint: Désactivation de l'avertissement pour W100 ne fonctionnant pas dans 2.9.3

Merci pour le rapport ! Il s'agit bien d'une régression.

Non pas que cela vous aide beaucoup, mais il semble que la nouvelle version ait fait surface un bogue existant précédemment - dans le processus de réduction de l'entrée que vous avez partagée, j'ai également pu rencontrer ce problème dans la version 2.9.2.

Je dois m'éloigner un peu, mais j'espère avoir un patch prêt ce soir (EST).

Voici l'histoire :

Lors de la rencontre d'un caractère de parenthèse ouverte ( ( ) dans une expression
position, un analyseur JavaScript compatible ES2015 comme celui de JSHint doit déterminer
s'il marque le début d'un opérateur de regroupement ou d'une fonction fléchée.

JSHint le fait en tokenisant toutes les entrées qui suivent jusqu'à ce qu'il trouve un
caractère de parenthèse fermant "correspondant" ( ) ). À ce stade, cela peut faire un
détermination quant à la nature de la production en question - si elle est suivie
par le jeton => , c'est une fonction fléchée ; sinon, c'est un opérateur de regroupement.

Tant qu'il anticipe, il n'applique pas les directives en ligne qu'il rencontre
comme -W100 . Cependant, le lexer est responsable de l'émission de certains peluches
erreurs _incluant_ W100 . Ainsi, dès que JSHint commence à "anticiper", son
le comportement en réponse à ces personnages potentiellement dangereux est "verrouillé".
(Cela suggère une solution à court terme pour toute personne souffrant de cette régression : désactiver
W100 avant l'IIFE. Pas idéal, je sais, mais notez que la pertinence de celal'avertissement est contesté .)

Cette régression est due à un patch apparemment sans rapport : gh-3003.
Auparavant, l'anticipation était annulée si un jeton point-virgule était
rencontré, comme dans :

(function() {
;//<-- lookahead ends at this semicolon token
}());

... cependant, cela s'est avéré être une heuristique invalide car la fonction de flèche
les paramètres peuvent eux-mêmes contenir ce jeton :

(x = function() {
;//<-- lookahead should *not* end at this semicolon token
}) => x;

Nous l'avons donc supprimé afin de reconnaître correctement les fonctions fléchées dans ces cas.

Dans cet esprit, le cas de test entièrement réduit peut être un peu plus clair (c'est-à-dire
est un caractère non imprimable \u200f dans le littéral de chaîne) :

(function() {
    ;

    /*jshint -W100 */
    "‏";
})();

Avant gh-3003 (par exemple JSHint à la version 2.9.2), le point-virgule arrêtait le
à l'avance, et le caractère non imprimable ne serait pas lexique avant _après_ le
La directive JSHint a été appliquée. Avec le correctif appliqué, JSHint lexe le caractère
_avant_ d'appliquer la directive et procède à l'avertissement.

Cela montre également comment le problème fondamental existe même dans JSHint 2.9.2.
L'entrée suivante déclenche de manière incorrecte un avertissement même dans cette version de
JSHint :

(function() {
    /*jshint -W100 */
    "‏";
})();

Parce qu'ici, l'anticipation déclenchée par des parenthèses n'est interrompue ni dans
version.

La solution idéale serait d'appliquer des directives lors de l'anticipation. Malheureusement, à cause
à la nature très flexible des directives en ligne de JSHint, ce n'est pas
possible. Les utilisateurs s'attendent à ce que les directives aient une "portée de fonction", ce qui signifie que le lexer
aurait besoin d'être conscient de la sémantique environnante des jetons qu'il produit.

J'ai soumis un correctif ici: gh-3016. À long terme, je pense que nous devrions envisager
autres améliorations de l'heuristique d'anticipation - sans le point-virgule (invalide)
vérifier, la pratique courante d'envelopper des programmes entiers dans un IIFE entraînera
JSHint pour lexer initialement toutes les entrées.

Merci pour l'explication détaillée!
Je vois à quel point cela peut être délicat sans ajouter une immense quantité de travail supplémentaire pour les portées.
Nous nous en tiendrons à 2.9.2 pendant un certain temps car cela fonctionne pour nos fichiers et nous chercherons à décomposer les parties problématiques en blocs que nous pourrons gérer à l'avenir :)

Le correctif de ce bogue est désormais disponible dans la version 2.9.4 de JSHint récemment publiée :

http://jshint.com/blog/2016-10-20/release-2-9-4/

S'il vous plaît laissez-nous savoir si vous rencontrez toujours des problèmes avec cette version!