#24210: Updated handling of undefined values in Enum types

[ggajos]

Fixes #24210

I've managed to identify two problems in #24210.

1. The magical 0.

This is produced in the code below, along with the cryptic exception. However, I believe that this error should still be produced when user provided some wierd value like "a" - "a".

            else if (enumKind === EnumKind.Literal) {
                error(initializer, Diagnostics.Computed_values_are_not_permitted_in_an_enum_with_string_valued_members);
                return 0;
            }

I've added additional clause to exclude the undefined from this logic. I've targeted the undefined keyword very specifically to avoid cases when something is evaluated to undefined (limit regression).

2. Prefixing in substitution phase

The substitution phase is trying to add Enum name prefix (as it is doing for combining multiple enum members). Effectively converting Identifier to PropertyAccessExpression. In other words, converting undefined to EnumName.undefined. While this make sense in some cases, I believe that undefined should have higher precedence here.

I've added clause in transformer.ts::trySubstituteNamespaceExportedName to exclude the undefined from this processing.

[ghost]

All CLA requirements met.

[sandersn]

I'm trying to clear out our PR backlog and finally reviewed this. Of course, I understand if you are not interested in finishing it.

[sandersn]

Shouldn't there be an error here? I thought undefined was supposed to be an error, but with an undefined-specific message.

[sandersn]

Are Infinity and NaN supposed to be errors or not? Looking at the previous discussion, it seems only intended to be an error for const enum.

[sandersn]

undefined/NaN/Infinity are still turned into quoted strings. That's not correct, is it?

[sandersn]

To help with PR housekeeping, I'm going to close this PR since it's pretty old now.