Suboptimal compilation for rest parameters

[a-bronx]

There is an TS/ES.next idiom for the JS arguments array: (...args: any[]). But using it may produce suboptimal transpilation result, for example:

function debug(...args: any[]) {
    if (!settings.debug) return;
    console.log("DEBUG:", ...args);
}

produces following JavaScript (ES5) code:

function debug() {
    var args = [];
    for (var _i = 0; _i < arguments.length; _i++) {
        args[_i] = arguments[_i];
    }
    if (!settings.debug)
        return;
    console.log.apply(console, ["DEBUG:"].concat(args));
}

Note that the arguments is copied to the args array immediately at the beginning of the function, before its real usage. This causes the code executed every time the debug() function is called, even if it is unnecessary.

Expected behavior would be something more intelligent: either moving the arguments unrolling code closer to the usage place (may be tricky if there are multiple usage points), or using Array.prototype.slice.call(arguments) in-place without copying it into the temporary args.

Compare with Babel's transpilation result:

function debug() {
    var _console;

    if (!settings.debug) return;

    for (var _len = arguments.length, args = Array(_len), _key = 0; _key < _len; _key++) {
        args[_key] = arguments[_key];
    }

    (_console = console).log.apply(_console, ["DEBUG"].concat(args));
}

Note that here the copying was moved past the conditional expression and happens only when needed.

[RyanCavanaugh]

Accepting PRs for the following optimizations (doesn't need to have all of them):

• Move the array copy emit to the first top-level statement which is before any statement which references it
• Elide the array copy emit if it's never referenced
• Elide the array copy emit if all accesses of the rest arg are of the form x[k] where k is a numeric literal, and replace k with k + n (where n is the correct offset)

[charlespierce]

@Kingwl Are you still working on this issue? I'd like to take a swing at implementing some of the optimizations but don't want to duplicate work.

[Kingwl]

@charlespierce No, I'm not on it, please feel free

[charlespierce]

PR Opened with implementation of the first two bullet points: #20307

[RyanCavanaugh]

@ORESoftware please don't leave +1 comments; use the GitHub reactions feature (👍 on the issue). And there's certainly no point to multiple +1 comments on the same issue

[ORESoftware]

oh sorry I didn't realize I had already done that! yeah I haven't figured out how to use the reactions but I will now

[charlespierce]

@RyanCavanaugh The PR for this issue #20307 is still awaiting review. I recognize it's a big diff, touching so many existing baselines, so is there anything I can do to help make it more manageable?

[Kingwl]

i'd like to work on this (again) 😅

[DanielRosenwasser]

I think this is a duplicate of #498

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[a-bronx]

I think it is a different issue. The #498 is about TS generating code for unused rest parameter. This issue is about rest parameters that are used in some (possibly rare) code paths, but generated code is placed into all code paths, making it suboptimal.