In new solver, blocked type introduced unexpectedly in bitwise op heavy code

[Dekkonot]

I apologize for the vague title, but I don't know a better way to describe this issue since I haven't been able to isolate it.

I tried the new solver out on a SHA-512 hashing module I wrote a while ago. As a result of being a 64-bit algorithm implemented using 32-bit ones, it's very heavy on bit operations and arithmetic but is otherwise very simple. However, somewhere a type constraint isn't resolving, which results in a blocked type.

Here is the code that's producing the errors: https://gist.github.com/Dekkonot/84c0b056d330801ec2a656cb6a27ca08

Let me know if I can help any, as this is a much worse bug report than I'd like to be leaving.

[karl-police]

I wonder if the type checker ever finishes resolving for it

It's still going as I type this.

I wonder if it has to do with

local d1_front, d2_front, d3_front, d4_front = digestFront[1], digestFront[2], digestFront[3], digestFront[4]
local d5_front, d6_front, d7_front, d8_front = digestFront[5], digestFront[6], digestFront[7], digestFront[8]

Since there's a Unit Test that mentions that not working well regarding type checking on the new solver, I forgot where though but it had to do with refinements.

Actually it was for tables.

typeguard_cast_free_table_to_vector

[andyfriesen]

Minimal reproduction:

--!strict

local function f()    
    local a
    local b

    local c = a + b

    print(c + d)
end

[hgoldstein]

I just looked at the linked file and saw that there's exactly one error using the latest version of Luau, which is that we do not allow returning an under-pack, as in:

local function foo(): number
    return 42, "foo" -- Disallowed in the new solver
end

Otherwise all the math heavy code seems to be type checking. I want to say the other issue is already tracked elsewhere, but regardless I'm going to close this issue out as fixed.