Feature request: IOperation support for queries

[bkoelman]

Feeding the next code sample to an OperationWalker hits nothing. Please consider IOperation support for queries.

var query =
    from ch in text
    where ch >= 'a' && ch <= 'z'
    select char.ToUpperInvariant(ch);

[jinujoseph]

cc/ @genlu

[genlu]

LINQ was left out with the intention to support them in future, when we made the effort to release IOperation last year. We need to discuss again whether it should be in V1 or not.

[mavasani]

Note that not implementing this completely means that our current implementation makes no analyzer callbacks for anything inside a query - parameter/field/local references, invocations, etc.

I don't think that is acceptable for any new language feature. We need to take one of the following approaches:

1. Ensure that we have a temporary IOperationWithChildren type that ensures the bound child nodes of new language features to still be part of the Operation tree, so the analyzer driver can make callbacks for them
2. Design an API for the language feature.

[mavasani]

I am moving this back to 15.3 to discuss in the API review meeting.

[mavasani]

I have opened #18968 to track the work to add IOperationWithChildren internal type as a workaround for NYI features.

[jinujoseph]

Design Meeting Decision

For now lets unblock users with the workaround defined in #18968 . we need to come back and discuss about what the API for queries looks like.

[jinujoseph]

we need to collect a lot of information here so that we can then get together to discuss how we want this API to look like.

We need to identify differences between the languages (for example VB is semantic and C# is syntactic). We need to enumerate all the different types of queries. We need to understand all the strange VB cases. We need to get info on transparent identifiers and the like.

Basically, you needs to go read up a lot on these guys and collect a lot of info as we'll likely need a lot of design around this.

[mavasani]

See #21356 (comment) for discussion

[CyrusNajmabadi]

Design decisions:
Vastly reduce the IQueryExpression API. Do not expose clauses. Do not find a way to map from a query clause node to anything. Rename IQueryExpression to something like ITranslatedQueryExpression (name TBD).

Figure out engineering way to "lower" the current VB query tree so that query lambdas are rewritten to regular lambdas. This will ensure that range variables are rewritten into lambda parameter access. C# and VB trees should look more similar.

--

In future (potentially based on customer demand) we can supply a higher level Query API that more closely matches the original source (along with things like range variables and the like).

[mavasani]

Removing the Urgency-Now label and marking as 15.later - we have basic support for translated query expressions now, which matches our v1 scope. Keeping this issue open to track richer query APIs for v2.

[mavasani]

#28098 tracks exposing richer IOperation API for queries. This issue was closed as we do expose an ITranslatedQueryOperation for queries.