Can't emit types into same namespace as values

[evmar]

interface Foo { x: number; }
var Foo;

is legal TS. But if you translate the interface into Closure directly it goes into the single (value) namespace and the two definitions conflict.

It's easy enough to just emit interfaces under some mangled name in Closure, e.g.

interface Foo { x: number }
/** @record */
function tsickle_Foo() {}
/** @type {number}
tsickle_Foo.prototype.x;

but then you need to fix every reference to that interface in any Closure type, while at the same time leaving other references (e.g. Array) alone. And you need to figure out how to import it across files (if a file does import {Foo} from bar, you'd need to change it to import {Foo, tsickle_Foo} from bar).

[evmar]

Rado suggested we might be able to do some trickery like

interface ts_Foo { ... }
type Foo = ts_Foo;

and then when Foo is used, note that there's an alias and inspect that to get data about the emitted type.

But a local experiment found that the place where we emit types gets the type after aliasing has been resolved.

[evmar]

Idea: always emit TS interfaces into a mangled Closure name, like tsickle_$name. Then there's no collisions possible, and it's always easy to guess the mangled name -- whenever you see an interface reference, emit it with the mangled name.

Problem 1. This breaks for builtin types like "Array" and "Object". However, emitting those interfaces verbatim as we do right now is saying that they are equivalent between TS and Closure's definitions of those terms. I think this is fine for Array and Object, but it might not be fine for more complex types. I think a whitelist (perhaps derived from lib.d.ts) of types that are considered compatible might get us pretty far.

Problem 2. Mangling names breaks interop with Closure code. E.g. a function returns a FooBar, and we see that and emit it as a tsickle_FooBar in our code.

I think collisions are unlikely enough that this approach is not gonna work. I will leave it here as a rejected proposal.

[evmar]

Idea 2: locally detect when there is a naming conflict and just dodge it there.

It might be possible to look up, given a symbol, whether that symbol represents both a type and a name in a TS file. When that scenario occurs, rewrite all the instances of the type to something else when emitting.

The hard part then is making the dependent code recognize it. Within a compilation unit perhaps we can just construct a map by doing one pass over all the files first before emitting any. Across compilation units, we can stash the mangled name into a comment and extract it from the docstring in the d.ts file(!).

This might actually work. I'm gonna prototype it now.

[evmar]

It took me quite a while to figure out how to find the conflicting symbols, but it seems to basically work in a single file test case. Next, I'll attempt a multi-file case.

Multi-file is hard because you can write:

import {Foo} from './bar';

and we need to figure out that it is

import {Foo, tsickle_Foo} from './bar';

(where tsickle_Foo is the interface name).

[evmar]

This works! At least in my test case -- it generates these funky names and adds extra exports/imports where necessary. But then it fails due to #112 . I need to fix that first before I can fix this.

[evmar]

Another simpler idea is: when there's a type/value conflict, just omit bringing the type into the Closure and treat it as {?}. That "solves" this problem at the cost of slightly weaker typing.

I still think I can implement the renaming thing but it might be worth checking how much it helps because it adds a lot of complexity.

[evmar]

We now think that #146 (comment) can work.