Dartdoc: anotasi null-safety pada paket yang tidak dimigrasi

Dibuat pada 21 Okt 2020  ·  10Komentar  ·  Sumber: dart-lang/dartdoc

Langkah-langkah reproduksi:

# Extract package:retry version 3.0.1
$ curl -L https://storage.googleapis.com/pub-packages/packages/retry-3.0.1.tar.gz | tar -xz
$ pub get

# Get dartdoc from git
$ mkdir /source/dartdoc
$ git clone https://github.com/dart-lang/dartdoc.git /source/dartdoc
$ cd /source/dartdoc; pub get; cd -;

# Generate docs
$ dart /source/dartdoc/bin/dartdoc.dart 

Perhatikan bahwa pubspec.yaml untuk package:retry memiliki:

environment:
  sdk: ">=2.0.0 <3.0.0"

Dan .dart_tool/package_config.json menentukan versi bahasa 2.0 untuk package:retry :

{
  "configVersion": 2,
  "packages": [
    /* various other dependencies, mostly test and it's transitive dependencies, omitted here */
    {
      "name": "retry",
      "rootUri": "../",
      "packageUri": "lib/",
      "languageVersion": "2.0" // <-- language version 2.0, hence, no library in package:retry supports null-safety
    }
  ],
  "generated": "2020-10-21T10:44:27.912220Z",
  "generator": "pub",
  "generatorVersion": "2.10.0"
}

Hasil tak terduga:

3PjXUKmqd6fA2M4

Meskipun benar bahwa fungsi retry tidak dapat mengembalikan null , paket tidak dimigrasikan ke null-safety, jadi haruskah kita benar-benar menambahkan tag null-safety apa pun di sini?

P1 bug nnbd

Semua 10 komentar

Catatan. itu benar bahwa perpustakaan individu dapat memilih keluar dari keamanan nol, dan dengan demikian, dapat dikatakan bahwa itu berharga untuk membubuhi keterangan apakah suatu fungsi atau kelas mendukung keamanan nol.

Tetapi untuk sebagian besar paket yang dimigrasikan ke null-safety, semua library akan dimigrasikan ke null-safety.

Sunting: Saya tidak sepenuhnya yakin apa yang harus kita lakukan di sini. Hanya saja menambahkan "null-safety" ke perpustakaan dalam paket yang tidak memiliki versi bahasa >= 2.12.0 mungkin salah.

Setuju bahwa ini mungkin salah. Tidak yakin apa yang terjadi di sini tetapi akan mencoba untuk melihat ke dalamnya besok; jika itu tersebar luas (yaitu kita sekarang menandai SEMUANYA seperti ini untuk beberapa alasan) mungkin harus naik ke P1.

Saya tahu bahwa penganalisa masih mengetahui kebenaran bahwa ini bukan paket aman-nol, namun sekarang kami menaburkan tag pengaman nol di semua tempat.

@jcollins-g apakah kita pernah menginginkan tag ini di tingkat anggota? Di tempat lain, misalnya di pub.dev, kita akan memperlakukan keamanan nol sebagai properti tingkat paket (baik seluruh paket memilikinya, atau tidak)

@ mit-mit Saya juga tidak memiliki pendapat yang kuat tentang itu. Ada argumen yang dibuat bahwa saat menelusuri kumpulan dokumen API dan melintasi batas paket, mungkin menyenangkan untuk mengetahui kapan Anda menemukan (atau keluar dari) paket aman nol, dan tag anggota adalah salah satu cara untuk melakukannya itu.

Kita bisa meletakkannya di sini?

Screenshot 2020-10-22 at 21 05 14

Ada argumen yang dibuat bahwa saat menelusuri kumpulan dokumen API dan melintasi batas paket, mungkin menyenangkan untuk mengetahui kapan Anda menemukan (atau keluar dari) paket aman nol, dan tag anggota adalah salah satu cara untuk melakukannya itu.

