Skip to content

More enum decoding#740

Merged
tothtamas28 merged 7 commits into
masterfrom
more-enum-decoding
Oct 14, 2025
Merged

More enum decoding#740
tothtamas28 merged 7 commits into
masterfrom
more-enum-decoding

Conversation

@tothtamas28
Copy link
Copy Markdown
Contributor

  • Decode single-variant enums
  • Decode multi-variant enums with direct tag encoding

@tothtamas28 tothtamas28 self-assigned this Oct 13, 2025
@tothtamas28 tothtamas28 marked this pull request as ready for review October 13, 2025 16:50
Copy link
Copy Markdown
Collaborator

@jberthold jberthold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few questions but we can merge this and follow up in the next decoding iteration.

Comment thread kmir/src/kmir/decoding.py
Comment on lines +267 to +268
case _:
raise AssertionError('Undhandled case')
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there another case? (I think not)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There isn't, I just want to explicitly indicate to the reader who's not familiar with the data model that this is the case.

Comment thread kmir/src/kmir/decoding.py

assert len(discriminants) == 1, 'Expected a single discriminant for single-variant enum'
discriminant = discriminants[0]
assert tag_index == discriminant, 'Assumed tag_index to be the same as the discriminant'
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 a bit confusing because the tag_index sounds like metadata, while the discriminants vector stores values (the ones used in #switchInt and retrieved by RValue::Discriminant). Or maybe the Single variant shape works differently and tag_index is a misnomer?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may be 100% wrong here. For P-Token though, this assertion doesn't fail.

Copy link
Copy Markdown
Collaborator

@jberthold jberthold Oct 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could check what happens when you have a non-standard discriminant in a single-variant enum:

enum Testing { Testing{ field: u16 } = 123 , }

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not try this, but according to (a more recent version of) the docs, index is always 0 for Single(index). I will fix this in the next PR.

Comment thread kmir/src/kmir/decoding.py
Comment on lines +316 to +317
assert tag_field == 0, 'Assumed tag field to be zero'
assert len(offsets) == 1, 'Assumed offsets to only contain the tag offset'
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it certain that there are no other fields shared between the different variants of an enum?
(I was unable to produce a counter-example in my experiments but the doc.s talk about the possibility of other shared fields...).

We can merge and iterate, though.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is far from certain, I only have guesses about this data model. That's why I made all the assertions with the error messages. So far it seems to work for P-Token.

Comment thread kmir/src/kmir/ty.py
Comment on lines +345 to +350
class IntegerLength(Enum):
I8 = 1
I16 = 2
I32 = 4
I64 = 8
I128 = 16
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(nit-pick) We also have IntTy in the same file and quite similar to this one. Do we need both?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same thought, but the Rust code has two separate enums, and I didn't want to innovate.

(The reason there's two might be that the other one also has a value for isize).

@tothtamas28 tothtamas28 merged commit 6c8d46e into master Oct 14, 2025
7 checks passed
@tothtamas28 tothtamas28 deleted the more-enum-decoding branch October 14, 2025 08:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants