New compiler error (call is ambiguous) in X# 2.15.0.3

[leon-ts]

The following code generates a compiler error:
'Error XS0121 The call is ambiguous between the following methods or properties: 'System.Math.Max(sbyte, sbyte)' and 'System.Math.Max(int, int)'

Example code:

LOCAL dwValue := 1 AS DWORD
? Math.Max(dwValue, 2)

Environment:
X# 2.15.0.3
IDE: VS2019

This is one example. The same error occurs for other data types, as well as in other methods, for example, System.Array.Copy , etc.
In the previous version 2.14.0.4, the X# compiler successfully compiled code like this.

P.S. Today I have a day off and I took the time to install the new version of X# 2.15.0.3 instead of 2.14.0.4 and immediately ran into the error described above when compiling my projects.

[cpyrgas]

Indeed, that should compile, since there's an overload that accepts 2 DWORDs, so the compiler should had picked that. Please not that the problem happens only when the Implicit Arithmetic Conversions (/vo4) compiler option is enabled.

Leonid, can you please post samples of the other cases as well? So that we make sure that all are fixed.

And for now, a workaround would be to explicitly specify the 2nd param is a DWORD, too, for example by using

Math.Max(dwValue, 2U)

[leon-ts]

Chris,
all other cases are similar and really easy to fix with explicit type casting. Moreover, I believe that the compiler is right in these cases and I like its new behavior in such situations. But this is except for the case described at the beginning of this ticket, where, in my opinion, the compiler could itself cast the literal to the desired type (as it did in previous versions).

Generalized cases here:
Case 1

LOCAL dwValue := 1 AS DWORD
? Math.Max(dwValue, 2)
? Math.Max(2, dwValue)

Case 2

LOCAL a := <BYTE>{} AS BYTE[]
LOCAL buffer := <BYTE>{} AS BYTE[]
LOCAL fieldOffset := 0 AS INT64
LOCAL bufferOffset := 0, length := 0 AS INT
System.Array.Copy(a, fieldOffset, buffer, (INT64)bufferOffset, length)

Case 1, in my opinion, could be handled by the compiler. As for case 2, I have no complaints.

A small note to case 2: if you hover over the Copy method, there is no tooltip (only the 'NAMESPACE System' is displayed). Tickets with similar remarks to Intellisence probably already exist. Therefore, I will not create a new ticket.

[cpyrgas]

Thanks Leonid.
I agree case 2 is not a bug, since it's mixing 32 and 64 bit integers. Although interestingly c# does not report an error on it, and neither X# does when /vo4 is disabled. But I don't like this behavior. Anyway, will leave it for now. On the other hand, when you do this there is an error, which is the same as case 1:

System.Array.Copy(a, (INT64)fieldOffset, buffer, (INT64)bufferOffset, 123)

Robert, do you agree that case 1 is a bug and I should create a test for it? Or is it that due to the way that /vo4 works, this error is unavoidable?

[cpyrgas]

Oh, also @leon-ts , I don't remember such a problem logged for the intellisense issue, so I'd suggest opening a ticket for it. Including another problem, that if you hover over "Array", then the tooltip shows info about the X# ARRAY class, not the System.Array one.

[RobertvanderHulst]

Leonid, Chris,
I am not sure if I can fix this without breaking other things, but I will give it a try.
What the compiler does it match the various overloads with the arguments and their types and give each overload a "weight" based on how the parameter types match the argument types.
I can probably give literal arguments a bit lower weight than other argument types to fix this. I'll keep you informed

[RobertvanderHulst]

The reason for the issue with Math.Max(...) is that /vo4 allows you to "silently" convert between numeric types.
When the compiler finds 2 alternative method/function calls if compares the argument types with the parameter types.
Because of /vo4 the routine that compares types says "yes you can convert a DWORD to SByte" and "Yes you can convert a DWORD to an int".
That makes both alternatives likely candidates.
For now I would recommend to add a line
#pragma options("vo4", off)
before the line where you see this error and to restore the setting with
#pragma options("vo4", restore)
after the line that causes the error.

[RobertvanderHulst]

The quickest solution for this, that I can think of, is to let the compiler choose the right overload.
When it fails to find an overload, I could temporarily disable /vo4 and try again and compare the results.

[RobertvanderHulst]

I tried to implement this and it seems to work fine.

[cpyrgas]

Indeed seems to work fine and I'm not seeing any unwanted side effects. Just note that now also case 2 in #1211 (comment) does not report a warning or error anymore. I'm not really a fun of this, but that's what also c# does and what X# already did previously with /vo4 disabled, so let's say it's the correct behavior.

Confirmed fixed.