Consider property accesses in heritage clauses as type-space references

[Wesley Wigham (weswigham)]

at least for calculating type reference directives.

Fixes #15487

[Daniel Rosenwasser (DanielRosenwasser)]

Wait, I don't understand; in an implements heritage clause, I would have assumed we'd parse out a type reference, not a property access.

[Ryan Cavanaugh (RyanCavanaugh)]

parseHeritageClause doesn't differentiate implements from extends; it always interprets the operands as expressions:

        function parseHeritageClause(): HeritageClause | undefined {
            const tok = token();
            if (tok === SyntaxKind.ExtendsKeyword || tok === SyntaxKind.ImplementsKeyword) {
                const node = <HeritageClause>createNode(SyntaxKind.HeritageClause);
                node.token = tok;
                nextToken();
                node.types = parseDelimitedList(ParsingContext.HeritageClauseElement, parseExpressionWithTypeArguments);
                return finishNode(node);
            }

            return undefined;
        }

e.g. class C implements {} { } is a semantic error, not a syntax error

[Wesley Wigham (weswigham)]

Yeah - it'd be kinda odd to parse them differently (it'd make handling them a pain, at least, since you'd need both type-space and value-space codepaths for everything syntactically heritage-clause related).

[Lucas Azzola (azz)]

Thanks for the fix! Does this change also fix #15488?