FYI @davidwengier @tmat to see if this will break EnC:

Also FYI @CyrusNajmabadi, it's likely that generate field/property is going to break in a Program class:

I think the behavior should be that codefix is offered, and if we're in a global statement, then generate partial Program and add the property/field in it.

Thanks @Youssef1313. EnC itself should be fine, but I would expect test failures which will be easy enough to correct

I don't think we can continue checking for top-level code container type just by checking the name. We need to check if the Program type is in fact the synthesized implicit type (or if it is partial we need to somehow check if it has a synthesized partial declaration). It would be good to have a compiler API that tells us whether a type is the implicit top-level type.

There might also be some cases to test/consider around partial class Program.

The distinctive mark of a simple program will be the Program.<Main>$ method (remains unspeakable).

So we'll need to check if the type contains <Main>$? Seems like there should be API that does that.

The code was already checking for <Main>$ so it's not really a change.
We can discuss possible public API, but I'm not clear what would the user scenarios be. Do we just care whether there is <Main>$? Do we care whether it's a pure simple program, or whether it has some user-defined members from a partial declaration?

I see. I guess it's ok then. For some reason I thought we are checking the type.

A more ideal behavior is to generate the property as follows:

P = 10;

partial class Program
{
    public int P { get; private set; }
}

In case you find it out-of-scope for this PR, we can open a tracking issue for that.

AddNonTypeMember(member, declaredMembersAndInitializers)

Do we have a race condition where external callers of GetSimpleProgramEntryPoints() might get back an entry point that hasn't been added to MembersAndInitializers yet? If so, what are the implications? #Closed

I don't think that is possible. GetSimpleProgramEntryPoints is atomic. It will return exactly one set of entry points, then we'll incorporate them into MembersAndInitializers.
Different threads will see the same set of entry points, and there is not other way to get entry point symbols than through GetSimpleProgramEntryPoints.

Does that make sense, or do you still think there might be a way?

Is it true that we can't get here in an error scenario like the following:

namespace NS;

var x = 1;

#Resolved

Correct. I'll add a few tests.
ParseNamespaceBody parses differently in global context (outside of a namespace). See isGlobal local. It recognizes when inside a namespace (either with brace or semi-colon).

nit: It feels like the motivating scenario was typeof(Program).Assembly and reflection. Consider testing this in a scenario where partial class Program is not explicitly declared. #Resolved

Good idea. Adding a typeof test.

Is it true that in non-error scenarios, there is either 1 element in here, or the SimpleProgramEntryPointInfo itself is null? #Resolved

It feels like if we expect exactly one of these in a non-error scenario we might put a field on this class for that "single" one, and only use this field for error recovery. However, since it's not likely that very many of these will be created, it doesn't seem like an important change.

Correct. There's one entry per file with top-level statement.
However, there's code (SynthesizedSimpleProgramEntryPointSymbol? GetSimpleProgramEntryPoint(CSharpCompilation compilation, CompilationUnitSyntax compilationUnit, bool fallbackToMainEntryPoint)) which needs to access all of the entry point symbols. That's why I couldn't store just zero/one here.

nit: this seems like it could be a little more elegant as one big pattern :) #Resolved

checker.Method(5, 1)

Do we understand what method is added here? #Resolved

We didn't use to generate a parameterless constructor for the entry-point type (which is a reference type). Now we do.

4

Do we understand why this number has changed? #Resolved

CompileAndVerify(comp, expectedOutput: "Hi!");

It looks like this test was testing interesting success scenario. I think we should keep it as such. The class name isn't important, so renaming it would be more appropriate. #Pending

CompileAndVerify(comp, expectedOutput: "Hi!");

Same here #Pending

Why the test scenario is drastically modified? #Pending

Sure. We can rename the type name