Fix singleton parameters in overloaded functions

[m4fh]

• Fixes Overloaded functions with singleton parameters error incorrectly in new type solver #1691
• Fixes String literals aren't refined to singleton types in function overloads #1589

[m4fh]

This code snippet is working now, and you get autocompletion with luau-lsp too (which was broken previously).

--[[
    local date: {
        day: number,
        hour: number,
        isdst: boolean,
        ... 6 more ...
    }
]]
local date = os.date("*t", 0)

[aatxe]

Looks good, just needs to be flagged properly! Thanks!

[m4fh]

Thank you for the review! I think I’ve fixed it.

On a side note, while this does fix most of the issues I had with overloaded functions, I’ve noticed that it sometimes still doesn’t work. After some debugging, it seems that when a type alias or type function is used to 'create' the functions before intersecting them, fnType becomes a pending type (I don’t remember the exact name, to be honest). As a result, getExpectedCallTypesForFunctionOverloads can't determine the expected types.

I assume this could be fixed by somehow waiting for the type to resolve, but I’m not familiar enough with the codebase to know how to do that. I’d love to figure it out, and maybe there’s a simple approach I’m missing? No worries if not, I just wanted to make sure 😅

[aatxe]

Yeah, the change you've got here is to constraint generation, which is the first pass of the type inference system. Things like type aliases are not resolved yet, and many things have free or blocked types before inference starts to run. @hgoldstein has been working on a bunch of bidirectional typing stuff, and this should be in the same vein as that really. There'll need to be some work in constraint solving roughly equivalent in some way to what you've done here, but even fixing the constraint generation side of things for the cases where we can resolve things eagerly is a solid improvement.

[m4fh]

Yeah, the change you've got here is to constraint generation, which is the first pass of the type inference system. Things like type aliases are not resolved yet, and many things have free or blocked types before inference starts to run. @hgoldstein has been working on a bunch of bidirectional typing stuff, and this should be in the same vein as that really. There'll need to be some work in constraint solving roughly equivalent in some way to what you've done here, but even fixing the constraint generation side of things for the cases where we can resolve things eagerly is a solid improvement.

I see, so I definitely bit off more than I could chew here 😅. Thank you for taking the time to explain it to me. I'm happy I could be of any help whatsoever.