-
Notifications
You must be signed in to change notification settings - Fork 84
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
Assertion failure on switch statement with case label in nested block #522
Comments
Famous "last words" haha, I just hit this in prod! Some "temporary" workaround is using this. Now that @gitoleg work has landed we probably have the machinery to solve this. Any chance (or any plans) you might work on this soon @gitoleg? (cc. @wenpen) |
I will take a look in the next few days, sure |
This is all about codegen, so I would say the previous work has nothing to do with it. Speaking about the current issue, it's still not obvious for me how to handle it properly, though I think I can suggest an approach.
The original codegen even doesn't emit any random code as far I can see, and I think we need to do the same. We could extend the current issue example (will refer it as example 1) to make it a little more interesting (example 2):
The Now, what I would do. I would create a small class for the switch stmt processing with several fields like case attributes, maybe switch variable type - and maintain a pointer to it in the So we will able to handle nested switch statements and we can fix the example 1 . @bcardosolopes what do you think? Is it a good/workable solution? Or I miss some details here? |
Right, I wasn't implying that, sorry for the misunderstanding. My initial thinking is that we could probably map these weird inner cases with synthetic gotos/labels, since they violate some scope control-flow.
Thanks for looking into this.
If the original codegen is doing that (I haven't checked), I agree we should do the same - It'd probably be nice to maintain the statement for the sake of providing unrecheable diagnostics later on, e.g. even though we ignore the emission, we could emit an empy scope with source loc on a basic block that is unrecheable. But just initially supporting lowering works for me. I also don't see any current warnings for these types of unrecheable statements in clang.
Yep, we currently track some of it already as part of
Sounds great to me, thanks for sharing a solution. Do you have any interest to work on this? |
I do) But I can't promise I'll do it soon. So if someone wants to do it earlier, just let me know, e.g. right here. Otherwise I'll return to this issue later and keep you informed about the progress/problems etc. |
@wenpen do you want to work on this one? |
@piggynl this could be a good issue to tackle as well. |
I'm still working on #528, and I feel these problems should be resolved in a unified solution. |
I have a proposal to fix this issue by modifying the definition of What's the limitation of current
|
@wenpen thanks for taking the time to propose a holistic solution, very nice writeup. I think it overall makes sense, the part that bothers me is having a design that prioritize the corner case of the language in detriment of the common use cases, but I think this is hinting at the right direction. Given your proposal, few questions:
Thanks! |
Here is an example code to discuss the mixed (common and corner) case.
Good point! I feel it's a better structure to make cir.case have a region for "normal" use case. So, I'd like to keep the current logic to scan
My thought is same with the current implement: use
Yes, it looks similar. But when I tried some code to see the cir, it crashed. Have created issue 688 for it. Will have another try later. Thanks for your suggestions~ @bcardosolopes |
ClangIR hits an assertion failure when a switch statement contains a case label that is within a nested block statement.
While code like this is unlikely to appear in production and will usually be found in test suites that try to break the compiler, it is legal code in both C and C++ and should not trigger an internal compiler error.
The text was updated successfully, but these errors were encountered: