sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: JIT vs. eager mismatches for jit.traced `int8` to `int32` casting
Labels: oncall: jit,NNC

## 🐛 Bug

A traced model seems to create overflows when `int8` tensor values are transformed to `int32` on the GPU.

## To Reproduce

```python
import torch
import torch.nn as nn

class AddSubNet(nn.Module):
    def __init__(self, *args):
        self.torch_output0_dtype = args[0][0]
        self.torch_output1_dtype = args[0][1]
        super(AddSubNet, self).__init__()

    def forward(self, input0, input1):
        return (input0 + input1).to(self.torch_output0_dtype), \
               (input0 - input1).to(self.torch_output1_dtype)

device = 'cpu'
model = AddSubNet((torch.int32, torch.int32)).to(device)
x1 = torch.randint(-127, 128, (16,)).to(torch.int8).to(device)
x2 = torch.randint(-127, 128, (16,)).to(torch.int8).to(device)
model_cpu = torch.jit.trace(model, (x1, x2))

print('input')
print(x1)
print(x2)

out1_cpu, out2_cpu = model_cpu(x1, x2)
print('cpu output')
print(out1_cpu)
print(out2_cpu)

device = 'cuda'
model.to(device)
x1 = x1.to(device)
x2 = x2.to(device)

model_gpu = torch.jit.trace(model, (x1, x2))
#print(model_gpu.graph)

out1, out2 = model_gpu(x1, x2)
print('cuda output')
print(out1)
print(out2)
```
Output:
```python
input
tensor([ -14,  127,  -24,    9, -115,  -24, -102,   -5,    5,   93,   45,  -69,
         -74,   46,  109,  -90], dtype=torch.int8)
tensor([  32,  -46,   13,   78,  109,  -84, -104,   76,   29,  -97,  -90,   73,
          17, -105,   34,  117], dtype=torch.int8)
cpu output
tensor([  18,   81,  -11,   87,   -6, -108,   50,   71,   34,   -4,  -45,    4,
         -57,  -59, -113,   27], dtype=torch.int32)
tensor([ -46,  -83,  -37,  -69,   32,   60,    2,  -81,  -24,  -66, -121,  114,
         -91, -105,   75,   49], dtype=torch.int32)
cuda output
tensor([  18,   81,  -11,   87,   -6, -108, -206,   71,   34,   -4,  -45,    4,
         -57,  -59,  143,   27], device='cuda:0', dtype=torch.int32)
tensor([ -46,  173,  -37,  -69, -224,   60,    2,  -81,  -24,  190,  135, -142,
         -91,  151,   75, -207], device='cuda:0', dtype=torch.int32)
```
The mismatches look like overflowing values (e.g. `50` vs. `-206`).

## Environment

```
PyTorch version: 1.11.0.dev20211019+cu111
Is debug build: False
CUDA used to build PyTorch: 11.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.3 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Clang version: Could not collect
CMake version: version 3.21.3
Libc version: glibc-2.31
```
Reproduced on different GPUs.

## Additional information

Enabling `nvfuser` via:
```python
torch._C._jit_set_nvfuser_enabled(True)
torch._C._jit_set_texpr_fuser_enabled(False)
torch._C._jit_set_profiling_executor(True)
torch._C._jit_set_profiling_mode(True)
torch._C._jit_override_can_fuse_on_cpu(False)
torch._C._jit_override_can_fuse_on_gpu(False)
torch._C._jit_set_bailout_depth(20)
```
yields matching values.

CC @malfet as we've discussed this issue. (Initially I thought it would be ARM-specifc, but that turns out to be wrong)
Repository: terminal
Issue: JSON fails to parse with a trailing comment at the end of an array
Labels: Help Wanted,Resolution-External,Issue-Bug,Area-Settings,Product-Terminal

### Windows Terminal version (or Windows build number)

1.10.2714.0

### Other Software

_No response_

### Steps to reproduce

In the settings file, put a comment at the end of an object with a comma after it.

This fails:

    "actions": [
      {},
      // ...
    ],

Dropping either the `,` or the comment makes it work.

### Expected Behavior

Should be parsed as usual since both terminating commas and comments are allowed, or forbid trailing commas (assuming that comments are a desired feature).


