Chapel: type resolve error under unusual circumstances

[ben-albrecht]

Summary of Problem

A class with a domain of strings incorrectly raises a type resolve compilation error under a specific circumstance (see code below). I was not able to reduce the reproducing example any further, but find it hard to imagine it can't be distilled further.

Steps to Reproduce

Source Code:

The following program fails to compile with the unable to resolve type error:

// Compiling gives " error: unable to resolve type (annotated below)

var watDom: domain(string);
var wat: [watDom] WAT;

class WAT { }

class R {
  var dom: domain(string); // <-- unable to resolve this type
}

class C {
  proc this(idx: int):R { return new R(); }
}

Changing almost anything in the above example results in the program compiling correctly, e.g. removing the : int type in proc this, or changing watDom to a domain(int).

For reference, the following program compiles successfully:

// For reference, this works
var r = new R();

var c = new C();
var r2 = c[2];


class R {
  var dom: domain(string);
}

class C {
  proc this(idx: int):R { return new R(); }
}

Configuration Information

• Output of chpl --version: chpl Version 1.17.0 pre-release (81b7d17)

[ben-albrecht]

This bug was reported by @marcoscleison in https://github.com/marcoscleison/cdo/issues/7

[ben-albrecht]

Tried compiling the working case with valgrind to see if were just getting lucky when it worked, but it did not change the result.

[mppf]

Removing the return type declared with the proc this should also fix it.

I think there's something going wrong with the default type constructor for R when it's trying to be created from the return type.

[daviditen]

The index type of the two domains doesn't appear to matter as long as they match. The following version fails in the same way with t set to int, real, complex, etc. But if you set them to any two different types it compiles.

config type t = string;

var watDom: domain(t);

class R {
  var dom: domain(t); // <-- unable to resolve this type
}

class C {
  proc this(idx: int):R { return new R(); }
}

[mppf]

Here's another interesting tidbit: the error occurs when trying to resolve _type_construct_R from within a call to resolve dsiNewAssociativeDom for the watDom:domain(string) declaration. That seems pretty odd.

[cassella]

If I change proc this( to proc that(, it compiles.

[bradcray]

If the observations posted here are sufficient to permit Marcos to work around the bug, could we remove the gating issue label?

[marcoscleison]

Thank you for all help.
I followed the suggestion of @ben-albrecht and refactored the declaration:

proc this(idx:int):Row{}

to

proc this(idx:int):Row{}

I compiled a problematic piece of code with this change. I will make more tests and notify here.
Thank you very much.

[marcoscleison]

Hi all,

This bug is occurring again. The same error occurred with Chrest declaration.
When I try to add some associative array in ChrestClient class:
https://github.com/marcoscleison/chrest/blob/258344d8a2e04713f40705e9554dc6dc2c7e2fa8/src/ChrestClient.chpl#L431

The compiler error with the first associative array declaration of the module:
https://github.com/marcoscleison/chrest/blob/258344d8a2e04713f40705e9554dc6dc2c7e2fa8/src/ChrestClient.chpl#L91

[marcoscleison]

This error may be related to proc this();
In CDO it was an issue related to proc this()method overloading.
In ChrestClient, we use a lot of proc this();
The first time that this issue appeared in Chrest, was when I tried to create a session class with an associative array. I could not use the class because of the issue. Then, I tried to add the associative array in ChrestClient class. The compiler trigged the error.
When I remove the associative array and declare as a simple array, the error disappears.
So, the declaration such as var myDom:domain(string); triggers the error.

[ben-albrecht]

@marcoscleison - Until this is resolved, I would suggest trying some of the changes that resolved the issue previously, such as modifying the proc this signature to have an inferred return type (assuming that's feasible in your code).

Let us know if you are unable to find a work-around, and I will mark it as a gating issue.

[mppf]

The following reproduces the issue for me, but without domains:

proc mytuple return (1,2,3);
proc f(arg:int) return arg;

class NotDomainString {
  type t;
  param locking;
  var x = f(mytuple(1)); // calls 'this', 'f'
}

proc build_not_domain(type t) {
  var x = new NotDomainString(t,true);
  return x;
}

var watDom = build_not_domain(string);
var x:CC;

class RR {
  var dom = build_not_domain(string);
}

class CC {
  proc this(idx: int):RR { return new RR(); }
}

proc f(arg:CC):RR return arg;

my PR #8926 should resolve the non-domain version of the issue but won't be in 1.17. Meanwhile the associative domain version will be resolved by PR #8921 which should be in 1.17.