@vasslitvinov: Any idea what's going on here?
Perhaps this may help
var f = open("", iomode.rw);
coforall i in 1..100 with (var reader = f.reader()) do for i in 1..10 do;
internal error: unexpected intent in tiMarkForForallIntent() [passes/createTaskFunctions.cpp:155]
(Just so you don't miss coforall case)
Also happens with begin.
Guessing it's the this arg, I was able to work around the forall compilation problem by adding a wrapping regular function,
proc getreader(f) { return f.reader(); }
var f = open("", iomode.rw);
forall i in 1..100 with (var reader = getreader(f)) do ;
That approach doesn't help the coforall.
Oh, oops. As @ben-albrecht and @bradcray noticed in #14386, the problem here has to do with f.reader() being a throws function, not with the this argument. My workaround "worked" as written only because the code being at implicit-module scope, the getreader() helper can call a throwing function without a try and without itself being throwing.
The error still happens when the non-method getreader() is marked throws in order to propagate f.reader()'s errors:
module foo {
proc getreader(f) throws {
return try f.reader();
}
var f = try! open("", iomode.rw);
forall i in 1..100 with (var reader = getreader(f)) do ;
}
foo.chpl:8: internal error: number of actuals (2) does not match number of formals (3) in getreader() [resolution/lateConstCheck.cpp:139]
It can still be worked around in a non-prototype-module context by making getreader() dispose of any errors reader() throws:
module foo {
proc getreader(f) {
return try! f.reader();
}
var f = try! open("", iomode.rw);
forall i in 1..100 with (var reader = getreader(f)) do ;
}
coforall i in 1..100 with (var reader = f.reader()) do for i in 1..10 do;
The compiler now reports "task-private variables are not supported for coforall/cobegin/begin".
Consider this an unimplemented feature.
As a workaround, wrap with try!, ex.:
forall i in 1..100 with (var reader = try! f.reader()) do ;
@vasslitvinov: Is there a follow-on issue capturing the unimplemented feature of adding support for extending this support to non-POD types? If not, would you create one?
@bradcray I consider #9749 to be such an issue.
Most helpful comment
Guessing it's the
thisarg, I was able to work around theforallcompilation problem by adding a wrapping regular function,That approach doesn't help the
coforall.