Return and parameter types of methods is not entirelly correct.

[ElektroKill]

Describe the bug When a method does not have a physical counterpart, the return type and parameter types are unknown and need to be inferred. In my testing, it looks like the return type of these methods is not inferred at all and is just set to System.Object. This causes many boxing issues to occur when these methods are used.

In this method, we see that the parameter was inferred but the return type is System.Object. If we look at the IL code we see that the return value is boxed as System.UInt32. However, if we look at the usage of this method we see that the return value is unboxed as System.Int32. This leads to an exception at runtime since the types do not match. The return type should be inferred so that hopefully casts can be inferred at later stages of recompilation. Furthermore, this is a bit more nitpicky but the parameter of __VMFUNCTION__07F2 could also be inferred as System.Byte[] instead of System.Array for greater accuracy.

To Reproduce Attempt to devirtualize the sample provided in the zip below. NOTE: there are other methods in this unrelated to the problem. sample.zip

[Washi1337]

This will require quite some architectural changes probably, as reliable return type inference will most likely require type analysis on an inter-procedure level.

Type inference is done by inspecting all data flow sinks of a value (i.e. where the value is consumed), and inferring some common base type between them. Sinks of a return value are places that are near the original call of the subroutine, which usually resides in another subroutine.