fix(37165): Cannot read property 'flags' of undefined

[a-tarasyuk]

Fixes #37165

[sandersn]

globalObjectType is the type for Object and should not be undefined under normal circumstances. We should probably fix that instead of covering over the problem.

It's possible that it's undefined in some situations, but in that case, other uses of getGlobalType need to consider this possibility, and the situation needs to be documented, probably on the declaration of getGlobalType.

[a-tarasyuk]

@sandersn Thanks for the feedback. 👍

The globalObjectType initialized in the line #35978. However, three is code above (Line #35963) which can refer to globalObjectType.

if (augmentations) {
    // merge _global_ module augmentations.
    // this needs to be done after global symbol table is initialized to make sure that all ambient modules are indexed
    for (const list of augmentations) {
        for (const augmentation of list) {
            if (!isGlobalScopeAugmentation(augmentation.parent as ModuleDeclaration)) continue;
            mergeModuleAugmentation(augmentation);
        }
    }
}

....

// Initialize special types
 globalArrayType = getGlobalType("Array" as __String, /*arity*/ 1, /*reportErrors*/ true);
 globalObjectType = getGlobalType("Object" as __String, /*arity*/ 0, /*reportErrors*/ true);

As I  remember correctly the chain which causes the crash looks like so
 mergeModuleAugmentation
-> resolveExternalModuleSymbol
-> resolveSymbol
-> resolveAlias
-> getTargetOfAliasDeclaration
-> getTargetOfExportAssignment
-> getTargetOfAliasLikeExpression
-> resolveEntityName
-> resolveName
-> resolveNameHelper
-> getSymbol
-> resolveAlias
-> getTargetOfAliasDeclaration
-> getTargetOfImportSpecifier
-> getExternalModuleMember
-> getPropertyOfType

I'll check maybe need to throw error earlier without checking to existence globalObjectType.

[sheetalkamat]

Looked into this and it turns out this happens because of export as namespace and module agumentations.In the repro when trying to create new merged global of Bar we need to resolve what it is (which results in finding Bar from foo) but this happens before global object type and others are calculated resulting in accessing globalObjectType (because Foo doesn't have Bar so we are trying to figure out if its from global object type).

This raises question of all these globalTypes that we calculate being accessed before and needs to be thought through?

Note that we have similar situation which does get guarded unintentionall... but using undefined instead of getting correct globalObjectType would mean that we would report error which is questionable? In repro scenario we would get this error, but if we comment our Bar declaration from the global we wouldn't.

bar.d.ts:1:10 - error TS2305: Module '"./foo"' has no exported member 'toString'.

1 import { toString as Bar } from './foo';
           ~~~~~~~~


Found 1 error.

[a-tarasyuk]

@sheetalkamat Thanks for the detailed feedback 👍. What solution do you think is acceptable for this issue?

[sheetalkamat]

@ahejlsberg @weswigham @RyanCavanaugh @DanielRosenwasser to comment on what to do when hitting globalObject type before its populated (during module augmentation where the global*types are not yet calculated but module augmentation might use them)

[DanielRosenwasser]

I think the right thing is to report an error and see what breaks in test suites, and ask partner teams to try it out.

[sandersn]

@a-tarasyuk can you try reporting an error, and then we'll pass this build on to some partners if the results on our tests are good?

[sheetalkamat]

@sandersn #37964 is preferred solution and needs more validation of user and rwc tests which i havent gotten to yet.