Type Solver Beta: Type info remains after a typecast, causing invalid type errors

Bug Reports Studio Bugs
,
1

When using the new type solver beta, some type info appears to linger even after type-casts, which can cause type errors that should be invalid.

See the following example for more info:

--!strict

--Example module that represents a tuple
local module
do
	local a: {(Player)->()} = {}
	local b: {[Player]:boolean} = {}
	
	module = {a,b}
end

--a & b both resolve to {[Player]:boolean} | {(Player)->()},
--	but we know the hardcoded order of a and b.
--Attempt to typecast these values as 'any'
local a:any, b:any = unpack(module::any)

--Even though we typecasted as any, we still get the following warning from the original types;
--TypeError: None of the overloads for function that accept 2 arguments are compatible.
table.insert(a, function(plr)
	print("Player object:", plr)
end)

Beta features:

  • Luau type solver beta
  • Incremental typechecking

Expected behavior

Type-casts should fully overwrite the type info, and later errors related to the original typings should not occur.

2

This is not entirely correct, the typecast is overwriting the type info, but the actual issue involves table.insert’s intrinsic type not behaving properly with any.

table.insert({} :: any, true)
3

:sweat_smile: guess I overlooked this because the type error threw me off
I tested a bunch before filing this to make sure I didn’t misunderstand what was happening, which is exactly what happened anyways.
Thanks for the reply

1 Like
4

This looks like an actual bug with typechecking table.insert, and we’re currently in the process of going through and auditing signatures and the typechecker itself for any changes that need to be made to ensure all the builtin functions work correctly.

1 Like