Closed wandernauta closed 1 month ago
Yeah so the successor of a class with type arguments and its methods are declared in an InstantiationContext instead of the normal scope. Since the InvokeConstructor node does not name generic type arguments it is rewritten normally and looks for the successor in the normal scope. We could add a case to check for this case where a constructor does not name any type arguments but the class does. However in Java it's allowed to instantiate a class while omitting the type arguments so if we want to support that. I guess we'd have to make the InvokeConstructor call refer to the version that is always instantiated. (the one with keepBodies=true) We could do that explicitly or make that version the successor of the old class in the normal scope.
Or we can choose to not support the Java edge case, and leave it for the person who will finalize the generics support. That might make things easier? It's just one line in the check method of the relevant nodes, right?
Yes that's also possible, I have no particular preference
Related: e90a6745fae3499983e240b2adb11fb903d7b40c
The following (bogus) PVL program causes VerCors to crash with a seemingly unrelated exception:
I would instead expect a type error to be logged. Providing too many type arguments causes VerCors to log a type error, as expected. Providing angle brackets but no type arguments is a syntax error.
Version: https://github.com/utwente-fmt/vercors/commit/33132556d2619e2dd88e55f2a5dadd5aa03869ce (dev branch).
This issue was found by fuzzing.