Skip to content

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

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom
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
# for free to join this conversation on GitHub. Already have an account? # 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