Function call resolution can be confused

[charlesstaats]

I think it's best to give an example, which will consist of three short files.

structA.asy:

typedef import(T);
struct A_T {}

structB.asy:

typedef import(T);
from structA(T=T) access A_T;
struct B_T { };
A_T B2A(B_T) { return new A_T; }

test.asy:

from structA(T=int) access A_T as A_int;

from structB(T=int) access
    B_T as B_int,
    B2A;

void f(A_int) {}

f(B2A(new B_int));

Action: run asy test.

Expected result: Asymptote runs successfully and produces no output.

Actual result: we get the following nonsensical-sounding error:

f(B2A(new B_int));
 ^
test.asy: 9.2: cannot call 'void f(A_T)' with parameter '(A_T)'

I have tried and failed to reproduce this error without using templated imports. However, there may be something I am missing. So I still cannot guarantee that this error has anything to do with templates.

---

Workaround

In test.asy, access everything from structB, even if structB gets it from structA:

from structB(T=int) access
    A_T as A_int,
    B_T as B_int,
    B2A;

void f(A_int) {}

f(B2A(new B_int));

[johncbowman]

This simplified example

struct U {
  struct B {}
}

struct A {}

A g() {return new A;}

void f(U.B) {}

f(g());

generates the same strange error message:

f(g());
 ^
test.asy: 11.2: cannot call 'void f(B)' with parameter '(A)'

I think the only issue here is that the error message should read:

test.asy: 11.2: cannot call 'void f(U.B)' with parameter 'A'

[charlesstaats]

In the example you found, there should be an error. In the example I proposed, there should not be any error: the expected argument type and the actual argument type are both the A_T defined in structA(T=int). But the compiler fails to recognize that the two A_int types are in fact the same type.

[johncbowman]

Sorry, I was distracted by the extra parentheses around the function argument in the error message (this cosmetic issue has incidentally now been fixed in 337b9f3786c808e746aa0446784821813e5b0f4c). Charles and I just noticed that this issue was a byproduct of redundant templated imports with identical signatures, which was fixed in commit 3429cdc71e39e53a08f1784137bcbf4fc7599fde.