Macro expansion inferes with type deduction

[GoogleCodeExporter]

The following test case might not be a bug - it might also a misunderstanding 
from my side. 
If it's not a bug then the behaviour is at least surprising.

Method testGood() introduces 2 let values which are pass to assertEq().
Method testBad() does not use let values; instead, the expressions for the let 
values are directly used as
arguments for assertEq().
My expectation is that both methods have same semantics. In reality, method 
testGood() compiles and runs while 
method testBad() produces the following messages:

D:/.../tart/trunk/lib/testing/tart/testing/Asserts.tart:55:       Unify: 
{Result: 
int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#constant_int|%%T
-1391^|%%T-1392^} != {Result: 
int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#constant_int|%%T
-1404^|%%T-1405^} with 
{%T:{Result:int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#cons
tant_int|%%T-1391^|%%T-1392^}}
   Neither {Result: int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#constant_int|%%T-1391^|%%T-1392^} nor {Result: int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#constant_int|%%T-1404^|%%T-1405^} is more specific than the other.
D:/.../tart/trunk/lib/testing/tart/testing/Asserts.tart:55:    Unify: 
%%T-1379={Result: 
int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#constant_int|%%T
-1391^|%%T-1392^} != {Result: 
int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#constant_int|%%T
-1404^|%%T-1405^} with {%T:{Result: 
int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#constant_int|%%T
-1391^|%%T-1392^}}
D:/.../tart/trunk/lib/testing/tart/testing/Asserts.tart:55: info: def 
assertEq[%T](expected:%T, actual:%T) with {%T:{Result: 
int8|int16|int32|int64|uint8|uint16|uint32|uint64|float|double|#constant_int|%%T
-1391^|%%T-1392^}} [IdenticalTypes]
..\..\tart\trunk\compiler\lib\Sema\TypeTransform.cpp:289: Fatal error (Type 
constraint not handled)

import tart.collections.ArrayList;
import tart.collections.Iterators;
import tart.testing.Test;

@EntryPoint
def main(args:String[]) -> int32 {
  return Test.run(BugTest2);
}

class BugTest2 : Test {

  // This test case works.
  def testGood() {
    let no = 500;
    let list = ArrayList[int]();
    for i in Iterators.CountingIterator(no) {
      list.add(i);
    }
    for i in Iterators.CountingIterator(no) {
      let exp = i+1;
      let act = list[i]+1;
      assertEq(exp, act);
    }
  }

  // This test case produces a compiler error.
  def testBad() {
    let no = 500;
    let list = ArrayList[int]();
    for i in Iterators.CountingIterator(no) {
      list.add(i);
    }    
    for i in Iterators.CountingIterator(no) {
      assertEq(i+1, list[i]+1);
    }
  }
}

Original issue reported on code.google.com by kai.na...@gmail.com on 7 Dec 2010 at 5:28

Attachments:

• BugTest3.tart

[GoogleCodeExporter]

Interesting. I'll look into it.

Note that I've recently improved the error messages for failures like the 
above, but haven't pushed it out yet.

Original comment by viri...@gmail.com on 7 Dec 2010 at 5:45

• Changed state: Accepted
• Added labels: Component-Compiler, OpSys-All, Priority-Medium, Type-Defect

[GoogleCodeExporter]

Modified the type solver and added tests.

Original comment by viri...@gmail.com on 17 Jan 2011 at 3:40

• Changed state: Fixed