Add ECMA augments regarding instance and type construction.

[MichalPetryka]

Multiple initializations of instances and types might violate runtime invariants, we should forbid them then as discussed in #109679.

Users are not expected to have been relying on the behaviour being legal, especially since multiple type initializations are already resulting in invalid behaviour due to JIT optimizations.

cc @jkotas @tannergooding @EgorBo as discussed.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

[hamarb123]

Is there any reason to go this far? Wouldn't it be more sensible to say that it's just unsupported for all the types in the BCL & special types like delegates, enums (not that these can even have ctors), etc. (+ probably also anything else that doesn't explicitly document it as fine, but this library documentation part about other libs in this bracket doesn't seem like a concern for ECMA-335, other than at most as a comment to point out what should be common sense) - but that doesn't mean it should necessarily be invalid in every single case as a blanket rule (not that I wouldn't find such code not suspiscious) (like how we might say it's unsupported to take a ref readonly and write to it using Unsafe in general, but that doesn't mean it's actually wrong in every single scenario, just highly suspiscious that known mutable memory is being passed as readonly and then treated as mutable again later). An example usage where it might not be wrong is calling instance constructor on an object from GetUninitializedObject (assuming the constructor actually initialises all fields obviously, since idk if we guarantee that it's already zeroed).

[jkotas]

Is there any reason to go this far? Wouldn't it be more sensible to say that it's just unsupported

ECMA spec is concerned about verifiable code only. It touches on valid unverifiable code here and there, but it is very far from having a full precise definition of valid unverifiable code. In general, it leaves the behavior of valid unverifiable code as undefined.

I see things like calling constructor multiple times as a potentially valid unverifiable code.

[jkotas]

Type initializers shall not be called explicitly from user code

This contradicts "A type initializer shall be executed exactly once for any given type, unless explicitly
called by user code." in the next chapter.

[MichalPetryka]

That is changed with the next paragraph.

[jkotas]

unless the previous attempt resulted in a System.TypeInitializationException being thrown at the location that triggered it.

I am not sure what this is trying to say.

[MichalPetryka]

If a .cctor throws an exception, the type is not marked as initialized so the .cctor will be called again by the runtime until it succeeds.

[jkotas]

That's not correct. If the .cctor throws exception, the runtime won't try to run the .cctor again. The failure is cached.

[MichalPetryka]

I did not know that, I feel like older versions of legacy Mono might've been non compliant with this cause I recall it being rerun in Unity.

[jkotas]

This is not correct. Try this:

class A
{
    A() : this(1)
    {
    }

    A(int x)
    {
    }
}

[jkotas]

Also, you may want to update the wording in the call instruction verification rules that have the same mistake: "The call instruction can also be used to call an object’s base class constructor, or to initialize a value type location by calling an appropriate constructor, both of which are treated as special cases by verification.".

It may be sufficient to just fix the call verification rules to be more precise instead of duplicating it here.

[hamarb123]

I see things like calling constructor multiple times as a potentially valid unverifiable code.

If this is the direction we go, I'd prefer if we explicitly mention something along the lines of the above somewhere at least. I think it would be good to better document stuff around valid unverifiable code.