[L] Change in dart/sdk[main]: Add documentation for several additional warnings
Brian Wilkerson (Gerrit)
Brian Wilkerson voted Commit-Queue+1![]( "Open in Gerrit")
| Commit-Queue | +1 |
Related details
- Samuel Rawlins
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Samuel Rawlins (Gerrit)
Samuel Rawlins voted and added 2 comments![]( "Open in Gerrit")
Votes added by Samuel Rawlins
| Code-Review | +1 |
2 comments
The following code produces this diagnostic because :Remove 'because'? Or keep going?
Related details
- Brian Wilkerson
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Brian Wilkerson (Gerrit)
Brian Wilkerson added 1 comment![]( "Open in Gerrit")
The following code produces this diagnostic because :Remove 'because'? Or keep going?
Sorry, I thought I'd verified the completeness of all of the changes, but I obviously missed one. Now fixed. PTAL.
Related details
- Amanda Fitch
- Konstantin Shcheglov
- Samuel Rawlins
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Samuel Rawlins (Gerrit)
Samuel Rawlins voted Code-Review+1![]( "Open in Gerrit")
- Amanda Fitch
- Brian Wilkerson
- Konstantin Shcheglov
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Konstantin Shcheglov (Gerrit)
Konstantin Shcheglov voted Code-Review+1![]( "Open in Gerrit")
| Code-Review | +1 |
Related details
- Amanda Fitch
- Brian Wilkerson
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Brian Wilkerson (Gerrit)
Brian Wilkerson voted Commit-Queue+2![]( "Open in Gerrit")
| Commit-Queue | +2 |
Related details
- Amanda Fitch
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit Queue (Gerrit)
Commit Queue submitted the change![]( "Open in Gerrit")
Change information
Add documentation for several additional warnings
- M pkg/analyzer/lib/src/error/codes.g.dart
- M pkg/analyzer/messages.yaml
- M pkg/analyzer/test/verify_diagnostics_test.dart
Code-Review: +1 by Samuel Rawlins, +1 by Konstantin Shcheglov
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Connie Ooi (Gerrit)
Connie Ooi added 25 comments![]( "Open in Gerrit")
/// String p0: the name of the function or method whose return type couldn't
/// be inferredsuggestion: "...can't be inferred"
The analyzer produces this diagnostic whenreplace 'when' with when:
- the language option `strict-inference` has been enabled in the analysis options file,replace with "the language option `strict-inference` is enabled in the analysis options file,
- a list, map or set literal doesn't have type arguments, andreplace with "a list, map, or set literal has no type arguments"
The following code produces this diagnostic because the type of the
elements of the list literal can't be inferred by the analyzer:
Replace with "The analyzer produces this diagnostic for the following code because it cannot determine the list literal's element type:"
The analyzer produces this diagnostic whenwhen:
- the language option `strict-inference` has been enabled in the analysis options file,replace with "the language option `strict-inference` is enabled in the analysis options file,"
- the invocation of a method or function doesn't have type arguments, andreplace with "...has no type arguments, and"
The following code produces this diagnostic because the invocation of the
method `m` doesn't have type arguments and the type arguments can't be
inferred:rewrite "The analyzer reports this diagnostic because the invocation of method `m` has no type arguments, and the values can't be inferred:"
The analyzer produces this diagnostic whenwhen:
- the language option `strict-inference` has been enabled in the analysis options file,see above suggestions for this phrase
- the declaration of a method or function doesn't have a return type, andsee above "... has no return type"
The analyzer produces this diagnostic whenwhen:
- the language option `strict-inference` has been enabled in the analysis options file,see above for suggestion
- the declaration of a variable doesn't have a type, andreplace with "...has no type..."
The following code produces this diagnostic because the variable `s`
doesn't have an explicit type and the type can't be inferred because
there's no initializer:
replace with "The analyzer produces this diagnostic for the following code because the variable `s` has no explicit type and no initializer, so its type cannot be inferred:"
The analyzer produces this diagnostic whenwhen:
- the language option `strict-inference` has been enabled in the analysis options file,see above
- the declaration of a formal parameter doesn't have a type, and"...has no type"
The type of a parameter of a method can be inferred if the method
overrides an inherited method.rewrite "The type of a method's parameter can be inferred if it overrides an inherited method."
The analyzer produces this diagnostic when the type of the object being
matched can't ever be matched by the pattern.rewrite: "The analyzer produces this diagnostic when the object's type can't be matched by the pattern."
The following code produces this diagnostic because a `double` is being
matched by a pattern that requires an `int`, which can never succeed:
replace with "This diagnostic is produced because a `double` is matched by an `int` pattern, which can never succeed."
If one of the types is wrong, then change one or both of the types so that
the pattern can succeed:
replace with "If one of the types is wrong, change one or both so the pattern match can succeed."
If the types aren't wrong, then remove the pattern match:"If the types are correct..."
The analyzer produces this diagnostic when a lint that has been removed is
used in an analysis options file. Because the lint has been removed, the
reference to it (such as enabling it) will have no effect.suggestion: "The analyzer produces this diagnostic when a lint that has been removed is used in an analysis options file. Because the lint no longer exists, referencing it will have no effect."
Related details
- Brian Wilkerson
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Brian Wilkerson (Gerrit)
Brian Wilkerson added 27 comments![]( "Open in Gerrit")
Thanks for the review!
I have questions about a couple of the changes, but most of them I've already applied in a follow-up CL. I'll send out the new CL after we've finished discussing my questions.
/// String p0: the name of the function or method whose return type couldn't
/// be inferredsuggestion: "...can't be inferred"
Done
The analyzer produces this diagnostic whenBrian Wilkersonreplace 'when' with when:
Done
- the language option `strict-inference` has been enabled in the analysis options file,replace with "the language option `strict-inference` is enabled in the analysis options file,
Done
- a list, map or set literal doesn't have type arguments, andreplace with "a list, map, or set literal has no type arguments"
Done
The following code produces this diagnostic because the type of the
elements of the list literal can't be inferred by the analyzer:
Replace with "The analyzer produces this diagnostic for the following code because it cannot determine the list literal's element type:"
You're right that in one sense it's really the analyzer producing the diagnostic and not the code itself, and in many ways what you wrote is more readable.
However, the docs are extremely formulaic. This was done intentionally for easy of reading by humans, and I think it probably helps LLMs as well. As a result I'm hesitant to deviate from the formula.
I'm wondering whether we can improve the text without sacrificing the formula. For example:
```
The following code produces this diagnostic because the type of the
list literal's elements can't be inferred:
```
What do you think?
The analyzer produces this diagnostic whenBrian Wilkersonwhen:
Done
FWIW, while I have no problem with how you reviewed these docs, I'm fine with a suggestion including something like "here and elsewhere" as a reminder to go through the changes looking for similar text that needs to be updated in the same way. Might save you some time when reviewing future docs.
- the language option `strict-inference` has been enabled in the analysis options file,replace with "the language option `strict-inference` is enabled in the analysis options file,"
Done
- the invocation of a method or function doesn't have type arguments, andreplace with "...has no type arguments, and"
Done
The following code produces this diagnostic because the invocation of the
method `m` doesn't have type arguments and the type arguments can't be
inferred:rewrite "The analyzer reports this diagnostic because the invocation of method `m` has no type arguments, and the values can't be inferred:"
Similar to above, what do you think of
```
The following code produces this diagnostic because the invocation of `m`
has no explicit type arguments, and the arguments can't be inferred:
```
I think it might be better to say "arguments" rather than "values" because it might not be clear which values we're talking about, especially for developers whose primary language isn't English. (I also add "explicit", because it's more technically correct, something I missed originally.)
The analyzer produces this diagnostic whenBrian Wilkersonwhen:
Done
- the language option `strict-inference` has been enabled in the analysis options file,see above suggestions for this phrase
Done
- the declaration of a method or function doesn't have a return type, andsee above "... has no return type"
Done
The analyzer produces this diagnostic whenBrian Wilkersonwhen:
Done
- the language option `strict-inference` has been enabled in the analysis options file,Brian Wilkersonsee above for suggestion
Done
- the declaration of a variable doesn't have a type, andreplace with "...has no type..."
Done
The following code produces this diagnostic because the variable `s`
doesn't have an explicit type and the type can't be inferred because
there's no initializer:
replace with "The analyzer produces this diagnostic for the following code because the variable `s` has no explicit type and no initializer, so its type cannot be inferred:"
I think the original is better because if the variable had an explicit type then there would be no inference. In other words, the precondition for this diagnostic is that there is a variable without an explicit type annotation, and the error is that inference can't be applied because there is no initializer. The suggested text kind of sounds to me like the problem is the absence of both a type and an initializer, and I'm wondering whether some developers might interpret it to mean that they need to add both (which isn't the case).
Am I missing something that you're seeing?
The analyzer produces this diagnostic whenBrian Wilkersonwhen:
Done
- the language option `strict-inference` has been enabled in the analysis options file,Brian Wilkersonsee above
Done
- the declaration of a formal parameter doesn't have a type, andBrian Wilkerson"...has no type"
Done
The type of a parameter of a method can be inferred if the method
overrides an inherited method.rewrite "The type of a method's parameter can be inferred if it overrides an inherited method."
Done
The analyzer produces this diagnostic when the type of the object being
matched can't ever be matched by the pattern.rewrite: "The analyzer produces this diagnostic when the object's type can't be matched by the pattern."
Done
The following code produces this diagnostic because a `double` is being
matched by a pattern that requires an `int`, which can never succeed:
replace with "This diagnostic is produced because a `double` is matched by an `int` pattern, which can never succeed."
What do you think of
```
The following code produces this diagnostic because a `double` is matched by an `int` pattern, which can never succeed:
```
If one of the types is wrong, then change one or both of the types so that
the pattern can succeed:
replace with "If one of the types is wrong, change one or both so the pattern match can succeed."
Done
If the types aren't wrong, then remove the pattern match:"If the types are correct..."
Done
The analyzer produces this diagnostic when a lint that has been removed is
used in an analysis options file. Because the lint has been removed, the
reference to it (such as enabling it) will have no effect.suggestion: "The analyzer produces this diagnostic when a lint that has been removed is used in an analysis options file. Because the lint no longer exists, referencing it will have no effect."
Done
The following code produces this diagnostic because :Brian WilkersonRemove 'because'? Or keep going?
Sorry, I thought I'd verified the completeness of all of the changes, but I obviously missed one. Now fixed. PTAL.
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Connie Ooi (Gerrit)
Connie Ooi added 4 comments![]( "Open in Gerrit")
The following code produces this diagnostic because the type of the
elements of the list literal can't be inferred by the analyzer:
Brian WilkersonReplace with "The analyzer produces this diagnostic for the following code because it cannot determine the list literal's element type:"
You're right that in one sense it's really the analyzer producing the diagnostic and not the code itself, and in many ways what you wrote is more readable.
However, the docs are extremely formulaic. This was done intentionally for easy of reading by humans, and I think it probably helps LLMs as well. As a result I'm hesitant to deviate from the formula.
I'm wondering whether we can improve the text without sacrificing the formula. For example:
```
The following code produces this diagnostic because the type of the
list literal's elements can't be inferred:
```
What do you think?
Yeah, that sounds great!
The following code produces this diagnostic because the invocation of the
method `m` doesn't have type arguments and the type arguments can't be
inferred:Brian Wilkersonrewrite "The analyzer reports this diagnostic because the invocation of method `m` has no type arguments, and the values can't be inferred:"
Similar to above, what do you think of
```
The following code produces this diagnostic because the invocation of `m`
has no explicit type arguments, and the arguments can't be inferred:
```
I think it might be better to say "arguments" rather than "values" because it might not be clear which values we're talking about, especially for developers whose primary language isn't English. (I also add "explicit", because it's more technically correct, something I missed originally.)
LGTM
The following code produces this diagnostic because the variable `s`
doesn't have an explicit type and the type can't be inferred because
there's no initializer:
Brian Wilkersonreplace with "The analyzer produces this diagnostic for the following code because the variable `s` has no explicit type and no initializer, so its type cannot be inferred:"
I think the original is better because if the variable had an explicit type then there would be no inference. In other words, the precondition for this diagnostic is that there is a variable without an explicit type annotation, and the error is that inference can't be applied because there is no initializer. The suggested text kind of sounds to me like the problem is the absence of both a type and an initializer, and I'm wondering whether some developers might interpret it to mean that they need to add both (which isn't the case).
Am I missing something that you're seeing?
That makes sense! I agree to keep the original
The following code produces this diagnostic because a `double` is being
matched by a pattern that requires an `int`, which can never succeed:
Brian Wilkersonreplace with "This diagnostic is produced because a `double` is matched by an `int` pattern, which can never succeed."
What do you think of
```
The following code produces this diagnostic because a `double` is matched by an `int` pattern, which can never succeed:
```
- Brian Wilkerson
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Brian Wilkerson (Gerrit)
Brian Wilkerson added 5 comments![]( "Open in Gerrit")
The updates are now in https://dart-review.googlesource.com/c/sdk/+/449840.
The following code produces this diagnostic because the type of the
elements of the list literal can't be inferred by the analyzer:
Brian WilkersonReplace with "The analyzer produces this diagnostic for the following code because it cannot determine the list literal's element type:"
Connie OoiYou're right that in one sense it's really the analyzer producing the diagnostic and not the code itself, and in many ways what you wrote is more readable.
However, the docs are extremely formulaic. This was done intentionally for easy of reading by humans, and I think it probably helps LLMs as well. As a result I'm hesitant to deviate from the formula.
I'm wondering whether we can improve the text without sacrificing the formula. For example:
```
The following code produces this diagnostic because the type of the
list literal's elements can't be inferred:
```
What do you think?
Yeah, that sounds great!
Done
The following code produces this diagnostic because the invocation of the
method `m` doesn't have type arguments and the type arguments can't be
inferred:Brian Wilkersonrewrite "The analyzer reports this diagnostic because the invocation of method `m` has no type arguments, and the values can't be inferred:"
Connie OoiSimilar to above, what do you think of
```
The following code produces this diagnostic because the invocation of `m`
has no explicit type arguments, and the arguments can't be inferred:
```
I think it might be better to say "arguments" rather than "values" because it might not be clear which values we're talking about, especially for developers whose primary language isn't English. (I also add "explicit", because it's more technically correct, something I missed originally.)
LGTM
Done
The following code produces this diagnostic because the variable `s`
doesn't have an explicit type and the type can't be inferred because
there's no initializer:
Brian Wilkersonreplace with "The analyzer produces this diagnostic for the following code because the variable `s` has no explicit type and no initializer, so its type cannot be inferred:"
Connie OoiI think the original is better because if the variable had an explicit type then there would be no inference. In other words, the precondition for this diagnostic is that there is a variable without an explicit type annotation, and the error is that inference can't be applied because there is no initializer. The suggested text kind of sounds to me like the problem is the absence of both a type and an initializer, and I'm wondering whether some developers might interpret it to mean that they need to add both (which isn't the case).
Am I missing something that you're seeing?
That makes sense! I agree to keep the original
Done
The following code produces this diagnostic because a `double` is being
matched by a pattern that requires an `int`, which can never succeed:
Brian Wilkersonreplace with "This diagnostic is produced because a `double` is matched by an `int` pattern, which can never succeed."
Connie OoiWhat do you think of
```
The following code produces this diagnostic because a `double` is matched by an `int` pattern, which can never succeed:
```
LGTM
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |