sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: `pipeline` doesn't work if `readable` listener is already attached
Labels: stream

### Version

v16.10.0

### Platform

`Linux solus 5.14.7-198.current #1 SMP PREEMPT Wed Sep 22 16:02:46 UTC 2021 x86_64 GNU/Linux`

### Subsystem

stream

### What steps will reproduce the bug?

```js
import {PassThrough, pipeline} from 'stream';

const first = new PassThrough();
const second = new PassThrough();

first.on('readable', () =>{
	console.log('readable');
});

pipeline(first, second, error => {
	console.log(`finished! error=${error}`);
});

first.push('foobar');
first.push(null);

second.resume();
```

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

Always.

### What is the expected behavior?

```diff
+finished! error=undefined
```

### What do you see instead?

```
readable
readable
```

### Additional information

_No response_
Repository: material-ui
Issue: [DatePicker] PickersDay - disableMargin doesn't affect weekday letters
Labels: bug 🐛,component: date picker

`disableMargins` prop, as the documentation states, removes the margins from the days of the calendar.
But it doesn't remove them from the weekday letters, which results in misalignment (see Current Behavior)

<!-- 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 😯

![image](https://user-images.githubusercontent.com/17963791/135270476-c06d676c-8742-4ed0-8bbe-c9cf0fb7e20e.png)
S for sunday is not vertically aligned with 5, same goes for the rest of the letters

## Expected Behavior 🤔

The letters are aligned to the numbers
(or additional prop for weekday letters is introduced like `disableWeekdayMargins`, which disables margins for the weekdays)

## Steps to Reproduce 🕹

go to https://mui.com/components/date-picker/#customized-day-rendering

## Your Environment 🌎
N/A really,  but here are the browsers:
Firefox: 93.0b9
Chrome: 96.0.4656.3
Repository: TypeScript
Issue: Auto import improvement for directory.
Labels: Suggestion,Awaiting More Feedback,Domain: Auto-import

# Suggestion
I have many components in my project, like:
```
components/
      button/
            button.tsx            // export class Button
            package.json       // { "main": "./button.tsx" }
     index.ts                      // export * from "./button"
pages/
    a.tsx
```
When auto importing `Button` in `a.tsx`.

### Expected behavior
`import {Button} from "./components/button";`

### Actual behavior
1) `import {Button} from "./components/button/button";`
2) `import {Button} from "./components/";`

When import `button/index.ts`, TS will omit `index` and use `button` automatically, but custom index file is not supported, through they can be loaded by specifying `main`/`types` field of `package.json`. 

One workaround is to rename all components to `index.tsx`, but it is a bad practice for two reasons:
1. When an error raised in one of the component, DevTools will only print `index.tsx` in source section.
2. When I opened many components at same time, it is very hard to find the correct `index.tsx`.

In addition, TS do not support multiple `*` and RegExp in `paths` of `tsconfig.json`,
I cannot write paths like:
```json
{
   "compilerOptions": {
      "path": {
         "./components/*": ["./components/*/*.ts"]
      }
   }
}
```
I have to add a 'package.json' to each component folder which only contains one line: `{"main": "./<dirname>.tsx"}`, which is too verbose.

