Enumerators fails to set state to "after" in various scenarios observable with GetEnumerator()

[jcouv]

[jcouv update:] From discussion with Stephen we need to prioritize this. The optimization is meant to only kick once, but the current implementation would allow it to happen again.
With the latest implementation, you can Dispose() and then GetEnumerator() again and it will not allocate a new instance. But we want it to.

The spec states that we should set state of the enumerator object to after in various scenarios:

• when a yield break is encountered
• when the end of the iterator body is encountered
• when an exception is thrown and propagated out of the iterator block
• when invoking Dispose causes an exception to be thrown

It is possible to observe whether the state was properly set to after by checking whether GetEnumerator() re-uses the current state machine instance or allocates a new one.

In the scenarios above, enumerators don't properly set the state to after.

The impact is not observable to my knowledge as we're making a change to ensure that Dispose() does set the state to after in non-exceptional cases, and this is only affecting an optimization.

[jaredpar]

@jcouv why did you put this in Backlog?

[jcouv]

@jaredpar My reasoning was: this is an old problem, it is only observable if you enumerate the same enumerator multiple times, and nobody reported it. So the impact seems limited.