Enhanced enums: incorrect missing case clause analyzer warning

[olof-dev]

The analyzer raises the warning missing_enum_constant_in_switch for the code below, saying Missing case clause for 'data' and similarly for moreData. Of course, they shouldn't have case clauses.

enum E {
  a, b;
  
  static final data = "I'm not a real enum member";
  static const moreData = 'Neither am I';
  
  String get name {
    switch(this) {
      case a:
        return 'AAAA';
      case b:
        return 'BBBB';
    }
  }
}

(Dart SDK version: 2.17.1 (stable))

[bwilkerson]

@scheglov @srawlins

I confirmed that this is still happening on head.

Also note the unfortunate "potentially non-nullable" for the diagnostic on name. We should consider dropping the "potentially" when there's no question about nullability.

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/247421

[mono0926]

@olof-dev

The code example is missing E..
The following should be correct:

enum E {
  a, b;
  
  static final data = "I'm not a real enum member";
  static const moreData = 'Neither am I';
  
  String get name {
    switch(this) {
      case E.a:
        return 'AAAA';
      case E.b:
        return 'BBBB';
    }
  }
}

[olof-dev]

@mono0926 Thanks for the input. The issue is not that the code doesn't run, but rather about an incorrect analyzer warning about missing case clauses for data and moreData. If you test your code sample e.g. on dartpad.dev you'll see the analyzer warning. I believe a fix has been pushed; see a893703.

[mono0926]

@olof-dev

I think I understand your intention.
I then pointed out that the case specification contains another error that is confusing.
In the current code, removing the static field as shown below causes another error:

enum E {
  a, b;
  
  String get name {
    switch(this) {
      case a: // `E.a` is correct
        return 'AAAA';
      case b: // `E.b` is correct
        return 'BBBB';
    }
  }
}

[olof-dev]

Ah sorry, now I understand what you mean. Just to be clear, I don't think it's the sample code that is incorrect: inside the enum definition, a resolves to E.a. The thing that's incorrect is the analyzer error shown in your screenshot. I think @scheglov's fix (see above) takes care of this too, but I didn't look very closely.

[scheglov]

Yes, the fix covers exactly this issue - understanding of usage of just simple identifiers in case for switch exhaustiveness.