IOperation: BoundLambda - value returned by IOperation.Type property might be inconsistent across languages

[AlekseyTs]

BoundLambda node in VB never has a Type, whereas in C# I believe it's Type is a target delegate type. If implementation of IOperation.Type simply returns value of the Type property, then returned value for VB will always be null and often (if not always) not null for C#.

I think IOperation.Type for ILambdaExpression should always be null and the target type (a delegate type or an Expression) can be discovered from the conversion on top of the lambda.

[333fred]

@AlekseyTs is correct. Example time.

Given the following C# code:

using System;

class Program
{
    static void Main(string[] args)
    {
        Action test = () => { };
    }
}

We have a syntax tree that looks like this:

If we get the IOperation node for the ParenthesizedLambdaExpression, we currently get this tree:

IOperation tree for "() => { }"

ILambdaExpression (Signature: lambda expression) (OperationKind.LambdaExpression, Type: System.Action) (Syntax: '() => { }')
  IBlockStatement (1 statements) (OperationKind.BlockStatement) (Syntax: '{ }')
    IReturnStatement (OperationKind.ReturnStatement) (Syntax: '{ }')

For the following VB code:

Module Program
    Sub Main(args As String())
        Dim test = Sub()
                   End Sub
    End Sub
End Module

We get the following sytnax tree:

Getting the IOperation of the MultiLineSubLambdaExpression returns this IOperation tree:

IOperation tree for "Sub()
                   End Sub"

IConversionExpression (ConversionKind.Basic, Implicit) (OperationKind.ConversionExpression, Type: Sub <generated method>()) (Syntax: 'Sub() ... End Sub')
  ILambdaExpression (Signature: Sub ()) (OperationKind.LambdaExpression, Type: null) (Syntax: 'Sub() ... End Sub')
    IBlockStatement (2 statements) (OperationKind.BlockStatement) (Syntax: 'Sub() ... End Sub')
      ILabelStatement (Label: exit) (OperationKind.LabelStatement) (Syntax: 'End Sub')
      IReturnStatement (OperationKind.ReturnStatement) (Syntax: 'End Sub')

The difference here is twofold:

1. In VB, as Aleksey said, the type of the ILambdaExpression is null, and in C# it's Action.
2. C# uses GetOperationOptions.Lowest when retrieving the bound nodes for a syntax node, so it gets the ILambdaExpression without the IConversionExpression. VB uses GetOperationOptions.Highest, so it gets the IConversionExpression. This is tracked by VB and C# implementation of SemanticModel.GetOperation uses different GetOperationOptions #17861, and is another example of why C# should probably be using Highest as well.

[AlekseyTs]

and is another example of why C# should probably be using Highest as well.

I actually think that we shouldn't get conversion node for an implicit conversion, therefore should go for the lowest node. Conversion can be discovered from looking at the parent node.

[333fred]

Perhaps we should have an extension on ILambdaExpression for this? @jinujoseph, can we add this to next week's IOperation meeting?

[AlekseyTs]

Perhaps we should have an extension on ILambdaExpression for this?

For getting the conversion? That isn't lambda specific, that is how it should work for all expressions, I believe. So, I am not sure if any special helper is needed, it is easy enough to look at the parent.

[333fred]

I guess I'm just concerned that just getting the parent to find the the type of an expression doesn't feel like a particularly natural thing for me to do.

[CyrusNajmabadi]

We need to investigate SemanticModel.GetTypeInfo for lambdas. See in C# what GetTypeINfo returns for both "TypeInfo.Type" and "TypeInfo.ConvertedType".

Our initial impression is that we probably want C# and VB to be the same (but htat might mean htat C# differs in IOperation from SemanticModel). We liked that lambdas were typeless as htat definitely matches VB's language interpretation, and we think it matches C#'s (though we need to confirm).

[CyrusNajmabadi]

If users want the type of a lambda, they would walk up to the parent conversion node if it exists. (we may provide an extension for this).

[333fred]

I tested the following cases:

Declaration	TypeInfo.Type	TypeInfo.ConvertedType
Action a = () => { };	null	NamedType System.Action
Dim a = Sub() End Sub	Nothing	Nothing
Dim a As Action = Sub() End Sub	Nothing	NamedType System.Action

Looks like we'll want to make C#'s version be consistent with VB, as that's what the SemanticModel does.

[333fred]

Fixed in e047f24.