### Actual Behavior

> Settings could not be loaded from file. Check for syntax errors, including trailing commas.
Repository: yt-dlp
Issue: [Feature Request] Replace phantomjs with something else?
Labels: enhancement,core:extractor

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of yt-dlp:
- First of, make sure you are using the latest version of yt-dlp. Run `yt-dlp --version` and ensure your version is 2021.10.10. If it's not, see https://github.com/yt-dlp/yt-dlp#update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar feature requests: https://github.com/yt-dlp/yt-dlp/issues. DO NOT post duplicates.
- Read "opening an issue" section in CONTRIBUTING.md: https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue
- Finally, put x into all relevant boxes like this [x] (Dont forget to delete the empty space)
-->

- [x] I'm reporting a feature request
- [x] I've verified that I'm running yt-dlp version **2021.10.10**
- [x] I've searched the bugtracker for similar feature requests including closed ones
- [x] I've read the opening an issue section in CONTRIBUTING.md
- [x] I have given an appropriate title to the issue


## Description

<!--
Provide an explanation of your issue in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->

```
PhantomJS is a discontinued headless browser used for automating web page interaction.
```

I'm not aware why PhantomJS is needed, however if it is could it be replaced with puppeteer or any other headless browser?

Thanks for continuing the development.
Repository: rust
Issue: feature(destructuring_assignment) suggested errorneously
Labels: A-diagnostics,T-compiler

([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=a12e8d29b2dd7cbabeaab6e4eedb7a2e))
```rust
fn main(){
  let foo: [u8; _] = [1,2,3];
}
```

```rust
error[E0658]: destructuring assignments are unstable
 --> src/main.rs:2:17
  |
2 |   let foo: [u8; _] = [1,2,3];
  |                 ^
  |
  = note: see issue #71126 <https://github.com/rust-lang/rust/issues/71126> for more information
  = help: add `#![feature(destructuring_assignment)]` to the crate attributes to enable

error: in expressions, `_` can only be used on the left-hand side of an assignment
 --> src/main.rs:2:17
  |
2 |   let foo: [u8; _] = [1,2,3];
  |                 ^ `_` not allowed here

For more information about this error, try `rustc --explain E0658`.
```

However the `#![feature(destructuring_assignment)]` seems to be completely irrelevant here, and indeed adding that ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=77442749bbc40c01f92b2545d540ec18))

```rust
#![feature(destructuring_assignment)]
fn main(){
  let foo: [u8; _] = [1,2,3];
}
```

still gives error of

```rust
error: in expressions, `_` can only be used on the left-hand side of an assignment
 --> src/main.rs:3:17
  |
3 |   let foo: [u8; _] = [1,2,3];
  |                 ^ `_` not allowed here
```

(Tangentially: technically the error message is wrong since `_` *is* used in the left hand side of an assignment. Just not as the variable name as rustc expected... )

cc #71126
Repository: terminal
Issue: In SUI, when selecting desktopWallpaper as background image it is not being applied
Labels: Issue-Bug,Product-Terminal,Priority-3,Area-SettingsUI

You could also add that when selecting desktop wallpaper as background image it is not being applied, even after save and WT restart:

