Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run-time error when using plinged CalValue data constructor field. #2

Open
rdwebster opened this issue Apr 8, 2010 · 2 comments
Open

Comments

@rdwebster
Copy link
Collaborator

A run-time error occurs when running the attached code (below).
There is a data constructor field which is a plinged CalValue.
Without the pling, the code runs successfully.

The error is:
java.lang.NoSuchMethodError: org.openquark.cal_FieldPlingBugTest.TYPE_Pling_Test.(Lorg/openquark/cal/internal/runtime/lecc/RTValue;)V

The problem doesn't happen here when the lecc_source option is turned on.

The attached code:

data PlingTest =
    PlingTest
         // A run-time error occurs when creating values of this type 
         // if the field here is plinged.
         testField :: !CalValue
    ;

doPlingTest :: String;
doPlingTest = 
    (PlingTest $ toCalValue "test")
    `seq`
    "<done>";
@indicee-michald
Copy link

This results from the type class (ie. TYPE_Pling_Test) generating a different member variable type depending on whether the pling is present or absent. If absent, testField is a RTValue. If present, testField is a CalValue. On the other hand the constructor class (ie. CAL_Pling_Test_Const) always uses a RTValue.

Note that RTValue extends CalValue. In the LECC source version this is not a problem because Java is kind enough to resolve that RTValue can be downcast to CalValue when call to the super() constructor is made.

Apparently the Java byte code needs to specify the types of arguments to a constructor explicitly, presumably to determine overloaded constructors. There are fields filled in DataConsDefinitionBuilder.createConstructor_allArgs() to keep track of the super class's type but an assumption was made that all parameter types would be RTValue. Fixed this to look up the correct type, which later gets handed of to the Java byte code generator.

@indicee-michald
Copy link

Fixed: 4c5f5b8

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants