fix(rsc): member expression usage binds unserializable variables

[james-elicx]

Description

Objects that are used in server functions can contain fields that are not serializable for client components. However, the server function may only be accessing specific properties within the object.

This is another interesting bug I found when testing out Payload CMS with Vinext.

When this scenario happens, the member expression for the variable should be bound instead of the variable itself. This would allow a complex object to be passed around, while only accessing serializable fields on it.

For safety, it will fall back to binding the bare variable for computed member expressions and shadowed objects.

As before, regression tests mostly generated by AI, although I did do a couple of extra ones myself for additional cases.

[hi-ogawa]

Thanks for tackling this. The expected behavior around this isn't of course documented as React feature, but happy to have this after review. I think Next also had some old PR mentioning whether they go for it or not, so would be nice to check up if there was a rational for and against supporting this.

[james-elicx]

It's a massive 4,000 line file so a bit hard to navigate without working in it before, but I believe their binding candidates are represented as this Name struct which has a list of the parts to build up the full member expression.

There's a retain_names_from_declared_idents function which then goes through the Names that were captured and dedupes them to the outermost use (config.cookie.name + config.cookie -> only config.cookie being bound as it's required for both) which I haven't done in this PR and would be a potential future optimisation.

So it seems like they definitely take the approach of binding full member expressions rather than bare variables where possible.

[hi-ogawa]

I think the reference I had in mind was this vercel/next.js#66464. It looked like this was one simplification path which they didn't eventually take. Are the examples brought up there something relevant to this PR?

[hi-ogawa]

Ah okay, it looks like that's indeed config.cookie.name + config.cookie case.

EDIT: Oh wait, so that's probably fixed in other PR by vercel/next.js#66601.