X Tutup
Skip to content

fix back assignment#764

Merged
Perryvw merged 14 commits intoTypeScriptToLua:masterfrom
hazzard993:back-assignment
Dec 18, 2019
Merged

fix back assignment#764
Perryvw merged 14 commits intoTypeScriptToLua:masterfrom
hazzard993:back-assignment

Conversation

@hazzard993
Copy link
Contributor

Closes #430

let x = false;
export { x };
x = true;

x should now be true.

// ts.Iterator is not a ES6-compatible iterator, because TypeScript targets ES5
const it: Iterable<ts.Symbol> = { [Symbol.iterator]: () => scopeSymbol!.exports!.values() };
return [...it].includes(symbol);
if (symbol.declarations.find(d => findFirstNodeAbove(d, ts.isBlock))) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a block above isn't enough to match symbol identities there

export let a = 1;
(() => {
    a = 2;
})();
export let a = 1;
switch (0 as any) {
    case 1:
        let a = 2;
    case 2:
        a = 3
}

Copy link
Contributor Author

@hazzard993 hazzard993 Dec 14, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer using ts.isBlock

But I am curious about what is expected to happen in a switch statement like this

@ark120202
Copy link
Contributor

Actually, that's a much more complex problem than I've expected.

Initially I've thought that exported symbol would have the same reference as local one, and so it would be possible to just use the old symbol matching logic there, but looking at it more, it actually makes sense that they are different. For example, it should be possible to give exported symbol a different name with { foo as bar }. Or even have multiple exported symbols for a single local one ({ foo as foo1, foo as foo2 }). To support that correctly we'd have to make quite huge changes to our export logic.

I'm not sure what would be the best way to go with this issue for now. If we're okay to go with incomplete (but better than nothing) support, I think the simplest thing would be to move export statements to the bottom of generated file. At least it would be enough to support the example from OP.

@hazzard993
Copy link
Contributor Author

hazzard993 commented Dec 14, 2019

I think I managed to get around it without changing the existing export logic too much

It should now be possible to export a variable under different names with export specifiers

When reassigning the variable synchronisation should still occur

let x = false;
export { x as a };
export { x as b };
x = true; // a and b now become true
x = true;
// becomes `exports.b = exports.a = x = true;` in TypeScript -> JavaScript
// becomes `____exports.b = <iife chain>` in TypeScript -> Lua

Copy link
Contributor

@ark120202 ark120202 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new symbol-based binding approach look very good!

@Perryvw Perryvw merged commit c1485af into TypeScriptToLua:master Dec 18, 2019
@hazzard993 hazzard993 deleted the back-assignment branch February 24, 2020 06:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support back assignment for variables exported with ExportDeclaration

3 participants

X Tutup