You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was tinkering with some ideas a couple days ago and noticed that this check fails the use of a locally scoped modifier instance if it has the same name as the composable parameter's modifier argument. I would expect the check to take scope into consideration and not fail when the modifier parameter name has been shadowed.
Notice below that the name modifier inside the Row (I wish I'd screencap'd the line numbers). Renaming that variable works around the problem.
Error
Rename Workaround
The text was updated successfully, but these errors were encountered:
I think your workaround is probably the right thing to do in this scenario if I'm honest. I'm not sure how easy it is to trace through shadowed names, and this is a compiler warning anyway :)
I'm assuming the local has a different UAST type than the parameter name or that maybe somehow PSI resolution might help do that tracing. I agree it isn't a huge deal, but it seems like a worthwhile endeavor to investigate if there's an easy solution.
If some of the test stubs were more robust (for example Modifier.then doesn't exist in the stubs so the analyzer doesn't know what to do with it). I wanted to spend more time with this over the past week, but I wasn't able to.
I was tinkering with some ideas a couple days ago and noticed that this check fails the use of a locally scoped modifier instance if it has the same name as the composable parameter's modifier argument. I would expect the check to take scope into consideration and not fail when the modifier parameter name has been shadowed.
Notice below that the name
modifier
inside theRow
(I wish I'd screencap'd the line numbers). Renaming that variable works around the problem.Error
Rename Workaround
The text was updated successfully, but these errors were encountered: