Open meetesh06 opened 3 weeks ago
Thanks for posting. This is a known limitation of our current type inference. The fix is fairly involved bc it isn’t just about the type inference portion (which is also more complex than what’s proposed here). I had a PR to implement it prior to OSS, but we also need to update our mutability inference accordingly.
We’re treating this one as an enhancement, not a bug, since type inference is already best effort and intentionally conservative.
What kind of issue is this?
Link to repro
https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAwhALYAOhCmOAFMJQIwC+AlEcADrFEA2CHEQDa-CAEMAJnkwBzADREwQgDKSZ8gLpEAvESgqAyjgk4E9NBP4r2vIgKGiIOABYIYSlTgDybjzr6hggmZhZWNgh2mPaOwpDkCABqEjAA3LF4aET0LJw8fA4Jyal6ymoasnIZfKxECJFcsUUUJTBl3n7u6bGsvLGCwjAIYB2tKT18wziwxMNgNX2YIKxAA
Repro steps
The following output is obtained after the InferTypes pass.
I would expect the type (
TFunction<BuiltInSetState>
) ofsomeVar$51
phi node to propagate at instruction 19 but it does not happen.I was able to figure out why it happens. During SSA generation the phi node's identifier has a
typeId
which is different than the identifier at instruction 19.I tried to fix this by adding the following patch (to be run right after enterSSA pass) which just makes sure in such cases we always use the same
typeId
:With this patch however 6 testcases fail:
The mutable range inference pass gets a weird range (I am not sure how starting location can be zero, I guessed that the mutable range must start at atleast instruction idx + 1).
inference fails with a cycle detected.
I would appreciate some insights, thank you.
How often does this bug happen?
Every time
What version of React are you using?
19