-
Notifications
You must be signed in to change notification settings - Fork 440
Description
Consider this program:
module A {
class Inner {
proc foo() {
return "Inner foo";
}
}
}
module B {
import A.Inner;
class Outer : Inner {
}
}
module C {
import B.Outer;
class Outermost : Outer {
}
}
module D {
import A.Inner;
import B.Outer;
import C.Outermost;
proc case1(x: int) {
override proc Outer.foo() do return "Outer foo:" + x : string;
var idk = (new Outermost()).foo();
writeln(idk);
}
proc case2(x: int) {
var idk = (new Outermost()).foo();
writeln(idk);
}
proc main() {
case1(10);
case2(20);
}
}This program was originally intended to demonstrate the incongruity of forwarding's behavior w.r.t. tertiary method overrides. However, I noticed that we somehow allow nested procedures to override methods across all uses of a class (presumably by inserting vtable entries). Pushing it a bit further, I had the nested procedure capture an outer variable, and immediately hit an internal compiler error. Without --devel:
inheritpoitrans.chpl:34: In function 'case2':
inheritpoitrans.chpl:35: internal error: AST-CAL-XPR-00823 chpl version 2.8.0 pre-release (eebfbf68b60)
Internal errors indicate a bug in the Chapel compiler,
and we're sorry for the hassle. We would appreciate your reporting this bug --
please see https://chapel-lang.org/bugs.html for instructions. In the meantime,
the filename + line number above may be useful in working around the issue.
With --devel:
inheritpoitrans.chpl:34: In function 'case2':
inheritpoitrans.chpl:35: internal error: number of actuals (3) does not match number of formals (2) in foo() [AST/CallExpr.cpp:823]
Presumably we should disallow defining override procs which capture outer variables. It's not even clear to me if we should allow defining override procs that don't capture variables (possible today) because it's strange to have a "local" definition affect a type across the entire program (by modifying its dispatch table / vtable).