[Umbrella] Lambda parameter inference

[jaredpar]

There are a number of issues reported against Roslyn where we are unable to provide Intellisense for, seemingly simple, lamda parameters. In many cases the same scenario worked in pre-Roslyn days. The root issue here is the compiler is unable to infer a target method / delegate given the partial information provided when typing.

Fixing this requires some changes to overload resolution (danger) and can de-volve into heuristics at times vs. hard rules. As such we're going to look at all of these issues together and make a wholistic change to this part of the compiler. This issue represents that with the individual bugs being tracked below.

• Type inference fails in lambda in incomplete object initializer #557 (See PR Improved error recovery for lambdas in a call with extra arguments. #11807)
• Confusing error from compiler around lambda with bad body #613
• Have compiler return semantic errors in lambdas even in the presence of syntax errors #1867 (See PRs Report semantic errors even in syntactically invalid lambdas. #7245 Report errors from (unbound) lambdas when the enclosing invocation fails #7555)
• Intellisense does not recognize parameter of locally assigned lambda #4480 (See PR Add a test for delegate creation expression containing broken lambda #11702)
• async keyword overly sensitive in VS2015 #5128 (See PR Improve lambda type inference for singular but erroneous method groups #11981)
• No intellisense on lambda parameter before variable declaration #5498 (See PR Improved error recovery for lambdas in a call with extra arguments. #11807)
• Completion missing members of lambda parameter in fault tolerance case #8237 (May need new APIs to address this)
• IntelliSense does not understand lambda parameter type, when overloaded with defaultValue #11053 (See PR Attempt type inference when there are no applicable methods #11718)
• No completion offered in partial statement with lambda #11358 (See PR Attempt type inference when there are no applicable methods #11718)
• Intellisense not working for lambdas with parameters #11412 (See PR Improve lambda type inference for singular but erroneous method groups #11981)
• Type inference and lambda binding failure when one method in the group and wrong number of arguments #11901 (See PR Improve lambda type inference for singular but erroneous method groups #11981)
• Improve lambda type inference when wrong number of lambda parameters #12063 (See PR Improve lambda type inference for singular but erroneous method groups #11981)
• IntelliSense: Lambda types not identified in some generic methods #16548 (appears to be fixed in milestone 2.0)
• No intellisense (due to unknown type) for delegate arguments #16555
• Unexpected red squiggles when working inside lambda #24654

Slightly related to these issues and included on this list is poor syntax error recovery. See

• Have compiler return semantic errors in incomplete members. #7536 (improved syntax error recovery in decl)
• Completion bug writing 'Task.' #10502 (improved syntax error recovery in statements)
• Improved parser recovery during typing #11817 (improved syntax error recovery in expr)

The Roslyn VB compiler has similar limitations, though its overload resolution implementation is not modeled after the C# implementation. See

• No completion offered in partial statement with lambda [VB] #11722 (the tip of the iceberg for VB)
• Errors inside VB lambda expression in Visual Studio 2015 not recognized #9341 (See PR Adjust heuristic to choose a set of best candidates for overload resolution failure. #13922)

[pawchen]

Please also check #5498 and #557

[gafter]

@DiryBoy Thank you so much for identifying those! I've created a fix for them in PR #11807.

[gafter]

@CyrusNajmabadi I still owe you #7536, but I'm placing this on the back burner for the moment while I work on patterns. Please let me know if you come to know of any further candidates for this list.

[jaredpar]

Moving this out to 2.1 for now as it feels like we've hit the major points here.

Should we possibly just close this out?

[gafter]

Pushing it to 2.1 makes sense.

I'd prefer to keep this umbrella open as long as we have work to do. It keeps it on the burner (front or back) so we're aware that there is more to do. I'm fine with pushing it out every release (or two) until we think there isn't anything more we can do.

[CarlLeth]

I've added an issue that shows this problem in a different context, which I don't think is covered by the other linked issues: #16548

[gafter]

Removing #613 from the list because that isn't really a problem inferring the type of the parameter. It is a problem deciding which overload of the method (none of which work) to complain about in the error message.

[gafter]

Adding #24654 to this list.