sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Segmentation fault when thread using dynamically loaded Rust library exits
Labels: A-thread-locals,C-bug,T-libs

Scenario: I have a Rust cdylib, which is loaded by a C program via `dlopen`. The C program creates a thread, and loads the Rust module inside it. It proceeds to call one of the Rust functions, and closes the library via `dlclose`. Then the thread exits. The Rust program has a thread local variable with a struct that implements `Drop`, which it modifies in the function called from C.

Full reproduction here: https://github.com/devongovett/rust-threadlocal-bug

On CentOS 7, which uses glibc 2.17, it segfaults at `__nptl_deallocate_tsd()` inside pthread_create.c. With later versions of glibc, there is no crash. I believe the crash occurs because Rust creates a thread local key with `pthread_key_create` but never calls `pthread_key_delete` (the call in the destructor is commented out): https://github.com/rust-lang/rust/blob/673d0db5e393e9c64897005b470bfeb6d5aec61b/library/std/src/sys_common/thread_local_key.rs#L231-L237

When the thread exits, glibc tries to call the destructor for the key, but because the dynamic library has already been unloaded via `dlclose` at this point, the function no longer exists and we get a crash.

My theory is that this only occurs with glibc 2.17 and not later versions is due to `__cxa_thread_atexit_impl` not existing in these older versions. This function is used when available to register destructors, otherwise a fallback implementation is used: https://github.com/rust-lang/rust/blob/71965ab4d05b023cd29c914ef1262a72cac02e01/library/std/src/sys/unix/thread_local_dtor.rs#L30-L42 However, I'm not sure about that. It could be some other change in glibc.

I have not tested, but I think the bug could potentially be fixed if the commented out destructor linked above were actually called. The comment indicates something about windows not supporting this, so maybe it could be called conditionally?

glibc 2.17 is indeed pretty old, however, it is the version used by the current CentOS 7 version which is not EOL until 2024, so I do think this bug should be fixed.

### Meta

`rustc --version --verbose`:
```
rustc 1.57.0 (f1edd0429 2021-11-29)
binary: rustc
commit-hash: f1edd0429582dd29cccacaf50fd134b05593bd9c
commit-date: 2021-11-29
host: x86_64-unknown-linux-gnu
release: 1.57.0
LLVM version: 13.0.0
```
Repository: storybook
Issue: Storybook crashes in browser when array wrapper syntax is used inside an arrow-function component with arguments
Labels: bug,has workaround,mdx

**Describe the bug**
When running storybook using `start-storybook`, rendering a component using arrow function syntax with one or more arguments, then adding a prop inside that component that renders elements in an array, causes Storybook to crash (see example below). After running storybook and navigating to this story, storybook will completely freeze and the tab will need to be closed.

This crash **doesn't** occur with a static build (running `build-storybook` and then opening the result in a browser).

**To Reproduce**

The following story will crash: 

```jsx
<!-- Example.stories.mdx -->

import { Canvas, Meta, Story } from '@storybook/addon-docs';

export const Example = () => 'Example';

<Meta title="Components/Example" component={Example} />

<Canvas>
  <Story name="Example">{(args) => <Example array={[<div key="foo">foo</div>, <div key="bar">bar</div>]} />}</Story>
</Canvas>
```

Step-by-step reproduction:

