Remove `EnumItemDiscriminant` class
Per the Rust reference: https://doc.rust-lang.org/reference/items/enumerations.html
Meaning that all possible enum items (identifiers, structs or tuples) can have a discriminant, even in 1.49 - however, the feature was still experimental back then.
Still, we need to remove the EnumItemDiscriminant class and instead add an optional std::unique_ptr<Expr> to the base EnumItem class, for all enum items to use it if required.
Eventually we'll also need to fix the parser to handle this
Hey, I think I'd like to work on this. Can you please provide resources on what I can do with this as well as which files I might have to work on along with a slightly more detailed description of what I might need to do ? Thanks for helping me out. @CohenArthur
hi @varun-r-mallya, sorry about this another contributor already asked to work on the issue beforehand on Zulip. apologies. if you want, you can do the same thing in our HIR and remove the HIR::EnumItemDiscriminant class
hi @CohenArthur i would like to contribute to this issue
hi @varun-r-mallya, sorry about this another contributor already asked to work on the issue beforehand on Zulip. apologies. if you want, you can do the same thing in our
HIRand remove theHIR::EnumItemDiscriminantclass
Sure. Can I have details on that and it's corresponding issue as well ?
@varun-r-mallya there isn't much more to say haha. have a look in the code for the class, find it, and then just delete it. this will cause a bunch of compilation issues and you'll need to fix them as well. if you are still having trouble once you're done with that feel free to ask more questions
hi @varun-r-mallya and @saeitoshi-10, are you guys working on this, i'd love to take a crack at this
hi @varun-r-mallya and @saeitoshi-10, are you guys working on this, i'd love to take a crack at this
So i just found some time so I think I'll be continuing work on this :)
I've added just one commit and amended and force pushed while checking which tests pass and fail. To keep things clean, I've created a new PR and closed the previous one.
The second PR also contains the commit from the first one due to one function in AST being dependent on it's HIR counterpart. The changelog in the second PR refers only to the most recent commit in it and this is causing a required check to fail. Once the first PR is merged, this will be fine (I think).
Nice work. Don't worry about creating new PRs when you force-push, though -- force-pushing your own branches is extremely common for this project