CI: https://ci.nodejs.org/job/node-test-pull-request/38622/

CI: https://ci.nodejs.org/job/node-test-pull-request/38623/

even if the same filename is used again

that's weird. filename is aslso the same when you don't specify it (it defaults to 'evalmachine.<anonymous>')

@joyeecheung @targos : I made a typo in my initial trial. Using a filename indeed helps, even if the same filename is used again:

> console.log(new vm.Script("", {cachedData: b, filename: 'a.js'}))
Script { cachedDataRejected: true }
undefined
> console.log(new vm.Script("", {cachedData: b, filename: 'a.js'}))
Script { cachedDataRejected: true }
undefined```

Yes, I think mkdtemp() does work with an empty prefix string. The only requirement is that the last 6 characters of the template must be XXXXXX. It just replaces the 6 trailing X characters (or more if present on BSD) of the template with random characters to make the directory name unique and makes the directory.

cc @jasnell Since this was added in https://github.com/nodejs/node/commit/060e5f0c0064e578c2150f13e3f91ac15fdeed92.

@bakkot thanks for the PR!

In the situation in question - i.e., when the case consists of exactly one statement, which is a BlockStatement - I've chosen to check for the fallthrough comment in both places. This means that it becomes possible to have a comment after the fallthrough comment, as long as it's after the block, as in

switch (foo) {
  case 1: {
    let x = value;
    console.log(value);
    // falls through
  }

  // some other comment
  case 2: {
    doSomething();
  }
}

I agree, I think it's fine to allow any comments after } when the fallsthrough comment is last in { ... }.

Unfortunately SDKMAN team doesn't feel ready to expand outside JVM ecosystem just yet. This issue can be closed for now. I'll raise a PR once/if they reconsider.

Description

After launching build 4017 for the first time, i could not see any sublime text window. the windows were listed in the window menu, but stayed hidden. I have two keyboards and it was focused on the 2nd one.

After managed to show the windows with selecting one window in the window menu with the Alt key pressed (a mac trick to reposition windows out of actual screen size).

After new launch, the problem did not reproduce.

Steps to reproduce

1. Start Sublime Text in safe mode
2. Second step
3. Third step

Expected behavior

Show windows at startup

Actual behavior

no visible window even after asking to bring them all to front in the window menu

Environment

• Build: 4107
• Operating system and version: macOS 10.13.6

Looks like we have 2 LGTMs then, but @ljharb's wasn't properly registered since it's a comment.

CI: https://ci.nodejs.org/job/node-test-pull-request/38621/

is it mainly a feature request for us (i.e V8 gives us the reason for the rejection but we don't expose it) or for V8 ?

I'd say both, V8 needs to expose more info about cache behavior in the embedder API and we need to expose that in our JS API, right now all we have is a boolean when internally it is more like a enum.

Likely I will have to implement the feature in a different way, possibly by validating some aspects of the bytecode on our own or by adding another checksum.

Does targo's suggestion of changing the filename work for you? That gives the script a different origin so the second try won't hit the compilation cache.

CI: https://ci.nodejs.org/job/node-test-pull-request/38620/

I agree it's confusing, but does the function "work" with an empty string? what does it do?

Thank you for the hit. I'll change this :+1:

I've removed semver-major. But I think it might have to go back. Second opinions?

@nodejs/streams @nodejs/http

I don't think so because these variables are reassigned values afterwards: https://github.com/nodejs/node/blob/6ccafaba0e4e92ba7ed3582711bc29a9042c2030/lib/internal/streams/transform.js#L258

Currently the error throw when passing the empty string is quite confusing to be honest: TypeError [ERR_INVALID_ARG_TYPE]: The "prefix" argument must be of type string. Received type string ('').

CI: https://ci.nodejs.org/job/node-test-pull-request/38619/

@bcoe Do you think this should be backported to v14.x?

Nit: Can this be declared as const?

Refs: https://github.com/nodejs/llhttp/releases/tag/release%2Fv3.0.0

@indutny

/cc @jasnell ?

<!-- ESLint adheres to the Open JS Foundation Code of Conduct: https://eslint.org/conduct

This template is for requesting a rule change. If you are here for another reason, please see below:

1. To report a bug: https://eslint.org/docs/developer-guide/contributing/reporting-bugs
2. To propose a new rule: https://eslint.org/docs/developer-guide/contributing/new-rules
3. To request a change that is not a bug fix, rule change, or new rule: https://eslint.org/docs/developer-guide/contributing/changes
4. If you have any questions, please stop by our chatroom: https://eslint.org/chat

Note that leaving sections blank will make it difficult for us to troubleshoot and we may have to close the issue.

-->

What rule do you want to change? padding-line-between-statements

Does this change cause the rule to produce more or fewer warnings? Potentially more

How will the change be implemented? (New option, new default behavior, etc.)? By extending the StatementTypes object with a new test.

Please provide some example code that this change will affect:

There is a code style rule in our company that there has to be a space between every variable declaration followed by a function call and vice versa.

<!-- Put your code examples here -->

const x = 10;
const y = 20;
const result = add(x, y); // <- thats ok because it is also a variable declaration
const p = 30;

const x = 10;
const y = 20;
printAdd(x, y); // <- this would be wrong because the declaration of y is followed by a call to printAdd
const p = 30; // <- would be also wrong

What does the rule currently do for this code? Right now nothing because i don't think i can configure the rule to my needs without extending the StatementTypes object.

What will the rule do after it's changed? Adding a space between assignments and function calls.

const x = 10;
const y = 20;

printAdd(x, y);

const p = 30;

foo(x);
bar(y);

Are you willing to submit a pull request to implement this change? Yeah

I think the problem is still what I wrote in the comment above. V8 has foreground tasks and background tasks. Typically background tasks could be ignored completely, they just exist to make V8 faster. For example, the optimizing compiler can be executed on a background task, but if this task is not executed, then V8 can still execute the baseline code. Similarly the garbage collector can be executed on a background task, but if the background task is not executed, then V8 will just stop the main thread and do garbage collection on the main thread. This means also, that when all foreground tasks have finished and only background tasks are left, you can just terminate the node without any issue.

The only case where background tasks are important, and where node should wait for background tasks, is asynchronous compilation of WebAssembly modules. In that case the WebAssembly module gets compiled completely on background tasks, and the last background task will then spawn a foreground task to continue execution on the main thread. This means that if node terminates when no foreground task is available anymore, it would not wait for WebAssembly compilation to finish, and not would potentially not execute an important part of a script.

V8 introduced the API function Isolate::HasPendingBackgroundTasks() to tell the embedder if there is background work that will spawn a foreground task or not. If Isolate::HasPendingBackgroundTasks() returns false, then node can just terminate. But if Isolate::HasPendingBackgroundTasks() returns true, node should also wait for background tasks to finish.

This seems to only happen with conhost.exe.

CI: https://ci.nodejs.org/job/node-test-pull-request/38618/

Bumps tslib from 2.0.3 to 2.2.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/Microsoft/tslib/releases">tslib's releases</a>.</em></p> <blockquote> <h2>tslib 2.2.0</h2> <p>This release supports TypeScript 4.3's new functionality for ECMAScript private methods and accessors, and private static class members.</p> <p>It does so by expanding the scope of <code>__classPrivateFieldGet</code> and <code>__classPrivateFieldSet</code>. See <a href="https://github-redirect.dependabot.com/microsoft/tslib/pull/146">microsoft/tslib#146</a> for more details.</p> <h2>tslib 2.1.0</h2> <p>This release adds a new <code>__spreadArray</code> helper which avoids side-effects compared to the now-deprecated <code>__spreadArrays</code> and <code>__spread</code> helpers. See <a href="https://github-redirect.dependabot.com/microsoft/tslib/pull/133">microsoft/tslib#133</a> for more details.</p> <p>This release also provides a more-specific error message when extending from a type which is not a function and not null. See <a href="https://github-redirect.dependabot.com/microsoft/tslib/pull/138">microsoft/tslib#138</a> for more details.</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/microsoft/tslib/commit/f7eea49789d7902f96802d37e674e75590f7eb66"><code>f7eea49</code></a> Bump version to 2.2.0.</li> <li><a href="https://github.com/microsoft/tslib/commit/145fdc06d95a5220ee916bf19ce5f7d7a5b87e48"><code>145fdc0</code></a> update private class element helpers (<a href="https://github-redirect.dependabot.com/Microsoft/tslib/issues/2">#2</a>) (<a href="https://github-redirect.dependabot.com/Microsoft/tslib/issues/146">#146</a>)</li> <li><a href="https://github.com/microsoft/tslib/commit/54a056a7e501b5e1978fe1cb5b743bb0f69a2a74"><code>54a056a</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/Microsoft/tslib/issues/141">#141</a> from microsoft/bumpVersion-2.1.0</li> <li><a href="https://github.com/microsoft/tslib/commit/e7a115533a28b90e48139e77462e0b5812983847"><code>e7a1155</code></a> Bump version to 2.1.0.</li> <li><a href="https://github.com/microsoft/tslib/commit/88a77b89fb06b3f0c9a5c6ed353a1be0da3092c8"><code>88a77b8</code></a> Update tslib to support new __spreadArray helper (<a href="https://github-redirect.dependabot.com/Microsoft/tslib/issues/133">#133</a>)</li> <li><a href="https://github.com/microsoft/tslib/commit/cff487d37b90744c080f7e4d24eb1f9cf7a4a6a2"><code>cff487d</code></a> Ported runtime TypeError for non-function, non-null __extends (<a href="https://github-redirect.dependabot.com/Microsoft/tslib/issues/138">#138</a>)</li> <li><a href="https://github.com/microsoft/tslib/commit/fcba93d415a6d84914916769ba17871902dd4598"><code>fcba93d</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/Microsoft/tslib/issues/136">#136</a> from microsoft/fix_ci</li> <li><a href="https://github.com/microsoft/tslib/commit/0fc8e738916d1ca05343eea26b727045e0ebc211"><code>0fc8e73</code></a> Fix CI</li> <li>See full diff in <a href="https://github.com/Microsoft/tslib/compare/2.0.3...2.2.0">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

</details>

Superseded by #940.