1. Add the aforementioned story to your storybook
2. Run storybook using `start-storybook` (this bug doesn't happen when using a static build)
3. Navigate to the story in your browser (note that doing so will make your browser tab crash)

The arrow function declared as a child of our `<Story>` element is the culprit. The crash appears to go away if you do **either one** of the following:

- Remove any arguments from the arrow function
- Remove the array syntax from within the function body (delete it, replace it with fragment syntax, or factor it out so that it's no longer declared inside the arrow function)

**System**

```
Environment Info:

  System:
    OS: macOS 12.0.1
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
  Binaries:
    Node: 14.17.3 - ~/.nvm/versions/node/v14.17.3/bin/node
    npm: 6.14.15 - ~/.nvm/versions/node/v14.17.3/bin/npm
  Browsers:
    Chrome: 96.0.4664.110
    Edge: 95.0.1020.53
    Firefox: 89.0.2
    Safari: 15.1
  npmPackages:
    @storybook/addon-a11y: ^6.4.9 => 6.4.9 
    @storybook/addon-controls: ^6.4.9 => 6.4.9 
    @storybook/addon-docs: ^6.4.9 => 6.4.9 
    @storybook/addon-links: ^6.4.9 => 6.4.9 
    @storybook/addon-toolbars: ^6.4.9 => 6.4.9 
    @storybook/addon-viewport: ^6.4.9 => 6.4.9 
    @storybook/addons: ^6.4.9 => 6.4.9 
    @storybook/builder-webpack5: ^6.4.9 => 6.4.9 
    @storybook/manager-webpack5: ^6.4.9 => 6.4.9 
    @storybook/react: ^6.4.9 => 6.4.9 
    @storybook/theming: ^6.4.9 => 6.4.9 
```

**Additional context**
Occurs in the following browsers:

Google Chrome Version 96.0.4664.93
Firefox 89.0.2
Safari Version 15.1
Repository: deno
Issue: Type checking JSON modules when dynamic improting incorrect
Labels: bug,cli,upstream,tsc

Given the following JSON:

**a.json**

```json
{ "a": 1 }
```

Being imported in the following fashion:

```ts
const a = await import("./a.json", { assert: { type: "json" } });
```

The following should type error, but doesn't:

```ts
console.log(a.a);
```

When in fact, only this should pass type checking:

```ts
console.log(a.default.a);
```

This is likely related to `"allowSyntheticDefaultImports"` being enabled, which is required in certain scenarios, but causes TypeScript to not properly type JSON module being dynamically imported.
Repository: create-react-app
Issue: Bug: [5.0] Can't resolve 'react/jsx-runtime'
Labels: issue: bug report

### Describe the bug

Importing the package `react-data-grid` results int he following error upon `yarn start`:
```
ERROR in ./node_modules/react-data-grid/lib/bundle.js 3:0-56
Module not found: Error: Can't resolve 'react/jsx-runtime' in '/Users/alamothe/Projects/car-manager/fleet-client/node_modules/react-data-grid/lib'
Did you mean 'jsx-runtime.js'?
BREAKING CHANGE: The request 'react/jsx-runtime' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
```
No error is observed in CRA 4.

### Did you try recovering your dependencies?

Yes.

### Which terms did you search for in User Guide?

Searched for: `Can't resolve 'react/jsx-runtime'`

### Environment

```
Environment Info:

  current version of create-react-app: 4.0.3
  running from /Users/alamothe/.config/yarn/global/node_modules/create-react-app

  System:
    OS: macOS 11.6.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 14.18.2 - /usr/local/opt/node@14/bin/node
    Yarn: 3.2.0-rc.7 - /usr/local/bin/yarn
    npm: 6.14.15 - /usr/local/opt/node@14/bin/npm
  Browsers:
    Chrome: 96.0.4664.110
    Edge: 96.0.1054.53
    Firefox: 94.0.2
    Safari: 15.1
  npmPackages:
    react: ^17.0.2 => 17.0.2 
    react-dom: ^17.0.2 => 17.0.2 
    react-scripts: 5.0.0 => 5.0.0 
  npmGlobalPackages:
    create-react-app: 4.0.3
```

### Steps to reproduce

1. Import `react-data-grid`

### Expected behavior

No error, like in 4.0
Repository: rust
Issue: rustdoc: add support for --emit=dep-info
Labels: T-rustdoc,C-feature-request

When running rustdoc, cargo currently doesn't know which files are used for each cargo target. Because of this, cargo conservatively assumes that a modification to *any* file in the project will require rebuilding the documentation for all targets. When running `rustc`, cargo uses the dep-info file to know which files each target is built from, so that it can know to only track for changes in those files. It would be helpful if rustdoc had a similar ability so that cargo could more precisely track the files.

Since we probably don't want to pollute the output directory with this dep-info file, it would be good to ensure that it supports the `--emit dep-info=PATH` syntax that `rustc` has so that cargo could squirrel away the file somewhere else in the target directory.

It might be nice if this also included paths passed to CLI options like `--extend-css`, though that is a stretch goal.

Ideally it would be essentially the same as `rustc`, supporting the `# env-dep:` comments as well to track environment variables that were used.
Repository: vscode
Issue: Custom Buttons and Labels for QuickPicks
Labels: feature-request,api,quick-pick

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
It would be great to be able to add some custom buttons to our QuickPicks, especially for our Azure Extension wizards.  Specifically, being able to have an "OK" button would be useful so that the user can confirm without clicking on a quick pick item.

Here is an example of what I am referring to:
![image](https://user-images.githubusercontent.com/5290572/146286726-85f15441-d324-45ba-ac8a-95f5b7973bfa.png)

I think that the simpleFileDialog already leverages some unexposed properties to do this already.
https://github.com/microsoft/vscode/blob/91b97cec911a954bcd83d2613bb6d7b6bd4023ad/src/vs/workbench/services/dialogs/browser/simpleFileDialog.ts#L280-L281

@isidorn
Repository: flutter
Issue: BouncingScrollPhysics.frictionFactor documentation is wrong
Labels: framework,f: scrolling,d: api docs,P2,team-framework,triaged-framework

https://api.flutter.dev/flutter/widgets/BouncingScrollPhysics/frictionFactor.html

> This factor starts at 0.52 and progressively becomes harder to overscroll as more of the area past the edge is dragged in (represented by an increasing overscrollFraction which starts at 0 when there is no overscroll).

However, the bigger the `overscrollFraction` parameter is, the less the returned friction

This codesample will print out decreasing values

```dart
import 'dart:math' as math;

void main() {
  double frictionFactor(double overscrollFraction) => 0.52 * math.pow(1 - overscrollFraction, 2);
  for (double i = 0; i < 1; i += 0.01) {
    print(frictionFactor(i));
  }
}
```
Repository: go
Issue: cmd/compile: generic code compile never end
Labels: NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel go1.18-7f231453 Thu Dec 16 00:34:10 2021 +0000 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/gura/Library/Caches/go-build"
GOENV="/Users/gura/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/gura/go/pkg/mod"
GONOPROXY="*.uangel.com"
GONOSUMDB="*.uangel.com"
GOOS="darwin"
GOPATH="/Users/gura/go"
GOPRIVATE="*.uangel.com"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/gura/sdk/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/gura/sdk/gotip/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.18-7f231453 Thu Dec 16 00:34:10 2021 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/gura/git/gotptest/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/mr/dvhjg7zd4l125pln73bqyr400000gn/T/go-build2752388136=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->
https://gotipplay.golang.org/p/4ZB6ITms4-e

Sorry the code is too long, but that is minimum.
Full source can be downloaded from here : https://github.com/csgura/gotptest


### What did you expect to see?
Compiler compiles it within a reasonable time or prints error message. 


### What did you see instead?
It never end.

If I delete some functions Applicative5 ~ Applicative14,  it works well. 
So I don't think that the problem is matter of data structure or algorithm problem.

Working version is here : https://gotipplay.golang.org/p/lWWj0aK9mqo
Repository: rust
Issue: Document behavior of try-mark-green and loading stale `DefPathHash`
Labels: T-compiler,A-incr-comp

> That's right - we bail out of marking it green before we try to load a stale defpathhash
>
> We should document that somewhere, if it's not already

[Discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/241847-t-compiler.2Fwg-incr-comp/topic/.2391696.20et.20al/near/265031053). cc @Aaron1011
Repository: vscode
Issue: Notebooks moves focus in and out of output
Labels: debt,smoke-test-failure,notebook

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=147037&view=logs&j=672276a2-8d3a-5fab-615d-090c51352f92&t=0699ae84-7245-5a45-5eee-80b086af2725&l=68

```
1) VSCode Smoke Tests (Electron)
       Notebooks
         moves focus in and out of output:
     Error: Timeout: is active element '.quick-input-widget .quick-input-box input' after 20 seconds.
      at poll (D:\a\1\s\test\automation\out\code.js:65:19)
      at async Code.waitForActiveElement (D:\a\1\s\test\automation\out\code.js:192:9)
      at async QuickInput.waitForQuickInputOpened (D:\a\1\s\test\automation\out\quickinput.js:22:9)
      at async QuickInput.selectQuickInputElement (D:\a\1\s\test\automation\out\quickinput.js:31:9)
      at async QuickAccess.runCommand (D:\a\1\s\test\automation\out\quickaccess.js:84:9)
      at async Notebook.focusFirstCell (D:\a\1\s\test\automation\out\notebook.js:24:9)
      at async Notebook.openNotebook (D:\a\1\s\test\automation\out\notebook.js:17:9)
      at async Context.<anonymous> (out\areas\notebook\notebook.test.js:52:13)
```
Repository: vscode
Issue: Notebooks moves focus in and out of output / cell action execution
Labels: debt,smoke-test-failure,notebook

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=147117&view=logs&j=672276a2-8d3a-5fab-615d-090c51352f92&t=0699ae84-7245-5a45-5eee-80b086af2725&l=73

```
 1) VSCode Smoke Tests (Electron)
       Notebooks
         moves focus in and out of output:
     Error: Timeout: is active element 'webview, .webview' after 20 seconds.
      at poll (D:\a\1\s\test\automation\out\code.js:65:19)
      at async Code.waitForActiveElement (D:\a\1\s\test\automation\out\code.js:192:9)
      at async Notebook.focusInCellOutput (D:\a\1\s\test\automation\out\notebook.js:64:9)
      at async Context.<anonymous> (out\areas\notebook\notebook.test.js:54:13)

  2) VSCode Smoke Tests (Electron)
       Notebooks
         cell action execution:
     Error: Timeout: get element '.notebook-editor .monaco-list-row.focused' after 20 seconds.
      at poll (D:\a\1\s\test\automation\out\code.js:65:19)
      at async Code.waitForElement (D:\a\1\s\test\automation\out\code.js:188:16)
      at async Notebook.openNotebook (D:\a\1\s\test\automation\out\notebook.js:16:9)
      at async Context.<anonymous> (out\areas\notebook\notebook.test.js:60:13)
```
Repository: PowerToys
Issue: [Windows] - Color Picker & File Explorer add-ins in Windows
Labels: Idea-Enhancement,Product-File Explorer,Product-Color Picker

### Description of the new feature / enhancement

The Power Toys Color Picker and File Explorer add-ins both greatly empower the user, and as such those features could do well in **_Windows 11 by default,_** in a future Fall or Spring Creators Update. These two features both are refined, straightforward, not glitchy, and are not too advanced or risky for the novice or intermediate user to use regularly. The other features belong in Power Toys but expanding File Explorer Preview and Thumbnail capabilities for documents, and especially graphic designers, is ripe for standard delivery, just as the smart clipboard memory and sync has greatly revolutionized editing and computing.

![Screenshot (462)](https://user-images.githubusercontent.com/28911599/146320815-247fff4d-bf7a-41e0-9e01-c6dd1b4b58fa.png)

![Screenshot (461)](https://user-images.githubusercontent.com/28911599/146320817-3ce8e9f8-a3ba-4740-ab95-9d4d24cced92.png)


### Scenario when this would be used?

**_Graphic Designers especially_** would flock to Windows 11, and maybe away from the Mac OS, when seeing how facile and flexible the Color Picker is in action. And SVG - Markup - PDF File Explorer accurate depictions assist the graphic designer greatly too boot, and not just coders and other developers of textual documentation

<img width="1920" alt="Screenshot (465)" src="https://user-images.githubusercontent.com/28911599/146322850-67d7865e-073a-4caa-ae7a-7f06d84f72f7.png">

### Supporting information

-  Power Toys settings dialog for Color Picker is fairly simple and straightforward, and thus could be incorporated into default Windows 11 builds without cluttering up option glut for the user to grasp.

- Power Toys Color Picker behavior is well behaved without any advanced costs in awkward or difficult to understand behavior to the novice to medium user.

- Power Toys expansions of file types depicted in Preview and Thumbnail in File Explorer would add no consternation or confusion to the user.
Repository: electron
Issue: [Feature Request]: No way to listen to keydown / keyup in devTools webContents
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

In my app the end user gets to use the devTools.  I need to listen to keydown on devTools to make keyboard shortcuts work while devTools are focused. 

### Proposed Solution

Possible solutions:

1. Add a keydown event (and possibly other input events) on devTools webContents

2. (or) Enable to listen for keydown / keyup events on the entire BrowserWindow (provided that it's possible to check which webContents are the source of the event (or currently focused), as DOM bindings in regular webContents would still be preferred wherever possible).

3. (or) Enable preload script in devTools (this is a regular web page after all, right?)

### Alternatives Considered

I don't have experience with devTools extension API  but I read the docs and I don't think it would be possible.
https://developer.chrome.com/docs/extensions/mv3/devtools/
https://developer.chrome.com/docs/extensions/reference/devtools_panels (the only API that allows to interact with the devTools page?)

It does not seem like there are any alternatives.

### Additional Information

_No response_
Repository: go
Issue: x/website: update the contents of https://go.dev/talks/
Labels: NeedsInvestigation,website

Hi, the contents of https://go.dev/talks/ is really useful. But the contents are still of 2019, which have not been updated for two years.

It would be appreciated if you can update the contents of 2020 and 2021. 

Thanks.
 
### What is the URL of the page with the issue?
 https://go.dev/talks/
 
 
 
### Screenshot

 
![image](https://user-images.githubusercontent.com/1326520/146343870-9fe360c4-1c3e-4015-a5ed-4e6526f21931.png)


 
 
### What did you expect to see?
 Keep the contents updated.
Repository: pytorch
Issue: Question about collect tensor in distributed dataparallel?
Labels: oncall: distributed,Stale

torch.distributed.all_gather is used to Gathers tensors from the whole group in a list.
This is the example in documents.
>>> # All tensors below are of torch.int64 dtype.
>>> # We have 2 process groups, 2 ranks.
>>> tensor_list = [torch.zeros(2, dtype=torch.int64) for _ in range(2)]
>>> tensor_list
[tensor([0, 0]), tensor([0, 0])] # Rank 0 and 1
>>> tensor = torch.arange(2, dtype=torch.int64) + 1 + 2 * rank
>>> tensor
tensor([1, 2]) # Rank 0
tensor([3, 4]) # Rank 1
>>> dist.all_gather(tensor_list, tensor)
>>> tensor_list
[tensor([1, 2]), tensor([3, 4])] # Rank 0
[tensor([1, 2]), tensor([3, 4])] # Rank 1

However, what should i do if the tensor have different size in different rank?
Such as:
a = torch.ones((3,2,10)) #Rank 0
b = torch.ones((5,4,10)) #Rank 1
I want to know how to gather this two tensor?

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang
Repository: pytorch
Issue: comile error
Labels: needs reproduction,module: build,triaged,module: mkldnn,module: third_party


![1](https://user-images.githubusercontent.com/33850693/146349691-0d34bdf1-a976-42f9-b7b2-af52a9da3610.jpg)


when I 'python setup.py install' ,get error above.

cc @malfet @seemethere @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh @VitalyFedyunin
Repository: terminal
Issue: [Windows Terminal] : 'Edit' button present for 'Actions' should be visible always.
Labels: Issue-Bug,Area-Accessibility,Product-Terminal,HCL-E+D,A11yUsable,HCL-WindowsTerminal,A11yCO

### Windows Terminal version

1.12.3472.0

### Windows build number

22509.1011

### Other Software

**Test Environment: **
OS: Windows 11 Version Dev (OS Build 22509.1011)
App: Windows Terminal Preview
Screen Reader: Narrator



### Steps to reproduce

**Repro Steps: **

1.Open Windows Terminal.
2.Open Settings page using 'Ctr+,'
3.Navigate to 'actions' list-item via 'Up/down' arrow keys & press enter.
4.Now Navigate to Actions present in the right pane via down arrow key.
5.Observe the issue.

**User Experience: **
Users will get impacted here & may not know the availability of 'Edit' button by looking the UI itself, if it is not visible always.

Attachments:

[Edit button should visible always.zip](https://github.com/microsoft/terminal/files/7743473/Edit.button.should.visible.always.zip)





### Expected Behavior
'Edit' button should always be visible & should be accessible via 'Shift tab' also.

### Actual Behavior

'Edit' button is visible only when it receives focus & 'Edit' button is not accessible via 'Shift + Tab.