Have compiler return semantic errors in lambdas even in the presence of syntax errors

[jmarolf]

Today, the compiler does not return semantic errors inside lambdas in the IDE if there are syntax errors. This causes several quick fix scenarios to fail inside lambdas (for example #1239, #1241, and #1744 are all caused by this problem).

Consider the code sample below from issue #1239:

using System.Threading.Tasks;

class C {
    C() {
        Task.Run(() => {
            new C(0)
        });
    }
}

new C(0) will never be squiggled by the IDE because of the lack of a semicolon. This makes quick-fixes that could generate a constructor unable to run because there is no error to trigger them.

By having the compiler return semantic errors in lambdas even in the presence of syntax errors, many more IDE scenarios will "Just Work"

[CyrusNajmabadi]

Note: whenever this is fixed we need to remove the UnboundIdentifiersDiagnosticAnalyzerBase type and ensure all AddUsing tests (and other tests that depend on this type) still continue passing. Right now, this type is a hack at the IDE layer to get and display reasonable semantic errors to the user and to drive our normal features. This should not be something the IDE is responsible for doing. Users should be getting these errors, even in the presence of a syntax error in a lambda, and our features should not have to list for syntax errors to drive semantic features.

[CyrusNajmabadi]

Reactivating. Here are cases where we still don't get errors from the compiler:

using System.Linq;
class C { C() { "".Select(() => { new Byte  //<-- no error on Byte
class D { D() { "".Select(() => { new Byte  ( ) }   //<-- no error on Byte

class Program
{
    static void Main(string[] args)
    {
        args[0].Any(x => IBindCtx  // <-- no error on IBindCtx
        string a;
    }
}

[gafter]

For the first two cases, the compiler certainly does produce a semantic error about Byte not found. But I'll be sure to add a test case for them.

Working on the third case.

[gafter]

OK, in the third case we have a lambda of the form

e.Any(x => identifier string identifier; // and more broken syntax

and you're complaining that we don't give an error that we can't bind the first identifier? What are you imagining the compiler would be trying to bind it for? It simply doesn't line up with any recognizable expression form.

[gafter]

Here is a better repro for the third case:

        args[0].Any(x => IBindCtx, foo foo);

Here we should give an error that we can't bind IBindCtx.

[gafter]

OK, PR #7555 addresses all the new cases.

[gafter]

@CyrusNajmabadi OK, all fixed. I'm eager to catch as many of these cases as possible. You're welcome to open new issues for any new cases you discover.

[CyrusNajmabadi]

@gafter Will do. Thanks!