[New Type Solver] Bug with Overloads

[jerrythemadlad (celina)]

Getting this weird type error with the new type solver, I can work around it if I pass two Color3 arguments instead of one, but passing only one Color3 shouldn’t result in a type error since there is an overload for that. I think this might be related to version 702

In the New Luau Type Solver, overload resolution is now slightly more principled during type inference. Prior we would attempt to unify arguments with all of the possible overloads, which would often select an overload at random.

Originally posted as Problem with Overloads with New Type Solver

Expected behavior

To be able to use the first overload without any type warnings or issues.

[MercuryBromine0]

Hello! Agreed, it looks like the new solver should be able to infer that the first overload is correct. Would you be able to share a standalone RBXL that demonstrates the problem so we can figure out the right solution?

[jerrythemadlad (celina)]

Alright.
TypeOverloadError.rbxl (57.2 KB)

[MercuryBromine0]

Thank you for repro! I’ve figured out what’s going wrong here, we aren’t handling relationships between the Roblox API types (such as Color3) and table types correctly. You can see a similar issue with:

--!strict
local function ohno(c: Color3): { Color3 }
    -- This should error ... but doesn't :(
    return c
end

… because of this, we see two overloads as valid when one (the one that takes a { Color3 }) isn’t.

We’ll try to get a fix in for this ASAP.

[MercuryBromine0]

Hello! Sorry for the delay, but we’ve rolled out a fix to this issue. The snippet (which you included in your RBXL, thank you for that) now no longer errors:

--!strict
local Beam:Beam = Instance.new("Beam")
Beam.Color = ColorSequence.new(Color3.new(1,0,0))

I’m going to mark this bug as fixed, but please feel free to open another bug report if you encounter more problems!