Dartdoc: annotations de sécurité nulle sur les packages non migrés

Créé le 21 oct. 2020  ·  10Commentaires  ·  Source: dart-lang/dartdoc

Étapes de reproduction :

# 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

Notez que le pubspec.yaml pour package:retry a :

environment:
  sdk: ">=2.0.0 <3.0.0"

Et .dart_tool/package_config.json spécifie la version 2.0 de la langue pour 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"
}

Résultat inattendu :

3PjXUKmqd6fA2M4

Bien qu'il soit exact que la fonction retry ne puisse pas renvoyer null , le package n'est pas migré vers la sécurité nulle, devrions-nous donc vraiment ajouter une sorte de balise de sécurité nulle ici ?

P1 bug nnbd
Source
picture jonasfj

Tous les 10 commentaires

Noter. il est exact que les bibliothèques individuelles peuvent se retirer de la sécurité null, et donc, on peut affirmer qu'il est utile d'annoter si une fonction ou une classe prend en charge la sécurité null.

Mais pour la plupart des packages migrés vers la sécurité nulle, toutes les bibliothèques seront migrées vers la sécurité nulle.

Edit : Je ne suis pas tout à fait sûr de ce que nous devrions faire ici. Le simple fait d'ajouter "null-safety" aux bibliothèques dans les packages qui n'ont pas de version linguistique >= 2.12.0 est probablement faux.

jonasfj picture jonasfj le 21 oct. 2020

Convenez que c'est probablement faux. Je ne sais pas ce qui se passe ici, mais j'essaierai d'y réfléchir demain ; s'il est répandu (c'est-à-dire que nous marquons maintenant TOUT comme ça pour une raison quelconque) devrait probablement passer à P1.

jcollins-g picture jcollins-g le 21 oct. 2020

Je sais que l'analyseur sait toujours que ce ne sont pas des packages à sécurité nulle, mais maintenant nous saupoudrons des balises de sécurité nulles partout.

jcollins-g picture jcollins-g le 21 oct. 2020
👍1

@jcollins-g voulons-nous jamais cette balise au niveau du membre ? Ailleurs, par exemple sur pub.dev, nous allons traiter la sécurité nulle comme une propriété au niveau du package (soit le package entier l'a, soit il ne l'a pas)

mit-mit picture mit-mit le 22 oct. 2020

@mit-mit, je n'ai pas d'opinion tranchée là-dessus de toute façon. Il y a un argument à faire valoir que lorsque vous parcourez le corpus de documents d'API et que vous franchissez les limites des packages, il peut être utile de savoir quand vous êtes tombé dans (ou hors) un package null safe, et une balise de membre est une façon de le faire ce.

jcollins-g picture jcollins-g le 22 oct. 2020

On pourrait le mettre ici ?

Screenshot 2020-10-22 at 21 05 14

mit-mit picture mit-mit le 22 oct. 2020
👍1

Il y a un argument à faire valoir que lorsque vous parcourez le corpus de documents d'API et que vous franchissez les limites des packages, il peut être utile de savoir quand vous êtes tombé dans (ou hors) un package null safe, et une balise de membre est une façon de le faire ce.

Est-il généralement possible de sortir d'un package null-safe dans quelque chose qui n'est pas null-safe ?

Sur pub.dev l'analyse dans pana classera uniquement un package comme prenant en

  • La version linguistique est >=2.12 ,
  • Aucune bibliothèque dans le package ne désactive la sécurité nulle à l'aide d'un _marqueur de version linguistique_ ( // @dart=2.5 ),
  • Toutes les dépendances (à l'exception de dev_dependencies ) dans la résolution actuelle de pub upgrade _supportent null-safety_ (suivant cette définition récursive).

Par conséquent, si vous commencez à lire la documentation d'un package qui prend en charge la sécurité nulle, il est peu probable que vous tombiez accidentellement sur un package/une bibliothèque qui n'est pas à sécurité nulle.

Mais vous pouvez aller dans l'autre sens, si vous commencez à partir d'un package qui n'est pas null-safe. Et si vous vous retrouvez sur une page de documentation en la trouvant dans une recherche google, je suppose que c'est aussi bon à savoir. Donc, une étiquette au niveau de la bibliothèque pourrait être sympa.

jonasfj picture jonasfj le 23 oct. 2020

Cela s'avère être un problème difficile à résoudre en raison de https://github.com/dart-lang/sdk/issues/43903 que je comprends être également un problème difficile à résoudre en raison de l'indicateur d'expérience et de son utilisation pour non nullable. Ce problème peut "disparaître" lorsque l'indicateur devient par défaut. Mon inclination est de permettre aux balises d'être erronées pendant une courte période, en supposant que l'indicateur devienne bientôt activé par défaut dans l'analyseur, car contourner cela demandera des efforts importants. Je discuterai avec l'équipe d'analyse lundi, la plupart d'entre eux sont sortis aujourd'hui.

jcollins-g picture jcollins-g le 23 oct. 2020

Quelques mauvaises nouvelles. L'activation de l'indicateur par défaut ne résoudra pas réellement le problème. Nous avons donc besoin du travail supplémentaire nécessaire pour corriger ce problème. La bonne nouvelle est que @scheglov a déjà fait le gros du travail dans l'analyseur et le dartdoc pour résoudre ce problème dans #2309, bien qu'il doive être mis à jour et que certains problèmes de compatibilité Windows soient corrigés. Une fois ce travail terminé, il devrait être possible de corriger ce bogue.

Travailler maintenant pour démarrer un PR basé sur #2309 avec des correctifs pour les problèmes qu'il a rencontrés et résoudre les conflits de fusion.

jcollins-g picture jcollins-g le 26 oct. 2020

La tentative d'utilisation d'une version mise à jour de #2309 pour résoudre ce problème a rencontré des problèmes. La version courte est que dartdoc permet certaines choses nécessitant des résolveurs non par défaut et donc certains de nos tests échouent. C'est probablement soluble mais pas dans le temps imparti.

Ma deuxième tentative pour le "réparer" vient de réimplémenter la logique de lecture pubspec dans dartdoc. C'était idiot, mais ça aurait marché. @scheglov a souligné que cela pourrait être dû au fait que les packages ne sont pas transmis dans AnalysisDriver et que nous ne l'avions pas fait.

2411 corrige le problème en transmettant la structure de package correcte à AnalysisDriver, ce qui entraîne un correctif.

Le bogue n° 2410 a été déposé pour traiter le port vers AnalysisContextCollection, car un échec à résoudre cette dette entraînera sans aucun doute des problèmes plus déroutants comme celui-ci à l'avenir.

Bogue n°2409 déposé pour implémenter le commentaire de @mit-mit sur la modification du positionnement de la balise de sécurité nulle.

Se fermera et se déplacera pour publier une nouvelle version après l'arrivée du #2411.

jcollins-g picture jcollins-g le 30 oct. 2020
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

Dinesh-DK picture Dinesh-DK  ·  15Commentaires
littlen101 picture littlen101  ·  4Commentaires
a14n picture a14n  ·  17Commentaires
Hixie picture Hixie  ·  10Commentaires
maiermic picture maiermic  ·  8Commentaires