Problems using methodmap as a default argument
methodmap MM {
public MM(int i) { return view_as<MM>(i); }
}
void f(MM mm = MM(0)) {}
Given this code, both 1.12 and master error, saying the argument default isn't a constant. I guess this is the expected behavior, but maybe could actually work? As a nitpick, the location given by master is off, pointing at the opening paren:
5 | void f(MM mm = MM(0)) {}
---------------^
However, if we flip around the declarations like so and actually use f:
void f(MM mm = MM(0)) {}
methodmap MM {
public MM(int i) { return view_as<MM>(i); }
}
public void main() { f(); }
Now 1.12 errors saying f's parameter doesn't have a default value. If we just don't use f at all, then it compiles. I didn't look into what ends up in the binary.
However, master segfaults here:
https://github.com/alliedmodders/sourcepawn/blob/d23897eb8ad3a4e18771e4c21837ffe50588e93b/compiler/semantics.cpp#L1934
The FunctionDecl for MM is probably wrong as fun->decl_.type.type is null, which is what return_type() returns. I didn't look into what 1.12 is actually doing.
I'm actually kind of surprised this parses. I think for now I'll just address the segfault, and figure out how to get more advanced default arguments working in 1.13.
In this case, when binding the default argument, we don't have a return type for "MM(0)" because we haven't bound "MM" yet. This is surprisingly difficult to fix and is part of a class of bugs that I'm hoping to resolve more completely, eventually. I think we'll need to recursively resolve name bindings (something the experimental compiler could do), but I'm a ways off from getting there.
I'll leave the bug open in case a simpler fix pops in mind. I think trying to harden all of Semantics against partial ASTs is a losing battle though.