TypeScript crashes when assigning property to function

[billyjanitsch]

TypeScript Version:

3.4.0-dev.20190131, but I can repro back to at least 3.2.1.

Search Terms:

crash function property assignment
Debug Failure. Diagnostic emitted without context

Code

function A() {
  return null
}

A.B = 'foo'

function C() {
  return null
}

C.D = A

Expected behavior:

When running tsc -d, TypeScript should parse this file.

Actual behavior:

TypeScript crashes with a cryptic error message:

Debug Failure. Diagnostic emitted without context

Note that this only happens when the -d flag is specified.

Playground Link:

I can't repro in the playground because the playground doesn't seem to have an option to generate declarations.

Related Issues:

No, there are 0 issues containing the error message.

[NicholasLYang]

I've been trying to tackle this one. So far I've figured out that the crash happens due to a symbol appearing with SymbolFlags.ValueModule activated, which causes the second condition in createAnonymousTypeNode to be triggered, calling symbolToTypeNode -> lookupSymbolChain -> trackSymbol -> crash. This probably only happens with -d because this whole chain only gets called through typeToString, which wouldn't get called if we're just outputting plain JS.

First, does that reasoning sound valid? Second, could I get some sort of clarification on what a ValueModuleactually is? Reading through the code, it appears to be an ES6 module? My best guess at this point is that this typing is incorrect. But I could be off base with that.

[RyanCavanaugh]

ValueModule refers to a namespace that will have a corresponding runtime value. For example:

namespace X {
  export type Y = { n: number; }
}

The X symbol will not have ValueModule set because there's no codegen for a type-only namespace. But here, it would:

namespace X {
  export const Z = 10;
}

In general in the codebase, in the absence of other evidence from context, you should assume "module" refers to the namespace construct and "external module" refers to an ES6 module.

[RyanCavanaugh]

Namespace-like objects can also be synthesized via examples like the OP.

Probably the bug here is that the declaration emit codepath wasn't hardened to do the right thing when presented with "namespaces" like the one above.

[NicholasLYang]

Great! Thanks for the response. I'll try to fix this bug in the next few days.

[agwells]

I've encountered what appears to be a variation of this bug in TS 3.3.4000 , that seems to happen with tsc --watch or tsc -d, and a particular relationship of types spread across two files.

I suspect it's the same underlying bug, because it throws that same "Debug Failure. Diagnostic emitted without context" message, and one of the necessary elements for reproduction, is assigning a property to a function.

Here's a reproducible example: https://github.com/agwells/ts-loader/tree/master/examples/fork-ts-checker-webpack-plugin

// File 1: myfunction.ts

interface NotExportedInterface {}

export function exportedFunction(): NotExportedInterface {
  return {};
}

// File2: mycomponent.ts
import { exportedFunction } from './myfunction';

export function MyComponent() {
  return null;
}
MyComponent.defaultProps = {
  // Comment out this line, and it works.
  myProp: exportedFunction(),
};

And the result:

[7:22:15 PM] Starting compilation in watch mode...

/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:71495
                throw e;
                ^

Error: Debug Failure. Diagnostic emitted without context
    at throwDiagnostic (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:65136:61)
    at handleSymbolAccessibilityError (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:65202:33)
    at Object.trackSymbol (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:65221:13)
    at lookupSymbolChain (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:28411:33)
    at symbolToTypeNode (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:28544:29)
    at typeToTypeNodeHelper (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:27872:27)
    at addPropertyToElementList (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:28239:59)
    at createTypeNodesFromResolvedType (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:28190:25)
    at createTypeNodeFromObjectType (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:28030:35)
    at createAnonymousTypeNode (/code/reference/ts-loader/examples/fork-ts-checker-webpack-plugin/node_modules/typescript/lib/tsc.js:27984:42)

[johnnyreilly]

Thanks for your investigations @agwells! Could you keep your reproducible repo around please? It'll give the Typescript team a good place to test that the eventual fix works for API consumers as well.

Thanks again for digging into this; it's super appreciated! ❤️

[agwells]

Could you keep your reproducible repo around please?

Will do! And thanks for your help in investigating it. I wouldn't have had the time to learn the right tests to perform by myself.