X Tutup
Skip to content

fixed usage of lua keywords as property names#586

Merged
tomblind merged 8 commits intomasterfrom
lua-keyword-property-names
May 24, 2019
Merged

fixed usage of lua keywords as property names#586
tomblind merged 8 commits intomasterfrom
lua-keyword-property-names

Conversation

@tomblind
Copy link
Collaborator

No description provided.

parameters,
node
);
if (this.isUnsafeName(node.expression.name.text)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

It shouldn't check for builtins there

@ark120202
Copy link
Contributor

Some inconsistent behavior:

declare var local: any;
declare var _G: any;

const a1 = { local };
const a2 = { local: local };
const b1 = { _G };
const b2 = { _G: _G };
local a1 = {["local"] = ____local}
local a2 = {["local"] = local}
local b1 = {_G = _____G}
local b2 = {_G = _G}

For _G there it should always be {_G = _G}, but it's more complex for local. Because we also could have _G.local somewhere it could be {["local"] = _G["local"]}, but because we also have env it should be {["local"] = _ENV["local"]} or {["local"] = getfenv(1)["local"]} (depending on target).

@tomblind
Copy link
Collaborator Author

I don't think it makes sense to declare a variable local, since that wouldn't be valid in lua. I think we should throw an error for that and let users explicitly access it the same way they would need to in lua (_G["local"])

- not using element call for methods with lua builtin names
- fixed shorthand assignment of declared lua builtins
- banned lua keywords as identifier names in declare statements
// Ignore declarations
if (node.modifiers && node.modifiers.some(modifier => modifier.kind === ts.SyntaxKind.DeclareKeyword)) {
return undefined;
return this.transformDeclareStatement(node);
Copy link
Contributor

Choose a reason for hiding this comment

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

These types can be declared in other file that isn't going to be transformed, so it should be handled when it's used

}
}

public transformDeclareStatement(node: ts.Statement): StatementVisitResult {
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO we shouldn't do this anymore. First, it would be quite a surprising behavior if some code would work in .d.ts files (since we don't transform them) and won't in regular. Second, it's pretty much valid to declare it, because it also may be used to augment _G type.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I see your point about the inconsistency being confusing, but I don't see how that can be a valid declaration. Such variables could be declared as a property of _G, but this error wouldn't be triggered by that.

Also I think it would be a good idea to leave this function in (just returning undefined) as it makes sense as an api method.

Copy link
Contributor

Choose a reason for hiding this comment

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

The best type for _G is typeof globalThis, which includes all globally declared symbols

@tomblind tomblind merged commit 3d7833e into master May 24, 2019
@tomblind tomblind deleted the lua-keyword-property-names branch May 24, 2019 19:06
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.

3 participants

X Tutup