`components/index.ts` re-exports all components in this directory. It is designed for users outside of this project.
I prefer direct exports over re-exports in `components` directory. (Mixed: #45015, #43777)

## 🔍 Search Terms
auto import shortest directory

## ✅ 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
Auto-import feature improvement for best practise.

## 📃 Motivating Example

## 💻 Use Cases
Repository: rust
Issue: Panics in procedural macros can lead to hundreds of unrelated resolution errors
Labels: A-diagnostics,T-compiler,D-verbose,A-proc-macros

One thing I've often seen with rustc when I'm developing a procedural macro is that I'm in a situation where a procedural macro is generating a bunch of code and I've got a file that's using all the code the procedural macro. Everything works well but inevitably I've got a bug in the macro and the macro panics. This causes the macro to not actually produce any items, but all the code I have that was hand-written and using the results of the generated macro is still there. This leads rustc to generate an error-per-use-of-generated code, which often for me at least can be in the dozens or hundreds of errors. I find that I basically have to sift through all the compiler errors back to the top to find the one with the procedural macro to actually find the issue.

Ideally I think rustc would recognize macro expansion errors and stop producing other name resolution errors related to the module that had the macro expansion error. Given that the macro could have possibly produced anything else in the module any other further error could be a false positive.

As a small example with this procedural macro:

```rust
// pm.rs
extern crate proc_macro;

use proc_macro::TokenStream;

#[proc_macro]
pub fn foo(a: TokenStream) -> TokenStream {
    if a.to_string() == "a" {
        panic!()
    }
    "pub fn foo() {}".parse().unwrap()
}
```

and a `main.rs`:

```rust
// main.rs
pm::foo!();

fn main() {
    foo();
}
```

compiling this yields no error:

```
$ rustc pm.rs --crate-type proc-macro
$ rustc main.rs --extern pm=./libpm.so
```

but changing `main.rs` to this:

```rust
// main.rs
pm::foo!(a);

fn main() {
    foo();
}
```

yields:

```
$ rustc pm.rs --crate-type proc-macro
$ rustc main.rs --extern pm=./libpm.so
error: proc macro panicked
 --> main.rs:1:1
  |
1 | pm::foo!(a);
  | ^^^^^^^^^^^^
  |
  = help: message: explicit panic

error[E0425]: cannot find function `foo` in this scope
 --> main.rs:4:5
  |
4 |     foo();
  |     ^^^ not found in this scope

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0425`.
```

The second error here isn't very helpful because it's just a knock-on effect of the first error. While this example itself is quite isolated and easy to debug, it's a bit more troublesome to sift through hundreds of knock-on effects from a mistake in a procedural macro than one.
Repository: godot
Issue: [Bullet] Godot 3.x with Bullet, collision layer & mask choice affects collision accuracy
Labels: bug,confirmed,topic:physics,topic:3d

### Godot version

3.x build 65ab9130e1e323b43b94f3336a58b6c6e7681c28

### System information

OS: Arch Linux, CPU: Ryzen 5, GUP: RX 480

### Issue description

Collisions between two physics bodies behave better when the collision layer & mask are chosen so that
`(collision_layer_a & collision_mask_b) != 0 AND (collision_layer_b & collision_mask_a) !=0` with respect to when
`(collision_layer_a & collision_mask_b) != 0 AND (collision_layer_b & collision_mask_a) ==0`
or
`(collision_layer_a & collision_mask_b) == 0 AND (collision_layer_b & collision_mask_a) !=0`
but two bodies should either not collide or properly collide.

This could also be affecting CCD. 

### Steps to reproduce

Attached is a project with two scenarios in which the only difference is the collision layer of the two rigid bodies.
The two rigid bodies have the same properties except for position & initial velocity (so same layer & collision mask).
In the well-behaved one, the rigid bodies are both stopped by the static one.
In the not well behaved one, the slow rigid body is stopped, but the fast one is not.

### Minimal reproduction project

[godot_bullet_collision_bug.zip](https://github.com/godotengine/godot/files/7252994/godot_bullet_collision_bug.zip)
Repository: flutter
Issue: background color of opened popup_menu isn't changing properly
Labels: framework,f: material design,has reproducible steps,found in release: 2.5,found in release: 2.6,team-design,triaged-design

I've added dark/light toggle to popup menu and found that it's not working as expected.

Neither changing color of `PopupMenuButton` nor changing `PopupMenuThemeData.color` both not leads to background color changing when the menu is in opened state. It changes only after reopen. After some research found the reason:

https://github.com/flutter/flutter/blob/dev/packages/flutter/lib/src/material/popup_menu.dart#L900
```
Future<T?> showMenu<T>({
...
return navigator.push(_PopupMenuRoute<T>(
   ...
    color: color, //this initialize route with color when menu  was opened
   ... 
  ));
```

and there it has more priority than the theme's one (which changes propertly).
https://github.com/flutter/flutter/blob/dev/packages/flutter/lib/src/material/popup_menu.dart#L603
```
color: route.color ?? popupMenuTheme.color,
```

For now, found workaround which solves my problem - do not set both of this colors. It leads to getting color from `ThemeData.cardColor` as fallback and it reacts on theme changing propertly.
Repository: pytorch
Issue: Incorrect reference to previous kernel in the warning displayed when overriding a previously registered kernel for the same operator and the same dispatch
Labels: triaged,module: dispatch

Context:
For `mul.Tensor`, when I register a fallthrough impl for ZeroTensor key as well as a specific registration in native_functions.yaml, I get a runtime warning that my previously registered kernel is being overrided  for the same operator and the same dispatch key (as expected). However, the previous_kernel, it points to seems incorrect. 

Relevant changes:
```
--- a/aten/src/ATen/ZeroTensorFallback.cpp
+++ b/aten/src/ATen/ZeroTensorFallback.cpp
@@ -88,8 +88,8 @@ namespace at {
-    // m.impl("mul.Tensor", torch::CppFunction::makeFallthrough());
+    m.impl("mul.Tensor", torch::CppFunction::makeFallthrough());
```

`aten/src/ATen/native/native_functions.yaml`
```
- func: mul.Tensor(Tensor self, Tensor other) -> Tensor
  device_check: NoCheck   # TensorIterator
  structured_delegate: mul.out
  variants: function, method
  dispatch:
    SparseCPU, SparseCUDA: mul_sparse
    MkldnnCPU: mkldnn_mul
    ZeroTensor: mul_zerotensor
```

PR:
https://github.com/pytorch/pytorch/pull/64837

```python
import torch
x=torch.efficientzerotensor(2)
y=torch.randn(2)
z=torch.mul(x, y)
print(z, z.is_zerotensor())
```

output:
```
[W OperatorEntry.cpp:129] Warning: Overriding a previously registered kernel for the same operator and the same dispatch key
  operator: aten::add.Tensor(Tensor self, Tensor other, *, Scalar alpha=1) -> (Tensor)
    registered at aten/src/ATen/RegisterSchema.cpp:20
  dispatch key: ZeroTensor
  previous kernel: registered at ../aten/src/ATen/BatchingRegistrations.cpp:1020
       new kernel: registered at aten/src/ATen/RegisterZeroTensor.cpp:89 (function registerKernel)
[W OperatorEntry.cpp:129] Warning: Overriding a previously registered kernel for the same operator and the same dispatch key
  operator: aten::mul.Tensor(Tensor self, Tensor other) -> (Tensor)
    registered at aten/src/ATen/RegisterSchema.cpp:20
  dispatch key: ZeroTensor
  previous kernel: registered at ../aten/src/ATen/BatchingRegistrations.cpp:1020
       new kernel: registered at aten/src/ATen/RegisterZeroTensor.cpp:89 (function registerKernel)
Entering mul_zerotensor
tensor([0., 0.]) True
```

cc. @ezyang
Repository: vscode
Issue: Explorer does not refresh when previously removed root is coming back
Labels: bug,file-explorer

Testing #133753

macOS. I have a VS Code window open to the `vscode` repo but it does NOT have focus. I instead have focus on another window of VS Code (or another app... same behavior)

Here's the script I'm running outside of VS Code:

All it does is renames the vscode folder that I have open in VS Code and renames it back 100 times.
```ps
1..100 | % {
    mv ./vscode ./vscode-olddd
    sleep 10
    mv ./vscode-olddd ./vscode
    sleep 10
}
```

I noticed that the _removal_ of the vscode folder gets reflected in the VS Code instance with the `vscode` repo (where it gives you the `!` that says this folder doesnt exist)

However, when the rename gets changed _back_ to `vscode` thus "recreating" the `vscode` folder, nothing is reflected in the VS Code instance with the `vscode` repo.

However, once I focus the VS Code instance with the `vscode` repo then the contents are refreshed and it shows up and everything is fine.
Repository: godot
Issue: Crash in when instancing `CPUParticles3D` when multithread rendering is active
Labels: bug,topic:rendering,crash

### Godot version

4.0.dev.custom_build. 87de2e7c4

### System information

Ubuntu 21.04 - Nvidia GTX 970, Gnome shell 3.38 X11

### Issue description

Simple
```
func _ready():
	add_child(CPUParticles3D.new())
```
cause this crash
```
#0  futex_wait (private=0, expected=2, futex_word=0x55556092e080) at ../sysdeps/nptl/futex-internal.h:146
#1  __lll_lock_wait (futex=futex@entry=0x55556092e080, private=0) at lowlevellock.c:52
#2  0x00007ffff7db87b0 in __GI___pthread_mutex_lock (mutex=0x55556092e080) at ../nptl/pthread_mutex_lock.c:115
#3  0x00005555576dfd8b in __gthread_mutex_lock (__mutex=0x55556092e080) at /usr/include/x86_64-linux-gnu/c++/10/bits/gthr-default.h:749
#4  0x00005555576dfe0a in __gthread_recursive_mutex_lock (__mutex=0x55556092e080) at /usr/include/x86_64-linux-gnu/c++/10/bits/gthr-default.h:811
#5  0x00005555576dffba in std::recursive_mutex::lock (this=0x55556092e080) at /usr/include/c++/10/mutex:106
#6  0x000055555b8f33c4 in MutexImpl<std::recursive_mutex>::lock (this=0x55556092e080) at ./core/os/mutex.h:47
#7  CommandQueueMT::lock (this=0x55556092dd30) at core/templates/command_queue_mt.cpp:37
#8  0x000055555b8f3449 in CommandQueueMT::_alloc_sync_sem (this=0x55556092dd30) at core/templates/command_queue_mt.cpp:53
#9  0x000055555ae9e5af in CommandQueueMT::push_and_sync<RenderingServerDefault, void (RenderingServerDefault::*)()> (this=0x55556092dd30, p_instance=0x55556092dbc0, 
    p_method=(void (RenderingServerDefault::*)(RenderingServerDefault * const)) 0x55555ae757b8 <RenderingServerDefault::_thread_flush()>) at ./core/templates/command_queue_mt.h:399
#10 0x000055555ae75963 in RenderingServerDefault::sync (this=0x55556092dbc0) at servers/rendering/rendering_server_default.cpp:365
#11 0x000055555771c825 in Main::iteration () at main/main.cpp:2568
#12 0x00005555576d9e38 in OS_LinuxBSD::run (this=0x7fffffffd9e0) at platform/linuxbsd/os_linuxbsd.cpp:342
#13 0x00005555576d61df in main (argc=1, argv=0x7fffffffded8) at platform/linuxbsd/godot_linuxbsd.cpp:58
```

### Steps to reproduce

Above

### Minimal reproduction project

[Untitled Folder.zip](https://github.com/godotengine/godot/files/7254021/Untitled.Folder.zip)
Repository: godot
Issue: Merge conflict between GDNative and Android plugins shared libraries
Labels: bug,platform:android,topic:buildsystem,topic:export

### Godot version

3.3.3.stable

### System information

Android

### Issue description

We need to surface to the user when GDNative addons have **similarly named** shared libraries as the Android plugins included in the project.

As of [Godot 3.3.3](https://github.com/godotengine/godot/pull/49912), the GDNative addons silently override the shared libraries provided by the Android plugins which can lead to invalid builds and user confusion.

I'm not sure there's an automatic way we can resolve these merge conflicts, and so I'm leaning toward surfacing the issue to the user for a manual resolution (e.g: deleting the invalid shared libraries).

### Steps to reproduce

Load a Godot project which has GDNative addon(s) and Android plugin(s) with similarly named shared libraries and attempt to export the project.

### Minimal reproduction project

_No response_
Repository: go
Issue: runtime: enhance map cacheline efficiency
Labels: Performance,NeedsInvestigation

Looking at the Golang source code for how `map` is implemented [1], there seems to be a possible opportunity to enhance cacheline efficiency:

The current algorithm appears to work as follows for looking up a key in a map:

* Hash the key [2] and find the associated bucket [3].
* Search along bucket `.tophash` array [4] for a key candidate <-- cacheline fetch 1
* Binary compare key in key array [5] <-- cacheline fetch 2
* Grab associated element address in element array [6] <-- cacheline fetch 3 (when caller uses element address)

So there are 3 arrays in a bucket; `.tophash` array, key array, and element (value) array. Each array has the same hard-coded `bucketCnt` length of 8 elements [7]. A key array item size is typically 16 bytes. This means a typical total key array size is 8 items * 16 byte size = 128 bytes long, or 2x (typically sized) 64 byte cachelines. The total key array size means the associated element array item is usually located in a different cacheline.

This can also be seen (added padding and comments to make it easier to read) from the way the key and element addresses are calculated in the source code:

```
k  :=  add(unsafe.Pointer(b), dataOffset+i        *uintptr(t.keysize)                      ) // <-- [8]
e  :=  add(unsafe.Pointer(b), dataOffset+bucketCnt*uintptr(t.keysize)+i*uintptr(t.elemsize)) // <-- [9]
//                                                                    ^^^^^^^^^^^^^^^^^^^^^ element array
//                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ key array
//                            ^^^^^^^^^^ skip .tophash array
```

Possible optimization:

If the key and element arrays would be interleaved (instead of separate arrays) then this would not guarantee that the associated `key[n]` and `element[n]` are always in the same cacheline, but often they would be :-)

As an example, the interleaved version of the above `k` and `e` assignments would look something like this:

```
k  :=  add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize+t.elemsize)+uintptr(0)        )
e  :=  add(unsafe.Pointer(b), dataOffset+i*uintptr(t.keysize+t.elemsize)+uintptr(t.keysize))
```

In theory, performance would more often be better due to less CPU cacheline fetches, and otherwise the same performance as before?

[1] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L532
[2] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L515
[3] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L517
[4] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L532
[5] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L542
[6] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L543
[7] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L66
[8] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L538
[9] https://github.com/golang/go/blob/go1.17.1/src/runtime/map.go#L543
Repository: PowerToys
Issue: lock computer and put display to sleep
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

It would be great to implement an action that locks the ui (ie: WIN-L) and also puts the display to sleep immediately. 

I use a similar shortcut on my mac. it's really useful for when you are working someplace and want to make your computer secure and boring looking.

### Scenario when this would be used?

when stepping away from a system while working in public.

### Supporting information

_No response_
Repository: go
Issue: x/tools/internal/imports: do not detach comments above a given import when merging
Labels: NeedsInvestigation,Tools

### What version of Go are you using (`go version`)?

<pre>
go version go1.17 darwin/arm64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

* When formatting imports, gopls will merge multiple imports into a single declaration.
* Any comments attached to an import get detached.
* This breaks tools which parse go source files to act on directives associated with an import comment: think cgo preamble, but for other packages.
* In some cases (as given below) it can also break the cgo preamble, even though the "C" import is not merged.

For example,
```
// Package A
import "my.package/a"

// Package B
import "my.package/b"

// #cgo CFLAGS: -Wall
import "C"

// Package D
import "my.package/d"

import "fmt"
```

gets combined into:
```
// Package A
import (
	// Package B
	// #cgo CFLAGS: -Wall
	// Package D
	"fmt"

	"my.package/a"
	"my.package/b"
	"my.package/d"
)

import "C"
```

Here you can see that the comments associated with each of the packages have been detached.  This is especially problematic for the "C" package, which has lost its preamble entirely.

### What did you expect to see?

* Comments attached to an import should remain attached, whether they are grouped or not.

For the above example:
```
import (
  "fmt"

  // Package A
  "my.package/a"

  // Package B
  "my.package/b"

  // Package D
  "my.package/d"
)

// #cgo CFLAGS: -Wall
import "C"
```

where "C" remains detached, as given in func `mergeImports`, file `internal/imports/sortimports.go`.  In general, I don't see why it needs to remain detached, but I'm not suggesting that convention be changed.

You could also write this without the line separations between "same host" packages, as below, though it doesn't read as clearly:
```
import (
  "fmt"

  // Package A
  "my.package/a"
  // Package B
  "my.package/b"
  // Package D
  "my.package/d"
)

// #cgo CFLAGS: -Wall
import "C"
```

I would prefer the previous style where, in general, any package having an attached comment has one blank line of padding on top and bottom even if it is part of a "same host" package group.
Repository: storybook
Issue: Radio controls sharing state in .mdx
Labels: bug,block: argstable,needs triage

**Describe the bug**

When using `<ArgsTable/>` within a MDX file, using the same prop key on multiple `<ArgsTable/>` instances (each referencing a different story) results in state being shared between them:

https://user-images.githubusercontent.com/7410405/135351017-5b1f9bdd-4ca7-4f34-9fcd-3bab4a39cd9f.mov

**To Reproduce**

Reproduction repo: https://github.com/codetheweb/storybook-radio-repro.

**System**
```
Environment Info:

  System:
    OS: macOS 11.4
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 16.6.1 - ~/.nvm/versions/node/v16.6.1/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.20.3 - ~/.nvm/versions/node/v16.6.1/bin/npm
  Browsers:
    Chrome: 94.0.4606.61
    Firefox: 92.0
    Safari: 14.1.1
```

**Additional context**
I believe this is happening because radio IDs are not unique between the arg tables.