sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: pipeline deadlock with readable tail?
Labels: stream

https://github.com/nodejs/node/pull/40653#discussion_r739873780

@lpinca feel free to edit issue and fill out with your concern. Otherwise I will dig into this at some later point.

---

The `pipeline()` callback might never be called if the destination is a `Transform` stream that is not read. Here is an example.

```js
const stream = require('stream');

const chunk = Buffer.alloc(1024);
let bytesRead = 0;

const readable = new stream.Readable({
  read() {
    if (bytesRead === 100 * 1024) {
      readable.push(null);
    } else {
      bytesRead += chunk.length;
      readable.push(chunk);
    }
  }
});

const passThrough = new stream.PassThrough();

stream.pipeline(readable, passThrough, function (err) {
  if (err) {
    throw err;
  }

  console.log('done');
});
```

In the callback version this is not a big issue because `pipeline()` returns the last stream, so the user could resume the returned stream.

```js
pipeline(readable, passThrough, fn).resume();
```

In the promisified variant, `pipeline()` is just a wrapper that returns a promise that is fulfilled when the callback of the callback variant is called.

However the user could not be able to resume the returned stream because they might not have direct control on it. For example if the last entry is a generator.

```js
const stream = require('stream');
const streamPromises = require('stream/promises');

const chunk = Buffer.alloc(1024);
let bytesRead = 0;

const readable = new stream.Readable({
  read() {
    if (bytesRead === 100 * 1024) {
      readable.push(null);
    } else {
      bytesRead += chunk.length;
      readable.push(chunk);
    }
  }
});

async function* passThrough(source) {
  for await (const chunk of source) {
    yield chunk;
  }
}

async function run() {
  await streamPromises.pipeline(readable, passThrough);
}

run()
  .then(function () {
    console.log('done');
  })
  .catch(console.error);
```

In this case `stream.pipeline()` returns an internal `PassThrough` proxy that the user cannot resume so the promise returned by `streamPromises.pipeline()` might never be fulfilled.

A possible workaround is to resume the returned stream in the promisified variant.

```diff
diff --git a/lib/stream/promises.js b/lib/stream/promises.js
index 0db01a8b20..5bbadd43c5 100644
--- a/lib/stream/promises.js
+++ b/lib/stream/promises.js
@@ -23,13 +23,17 @@ function pipeline(...streams) {
       signal = options.signal;
     }
 
-    pl(streams, (err, value) => {
+    const stream = pl(streams, (err, value) => {
       if (err) {
         reject(err);
       } else {
         resolve(value);
       }
     }, { signal });
+
+    if (stream.readable) {
+      stream.resume();
+    }
   });
 }
```
Repository: rust
Issue: [ER] Suggest X::from() instead of "as" where possible
Labels: A-diagnostics,T-compiler

This is a diagnostic enhancement request in two similar parts.
Currently (1.58.0-nightly ff0e14829 2021-10-31) this gives no errors nor warnings:

```rust
#![allow(dead_code, unused_variables)]
fn main() {
    let x = 1_u32;
    let y = x as u64;
    const X: u32 = 1;
    const Y: u64 = X as _;
}
```

But I'd like a help message that suggests to replace the "as" with a from, nudging the programmer to write:

```rust
#![allow(dead_code, unused_variables)]
fn main() {
    let x = 1_u32;
    let y = u64::from(x);
    const X: u32 = 1;
    const Y: u64 = X as _;
}
```

And eventually once the two features are stable, nudging to write:

```rust
#![feature(const_num_from_num, const_trait_impl)]
#![allow(dead_code, unused_variables)]
fn main() {
    let x = 1_u32;
    let y = u64::from(x);
    const X: u32 = 1;
    const Y: u64 = u64::from(X);
}
```
Repository: create-react-app
Issue: need solution 
Labels: stale

