Fix null check optimization for IQueryable/DbSet types in LINQ queries

[Copilot]

Fixes #35598.

[roji]

nit: with pattern matching just writing out is ConstantExpression { Value: null } seems simpler, IMHO

[cincuranet]

The method IsNullConstant is already there, hence it seems reasonable to use it.

[roji]

I'm proposing to remove it, as a code modernization.

[cincuranet]

In that case I'd like to do in another PR, because that method exists in other places too.

[roji]

OK

[roji]

Is this correct? What happens if there's a local variable of type DbSet/IQueryable and which really does happen to be null (because of some condition in the user's code)?

(in #35598 it's asserted that this is a regression, I wonder what was the change from 8 to 9 which triggered it)

[cincuranet]

What happens if there's a local variable of type DbSet/IQueryable and which really does happen to be null (because of some condition in the user's code)?

Can you show a code?

[roji]

Something like:

using var db = new MyContext();
var ids = someFlag ? db.Items.Select(c => c.Id) : null;
var results = await db.Items.Where(r => ids != null && ids.Contains(r.Id)).ToListAsync();

[roji]

One more note:

(in #35598 it's asserted that this is a regression, I wonder what was the change from 8 to 9 which triggered it)

It would be good to understand this... Apparently this scenario was working before without this special-casing, which we'd ideally not need (it's always better to avoid adding more code/special cases if possible)

[cincuranet]

It would be good to understand this... Apparently this scenario was working before without this special-casing, which we'd ideally not need (it's always better to avoid adding more code/special cases if possible)

I don't think Copilot will be able to do this. So let me do it myself.