@@ -25993,6 +25993,77 @@ void f() {
2599325993}
2599425994```
2599525995
25996+ ### invalid_runtime_check_with_js_interop_types
25997+
25998+ _Cast from '{0}' to '{1}' casts a Dart value to a JS interop type, which might
25999+ not be platform-consistent._
26000+
26001+ _Cast from '{0}' to '{1}' casts a JS interop value to a Dart type, which might
26002+ not be platform-consistent._
26003+
26004+ _Cast from '{0}' to '{1}' casts a JS interop value to an incompatible JS interop
26005+ type, which might not be platform-consistent._
26006+
26007+ _Runtime check between '{0}' and '{1}' checks whether a Dart value is a JS
26008+ interop type, which might not be platform-consistent._
26009+
26010+ _Runtime check between '{0}' and '{1}' checks whether a JS interop value is a
26011+ Dart type, which might not be platform-consistent._
26012+
26013+ _Runtime check between '{0}' and '{1}' involves a non-trivial runtime check
26014+ between two JS interop types that might not be platform-consistent._
26015+
26016+ _Runtime check between '{0}' and '{1}' involves a runtime check between a JS
26017+ interop value and an unrelated JS interop type that will always be true and won't check the underlying type._
26018+
26019+ #### Description
26020+
26021+ The analyzer produces this diagnostic when an `is` test has either:
26022+ - a JS interop type on the right-hand side, whether directly or as a type
26023+ argument to another type, or
26024+ - a JS interop value on the left-hand side.
26025+
26026+ #### Examples
26027+
26028+ The following code produces this diagnostic because the JS interop type
26029+ `JSBoolean` is on the right-hand side of an `is` test:
26030+
26031+ ```dart
26032+ import 'dart:js_interop';
26033+
26034+ bool f(Object b) => [!b is JSBoolean!];
26035+ ```
26036+
26037+ The following code produces this diagnostic because the JS interop type
26038+ `JSString` is used as a type argument on the right-hand side of an `is`
26039+ test:
26040+
26041+ ```dart
26042+ import 'dart:js_interop';
26043+
26044+ bool f(List<Object> l) => [!l is List<JSString>!];
26045+ ```
26046+
26047+ The following code produces this diagnostic because the JS interop value
26048+ `a` is on the left-hand side of an `is` test:
26049+
26050+ ```dart
26051+ import 'dart:js_interop';
26052+
26053+ bool f(JSAny a) => [!a is String!];
26054+ ```
26055+
26056+ #### Common fixes
26057+
26058+ Use a JS interop helper, such as `isA`, to check the underlying type of
26059+ JS interop values:
26060+
26061+ ```dart
26062+ import 'dart:js_interop';
26063+
26064+ void f(Object b) => b.jsify()?.isA<JSBoolean>();
26065+ ```
26066+
2599626067### invalid_use_of_do_not_submit_member
2599726068
2599826069_Uses of '{0}' should not be submitted to source control._
@@ -26046,6 +26117,43 @@ void emulateCrashWithOtherFunctionality() {
2604626117}
2604726118```
2604826119
26120+ ### library_annotations
26121+
26122+ _This annotation should be attached to a library directive._
26123+
26124+ #### Description
26125+
26126+ The analyzer produces this diagnostic when an annotation that applies to
26127+ a whole library isn't associated with a `library` directive.
26128+
26129+ #### Example
26130+
26131+ The following code produces this diagnostic because the `TestOn`
26132+ annotation, which applies to the whole library, is associated with an
26133+ `import` directive rather than a `library` directive:
26134+
26135+ ```dart
26136+ [!@TestOn('browser')!]
26137+
26138+ import 'package:test/test.dart';
26139+
26140+ void main() {}
26141+ ```
26142+
26143+ #### Common fixes
26144+
26145+ Associate the annotation with a `library` directive, adding one if
26146+ necessary:
26147+
26148+ ```dart
26149+ @TestOn('browser')
26150+ library;
26151+
26152+ import 'package:test/test.dart';
26153+
26154+ void main() {}
26155+ ```
26156+
2604926157### library_names
2605026158
2605126159_The library name '{0}' isn't a lower\_case\_with\_underscores identifier._
@@ -28251,6 +28359,59 @@ Future<void> f() async {
2825128359Future<int> g() => Future.value(0);
2825228360```
2825328361
28362+ ### unintended_html_in_doc_comment
28363+
28364+ _Angle brackets will be interpreted as HTML._
28365+
28366+ #### Description
28367+
28368+ The analyzer produces this diagnostic when a documentation comment
28369+ contains angle bracketed text (`<...>`) that isn't one of the allowed
28370+ exceptions.
28371+
28372+ Such text is interpreted by markdown to be an HTML tag, which is rarely
28373+ what was intended.
28374+
28375+ See the [lint rule description](https://dart.dev/tools/linter-rules/unintended_html_in_doc_comment)
28376+ for the list of allowed exceptions.
28377+
28378+ #### Example
28379+
28380+ The following code produces this diagnostic because the documentation
28381+ comment contains the text `<int>`, which isn't one of the allowed
28382+ exceptions:
28383+
28384+ ```dart
28385+ /// Converts a List[!<int>!] to a comma-separated String.
28386+ String f(List<int> l) => '';
28387+ ```
28388+
28389+ #### Common fixes
28390+
28391+ If the text was intended to be part of a code span, then add backticks
28392+ around the code:
28393+
28394+ ```dart
28395+ /// Converts a `List<int>` to a comma-separated String.
28396+ String f(List<int> l) => '';
28397+ ```
28398+
28399+ If the text was intended to be part of a link, then add square brackets
28400+ around the code:
28401+
28402+ ```dart
28403+ /// Converts a [List<int>] to a comma-separated String.
28404+ String f(List<int> l) => '';
28405+ ```
28406+
28407+ If the text was intended to be printed as-is, including the angle
28408+ brackets, then add backslash escapes before the angle brackets:
28409+
28410+ ```dart
28411+ /// Converts a List\<int\> to a comma-separated String.
28412+ String f(List<int> l) => '';
28413+ ```
28414+
2825428415### unnecessary_brace_in_string_interps
2825528416
2825628417_Unnecessary braces in a string interpolation._
@@ -28481,6 +28642,39 @@ class C {
2848128642}
2848228643```
2848328644
28645+ ### unnecessary_library_name
28646+
28647+ _Library names are not necessary._
28648+
28649+ #### Description
28650+
28651+ The analyzer produces this diagnostic when a `library` directive specifies
28652+ a name.
28653+
28654+ #### Example
28655+
28656+ The following code produces this diagnostic because the `library`
28657+ directive includes a name:
28658+
28659+ ```dart
28660+ library [!some.name!];
28661+
28662+ class C {}
28663+ ```
28664+
28665+ #### Common fixes
28666+
28667+ Remove the name from the `library` directive:
28668+
28669+ ```dart
28670+ library;
28671+
28672+ class C {}
28673+ ```
28674+
28675+ If the library has any parts, then any `part of` declarations that use
28676+ the library name should be updated to use the URI of the library instead.
28677+
2848428678### unnecessary_new
2848528679
2848628680_Unnecessary 'new' keyword._
@@ -29522,6 +29716,35 @@ class B extends A {
2952229716}
2952329717```
2952429718
29719+ ### use_truncating_division
29720+
29721+ _Use truncating division._
29722+
29723+ #### Description
29724+
29725+ The analyzer produces this diagnostic when the result of dividing two
29726+ numbers is converted to an integer using `toInt`.
29727+
29728+ Dart has a built-in integer division operator that is both more efficient
29729+ and more concise.
29730+
29731+ #### Example
29732+
29733+ The following code produces this diagnostic because the result of dividing
29734+ `x` and `y` is converted to an integer using `toInt`:
29735+
29736+ ```dart
29737+ int divide(int x, int y) => [!(x / y).toInt()!];
29738+ ```
29739+
29740+ #### Common fixes
29741+
29742+ Use the integer division operator (`~/`):
29743+
29744+ ```dart
29745+ int divide(int x, int y) => x ~/ y;
29746+ ```
29747+
2952529748### valid_regexps
2952629749
2952729750_Invalid regular expression syntax._
0 commit comments