mirror of
https://github.com/dart-lang/sdk
synced 2024-09-05 00:13:50 +00:00
Writing review 3.0 diagnostics
Minor changes to last few 3.0 diagnostic message changes (late follow up). Mostly just a practice CL for me, after setting my sdk environment up for the first time. Fixes https://github.com/dart-lang/site-www/issues/4740 Change-Id: I8f6871a270089627538928dd95bcbf38a29b74e7 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309780 Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Commit-Queue: Marya Belanger <mbelanger@google.com>
This commit is contained in:
parent
77799f6d6c
commit
7918525a6b
|
@ -10981,7 +10981,7 @@ CompileTimeErrorCode:
|
|||
|
||||
#### Common fixes
|
||||
|
||||
Add a case for each of the constants that aren't currently being matched:
|
||||
Add a case for each of the values missing a match:
|
||||
|
||||
```dart
|
||||
enum E { one, two, three }
|
||||
|
@ -10993,7 +10993,7 @@ CompileTimeErrorCode:
|
|||
};
|
||||
```
|
||||
|
||||
If the missing values don't need to be matched, then add a wildcard
|
||||
If the missing values don't need to be matched, then add a wildcard
|
||||
pattern:
|
||||
|
||||
```dart
|
||||
|
@ -11006,9 +11006,9 @@ CompileTimeErrorCode:
|
|||
};
|
||||
```
|
||||
|
||||
But be aware that adding a wildcard pattern will cause any future values
|
||||
of the type to also be handled, so you will have lost the ability for the
|
||||
compiler to warn you if the `switch` needs to be updated.
|
||||
Be aware that a wildcard pattern will handle any values added to the type
|
||||
in the future. You will lose the ability to have the compiler warn you if
|
||||
the `switch` needs to be updated to account for newly added types.
|
||||
NON_EXHAUSTIVE_SWITCH_STATEMENT:
|
||||
problemMessage: "The type '{0}' is not exhaustively matched by the switch cases since it doesn't match '{1}'."
|
||||
correctionMessage: "Try adding a default case or cases that match '{2}'."
|
||||
|
@ -12768,15 +12768,15 @@ CompileTimeErrorCode:
|
|||
#### Description
|
||||
|
||||
The analyzer produces this diagnostic when an object pattern contains a
|
||||
field that doesn't have a getter name. The fields provide a pattern to
|
||||
match against the value returned by a getter, and not specifying the name
|
||||
of the getter means that there's no way to access the value that the
|
||||
pattern is intended to match against.
|
||||
field without specifying the getter name. Object pattern fields match
|
||||
against values that the object's getters return. Without a getter name
|
||||
specified, the pattern field can't access a value to attempt to match against.
|
||||
|
||||
#### Example
|
||||
|
||||
The following code produces this diagnostic because the object pattern
|
||||
`String(1)` doesn't say which value to compare with `1`:
|
||||
`String(1)` doesn't specify which getter of `String` to access and compare
|
||||
with the value `1`:
|
||||
|
||||
```dart
|
||||
void f(Object o) {
|
||||
|
@ -12786,8 +12786,8 @@ CompileTimeErrorCode:
|
|||
|
||||
#### Common fixes
|
||||
|
||||
Add both the name of the getter to use to access the value and a colon
|
||||
before the value:
|
||||
Add the getter name (same as the field name) to access the value, followed
|
||||
by a colon before the value to match against:
|
||||
|
||||
```dart
|
||||
void f(Object o) {
|
||||
|
@ -14084,14 +14084,14 @@ CompileTimeErrorCode:
|
|||
#### Description
|
||||
|
||||
The analyzer produces this diagnostic when a map pattern contains a rest
|
||||
pattern. The matching for map patterns already allows the map to have
|
||||
more keys than those explicitly given in the pattern, so a rest pattern
|
||||
wouldn't add anything.
|
||||
pattern. Map patterns will already match a map with more keys
|
||||
than those explicitly given in the pattern (as long as the given keys match),
|
||||
so a rest pattern is unnecesssary.
|
||||
|
||||
#### Example
|
||||
|
||||
The following code produces this diagnostic because there's a rest
|
||||
pattern in a map pattern:
|
||||
The following code produces this diagnostic because the map pattern contains
|
||||
a rest pattern:
|
||||
|
||||
```dart
|
||||
void f(Map<int, String> x) {
|
||||
|
|
|
@ -14419,7 +14419,7 @@ String f(E e) => [!switch!] (e) {
|
|||
|
||||
#### Common fixes
|
||||
|
||||
Add a case for each of the constants that aren't currently being matched:
|
||||
Add a case for each of the values missing a match:
|
||||
|
||||
{% prettify dart tag=pre+code %}
|
||||
enum E { one, two, three }
|
||||
|
@ -14431,7 +14431,7 @@ String f(E e) => switch (e) {
|
|||
};
|
||||
{% endprettify %}
|
||||
|
||||
If the missing values don't need to be matched, then add a wildcard
|
||||
If the missing values don't need to be matched, then add a wildcard
|
||||
pattern:
|
||||
|
||||
{% prettify dart tag=pre+code %}
|
||||
|
@ -14444,9 +14444,9 @@ String f(E e) => switch (e) {
|
|||
};
|
||||
{% endprettify %}
|
||||
|
||||
But be aware that adding a wildcard pattern will cause any future values
|
||||
of the type to also be handled, so you will have lost the ability for the
|
||||
compiler to warn you if the `switch` needs to be updated.
|
||||
Be aware that a wildcard pattern will handle any values added to the type
|
||||
in the future. You will lose the ability to have the compiler warn you if
|
||||
the `switch` needs to be updated to account for newly added types.
|
||||
|
||||
### non_exhaustive_switch_statement
|
||||
|
||||
|
@ -16434,15 +16434,15 @@ _Object patterns can only use named fields._
|
|||
#### Description
|
||||
|
||||
The analyzer produces this diagnostic when an object pattern contains a
|
||||
field that doesn't have a getter name. The fields provide a pattern to
|
||||
match against the value returned by a getter, and not specifying the name
|
||||
of the getter means that there's no way to access the value that the
|
||||
pattern is intended to match against.
|
||||
field without specifying the getter name. Object pattern fields match
|
||||
against values that the object's getters return. Without a getter name
|
||||
specified, the pattern field can't access a value to attempt to match against.
|
||||
|
||||
#### Example
|
||||
|
||||
The following code produces this diagnostic because the object pattern
|
||||
`String(1)` doesn't say which value to compare with `1`:
|
||||
`String(1)` doesn't specify which getter of `String` to access and compare
|
||||
with the value `1`:
|
||||
|
||||
{% prettify dart tag=pre+code %}
|
||||
void f(Object o) {
|
||||
|
@ -16452,8 +16452,8 @@ void f(Object o) {
|
|||
|
||||
#### Common fixes
|
||||
|
||||
Add both the name of the getter to use to access the value and a colon
|
||||
before the value:
|
||||
Add the getter name (same as the field name) to access the value, followed
|
||||
by a colon before the value to match against:
|
||||
|
||||
{% prettify dart tag=pre+code %}
|
||||
void f(Object o) {
|
||||
|
@ -17693,14 +17693,14 @@ _A map pattern can't contain a rest pattern._
|
|||
#### Description
|
||||
|
||||
The analyzer produces this diagnostic when a map pattern contains a rest
|
||||
pattern. The matching for map patterns already allows the map to have
|
||||
more keys than those explicitly given in the pattern, so a rest pattern
|
||||
wouldn't add anything.
|
||||
pattern. Map patterns will already match a map with more keys
|
||||
than those explicitly given in the pattern (as long as the given keys match),
|
||||
so a rest pattern is unnecesssary.
|
||||
|
||||
#### Example
|
||||
|
||||
The following code produces this diagnostic because there's a rest
|
||||
pattern in a map pattern:
|
||||
The following code produces this diagnostic because the map pattern contains
|
||||
a rest pattern:
|
||||
|
||||
{% prettify dart tag=pre+code %}
|
||||
void f(Map<int, String> x) {
|
||||
|
|
Loading…
Reference in a new issue