Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect 'not all cases are covered' when using enums with nonconsecutive items #3060

Closed
zielmicha opened this issue Jul 4, 2015 · 7 comments

Comments

Projects
None yet
7 participants
@zielmicha
Copy link
Contributor

commented Jul 4, 2015

This:

type DbusTypeChar* = enum
  dtArray = 'a',
  dtBool = 'b',
  dtStruct = 'r'

type DbusType* = object
  case kind*: DbusTypeChar
  of dtBool:
    discard
  of dtArray:
    itemType*: int
  of dtStruct:
    keyType*: int
    valueType*: int

produces compile error:

a.nim(7, 3) Error: not all cases are covered

While this works:

type DbusTypeChar* = enum
  dtArray = 'a',
  dtBool = 'b',
  dtStruct = 'c'

type DbusType* = object
  case kind*: DbusTypeChar
  of dtBool:
    discard
  of dtArray:
    itemType*: int
  of dtStruct:
    keyType*: int
    valueType*: int

(tested on 0.11.3 and devel)

@Perelandric

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2015

According to the manual on enumeration types...

An explicit ordered enum can have holes... However, it is then not an ordinal anymore,

Then under case statements...

For non ordinal types it is not possible to list every possible value and so these always require an else part.

So I'm pretty sure this is correct behavior according to the manual.

It does seem like non-ordinals of this type could be handled, unlike strings; it would be useful.

@zielmicha

This comment has been minimized.

Copy link
Contributor Author

commented Jul 6, 2015

Or maybe the error message should be something like "case without else on non-ordinal". I've spent some time looking for values I've missed.

@Varriount

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2015

Perhaps the error message should be modified to "not all cases are covered for non-ordinal type 'DbusTypeChar'"?

@ephja

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2015

I do not approve of this behavior for enums, because it means you can't enforce the case statement to be exhaustive. Exhaustiveness and an 'else' block can be useful too for enums when parsing buffer data.

@andreaferretti

This comment has been minimized.

Copy link
Collaborator

commented Aug 10, 2018

The error has changed to Error: selector must be of an ordinal type.

That said, I am not sure why an exhaustiveness check cannot be performed on a non ordinal enum - the possible values are certainly known at compile time in any case

@Araq

This comment has been minimized.

Copy link
Member

commented Aug 10, 2018

@andreaferretti That's a different regression, working on it...

@andreaferretti

This comment has been minimized.

Copy link
Collaborator

commented Oct 10, 2018

The error has changed to Error: low(kind) must be 0 for discriminant

@Araq Araq closed this in #9957 Dec 19, 2018

Araq added a commit that referenced this issue Dec 19, 2018

Fixes #3060 and adds error checking for invalid else branches in obje…
…ct variants (#9957)

* Fix semRecordCase

* Fix ftpclient.nim

* Check for ordinal type

* Check tyRange for exhaustiveness
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.