IndexDefect on --verbosity:3 when compiling nimbus
#24021
Labels
Comments
|
also on |
|
Minimal options would be Happens here: For some reason the compiler is producing a set |
metagn
added a commit
to metagn/Nim
that referenced
this issue
Oct 12, 2024
|
Minimized: type
FooKind = enum
a
b
BiggerEnum = enum b1, b2, b3, b4, b5, b6, b7, b8, b9, b10
Foo = object
case kind: FooKind
of a: discard
else:
z: BiggerEnum
proc p(foo: Foo, val: int) =
case foo.kind
of a:
discard
else:
discard foo.zThe type for the field check on Found the root cause #24290 |
Araq
pushed a commit
that referenced
this issue
Oct 12, 2024
…[backport] (#24290) fixes #24021 The field checking for case object branches at some point generates a negated set `contains` check for the object discriminator. For enum types, this tries to generate a complement set and convert to a `contains` check in that instead. It obtains this type from the type of the element node in the `contains` check. `buildProperFieldCheck` creates the element node by changing a field access expression like `foo.z` into `foo.kind`. In order to do this, it copies the node `foo.z` and sets the field name in the node to the symbol `kind`. But when copying the node, the type of the original `foo.z` is retained. This means that the complement is performed on the type of the accessed field rather than the type of the discriminator, which causes problems when the accessed field is also an enum. To fix this, we properly set the type of the copied node to the type of the kind field. An alternative is just to make a new node instead. A lot of text for a single line change, I know, but this part of the codebase could use more explanation.
narimiran
pushed a commit
that referenced
this issue
Oct 23, 2024
…[backport] (#24290) fixes #24021 The field checking for case object branches at some point generates a negated set `contains` check for the object discriminator. For enum types, this tries to generate a complement set and convert to a `contains` check in that instead. It obtains this type from the type of the element node in the `contains` check. `buildProperFieldCheck` creates the element node by changing a field access expression like `foo.z` into `foo.kind`. In order to do this, it copies the node `foo.z` and sets the field name in the node to the symbol `kind`. But when copying the node, the type of the original `foo.z` is retained. This means that the complement is performed on the type of the accessed field rather than the type of the discriminator, which causes problems when the accessed field is also an enum. To fix this, we properly set the type of the copied node to the type of the kind field. An alternative is just to make a new node instead. A lot of text for a single line change, I know, but this part of the codebase could use more explanation. (cherry picked from commit 1bebc23)
narimiran
pushed a commit
that referenced
this issue
Oct 23, 2024
…[backport] (#24290) fixes #24021 The field checking for case object branches at some point generates a negated set `contains` check for the object discriminator. For enum types, this tries to generate a complement set and convert to a `contains` check in that instead. It obtains this type from the type of the element node in the `contains` check. `buildProperFieldCheck` creates the element node by changing a field access expression like `foo.z` into `foo.kind`. In order to do this, it copies the node `foo.z` and sets the field name in the node to the symbol `kind`. But when copying the node, the type of the original `foo.z` is retained. This means that the complement is performed on the type of the accessed field rather than the type of the discriminator, which causes problems when the accessed field is also an enum. To fix this, we properly set the type of the copied node to the type of the kind field. An alternative is just to make a new node instead. A lot of text for a single line change, I know, but this part of the codebase could use more explanation. (cherry picked from commit 1bebc23)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Nim Version
2.0.8
Current Output
No response
Expected Output
No response
Possible Solution
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered: