The image explains the whole thing. hrp is binded as any, and the if statement references a completely separate condition that would not allow hrp to be inferred as falsy or nil. The function signature for OnPortalTouched_Tower is (Instance, Instance) -> ().
The line covered by the error is OnPortalTouched_TowerRush(hrp, current.TowerRush). The signature for OnPortalTouched_TowerRush is (Instance, string) -> ().
Expected behavior
I expect this error to not happen since hrp is defined as any and it isn’t checked in the if condition for being truthy or falsy. (ALSO this is in strict mode)
(Wasn’t sure about the subcategory but this seems pretty accurate. Sorry if it’s not!)
Hi! I tried to reproduce your issue using the following test code as a proxy to test the refinements here:
--!strict
const hrp : any = game:FindFirstChild("HumanoidRootPart")
local x : Instance = (nil :: any)
function takesIf(x : Instance, y : string) : ()
end
function takesElse(x : Instance, y : Instance) : ()
end
if x.Name then
takesIf(x, "hello")
else
takesElse(hrp, x)
end
However, I can’t see this error. Would you be able to share a place file to help us debug this a bit better?
How do I send a direct message/reply on here (i dont really know lol)
Reached out directly to you to get more information.
1 Like
Ok, reproduced the issue successfully. It’s a bug on our end, to do with how function arguments are unpacked. This is a minimal reproduction:
--!strict
local hrp : any = true
local boo : () -> number? = (nil ::any)
local bad : (x : number, y : number) -> () = (nil :: any)
bad(hrp, boo()) -- errors on hrp
To silence this error, you should either put parentheses around workspace.Towers:FindFirstChild(current.CurrentTower) or hoist it into a local definition like:
local towerFirstChild = workspace.Towers:FindFirstChild(current.CurrentTower)
which should silence the incorrect refinement. I will figure out how to fix this bug and report back when it’s done.
1 Like
Hi, following up here once more. There is a bug in the code you posted - the findFirstChild call returns Instance?, which must be either coerced or checked to be truthy before you can use it as an argument. The bug in our typechecking code is masking this issue.
Yes! I noticed this when I moved the value to a const binding. I intended to assert()/do a cast on it since it not being Instance? is an invariant I verify in a different part of the code.
1 Like
Hello!
Happy to report that a fix for this will go into the 734 release of Studio (next week). The problem was not actually a refinements issue after all - it was a mixture of incorrectly reporting the error location, and also truncating the types reported as part of the type mismatch.
Allowing two weeks for this change to roll out, if you still experience this issue please re-open this thread!
1 Like
