Identity of lambda parameters about nrefactory

[erik-kallen]

Perhaps a nice solution to this issue would be to override Equals (and GetHashCode) in classes implementing IVariable, and consider them equal if their Region property is the same.

[dgrunwald]

Yes, we compare variables by region sometimes in SharpDevelop. However I think having identity for IVariables produces by a single CSharpAstResolver would be nice.
I think implicitly-typed lambdas are the only case where we don't have IVariable identity already.
Now implicitly-typed lambdas are really complex, as the lambda depends on the target type (the delegate to which the lambda is converted), but figuring out the target type might involve overload resolution (for method calls in which the lambda is used as argument), which requires knowledge about the lamdba.
The implementation in NRefactory works like this:

1. The lambda resolves to a LambdaResolveResult. The lambda body is not resolved yet (one of the few places where ResolveVisitor deviates from the usual depth-first AST traversal).
2. The parent statement is resolved as usual. This might require analyzing the lambda in detail (for example as part of overload resolution). Such analysis happens using LambdaResolveResult.IsValid, where the caller (i.e. the overload resolution algorithm) supplies the parameter types to the lambda body. For every IsValid() call, a nested resolver is constructed for analyzing the lambda using the supplied type assignment. Multiple IsValid() calls may use several nested resolvers, one for each set of parameter types.
3. When the resolver reports the conversions that occurred as part of the parent statement (as with any conversions), the results from the nested resolver corresponding to the actually chosen conversion are merged into the main resolver.
4. LambdaResolveResult.Body is set to the main resolve result from the chosen nested resolver. I think this is the only place where NRefactory is mutating a ResolveResult (normally all resolve results are immutable). As this step is guaranteed to occur before the resolver returns the LamdbaResolveResult to user code, the mutation shouldn't cause any problems.

Now the issue with LambdaResolveResult.Parameters is that those parameters are still the typeless fake parameters created in step 1 for consumption in step 2. I think I can change step 4 to replace the parameters collection with the actual typed parameters. Though that only explains why there are two different IParameter instances, I have no idea where the third is coming from.

[dgrunwald]

I fixed LambdaResolveResult.Parameters to return the typed parameters to user code. This should solve the problem. I initially thought your test was demonstrating 3 different parameter instances, but you were comparing ResolveResult instances, not IParameter instances.

[erik-kallen]

FYI, I'm not 100% sure, but I think I saw this behaviour also for explicitly typed lambdas.

[erik-kallen]

My thought that I saw the behavior with explicitly typed lambdas was probably wrong and due to the bug you spotted in my test, comparing a ResolveResult to a variable in one case.