this happens in tests, which explicitly call into the simplifier with specific subnodes. in the test we call on an invocation expression with a null expression child.

I'm just going to say this list of where clauses is terrifyingly long.

:)

Why isn't this calling Syntaxfactory.ElementBindingExpression then? And then why do we need the overrides at all?

(This PR seems to expose a common way to create these, and then the feature gets a way to avoid use of that API...?)

So the design here is that you express the high level idea at the generator level, it then produces the right low-level C#/VB syntax for that concept. It turns out that syntax-level concept of an element binding for VB is an invocation expressoin. i.e. when you want to index into a nullable array in VB, you just write: a?(1), while in C# you do a?[1].

So this allows feature to say "i need to index into a nullable array" and get the right syntax without having to know about VB.

N/m i see what you're saying. The issue here is that it wants to create the invocation using the full arg list it had before, i.e. not a List<ArgumentSyntax> but a ArgumentListSyntax. The generators are not designed for that case. So this feature still does the work of doing it manually, but the generator at least exposes the entrypoint the customer and others would find valuable.

Should we split the two PRs then?

Up to you. Seems excessive to me. If you want that, LMK :)

Hmm, we probably should, or at least rebase the changes and break up the history. If we have to revert either the API change or the behavior change we don't want to accidentally revert the other one with it.

Sounds good. i will do that now.