![wt_bg_desktopWallpaper](https://user-images.githubusercontent.com/3933920/138021344-cfc16e4e-9fec-4dde-bd78-be52a6228e7c.png)

_Originally posted by @elsaco in https://github.com/microsoft/terminal/issues/11541#issuecomment-947279366_
Repository: godot
Issue: [GDNative] Access violation in godot::Dictionary::operator[] when called from tool class
Labels: bug,topic:gdextension

### Godot version

v3.3.3.stable.official [b973f997f] 64bit

### System information

Windows 10

### Issue description

This took me quite a while to figure out:
When trying to access a dictionary property in a non tool class from a tool class while in the editor (eg. when importing a resource). Godot will crash with an access violation 0x7FFFFFFFFFF. This happens when trying to overwrite the existing dictionary in the class or when trying to insert values.

### Steps to reproduce

Create GODOT_CLASS with a dictionary property
Create a second GODOT_CLASS that updates said property (`cls->dict = {};` or `cls->dict[key] = value;`) 
Register the first class as a normal class and the second class as a tool class
Execute the method updating the dictionary in the second class
Crash: Access violation

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: Lifetime issues when recording external CUDA streams with the caching allocator
Labels: module: cuda,triaged

## 🐛 Bug

TL;DR: The caching allocator keeps, for each block, a set of streams on which the block was used, and records events on those streams when the block is freed. If one of those streams is an external one, the stream might already be destroyed by the time cudaEventRecord is called, which then fails.

Imagine we have an _external_ stream, i.e., one created via `at::cuda::getStreamFromExternal` by passing a manually-managed raw `cudaStream_t` object. If that stream is passed to `c10::cuda::CUDACachingAllocator::recordStream`, the caching allocator will only add it to `block->stream_uses`, which is just a `std::unordered_set<at::cuda::CUDAStream>`. The streams in that set will be consumed at a later time, when the block is freed, in order to insert events onto them which are needed for the block to be safely reused.

The problem is that an external stream is basically a "raw" non-owning pointer to a `cudaStream_t` and by storing it rather than using it right away we basically create a dangling reference. This problem emerges if the original `cudaStream_t` is destroyed before the block on which it was registered is freed, as this will cause the call to `cudaEventRecord` to fail. This situation can easily occur in practice, especially during shutdown: I had a custom ProcessGroup which contained a stream and managed it lifetime, but it so happened that the ProcessGroup was destroyed before the gradient tensors.

## To Reproduce

Steps to reproduce the behavior:

1. Create an external stream
1. Create a tensor
1. Record the tensor on the stream
1. Destroy the stream
1. Destroy the tensor

cc @ngimel
Repository: go
Issue: proposal: spec: allow type parameters in methods
Labels: LanguageChange,Proposal,generics,LanguageChangeReview

[According to the Type parameters proposal](https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md), it is not allowed to define type parameters in methods.

This limitation prevents to define functional-like stream processing primitives, e.g.:

```go
func (si *stream[IN]) Map[OUT any](f func(IN) OUT) stream[OUT]
```

While I agree that these functional streams might be unefficient and Go is not designed to cover this kind of use cases, I would like to emphasize that Go adoption in stream processing pipelines (e.g. Kafka) is a fact. Allowing type parameters in methods would allow constructing DSLs that would greatly simplify some existing use cases.

Other potential use cases that would benefit from type paremeters in methods:

* DSLs for testing: `Assert(actual).ToBe(expected)`
* DSLs for mocking: `On(obj.Sum).WithArgs(7, 8).ThenReturn(15)`

---

Edited by @ianlancetaylor to add: for a summary of why this has not been approved, please see https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-parameterized-methods .
Repository: pytorch
Issue: [doc] Long Function Name (C++) overlapping on the side menu
Labels: module: docs,triaged

This function is documented only in C++ API (probably automatically). There is no equivalent function in Python to check.

![image](https://user-images.githubusercontent.com/19503980/138096871-cb3b41b5-77cd-417a-9a76-59877c386682.png)


cc @brianjo @mruberry
Repository: go
Issue: compile: convert standalone LEA to ADD/SUB to reduce port contention on x86/amd64
Labels: Performance,NeedsInvestigation

Except very new cores (e.g. sunny cove) LEA usually has around 2 cpu ports to execute while ADD has equal or more (4). It has shown advantageous in production profiles of C++ compiler optimized binaries to use ADD/SUB instead of LEA to reduce port contention.

We should test adding a pass after current SSA optimization that transforms stand alone simple LEA instructions (wasnt fused with compares ore moves) to use ADD and SUB where equivalent (modulo flags). We could also use that pass to split slow 3 operand LEAs to multiple ADDs or 2 operand LEAs.
Repository: flutter
Issue: in_app_purchase: purchaseStream silent
Labels: platform-android,p: in_app_purchase,package,P2,team-android,triaged-android

## Steps to Reproduce

We're using `in_app_purchase` with some success but there's one particular issue
When on purchase UI, user can press the system home button, leave to android home screen and resume the app from there
In this case the system purchase UI disappears but `purchaseStream` emits no events, leaving the app in the false presumption that the purchase is still underway

**Expected results:**
Either the system UI does not disappear or `purchaseStream` emits an error like the one emitted when user taps outside the system UI and it closes

**Actual results:** 
System UI disappears but `purchaseStream` emits no events

Please advise
Repository: create-react-app
Issue: creating app and npm start issue 
Labels: stale

Starting the development server...

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)
    at module.exports (/home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/NormalModule.js:417:16)
    at handleParseError (/home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/NormalModule.js:471:10)
    at /home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/NormalModule.js:503:5
    at /home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/NormalModule.js:358:12
    at /home/paulius/Documents/PHS-Lab/React/project1/node_modules/loader-runner/lib/LoaderRunner.js:373:3
    at iterateNormalLoaders (/home/paulius/Documents/PHS-Lab/React/project1/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
    at iterateNormalLoaders (/home/paulius/Documents/PHS-Lab/React/project1/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
/home/paulius/Documents/PHS-Lab/React/project1/node_modules/react-scripts/scripts/start.js:19
  throw err;
  ^

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:67:19)
    at Object.createHash (node:crypto:130:10)
    at module.exports (/home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/util/createHash.js:135:53)
    at NormalModule._initBuildHash (/home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/NormalModule.js:417:16)
    at /home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/NormalModule.js:452:10
    at /home/paulius/Documents/PHS-Lab/React/project1/node_modules/webpack/lib/NormalModule.js:323:13
    at /home/paulius/Documents/PHS-Lab/React/project1/node_modules/loader-runner/lib/LoaderRunner.js:367:11
    at /home/paulius/Documents/PHS-Lab/React/project1/node_modules/loader-runner/lib/LoaderRunner.js:233:18
    at context.callback (/home/paulius/Documents/PHS-Lab/React/project1/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
    at /home/paulius/Documents/PHS-Lab/React/project1/node_modules/babel-loader/lib/index.js:59:103 {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

Node.js v17.0.0


can some one explain I'm new with this stuff
Repository: rust
Issue: rustc --emit=dep-info -Zbinary-dep-depinfo -C prefer-dynamic=yes misses .so input dep
Labels: T-compiler,C-bug,-Cprefer-dynamic

With a command like:

```
rustc --emit=dep-info=foo.d -Zbinary-dep-depinfo -C prefer-dynamic ...
```

which uses the rust std library:

```
libstd-dafa2c58b8297b90.rlib
libstd-dafa2c58b8297b90.so
```

I expected to see both the .rlib and .so in the generated depfile, however, the .so is missing.

### Meta

`rustc --version --verbose`:

```
rustc 1.57.0-nightly (af9b508e1 2021-10-15)
binary: rustc
commit-hash: af9b508e1d6c83a8f0e6f5c0b2b75598aa37ed27
commit-date: 2021-10-15
host: x86_64-unknown-linux-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0
```

Why this is important: We rely on the depfile to know what inputs to upload for remote building.  When the .so file is missing we find that `rustc` still silently and happily builds the crate, but with a different (static?) linking result, which means local output != remote output (but we want perfect reproducibility).
Repository: react
Issue: devtools: "What caused this update?" when a lazy component resolves
Labels: Type: Bug,Component: Developer Tools,React Core Team

React version: 18.2.0
Devtools version: 4.23.0-e28a0db22

Since https://github.com/facebook/react/pull/21171 React Devtools shows which fiber scheduled an update.

In the case of 

```tsx
root.render(
  <React.Suspense>
    <LazyComponent />
  </React.Suspense>
);
```
where `LazyComponent` is some `React.lazy(() => {})` component we usually create two commits:
1. initial render where `LazyComponent` suspends
2. `LazyComponents` resolves

In legacy roots for the revealing commit Devtools displays the hostroot as the updater: https://github.com/facebook/react/pull/22602/files#diff-3582df0bd6a071e1986363b080d3012a9c492b8be7dd4e67f39d72078422d316R1368-R1376.
For new roots we get "unknown" for the second commit (i.e. no updates): https://github.com/facebook/react/pull/22602/files#diff-3582df0bd6a071e1986363b080d3012a9c492b8be7dd4e67f39d72078422d316R1267.
Codesandbox for full repro: https://codesandbox.io/p/sandbox/18-2-updaters-when-lazy-component-resolves-ff5x6h

I would've expected that for both roots we get the nearest Suspense boundary that can commit after `LazyComponent` resolved. Or at least the fiber that "unsuspended" (not sure if this is the right terminology). The corresponding hostroot wouldn't help me much but I'm not that concerned with legacy roots in this instance.

Right now the information isn't all that helpful. I noticed this especially for a larger apps with multiple suspense boundaries and partial hydration. 

I profiled the same codesandbox in the scheduling profiler but also couldn't extract any useful information with regards to why the second commit happened.
Repository: rust
Issue: Detect duplicate trait bounds
Labels: A-lints

We might look for a way to detect, and possibly remove, repeated trait bounds. Maybe as a lint? Or maybe this would be better in `rustfmt` or clippy?

An example from https://github.com/rust-lang/rust/pull/87880:

```rust
pub trait ControlFlowGraph:
    DirectedGraph + WithStartNode + WithPredecessors + WithStartNode + WithSuccessors + WithNumNodes
```

I was surprised this is allowed!

[Playground example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=62c189f3c882cffe1e91e7511d4a0179):

```rust
pub trait DirectedGraph {}
pub trait WithStartNode {}
pub trait WithPredecessors {}
pub trait WithSuccessors {}
pub trait WithNumNodes {}

pub trait ControlFlowGraph:
    DirectedGraph + WithStartNode + WithPredecessors + WithStartNode + WithSuccessors + WithNumNodes
{}
```

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"pierwill"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: react
Issue: Feature request: react-hooks/exhaustive-deps option to require deps arg.
Labels: Type: Discussion,React 18

Please add an option to the configuration for the `react-hooks/exhaustive-deps` eslint rule to require a `deps` argument for all hooks that can take it.

This new configuration option would throw a warning/error (don't care about default) for the code below:
```
const Demo = ({ thing }) => {
  useEffect(() => {
    console.log(thing)
  })
}
```

I am aware that this already throws an error:
```
const Demo = ({ thing }) => {
  useEffect(() => {
    console.log(thing)
  }, [])
}
```

This request is specifically concerning the case where no second argument is passed to hooks like `useEffect`, `useCallback`, `useMemo`, etc.

The configuration would be used in a way similar to this:
`'react-hooks/exhaustive-deps': ['warn', {alwaysRequireDeps: true }]`

Reasoning: 
I can't think of a scenario where firing the callback of `useEffect` on every render is desired. An intentional `eslint-disable-next-line` is acceptable if this scenario arises.
A missing `deps` arg can cause sneaky bugs.
Repository: rust
Issue: Rustc doesn't provide suggestions on typo'd trait functions
Labels: A-diagnostics,T-compiler

Given the [following code on nightly](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=1548de264ca82da0deb797b83ea916c5): 

```rust
trait Foo {
    fn baz(&self) { }
}

struct Bar;

impl Foo for Bar {}

fn main() {
    Bar.bar()
}
```

The current output is:

```
error[E0599]: no method named `bar` found for struct `Bar` in the current scope
  --> src/main.rs:10:9
   |
5  | struct Bar;
   | ----------- method `bar` not found for this
...
10 |     Bar.bar()
   |         ^^^ method not found in `Bar`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `playground` due to previous error
```

Ideally the output should look like:

```
error[E0599]: no method named `bar` found for struct `Bar` in the current scope
  --> src/main.rs:14:9
   |
5  | struct Bar;
   | ----------- method `bar` not found for this
...
14 |     Bar.bar()
   |         ^^^ help: there is an associated trait function with a similar name: `baz`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `playground` due to previous error
```

As a slightly less trivial example, I had something like this ([nightly playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=15f68a6f387dcfaba708795255fd0160)):

```rust
use futures::{stream, StreamExt};

fn main() {
    stream::iter(0..100).buffered_unordered(10);
}
```

And got a very not-helpful error message, which led me down to debugging an entirely different rabbit hole (maybe some other expression's type wasn't correctly infer; maybe there's a trait bound restriction), rather than a simple typo. 

cc: @davidbarsky