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.

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

Fix for decompiled calls to native Linq Api #151

Closed
wants to merge 18 commits into from

Conversation

magicmoux
Copy link
Contributor

@magicmoux magicmoux commented Jul 24, 2019

Hi @hazzik,

I've been testing DD for awhile in some side-project and I've encountered a case where the decompilation processor returns call-instructions to the Native Linq API, like

call Expression`1[...] Lambda[Func`2](System.Linq.Expressions.Expression, System.Linq.Expressions.ParameterExpression[])

If I'm not mistaken, these calls can be translated into lambdas and/or, let's say can at least be directly interpreted , here is a Processor.cs implementation to handle such cases.

Could you please take a look on it and tell me whether the solution is acceptable ?
Sorry, I'm not yet able to provide unit tests about those cases (in fact, my side-project follows a similar approach to the late KnockoutMVC you mentioned in #122 .)

Max.

var expectedParameters = m.GetParameters();
object[] convertedArguments = new object[expectedParameters.Length];
//TODO work a way to resolve non expression parameters into the expected type without resorting to a switch on the methodname if possible
for (int i = 0; i < expectedParameters.Count(); i++)
Copy link
Contributor Author

@magicmoux magicmoux Jul 24, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the really dirty part (lines 1133..1155) but it seems to be exhautive until now

@@ -1207,6 +1282,25 @@ static Expression BuildMethodCallExpression(MethodInfo m, Address instance, Expr
return Expression.NewArrayInit(arguments[0].Type.GetElementType(), initializers);
}

#region Nested Lambdas decompilation
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this region should better be name reflection decompilation

var rightExpression = rightState.Stack.Pop();
var leftExpression = leftState.Stack.Pop();
buffer.Add(Address.Merge(test, leftExpression, rightExpression, addressMap));
var rightExpression = rightState.Stack.Count > 0 ? rightState.Stack.Pop() : null;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor optimization

Max and others added 4 commits August 9, 2019 10:59
Added a special handling for backing fields to avoid annoying Linq2Entities exceptions on uncompletedly defined Computed Properties across type hierarchies:

For proof example, if you code this 
``` 
    public class LivingBeeing
    { 
    `   public virtual string Species { get; }
        [...]
    }
```
Related tests will fail
@magicmoux
Copy link
Contributor Author

Hi @hazzik,
long time no see,

could you take a look at this PR please ?
Thanks and good year's end in advance .
Max.

@magicmoux magicmoux closed this Sep 22, 2022
@magicmoux magicmoux deleted the FEAT-LinqCallsDecompilation branch September 22, 2022 13:04
@magicmoux magicmoux mentioned this pull request Sep 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants