Add a whiteline between methods.

By convention we throw a TranspileError here, see transpileContinue in Transpiler.ts.

Indent line 8 and 9 please.

Almost all test files have issues reported by tslint. I'm using VS Code and the extension seems to also apply the lint to the test files. I think ./tests/**/*.ts should be ignored by tslint?

tslint.json

{
/// ...
    "linterOptions": {
        "exclude": [
            "./test/**/*.ts"
        ]
    },
// ...
}

Eventually they should adhere to tslint I think, but for now I am treating tslint as "suggestions" for test files (which is why it doesn't fail builds).

Is it okay to disable tslint for ./test for now (as demonstrated above)? I'm using VS Code and it's rather obtrusive to have the test files full of errors. Unless a path's severity can be forced to "suggestion" in tslint.json? I couldn't find a feature like that after a quick search.

As long as you don't push it you can change it however you want :D

Can this backport stuff be removed since no 5.1 lua is executed?

When luaTarget is 5.1 and a variable destructuring is performed, e.g.

declare function myFunc(): [number, string];
let [a, b] = myFunc();

It has to rersult in

local a,b=unpack(myFunc())

Because Lua 5.1 doesn't have table.unpack, which is generated by 5.2 and onwards.

The tests that run Lua code rely on Fengari which only implements Lua 5.3 runtime. unpack (that was generated by luaTarget 5.1) is not defined in Lua 5.3 and thus has to be backported in order to be able to test Lua 5.1 code in Lua 5.3 VM.

Which tests are executed in Fengari that are compiled with target 5.1?

• @Test("loop versions")
• @Test("Bitop [5.1]")
• @Test("Assignment destructuring [5.1]")

Those are only transpiled, not executed.

Hmm those are not transpiled as 5.1 either... Sounds like something is off here, I will investigate.

It's caused by build_lualib.ts, the lualib is transpiled as 5.1. For example the generated map.lua uses unpack call:

function Map.constructor(self,other)
    self.items = {}
    self.size = 0
    if __TS__InstanceOf(other, Map) then
        self.size = other.size
        for _, __forOfValue0 in ipairs(other:entries()) do
        local key,value=unpack(__forOfValue0)
            do
                self.items[key] = value
            end
        end
    else
        if other~=nil then
            self.size = #other
            for _, __forOfValue1 in ipairs(other) do
            local key,value=unpack(__forOfValue1)
                do
                    self.items[key] = value
                end
            end
        end
    end
end

Does changing the lua version to 5.3 in build_lualib.ts fix that? I am fine with you changing that for now so we can get rid of this backport stuff, since that is just treating symptoms instead of the actual cause.

We will have to come up with a better fix later, probably changing the map implementation so it does not use unpack (or any version-sensitive stuff) would be the best answer, but we can do that in a different PR.

If the luaTarget for build_lualib.ts is changed to 5.3, then lualib would not work with Lua 5.1, as it would use table.unpack (at the moment). If we don't want to use backports, the other option is to add a polyfill so that transpiled 5.1 code supports table.unpack, e.g.

if not table.unpack then
    function table.unpack(...)
        return unpack(...)
    end
end

This polyfill should probably be included in the lualib, but ideally it would only be emitted when the project luatarget is set to 5.1, e.g. tstl --luaTarget 5.1

I actually just hotfixed unpack out of the map implementation, if you merge master into your branch that should hopefully fix the failing tests.