Have compiler return semantic errors in incomplete members.

[CyrusNajmabadi]

This is similar to https://github.com/dotnet/roslyn/issues/1867

Examples where we want semantic errors:

class C {
    Directory     //<-- want errors on Directory
    private int i; 
}

class Program {
    Func < FlowControl x    // <-- on both 'Func' and 'FlowControl'
} 

class C {
  [Extension]   //<-- in an attribute on nothing
} 

Note: i handled this in TypeScript by not even having the concept of an "Incomplete Member". If no existing member rule could parse out the text, then we fell back to "Field". This meant that we would properly consume the modifiers, attribute and type, and we'd give proper messages for when anything was missing.

By then being a field, all the remaining parts of the compiler just lit up and worked properly.

This is something we could consider doing in the C# compiler as well. (or we could just make it so that it binds Incomplete Members).

[CyrusNajmabadi]

pinging @gafter

[jcouv]

@gafter @CyrusNajmabadi I don't think this meets the RTM bar. Moving out.

[CyrusNajmabadi]

@jaredpar @jcouv IDE still needs this. Right now we have to have our own binder here and it means even basic things like public DateTime are things we have to manually analyze and understand ourselves (since this is an incomplete member where no binding happens).

It's really just a layer of hacks that continually causes us problems and leads to weird bugs for users that we're always chasing down and attempting to stamp out. Could we get some compiler eyes on this? Thanks!

[jaredpar]

This is something we'd need to discuss in the post 17.0 timeframe. At this point between C# 10 and the IDE work we're taking on we're over booked for 17.0.

[CyrusNajmabadi]

@jaredpar can we assign this to someone though?

[jaredpar]

We can but I'm not sure what that is going to help here. Until we have a priority for this relative to other asks not going to make progress on it.