Apakah biasanya mungkin untuk keluar dari paket null-safe menjadi sesuatu yang tidak null-safe?

Pada pub.dev analisis dalam pana hanya akan mengklasifikasikan sebuah paket sebagai mendukung null-safety , jika:

  • Versi bahasa adalah >=2.12 ,
  • Tidak ada pustaka dalam paket yang menyisih dari keamanan nol menggunakan _penanda versi bahasa_ ( // @dart=2.5 ),
  • Semua dependensi (tidak termasuk dev_dependencies ) dalam resolusi pub upgrade _supports null-safety_ (mengikuti definisi rekursif ini).

Oleh karena itu, jika Anda mulai membaca dokumentasi untuk sebuah paket yang mendukung null-safety, kecil kemungkinan Anda secara tidak sengaja menemukan paket/library yang tidak null-safe.

Tetapi Anda bisa pergi ke arah lain, jika Anda memulai dari paket yang tidak aman-nol. Dan jika Anda berakhir di halaman dokumentasi dengan menemukannya di pencarian google, saya rasa itu juga bagus untuk diketahui. Jadi label tingkat perpustakaan bisa bagus.

Ini ternyata menjadi masalah yang sulit untuk dipecahkan karena https://github.com/dart-lang/sdk/issues/43903 yang saya pahami juga menjadi masalah yang sulit untuk dipecahkan karena flag eksperimen dan bagaimana itu digunakan untuk non-nullable. Masalah ini mungkin "hilang" ketika bendera menjadi default. Kecenderungan saya adalah membiarkan tag menjadi salah untuk waktu yang singkat, dengan asumsi bendera menjadi default-on di penganalisis segera, karena mengatasinya akan membutuhkan upaya yang signifikan. Akan berdiskusi dengan tim penganalisa Senin, kebanyakan dari mereka keluar hari ini.

Beberapa berita buruk. Menyetel flag ke on sebenarnya tidak akan menyelesaikan masalah. Jadi kita perlu kerja ekstra yang terlibat untuk memperbaiki masalah ini. Kabar baiknya adalah @scheglov sudah melakukan tugas berat di penganalisis dan dartdoc untuk menyelesaikan masalah ini di #2309, meskipun perlu diperbarui dan beberapa masalah kompatibilitas windows diperbaiki. Setelah pekerjaan itu mendarat, mungkin untuk memperbaiki bug ini.

Bekerja sekarang untuk memulai PR berdasarkan #2309 dengan perbaikan untuk masalah yang dia hadapi dan menyelesaikan konflik gabungan.

Upaya menggunakan versi #2309 yang diperbarui untuk memperbaiki masalah ini mengalami masalah. Versi singkatnya adalah dartdoc mengizinkan beberapa hal yang memerlukan resolver non-default sehingga beberapa pengujian kami gagal. Ini mungkin bisa dipecahkan tetapi tidak dalam jangka waktu.

Upaya kedua saya untuk "memperbaiki" itu hanya mengimplementasikan kembali logika pembacaan pubspec di dalam dartdoc. Ini konyol, tetapi akan berhasil. @scheglov menunjukkan bahwa ini dapat disebabkan oleh tidak meneruskan paket ke AnalysisDriver dan memang, kami gagal melakukan ini.

2411 memperbaiki masalah dengan meneruskan struktur paket yang benar ke AnalysisDriver, menghasilkan perbaikan.

Mengajukan bug #2410 untuk menangani port ke AnalysisContextCollection sebagai kegagalan untuk mengatasi hutang itu tidak diragukan lagi akan menghasilkan masalah yang lebih membingungkan seperti ini di masa depan.

Mengajukan bug #2409 untuk mengimplementasikan komentar @ mit-mit tentang mengubah posisi tag keamanan nol.

Akan ditutup dan dipindahkan untuk menerbitkan versi baru setelah #2411 mendarat.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat