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.

Sign up for GitHub

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

Jump to bottom

deriving codegen: fold comparisons of variants without substructure into the catch-all #15618

Closed
pnkfelix opened this issue Jul 11, 2014 · 3 comments
Closed

deriving codegen: fold comparisons of variants without substructure into the catch-all #15618

pnkfelix opened this issue Jul 11, 2014 · 3 comments
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)

I was thinking of the particular case of C-like enums on the way home today.

Those cases are covered by this (not yet implemented) optimization: I really should be letting comparisons of two enums that both have no subparts (e.g. B and D in enum E { A(int), B, C(f64), D } fall through the catch-all as well, since the catch-all will have all of the information it needs to give the answers in such cases.

Once such an optimization is in place, then for C-like enums all of the cases would just fall through to the catch-all (i.e. there would be no preceding arms).
@steveklabnik steveklabnik added the A-codegen Area: Code generation label Feb 14, 2015
@steveklabnik
Copy link
Member

Triage: no idea.

@steveklabnik
Copy link
Member

Triage: same as in 2016

@nox nox mentioned this issue Mar 31, 2018
Closed
@oli-obk oli-obk added the WG-llvm Working group: LLVM backend code generation label Mar 31, 2018
@Mark-Simulacrum Mark-Simulacrum removed the WG-llvm Working group: LLVM backend code generation label Jul 29, 2018
@Mark-Simulacrum
Copy link
Member

I'm going to close this -- this essentially I believe comes down to this if -- which I think we can't remove in a completely backwards compatible manner today. If I'm wrong then we can reopen (but it becomes a really easy bug then I suspect, so it's odd that this wasn't fixed at the time).

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 13, 2023
@bors
Auto merge of rust-lang#15618 - shogo-nakano-desu:internal/port-anyma…
aaa1e8e 
…p, r=Veykril

internal: port anymap

## Description
- The anymap crate has been ported. During this process, unnecessary features for rust-analyzer have been removed.
- From the tests that were checking the existing licenses, the anymap license (`BlueOak-1.0.0 OR MIT OR Apache-2.0`) has been removed.

## Requests
- While porting the code this time, I have tried to respect the original author's intentions and have kept the comments/codes as much as possible. Please don't hesitate to tell me if you think the comments/codes also need to be appropriately modified.
- If there are any necessary changes regarding the licensing or anything else, please let me know so I can fix them.

## Issue
rust-lang/rust-analyzer#15500
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-codegen Area: Code generation C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@steveklabnik @pnkfelix @oli-obk @Mark-Simulacrum