Jshint: Menonaktifkan peringatan untuk W100 tidak berfungsi di 2.9.3

Terima kasih atas laporannya! Ini memang sebuah regresi.

Bukannya itu banyak membantu Anda, tetapi sepertinya rilis baru telah memunculkan bug yang sudah ada sebelumnya--dalam proses mengurangi input yang Anda bagikan, saya juga dapat mengalami masalah ini di versi 2.9.2.

Saya perlu menjauh sebentar, tetapi saya berharap patch siap malam ini (EST).

Berikut ceritanya:

Setelah menemukan karakter kurung terbuka ( ( ) dalam ekspresi
posisi, parser JavaScript yang sadar ES2015 seperti JSHint's harus menentukan
apakah itu menandai awal dari operator pengelompokan atau fungsi panah.

JSHint melakukan ini dengan menandai semua input yang mengikuti hingga menemukan a
karakter kurung tutup "cocok" ( ) ). Pada saat itu, itu bisa membuat
penentuan tentang sifat produksi yang bersangkutan--jika diikuti
dengan token => , ini adalah fungsi panah; jika tidak, ini adalah operator pengelompokan.

Saat melihat ke depan, itu tidak menerapkan arahan in-line yang ditemuinya
seperti -W100 . Namun, lexer bertanggung jawab untuk memancarkan serat tertentu
kesalahan _termasuk_ W100 . Jadi segera setelah JSHint mulai "melihat ke depan", itu
perilaku dalam menanggapi karakter yang berpotensi berbahaya ini "terkunci".
(Itu menunjukkan perbaikan jangka pendek bagi siapa saja yang menderita regresi ini: nonaktifkan
W100 sebelum IIFE. Tidak ideal, saya tahu, tetapi perhatikan relevansinyaperingatan diperdebatkan .)

Regresi ini terjadi karena tambalan yang tampaknya tidak terkait: gh-3003.
Sebelumnya, lookahead akan dibatalkan jika token titik koma
dihadapi, seperti pada:

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

...Namun, itu ditemukan sebagai heuristik yang tidak valid karena fungsi panah
parameter itu sendiri mungkin berisi token itu:

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

Jadi kami menghapusnya untuk mengenali fungsi panah dengan benar dalam kasus tersebut.

Dengan mengingat hal itu, kasus uji yang direduksi sepenuhnya mungkin sedikit lebih jelas (bahwa
adalah karakter \u200f yang tidak dapat dicetak dalam literal string):

(function() {
    ;

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

Sebelum gh-3003 (misalnya JSHint pada versi 2.9.2), titik koma akan menghentikan
lihat ke depan, dan karakter yang tidak dapat dicetak tidak akan di-lex sampai _after_ the
Arahan JSHint diterapkan. Dengan perbaikan yang diterapkan, JSHint mengubah karakter
_before_ menerapkan arahan dan melanjutkan untuk memperingatkan.

Ini juga menunjukkan bagaimana masalah mendasar ada bahkan di JSHint 2.9.2.
Masukan berikut salah memicu peringatan bahkan dalam versi
JSHint:

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

Karena di sini, tampilan depan yang dipicu tanda kurung juga tidak terganggu
Versi: kapan.

Perbaikan yang ideal adalah menerapkan arahan selama lookahead. Sayangnya, karena
dengan sifat arahan in-line JSHint yang sangat fleksibel, ini bukan
mungkin. Pengguna berharap bahwa arahan memiliki "ruang lingkup fungsi", yang berarti lexer
perlu menyadari semantik sekitar dari token yang dihasilkannya.

Saya telah mengirimkan perbaikan di sini: gh-3016. Dalam jangka panjang, saya pikir kita harus mempertimbangkan
peningkatan lain pada heuristik lookahead--tanpa titik koma (tidak valid)
periksa, praktik umum membungkus seluruh program dalam IIFE akan menyebabkan
JSHint untuk awalnya lex semua input.

Terimakasih untuk penjelasan detilnya!
Saya melihat betapa rumitnya ini tanpa menambahkan banyak pekerjaan ekstra untuk cakupan.
Kami akan tetap menggunakan 2.9.2 untuk sementara karena ini berfungsi untuk file kami dan akan melihat pemecahan bagian yang bermasalah menjadi blok yang dapat kami kelola di masa mendatang :)

Perbaikan untuk bug ini sekarang tersedia di JSHint versi 2.9.4 yang baru diterbitkan:

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

Beri tahu kami jika Anda masih mengalami masalah dengan versi tersebut!