Closed kg closed 7 years ago
The only bug that I can see here is the position of the IL_9C label (it should be in front of the 'try {').}
I don't see a better way to represent this control flow using if
statements; we would have to detect this kind of construct as a switch
statement to create more readable code.
(the control flow looks correct, invert the condition and reverse the then
and else
blocks to see what it's doing)
The transform for switch
over strings is currently quite fragile, runs way too late (it's a C# transform) and works only when the IL was using a switch
opcode. We'll have to rewrite that to run as a ILAst transform and detect if-goto-sequences as well as switch
opcodes.
An ILAst level switch transform would be super useful for me as well. Let me know if I can do anything to help with that (it'd let me remove JSIL's version of the switch transform). I'd offer to implement it myself but dominators and SSA both make my head hurt because I don't understand academic CS :)
This was fixed in the new decompiler engine (which just landed on the master branch) -- it no longer uses labels in the ILAst, and guarantees that branches never jump into nested blocks.
Ran into this in someone else's code that I was trying to translate and discovered that ILSpy has significant problems decompiling it:
(Sorry it's so complicated, that's about as much simplification as I could do while making it still fail to decompile)
ILSpy decompiles it to this:
and the ILAst looks like:
I'm not certain if this broken decompilation actually preserves control flow, either; my translator certainly can't turn it into working code, but that might be my fault. The output can't be compiled by CSC since the gotos violate the language rules (IL_9C is out of scope).