Closed cmeyertons closed 1 year ago
That is interesting. There is a similar test to one you've submitted:
Only difference is in where T
definition. One we have with class
, the submitted is without class
. Adding class
to your test fixes it. And removing breaks our test.
The class constraint fixing it is quite bizarre! Your solution is more elegant than mine - I just wasn’t sure I could apply it as globally as you did and tried to leverage the knowledge of the caller.
Looks great to me. What is the turnaround time on getting a fix published? On Monday, we will test adding the class constraint as a workaround.
What is the turnaround time on getting a fix published?
I was going to review one other PR, and then wanted to publish a new version. It is already past my deadline as I was going to do that on the past weekend (it's Monday here already).
I just wasn’t sure I could apply it as globally as you did
When there is an upcasting (cast to a parent type) - it should be safe to remove. I was worried about explicit interfaces, but tested them locally - works as expected.
Sounds great! Thank you very much for the quick resolution on this one!
It seems like there is a bug when there is an interface property involved -- when there are multiple implementations of the interface, the decompiler generates a ternary of each available implementation type.
However, in the initial decompile, we have a IQueryable (not TInterface), so we shouldn't have to do any kind of ternary logic at all.
Please see https://github.com/hazzik/DelegateDecompiler/pull/198 for the repro case.
Update: PR now has a working solution that appears to pass all tests, but it might not be fully comprehensive for what we are doing.
If I detect that a cast is occurring from the
T
fromQueryable<T>
and is the expressions parameter, we inform the method body decompiler the type we want to use isT
, not a ternary of all of the possible implementations.