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

deriving codegen: add intrinsic to map enum instance to its variant index #15620

Closed
pnkfelix opened this issue Jul 11, 2014 · 6 comments
Closed
Assignees
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@pnkfelix
Copy link
Member

Spawned off of #15503 (comment)

The other piece of the story there would be speeding up the mapping from the value to its discriminant index. Currently I am just emitting that code in place as another match statement, but in principle that could (and should?) be replaced by a compiler intrinsic, as discussed here: #15375 (comment)

@ghost
Copy link

ghost commented Jul 12, 2014

This is already exposed in the TyVisitor intrinsic: http://static.rust-lang.org/doc/master/core/intrinsics/trait.TyVisitor.html#tymethod.visit_enter_enum. Obviously, using that could be undesirable from a code bloat perspective so a separate intrinsic can still be a good idea.

@pnkfelix
Copy link
Member Author

The semantics of this intrinsic need to be consistent with whatever we decide to do for #15523

@emberian
Copy link
Member

emberian commented Aug 6, 2014

For my usecase, I don't really care about order, just equality, and this would let me compare token types without a very large match (that compiles to pretty poor code) and without transmuting to a fragile representation.

@pnkfelix
Copy link
Member Author

do note also huon's point here: #15375 (comment)

@durka
Copy link
Contributor

durka commented Mar 8, 2016

Should this still be open? What's the point of a variant index intrinsic?

@pnkfelix pnkfelix self-assigned this Mar 25, 2016
@pnkfelix
Copy link
Member Author

pnkfelix commented Oct 3, 2016

Due to huon's point from #15375 that the ordering (in terms of the value used for the discriminant) might change over time with changes to the compiler, plus the fact that the comments here indicate that the important thing is equality comparisons, not an ordering nor assignment to integer values, I am just going to close this.

@pnkfelix pnkfelix closed this as completed Oct 3, 2016
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

4 participants