![image](https://user-images.githubusercontent.com/49165830/139653349-5cf8bc93-f0cc-49ee-8b1b-c5faf240fcc6.png)
why it's not allowing me to deployment my repo into github.io?
Repository: create-react-app
Issue: Critical vulnerability in shell-quote
Labels: needs triage,issue: bug report

react-dev-utils is using shell-quote 1.7.2 which has a vulnerability that has been fixed in 1.7.3
Repository: godot
Issue: Make sub-resources unique on AnimationTree resources crashes Engine
Labels: bug,topic:editor,confirmed,crash,topic:animation

### Godot version

3.4 rc2

### System information

kubuntu 21.04

### Issue description

Possibly related to: #39510, #39510

The "make subresource unique" button in the animation tree makes resources such as the blend tree or state machine unique, but has no effect on nested resources.
If in the nodes editor of this resource we make the nested resource unique by selecting the resource node, it causes the engine to crash. 

### Steps to reproduce

1. Open example.tscn
2. Select AnimationTree
3. Select SubStateMachine (or any other node) in AnimationTree node editor
4. Press Make Sub-Resources Unique

### Minimal reproduction project

[AnimationTreeCrash.zip](https://github.com/godotengine/godot/files/7452522/AnimationTreeCrash.zip)
Repository: TypeScript
Issue: Module augmentation with multiple modules when using "export * from"
Labels: Needs Investigation

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

- "declare module"
- "export everything"
- "export * from"
- "module augmentation"

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about "export everything", "export * from", "declare module", "module augmentation"

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
_Used Code Sandbox, because it requires multiple files._
[Code Sandbox link with relevant code](https://codesandbox.io/s/runtime-firefly-l90qy?file=/src/index.ts)

### 💻 Code

See the Code Sandbox link, because it requires multiple files.

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
I've created a module augmentation using `declare module` in a package, where I try to extend an interface. This works once, but when the second module wants to extend that same interface, the initial interface is lost in the progress.

So as the example shows, the interface `Metadata` of `main-package` is the initial interface. When I'm trying to extend it in `module-a`, everything works fine. But when I'm also extending is in `module-b`, the initial interface typing is lost in the progress. Only when referring to `declare module "../../main-package/interfaces/metadata.interface"` in both modules, everything works as expected.

It looks like the cause is that I'm exporting the interface `Metadata` by using 
```ts
export * from './interfaces/metadata.interface';
```

The problem is resolved when I use:
```ts
export { Metadata } from './interfaces/metadata.interface';
``` 

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->
I expected it to just extend the interface when declaring the module in multiple packages, even if I'm using:
```ts
export * from './interfaces/metadata.interface';
```
Repository: next.js
Issue: Emitted 'error' event on WriteStream instance
Labels: Performance

### What version of Next.js are you using?

12.0.2

### What version of Node.js are you using?

v14.11.0

### What browser are you using?

chrome

### What operating system are you using?

windows

### How are you deploying your application?

next run build

### Describe the Bug

Hi, 

When making a build for production, I keep getting this error. I never had the issue before upgrading to version 12.0.0.
I tried deleting the file, but it only works when the dev server is not running, while it runs I cannot open or delete it and that make every production build fail.

```
info  - Creating an optimized production build .events.js:291
      throw er; // Unhandled 'error' event
      ^

Error: EPERM: operation not permitted, open 'D:\[...]\.next\trace'
Emitted 'error' event on WriteStream instance at:
    at D:\[...]\node_modules\next\dist\compiled\@vercel\nft\index.js:1:287421
    at D:\[...]\node_modules\next\dist\compiled\@vercel\nft\index.js:1:287860
    at FSReqCallback.oncomplete (fs.js:164:23) {
  errno: -4048,
  code: 'EPERM',
  syscall: 'open',
  path: 'D:\\[...]\\.next\\trace'
}
```

### Expected Behavior

I expect it to work when building

### To Reproduce

clone the with-typescript example, run `npm run dev` and once done `npm run build`
Repository: godot
Issue: TileSet Collision Editor - buggy behaviour when releasing key combinations in different order
Labels: bug,topic:editor,confirmed,topic:input,topic:2d

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___


### Godot version

3.3.4.stable.mono.official.faf3f883d

### System information

Windows 10

### Issue description

I'm following a YT tutorial on making a 2D game in Godot, and currently I'm adding collision rectangles to my TileSet in the TileSet editor, Collision tab.

I've noticed that the "New Rectangle" button can be activated using "Shift+R" shortcut, so I started using it to make the process faster, but then I've encountered some bugs:
- if the selection tool (mouse pointer icon) is active and "Shift+R" is pressed too fast, both icons stay highlighted and clicking on the tile grid has no effect (it acts as if only the selection tool was active)
- if the "New Rectangle" tool is active and "Shift+P" (New Polygon) is clicked too fast, both icons stay highlighted and clicking on the grid has the effect of "New Rectangle" tool
- if the "New Polygon" tool is active and "Shift+R" is clicked too fast, both icons stay highlighted and clicking on the grid has the effect of "New Polygon" tool

Actually, I think "clicking too fast" just means releasing the keys in different order, for example: if I have the selection tool active and I press Shift, then press R, then release R, then release Shift, the tool is properly changed to "New Rectangle". But if I press Shift, then press R, then release Shift, then release R, the bug appears. So it seems like releasing the keys in certain order matters, that's why doing it too fast may be causing issues.

### Steps to reproduce

1. Open the TileSet editor in the attached project.
2. Navigate to Collision tab.
3. Select the "Selection" tool.
4. Click on any cell on the grid.
5. Press and hold left Shift.
6. Press and hold R.
7. Release left Shift.
8. Release R.

After these steps, "Selection" and "New Rectangle" icons stay highlighted, clicking on the grid has the effect of "Selection" tool. Same stays true if you try "Shift+P" or start on different tool than "Selection".

### Minimal reproduction project

[minimal-example.zip](https://github.com/godotengine/godot/files/7453449/minimal-example.zip)
Repository: node
Issue: Thrown AbortErrors are not DOMExceptions
Labels: errors

### Version

v17.0.1

### Platform

any

### Subsystem

_No response_

### What steps will reproduce the bug?

```js
import { readFile } from 'fs/promises';

const ref = new DOMException('The operation was aborted', 'AbortError');
console.log('REF INSTANCE', ref instanceof DOMException);
console.log('REF OBJECT', ref);

const ab = new AbortController();
ab.abort();

try {
    await readFile('does_not_matter', { signal: ab.signal });
}
catch (err) {
    console.log('ERR INSTANCE', err instanceof DOMException);
    console.log('ERR OBJECT', err);
}
```

### How often does it reproduce? Is there a required condition?

100%, including for all other native APIs that supports signals.

### What is the expected behavior?

From the docs:

> If a request is aborted the promise returned is rejected with an `AbortError`

There is no mention that this is a non-standard `new DOMException(message, 'AbortError')` error. As such, I expect 'REF' and 'ERR' logged objects to be the same (except the stack).

### What do you see instead?

```
REF INSTANCE true
REF OBJECT DOMException [AbortError]: The operation was aborted
    at file://<snip>/fail.mjs:3:13
    at ModuleJob.run (node:internal/modules/esm/module_job:185:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:281:24)
    at async loadESM (node:internal/process/esm_loader:88:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12)
ERR INSTANCE false
ERR OBJECT AbortError: The operation was aborted
    at checkAborted (node:internal/fs/promises:373:11)
    at readFile (node:internal/fs/promises:845:3)
    at file://<snip>/fail.mjs:11:11
    at ModuleJob.run (node:internal/modules/esm/module_job:185:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:281:24)
    at async loadESM (node:internal/process/esm_loader:88:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12) {
  code: 'ABORT_ERR'
}
```

### Additional information

This is only an issue in node 17+, since previous versions did not have a `DOMException` global.
Repository: material-ui
Issue: Adding new component variants does not work as documented for all components
Labels: new feature

The v5 documentation details [how to create new variants](https://mui.com/customization/theme-components/#adding-new-component-variants) for components. The example there with Button works great with TS because `@mui/material/Button` exports `ButtonPropsVariantOverrides`.

However, it seems that not all components follow this pattern - namely `@mui/material/Menu` and `@mui/material/Select`. There are probably more, but these two do not export something along the lines of `SelectPropsVariantOverrides` - their variants are merely a string union. It would be great to achieve consistency in how new variants are added and typed across components

<!--
  Thank you very much for contributing to MUI by creating an issue! ❤️
  To avoid duplicate issues we ask you to check off the following list.
-->

<!-- Checked checkbox should look like this: [x] -->

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

There is no clear way to add new typed variants in TS for Select and Menu

## Expected Behavior 🤔

It should work as well as it does with the Button component - I should be able to create new variants for MuiSelect in my theme file.

## Steps to Reproduce 🕹

https://codesandbox.io/s/old-lake-ut7e1?file=/src/Demo.tsx

## Context 🔦

I'm trying to create new variants for MuiSelect in my theme file.

## Your Environment 🌎

<!--
  Run `npx @mui/envinfo` and post the results.
  If you encounter issues with TypeScript please include the used tsconfig.
-->
<details>
  <summary>`npx @mui/envinfo`</summary>
  
```
Browser: Chrome

  System:
    OS: macOS 11.6
  Binaries:
    Node: 14.17.6 - /usr/local/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 6.14.15 - /usr/local/bin/npm
  Browsers:
    Chrome: 95.0.4638.69
    Edge: Not Found
    Firefox: 93.0
    Safari: 15.0
  npmPackages:
    @emotion/react: latest => 11.5.0
    @emotion/styled: latest => 11.3.0
    @mui/core:  5.0.0-alpha.53
    @mui/icons-material: ^5.0.5 => 5.0.5
    @mui/lab: ^5.0.0-alpha.53 => 5.0.0-alpha.53
    @mui/material: latest => 5.0.6
    @mui/private-theming:  5.0.1
    @mui/styled-engine:  5.0.2
    @mui/system:  5.0.6
    @mui/types:  7.0.0
    @mui/utils:  5.0.1
    @types/react: latest => 17.0.33
    react: latest => 17.0.2
    react-dom: latest => 17.0.2
    typescript: latest => 4.4.4
```
</details>
Repository: TypeScript
Issue: Option: case-sensitive suggestions
Labels: Suggestion,Domain: Completion Lists,Awaiting More Feedback

# Suggestion
## 🔍 Search Terms

Different combinations of:
suggest, import, case-sensitive, case sensitive, case, complete, auto-complete, auto complete

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [X] This wouldn't change the runtime behavior of existing JavaScript code
* [X] This could be implemented without emitting different JS based on the types of the expressions
* [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

Add an (language-server) option, which can be utilized by IDEs to toggle the case-sensitivity of suggestions provided. 

## 📃 Motivating Example

Import suggestions currently match case-insisitive. Typing `item` and triggering suggestions would first show everything that *starts* with either `Item` or `item` and then everything that *contains* the same. The ability to toggle the behavior would narrow down suggest-"results" drastically, strongly improving UX. An option means this would be a non breaking addition.

## 💻 Use Cases

Often a function that has a single object argument is named using pattern like the following:
```ts
function doSomething(props: DoSomethingProps) { ... }
```
Especially in libraries, which export the type with the function for ease of usage and apply this naming so its easy to discover the input type when needed. When I want the type I would start typing upper case `D` and when I want the function I would type lower-case `d`.

Generally, the naming pattern upper/lower for Types/functions is so common, that finding anything with a sensitive setting would be much easier. Since its an option, nobody who does not agree would be harmed by this.


No workaround currently I'm aware of, other than just accepting almost twice as much suggestions as would be useful.
Repository: rust
Issue: "untyped pointers are not allowed in constant" diagnostic is unhelpful
Labels: A-diagnostics,T-compiler,A-const-eval,D-confusing,D-terse,A-raw-pointers

Given the following code ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=5c525f2baa852c78e8fd6d8d1d1f2918)):
```rust
const FOO: *const Vec<usize> = &Vec::new();
```

The current output is:
```
error: untyped pointers are not allowed in constant
 --> src/lib.rs:1:1
  |
1 | const FOO: *const Vec<usize> = &Vec::new();
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

This diagnostic is fairly opaque (what is an "untyped pointer"?) and doesn't provide much help for how to correct the situation. Unfortunately, I'm not certain how the diagnostic could be improved since I'm not entirely sure why it was emitted in the first place (it seems like it has something to do with leaking allocations in consts?).

@rustbot modify labels: +A-const-eval +A-raw-pointers +D-confusing +D-terse
Repository: rust
Issue: hidden_unicode_codepoints.rs interacts oddly with Firefox Inspector
Labels: C-cleanup,A-Unicode,T-compiler

The structure of the very special [hidden_unicode_codepoints.rs](https://github.com/rust-lang/rust/blob/master/compiler/rustc_lint/src/hidden_unicode_codepoints.rs) code has a documentation block that includes a left-to-right reversal character.

Its useful that it does this, because it demonstrates the problem that the associated lint is talking about.

However, from what I can tell, its presence in the file is causing the Firefox Inspector to present the remainder of the file in a funny way. See attached image.

![image](https://user-images.githubusercontent.com/173127/139708706-c09ed947-1791-4d4b-bfc9-cab7b373b4a2.png)

This is truly a minor hiccup, since we expect to see these text flow characters to occur only in *very* rare circumstances in our source code. Still, it would be nice if we could figure out a way to structure that source file that did not cause the Web Browser's inspector functionality to act so oddly.
Repository: material-ui
Issue: false positive for onDoubleClick on Chip
Labels: bug 🐛,component: chip

If I quickly tap with Chrome for Android on 2 different Chip components so that my taps are very spatially close, the onDoubleClick is called on the second Chip.
This happens if they are close horizontally but also vertically.

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

onDoubleClick is executed even if the Chip where this prop is set was clicked just once

## Expected Behavior 🤔

only onClick should be executed

## Steps to Reproduce 🕹

https://codesandbox.io/s/fast-waterfall-jkbxy?file=/src/Demo.tsx

Steps:
1. be sure to be on your mobile (i reproduce it with Chrome on Android)
2. tap on chip1
3. quickly tap on chip2

you should see: single1 - single2
what you get is: single1 - single2 - double2
Repository: vscode
Issue: Decorations flickering on editor change
Labels: feature-request,editor-api

Does this issue occur when all extensions are disabled?: Yes

- VS Code Version: 1.61.2
- OS Version: macOS Big Sur 11.6

I've recently been trying to optimize an extension that decorates `[[...]]` wikilinks in markdown documents. Every time I switched between editors a very noticeable flickering happened because of the syntax rehighlighting of the editor and, not so shortly after that, a delayed repainting of decorations. I checked other similar extensions and the pattern was always the same. It's even suggested in this "official" example: https://github.com/microsoft/vscode-extension-samples/blob/main/decorator-sample/src/extension.ts. There are two problems:

1. The suggested delay of 500ms might be reasonable for in-editor changes but for editor switching it produces this: https://github.com/foambubble/foam/issues/805#issuecomment-954604703.
2. Even with no throttling at all and with precalculation and caching of document decorations (that I roughly implemented here https://github.com/svsool/vscode-memo/pull/479) there is the same repainting glitch, although it's less obvious.

The second point is likely the hard one because it might be due to a more structural limit of the design. Why is VSCode triggering document-wise updates of decorations in unchanged documents? From the perspective of the extension author, is there any way to do that update incrementally, some knowledge of damaged/exposed chunks?

N.B. in the above cases extending the syntax was also problematic, for example because of the need to distinctively  decorate valid and invalid links. Even if the syntax extension approach were effective here, the point still stands that decorations seem ill-suited for anything but small documents and even in those documents they produce visual artifacts on editor switching.