[nem-bug] [Nemerle 0000770]: subtle overloading resolution bug, involving type inference of local functions

[feedback at nemerle.org]

The following issue has been RESOLVED.
======================================================================
<http://nemerle.org/bugs/view.php?id=770> 
======================================================================
Reported By:                aleksey
Assigned To:                malekith
======================================================================
Project:                    Nemerle
Issue ID:                   770
Category:                   Compiler (type engine)
Reproducibility:            always
Severity:                   minor
Priority:                   urgent
Status:                     resolved
Resolution:                 fixed
Fixed in Version:           
======================================================================
Date Submitted:             09-29-2006 22:34 CEST
Last Modified:              12-19-2006 16:47 CET
======================================================================
Summary:                    subtle overloading resolution bug, involving type
inference of local functions
Description: 
This happens under certain circumstances when passing parameters to
System.Console.Write or WriteLine function. Error message is always the
following:

expected array [System.Object]+, got "some type" in call result
: "some type" is not a subtype of array [System.Object] [simple require]
("some type" is return type of a local function involved)

Minimal code to reproduce the problem:
System.Console.WriteLine("{0}", (_+_)(1,1))

Another piece of code which reproduces the problem:
def y(i) { i(1, 2) }
def x(i, j) { i + j }
System.Console.WriteLine("{0}", y(x));
======================================================================

----------------------------------------------------------------------
 malekith - 12-16-06 12:24 
----------------------------------------------------------------------
The example with string instead of array[object] also doesn't work.

This is because of how delayed type inference works. It goes roughly like
that: The typer sees:
  def z(x,y){x+y}
and it doesn't know the type of 'x', so it cannot resolve '+', so it
leaves 'x+y' on the queue of expressions to be typed later. Therefore the
return type of 'z' is not known. Then the typer sees:
  z(1,2)
this is fine (we don't have any constraints yet on 'x' and 'y', so ints
fit just fine), but the type of that expression is not known (actually it
is known to be a subtype of object). 

Then it sees a call to 'test'. There are two overloads and both fit
(because we don't know the type of 'z(...)' yet). The more specific one is
selected (using regular overload resolution rules), which is the one with
array[object], so the return type of 'z' gets lower bound of
array[object]. 

Then the typer goes back to 'x+y' (which was stored on the queue), and
tries to type it. It finds out that x and y are ints, so there is a single
choice of '+' for them, but it happens not to return array[object], which
is where it fails.

The solution could be not to select the most specific overload when some
of the types are uncertains or something like that. But I'm affraid it is
not going to work well in some other cases... Need to think about it.

----------------------------------------------------------------------
 malekith - 12-19-06 16:47 
----------------------------------------------------------------------
I've implemented a fix on trunk, however it is more like a hack. In general
we do not commit to a single, best overload when we still have some
parameters that have no Hint (which means they are of a totally unknown
type), except, when it is the only possible overload, we're in a special
second pass of delayed typings or it is == or !=. The last part is a hack,
it might be a good idea to commit to a single overload also in some other
cases but the comparison operators seem to be crucial.

Rev 7120

Issue History
Date Modified  Username       Field                    Change              
======================================================================
09-29-06 22:34 aleksey        New Issue                                    
12-16-06 12:14 malekith       Assigned To               => malekith        
12-16-06 12:14 malekith       Priority                 normal => urgent    
12-16-06 12:14 malekith       Status                   new => assigned     
12-16-06 12:14 malekith       Description Updated                          
12-16-06 12:14 malekith       Additional Information Updated                    
12-16-06 12:24 malekith       Note Added: 0001582                          
12-19-06 14:13 malekith       File Added: badness.patch                    
12-19-06 16:47 malekith       Status                   assigned => resolved
12-19-06 16:47 malekith       Resolution               open => fixed       
12-19-06 16:47 malekith       Note Added: 0001586                          
======================================================================