jakt icon indicating copy to clipboard operation
jakt copied to clipboard

Return type inference doesn't reject incompatible returns

Open linusg opened this issue 2 years ago • 5 comments

function foo() {
    return true
    return "foo"
}

This should not compile, but generates the following:

#include "runtime/lib.h"


String foo();

String foo(){
using _JaktCurrentFunctionReturnType = String;
{
        return (true);
        return (String("foo"));
    }
}

linusg avatar May 20 '22 20:05 linusg

Similarly for conditional returns:

function foo() {
    if true {
        return 42
    }
}
#include "runtime/lib.h"


void foo();

void foo(){
using _JaktCurrentFunctionReturnType = void;
{
        if (true) {
            return (static_cast<i64>(42LL));
        }
    }
}

linusg avatar May 20 '22 20:05 linusg

I intend to fix this. My solution is to infer the return type to be the type of the first return statement anywhere in the function body and reject any future return statements if they have a different type. The conditional return issue is caused by the type checker only scanning the top level block and not any child blocks.

Lubrsi avatar May 21 '22 17:05 Lubrsi

I took a look as well, but the return statement never checks if it is of the correct type. I don't think it has anything to do with the blocks

mattisboeckle avatar May 21 '22 18:05 mattisboeckle

I already have a working fix for void or unknown return types, but the other types are trickier, because afaik there is no check for if the expr-value can be cast to the return type.

Which causes problem in code like

function foo() -> i32 {
    return 1
}

as the Literal 1 is considered an i64

mattisboeckle avatar May 21 '22 18:05 mattisboeckle

If this is the intended behaviour, there are some tests that are wrong. Namely: passing_array and mutable_unwrap

Can I get confirmation on if those are wrong?

mattisboeckle avatar May 22 '22 10:05 mattisboeckle