Verse compiler bug fixes

In 28.10, the verse team fixed two compiler bugs that may result in new errors occurring in your code.


Override accessibility

The first bug was that the compiler did not calculate accessibility of an overridden member of a class or interface correctly. The accessibility of a member is determined by the base definition of the member: if it is defined in a class or interface that isn’t accessible from some scope, then that scope should not be able to access the member. Before 28.10, the Verse compiler incorrectly allowed access to such an inaccessible member if it was overridden by a class that is accessible from the scope.

For example:

Submodule := module:

    # A class internal to Submodule that defines Method.
    # (Definitions that omit an access specifier default to <internal>)
    internal_base_class := class:
        Method<public>():void={}

    # A public subclass that overrides Method.
    public_sub_class<public> := class(internal_base_class):
        Method<override>():void={}

Function(Instance:Submodule.public_sub_class):void=
    Instance.Method() # Error in 28.10+

In this example, the call to Instance.Method() from Function was previously incorrectly accepted by the compiler, but in 28.10+ will be rejected. The straightforward fix is to add the access specifier to internal_base_class:

internal_base_class<public> := class:

(super:) call type checking

The second bug was that using (super:) to call a base class’s implementation of the current function was type checked as though it had the same signature as the calling function that overrides it.

For example:

base_class := class:
    Method():any=0

sub_class := class(base_class):
    Method<override>():int=(super:)Method()

This code was previously incorrectly accepted by the compiler. In 28.10+, the attempt to use the result of the (super:)Method() call as an int will be correctly rejected. In this case, you can fix the error by changing the return type of the base class’s Method from any to int:

base_class := class:
    Method():int=0

Unfortunately, not all code that is flagged by this new error will be so easy to fix. This bug meant that the compiler previously accepted both code with type mismatches, and code without type mismatches that the compiler is not yet powerful enough to verify.

1 Like

Can we get the second bugfix reverted? It was incredibly useful and could be used to implement mutables in parametric classes. Since this is being prevented now and we got no substitution, some projects broke and can’t be fixed.

I basically used it like this:

base_class:=class:
    var Value: any
    GetValue(): any = Value
sub_class(t: type):=class(base_class):
    GetValue(): t = (super:)GetValue()
    SetValue(InValue: t): void = set Value = InValue

Now this is impossible to fix. When i reported this bug, i also begged to not fix it without providing an alternative solution, like mutable fields for parametrics :smiling_face_with_tear:

@NickDroz @Daigoro Thank you for your report! Can you please re-post using the “New Issue” option on the Issues and Bug Reporting forums? Posts with this feature are connected directly into our development team so we can quickly get to them!

For more information, such as how to get the reference ID, please check out the article here: Using the Creative and UEFN Bug Reporting Form

I remember the last time where i submitted a report, didn’t end good. Nah, i kindly refuse, but thanks for letting me know.