Incorrect decompiled code (missing casts)

[pardeike]

dnSpyEx version

6.4.1

Describe the Bug

If you compare System.String.Equals(string, string) between reference code, dnSpyEx and ILSpy, you will see some functional differences. While this is a specific case, other examples exist that are similar:

Reference .NET code

public static bool Equals(String a, String b)
{
    if ((Object)a == (Object)b)
        return true;

    if ((Object)a == null || (Object)b == null)
        return false;

    if (a.Length != b.Length)
        return false;

    return EqualsHelper(a, b);
}

dnSpyEx

public static bool Equals(string a, string b)
{
	return a == b || (a != null && b != null && a.Length == b.Length && string.EqualsHelper(a, b));
}

ILSpy 8.1.0.7455

public static bool Equals(string a, string b)
{
	if ((object)a == b)
	{
		return true;
	}
	if ((object)a == null || (object)b == null)
	{
		return false;
	}
	if (a.Length != b.Length)
	{
		return false;
	}
	return EqualsHelper(a, b);
}

How To Reproduce

Just decompile mscorlib .NETFramework v4.0 and compare between ILSpy and dnSpyEx and the reference code at the given url. One problem that arrise is that the dnSpy code looks like a recursion where String.Equals() calls String.== and the other way around:

public static bool operator ==(string a, string b)
{
	return string.Equals(a, b);
}
public static bool Equals(string a, string b)
{
	return a == b || (a != null && b != null && a.Length == b.Length && string.EqualsHelper(a, b));
}

which of course isn't true.

Expected Behavior

The result should make sure the == operator is not called on (string, string) as shown in the code of ILSpy.

Actual Behavior

Some casting should be shown in the decompiled code (just like in ILSpy)

Additional Context

No response

[funkvps]

seems also related to the version of ILSPY engine.
#5

[ElektroKill]

Hi, the issue you are facing is a known limitation of the current decompiler engine. the engine is simply incapable of inserting the missing object casts there as it cannot predict the produced C# code will reference the correct member. Modern versions of ILSpy implement a sort of resolver that implements the C# member resolution specification. Using this resolver they can determine if additional casts need to be inserted or if additional qualifications on member references are needed.

Implementing such analysis logic in the current ILSpy 2.4 engine would be hard so this problem will likely be fixed when dnSpy moves to the newest ILSpy decompiler engine in the future. Progress on that is tracked by issue #5 as mentioned by @funkvps.