sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: The `catchError` method of `SynchronousFuture` returns a `Completer` that will never complete
Labels: framework,has reproducible steps,P2,found in release: 3.3,found in release: 3.7,team-framework,triaged-framework

Encountered while working on #113637.
Tangentially related: https://github.com/flutter/flutter/issues/115602. 

See title.

https://github.com/flutter/flutter/blob/c0719509a1603a2357996b38ce94397f10ac3957/packages/flutter/lib/src/foundation/synchronous_future.dart#L37

The `catchError` method returns a new `Future` (via `Completer<T>().future`) that will never resolve since the completer it originated from is never completed.

This can break Future chains that include `catchError`. Here is an example:

```dart
// Inside some StatefulWidget

void _onUserSearchButtonPressed() {
  // Retrieve user data from over the network and then show it on the UI.
  // In the event that the network call fails, we'll load it from somewhere else instead.
  // Results are cached. Upon a cache hit, _getUserInfoFromFlakyNetwork
  // will return a `SynchronousFuture` containing the cached data.
  _getUserInfoFromFlakyNetwork(this.usernameToSearchFor)
      .catchError((error, stackTrace) => _getUserInfoFromReliableNetwork()) 
      // Issue: if `_getUserInfoFromFlakyNetwork` returns a SynchronousFuture, 
      // the callback we provide to `then` will never be called.
      .then((userData) {
        // Update Widget state with userData
      })
     .catchError((error, stackTrace) () {
       // Handle error from _getUserInfoFromReliableNetwork
     });
}
```

**[Repro project](https://github.com/andrewkolos/repro_flutter_sync_future_onerror)**

While this issue, as far as I know, isn't directly solvable[^1], we could do more to prevent confusing situations like the above.

**Suggestions:**
1. (Not mutually exclusive) Add a note to the docstring of `SynchronousFuture` warning of this behavior.
2. (Not mutually exclusive) Have calls to `catchError` on `SynchronousFuture` print a warning.
3. Have calls to `catchError` simply return `this`. This would be breaking, as (buggy) code that used to be a no-op would no longer be a no-op.


[^1]: Since a `SynchronousFuture` can resolve synchronously, it's possible that the callback passed to `then` runs before `.catchError` can be run to register the error-handling callback.
Repository: pytorch
Issue: sm_80 support
Labels: module: cuda,triaged

### 🐛 Describe the bug

Why isn't sm_80 support shipped by default?

*GPU* with CUDA capability sm_80 is not compatible with the current PyTorch installation.
The current PyTorch install supports CUDA capabilities sm_37 sm_50 sm_60 sm_70.

### Versions

latest

cc @ngimel
Repository: go
Issue: spec: wording about when len(s)/cap(s) are constant doesn't match implementations
Labels: NeedsDecision

The spec (https://go.dev/ref/spec#Length_and_capacity) says:

> The expressions len(s) and cap(s) are constants if the type of s is an array or pointer to an array and the expression s does not contain [channel receives](https://go.dev/ref/spec#Receive_operator) or (non-constant) [function calls](https://go.dev/ref/spec#Calls); in this case s is not evaluated.

However, this doesn't precisely match what implementations allow.

For example, this package compiles successfully with Go 1.4 and gccgo 12.2.1, even though each len argument (syntactically) contains a channel receive and/or non-constant function call:

```
package p

import "unsafe"

const c = len([...]any{func() { <-(chan int)(nil); panic(0) }})

const d = len([...]any{unsafe.Sizeof(<-(chan int)(nil))})

const e = len([...]any{unsafe.Sizeof(new(int))})

type any interface{} // for Go 1.4
```

go/types allows declaration `c`, but rejects `d` and `e`. The same applies to recent cmd/compile using types2.

/cc @griesemer @ianlancetaylor
Repository: flutter
Issue: [Windows] [Multi-window] Support multiple accessibility trees
Labels: a: accessibility,platform-windows,a: desktop,P3,a: multi window,team-windows,triaged-windows

Today one Flutter engine has only 1 accessibility tree. In the multi-view future, 1 engine should support multiple accessibility trees.
Repository: pytorch
Issue: `torch.nn.ReplicationPad2D` Report "invalid configuration argument" Error under Compute Sanitizer
Labels: module: nn,module: error checking,triaged,module: padding

### 🐛 Describe the bug

A test of `torch.nn.Replication2D` reports "invalid configuration argument" error when it's run under compute sanitizer. Without sanitizers it terminates normally on GPU.
Test:
```python
import torch

def test():
    arg_class = torch.nn.ReplicationPad2d([0,0,30,1024,-1,0])
    arg_tensor = torch.rand([1, 1, 3, 3], dtype=torch.float32).clone().cuda()
    arg = [arg_tensor,]
    res = arg_class(*arg)

test()
```
Error log:
```
========= COMPUTE-SANITIZER
========= Program hit cudaErrorInvalidConfiguration (error 9) due to "invalid configuration argument" on CUDA API call to cudaLaunchKernel.
========= 
========= Program hit cudaErrorInvalidConfiguration (error 9) due to "invalid configuration argument" on CUDA API call to cudaGetLastError.
========= 
========= ERROR SUMMARY: 2 errors
```

### Versions

```
PyTorch version: 1.14.0a0+gitbdc9911
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: 11.1.0-6
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.10.6 (main, Nov  2 2022, 18:53:38) [GCC 11.3.0] (64-bit runtime)
Python platform: Linux-5.15.0-52-generic-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 11.6.124
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: 
GPU 0: NVIDIA GeForce RTX 3090
GPU 1: NVIDIA GeForce RTX 3090
GPU 2: NVIDIA GeForce RTX 3090

Nvidia driver version: 515.65.01
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.4.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.5
[pip3] torch==1.14.0a0+gitbdc9911
[pip3] torchvision==0.13.1
[conda] blas                      1.0                         mkl  
[conda] cudatoolkit               11.3.1               h2bc3f7f_2  
[conda] mkl                       2021.4.0           h06a4308_640  
[conda] mkl-service               2.4.0            py39h7f8727e_0  
[conda] mkl_fft                   1.3.1            py39hd3c417c_0  
[conda] mkl_random                1.2.2            py39h51133e4_0  
[conda] numpy                     1.21.5           py39he7a7128_1  
[conda] numpy-base                1.21.5           py39hf524024_1  
[conda] numpydoc                  1.2                pyhd3eb1b0_0  
[conda] torch                     1.14.0a0+gitce2f870          pypi_0    pypi
```

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
Repository: pytorch
Issue: torch.lobpcg should support black-box linear operators like SciPy
Labels: feature,triaged,module: linear algebra

### 🚀 The feature, motivation and pitch

Currently, the `torch.lobpcg` matrix-free eigensolver only supports fully materialized dense or sparse tensors as input. This makes it impossible to, for example, pass in a Hessian-vector product callable from `functorch` when you know that the Hessian of the function you're using will be positive definite. This is in contrast to [the SciPy implementation](https://docs.scipy.org/doc/scipy/reference/generated/scipy.sparse.linalg.lobpcg.html), which allows the user to provide a black-box `LinearOperator` callable as input. Since the algorithm itself is matrix-free and only relies on matrix-vector products to compute its solution, there's no _algorithmic_ reason why support for black-box callables couldn't be added relatively easily AFAICT.

### Alternatives

_No response_

### Additional context

_No response_

cc @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
Repository: puppeteer
Issue: [Bug]: No way to access 'Network.webSocketFrameReceived' without using internal APIs
Labels: feature,confirmed

### Bug description

In the past, I used to be able to do `page._client()` to get the current CDPSession, and setup `cdpSession.on('Network.webSocketFrameReceived', callback)`.

In recent versions, `_client()` has been marked as `@internal` and is no longer being exported in the TypeScript types. I can still access it if I ignore the type, but it seems that this is being discouraged.

There doesn't seem to be a way to hook onto WebSocket events anymore. Creating a new CDPSession using `await page.target().createCDPSession()` doesn't cut it, because the new session will not emit `Network.webSocketFrameReceived` events - it has to be the same one which was previously created.

I'd propose we either expose `page._client()` in some legitimate way, or add an API to make it possible to read WebSocket data directly in Puppeteer.

Reproduction:

```js
const page = await browser.newPage()
await page.goto('https://www.piesocket.com/websocket-tester')

// uses internals, but works:
const cdpSession = page._client()
cdpSession.on(
  'Network.webSocketFrameReceived',
  (d) => console.log('Internal CDP', d)
)

// "proper" way, but doesn't work - no events are emitted:
const newCdpSession = await page.target().createCDPSession()
newCdpSession.on(
  'Network.webSocketFrameReceived',
  (d) => console.log('New CDP', d)
)

// start WS
await startWS.click('button[type=submit]')
```

### Puppeteer version

19.2.2

### Node.js version

v19.0.1

### npm version

8.19.2

### What operating system are you seeing the problem on?

Linux, macOS, Windows

### Configuration file

```JavaScript
n/a
```


### Relevant log output

```Shell
n/a
```
Repository: godot
Issue: Garbled text rendering in editor with GL Compatibility renderer
Labels: bug,topic:rendering,topic:editor,confirmed,regression,topic:gui

### Godot version

v4.0.beta5.official [89a33d28f]

### System information

Windows 10, OpenGL Renderer: NVIDIA GeForce RTX 3060

### Issue description

Text shows as garbled and unreadable under certain conditions. I suspect the issue is related to DPI scaling, as the problem only happens on my work computer with two screens: one at 1080p 100% scaling and the other is a 2160p screen with 150% scaling. 

I wasn't able to replicate this in other computers with Windows 10, 100% DPI scaling and Windows 11, also 100% DPI scaling.

![image](https://user-images.githubusercontent.com/1028756/202610475-5c59d8ca-2f9e-40f5-b2d5-dd90092a2f79.png)
![image](https://user-images.githubusercontent.com/1028756/202610568-d5517532-2a54-4d6a-a79f-3dcb5e3745cd.png)

Using different font rendering options in the editor preferences didn't improve the situation.

I bisected the git history and seems like this commit introduced this problem: cd25e48456e58704f1450954a0c94b1e7fe079f4
PR #67562

here is a comparison of both project launchers side by side, one before and the other after the commit mentioned above
![image](https://user-images.githubusercontent.com/1028756/202611267-42f27d41-7750-455e-80e8-0a87200addf2.png)



### Steps to reproduce

Open the Godot editor. You can easily see the problem from the project launcher.
Alternatively you can open any script and the issue is easy to notice there too.

### Minimal reproduction project

N/A
Repository: pytorch
Issue: torch.addcdiv: input, tensor1, and tensor2 parameters should be of the same type
Labels: module: docs,triaged,module: assert failure

### 📚 The doc issue

In the latest article, for torch.addcdiv(input, tensor1, tensor2, *, value=1, out=None) operator, the input, tensor1, tensor2 types are not required to be consistent, but simply referred to as tensors. But in a real test, something goes wrong.

For example：

    import torch
    input = torch.rand([1], dtype=torch.float64)
    tensor1 = torch.rand([5, 5, 1], dtype=torch.float64)
    tensor2 = torch.rand([1, 5], dtype=torch.float32)
    value = 1
    print(torch.addcdiv(input, tensor1, tensor2, value=value))

result:  RuntimeError: !(has_different_input_dtypes && !config.promote_inputs_to_common_dtype_ && (has_undefined_outputs || config.enforce_safe_casting_to_output_ || config.cast_common_dtype_to_outputs_))INTERNAL ASSERT FAILED at "..\\aten\\src\\ATen\\TensorIterator.cpp":331, please report a bug to PyTorch. 


### Suggest a potential alternative/fix

Add input, tensor1, and tensor2 parameters of the same type.

cc @svekars @carljparker
Repository: three.js
Issue: Inappropriate color of LDraw part
Labels: Bug,Loaders

<!-- Ignoring this template may result in your bug report getting deleted -->

**Describe the bug**

Three.js (LDrawLoader) displays black part instead of grey.

There was **no error** on Windows 7 with Three.js version: 137 and Chrome. The only difference is Windows 10 and maybe newer version of Chrome. Updating three.js (137 -> 147) doesn't fix the problem. I use several models and for now I've found problem with one model, although [LDraw Model Viewer](https://www.ldraw.org/parts/tools/ldraw-model-viewer.html) displays this model correctly.


**Screenshots**

![ldrawIssue](https://user-images.githubusercontent.com/71113600/202651751-94648b96-395b-49df-8879-b04444a8c0b5.jpg)
Left: index.html opened with live server. Right: view from LDraw Model Viewer

**Platform:**

 - Device: Desktop
 - OS: Windows 10
 - Browser: Chrome 107, Firefox 107
 - Three.js version: 137 & 147
Repository: flutter
Issue: [camera] Consider converting `CameraException.code` to an enum
Labels: p: camera,package,c: proposal,team-ecosystem,P3,triaged-ecosystem

## Use case

When using the `camera` package, a developer probably wants to handle camera errors from the plugin.
Currently the error codes that are exposed to Dart are strings, which makes using them error prone.

https://pub.dev/documentation/camera_platform_interface/latest/camera_platform_interface/CameraException/code.html

## Proposal

Convert the CameraException.code from a String to an enum.
This enables using them in a switch and is less error prone.
Repository: godot
Issue: Distorted color palette in Color Picker
Labels: bug,topic:gui

### Godot version

3.5.1.stable

### System information

macOS Monterey 12.5

### Issue description

The palette colors from the Color Picker are distorted/squished on `3.5.1`.
And the arrows from the sliders are behind the input.

Seems to be working fine on Windows, as another user pointed out to me. 

<img width="273" alt="Captura de pantalla 2022-11-16 a les 21 41 56" src="https://user-images.githubusercontent.com/481475/202665816-89daa064-7bdd-410d-8919-0daaa14fdd88.png">

It works as expected on `3.4.5`.

<img width="294" alt="Captura de pantalla 2022-11-16 a les 21 44 49" src="https://user-images.githubusercontent.com/481475/202665825-a9fc2e2c-1233-4ebc-bd84-ff7fef12a177.png">


### Steps to reproduce

- Open Godot `3.5.1` on a Mac.
- Open the Color Picker.

### Minimal reproduction project

-
Repository: vscode
Issue: Explorer should show which folders are gitignored when multiple folders are collapsed into one item
Labels: feature-request,file-explorer

In the vscode-jupyter repo:

![image](https://user-images.githubusercontent.com/2193314/202678267-357ffc2e-e246-4da9-97a7-a856aaef6076.png)

The root folders aren't gitignored, so they should show up as white in the above screenshot.

![image](https://user-images.githubusercontent.com/2193314/202678377-fbfb733c-664d-4b93-9390-6645bdf13165.png)
Repository: tauri
Issue: [bug] Not works with js-ipfs #2564
Labels: type: bug,status: needs triage

### Describe the bug

refer to Not works with js-ipfs #2564
I created an mini repo.

### Reproduction

_No response_

### Expected behavior

_No response_

### Platform and versions

❯ cargo tauri info

Environment
  › OS: Mac OS 12.6.0 X64
  › Node.js: 16.17.0
  › npm: 8.15.0
  › pnpm: 7.16.1
  › yarn: 1.22.19
  › rustup: 1.25.1
  › rustc: 1.66.0-nightly
  › cargo: 1.66.0-nightly
  › Rust toolchain: nightly-x86_64-apple-darwin

Packages
  › @tauri-apps/cli [NPM]: 1.0.0-rc.7(outdated, latest: 1.2.0)
  › @tauri-apps/api [NPM]: 1.2.0(outdated, latest: 1.2.0)
  › tauri [RUST]: 1.1.1,
  › tauri-build [RUST]: 1.1.1,
  › tao [RUST]: 0.14.0,
  › wry [RUST]: 0.21.1,

App
`tauri.conf.json` error on ``: Additional property '$schema' is not allowed

### Stack trace

_No response_

### Additional context

_No response_
Repository: deno
Issue: Uncaught AddrInUse when restarting server in watch mode after saving file 
Labels: needs investigation,--watch,triage required 👀

Source: https://stackoverflow.com/questions/74444443/deno-watcher-uncaught-addrinuse-only-one-usage-of-each-socket-address

Reproduction:

- Run the code below with `deno run -A --watch server.ts`:

```ts
import express, { Express, Request, Response } from "npm:express@4.18";
import { v4 as uuidv4 } from 'npm:uuid@9.0.0';
const app: Express = express();

app.use("/", (_req: Request, res: Response) => {
    res.send(`uuid: ${uuidv4()}.`);
})

app.listen(8000, () => {
    console.log("App Running: http://localhost:8000");
});
```

- Make a change and save the file (either with auto-save or manually)
- When the file watcher restarts the error is thrown

```
Watcher File change detected! Restarting!
error: Uncaught AddrInUse: Only one usage of each socket address (protocol/network address/port) is normally permitted. (os error 10048)
Watcher Process finished. Restarting on file change...
```

I found that this error can happen when there is another process listening on the same port: https://stackoverflow.com/a/62190276/12769288, so maybe the file watcher tries to restart the server while the previous one is still listening?

Additionally the same error seems to happen on occasion in one of the tests: https://github.com/denoland/deno/issues/16044
Repository: flutter
Issue: Feature Request: add fourth and fifth mouse button to Gesture detector
Labels: c: new feature,framework,f: gestures,c: proposal,a: desktop,P3,team-framework,triaged-framework

For desktop applications it would be useful to use the  mouse to navigate back and forward in the navigator with the fifths and forth mouse button. It looks like only 1., 2. and 3. mouse buttons are covered in GestureDetector

In this video I covered it with two finger trackpad gesture detector but most desktop users like mice

https://user-images.githubusercontent.com/15329494/202690873-52b359f8-9fe6-444a-a5dd-0f3b3b98ed61.mp4
Repository: ant-design
Issue: The Tooltip does not recalculate size when text changes
Labels: Inactive

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/quirky-ben-udyls8?file=/src/App.tsx)

### Steps to reproduce

Mouse over the button, see the tooltip, click button, and should see the new tooltip text

### What is expected?

The tooltip text should be in the same position as the previous text

### What is actually happening?

The size of the tooltip remains the same, and the tooltip size is not being recalculated

| Environment | Info |
| --- | --- |
| antd | 4.22.4 |
| React | 18.2.0 |
| System | macOS Monterey |
| Browser | Chrome Version 106.0.5249.119 (Official Build) (arm64) |

---
I think there is something with the memo, when react re-render the component it only renders the div with the text, not the div where the math to set the size is

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: angular
Issue: User-defined extended diagnostics
Labels: feature,area: compiler,P4,feature: under consideration,compiler: extended diagnostics

### Which @angular/* package(s) are relevant/related to the feature request?

compiler-cli

### Description

With great pleasure I looked at the new possibilities of extended diagnostics, but unfortunately I found out that there is no possibility to extend it myself.

For the moment I can patch the execution to inject some own checks but it feels not awesome.

### Proposed solution

I think a good way to add some own rules would be a similar system like the builders schema.
You define within a checks.json file all supported rules, each rule can have a schema.json file to handle all configuration parameters.

```
{
  "checks": {
    "custom-check": {
      "implementation": "./custom-check",
      "schema": "./custom-check/schema.json",
      "description": "checks some custom stuff."
    },
    "custom-check-without-configuration": {
      "implementation": "./custom-check-without-configuration",
      "description": "checks some custom stuff."
    }
  }
}
```

The angular.json file contains a list of extending check sets on root level (same level as projects) and load all rules during build, serve, etc.

```
{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "version": 1,
  "projects": {
  },
  "extendedDiagnosticsExtensions": [
    "./local-provided-custom-checks",
    "@npm-provided/custom-checks"
  ]
}

```

The tsconfig.json file lists all checks also custom ones. If a custom one is not listed, it won't be enabled.

```
{
  "angularCompilerOptions": {
    "extendedDiagnostics": {
      // The categories to use for specific diagnostics.
      "checks": {
        // Maps check name to its category.
        "invalidBananaInBox": "suppress",
        "customCheck": "error",
        "customCheckWithoutConfiguration": "suppress",
      },

      // The category to use for any diagnostics not listed in `checks` above.
      "defaultCategory": "error"
    }
  }
}
```

### Alternatives considered

to be considered
Repository: godot
Issue: More than 7 CanvasGroup in a scene causes Vulkan to crash
Labels: bug,topic:rendering,needs testing,topic:2d

### Godot version

4.0.beta5

### System information

Pop!_OS 22.04 LTS
Hardware Model: Lenovo ThinkPad X1 Nano Gen 1
Memory: 16GiB
Processor: 11th Gen Intel Core i5-1130G7 @ 1.10GHz * 8
Graphics: Mesa Intel Xe Graphics (TGL GT2)

OS: Pop!_OS 22.04 LTS
OS Type: 64-bit
Gnome Version 42.4
Windowing System: X11

### Issue description

Instanciating a scene containing a canvas group seem to be problematic. In my project I could instantiate 6 or 7 before it ran unstable in the editor let alone the running game.
  
Restarting Godot, and just opening the scene with the instances causes the freeze.
  
Playing the scene will cause a major freeze after just a few seconds with a rather unhelpful error saying 
[swap buffers condition err is true returning ERR CANT CREATE]

After experimenting for an hour or two, I found out that removing the canvas group solved the problem.

In the bug reproducing project, it seemed that only duplicating the canvas group scene twice was enough to freeze my computer.

### Steps to reproduce

Open project - may freeze out of the bat.

If not, try duplicate the canvas_group.tscn in the main scene.

If project does not load at all, you can delete the main scene, recreate if by just adding an instance of canvas_group and duplicating it.

### Minimal reproduction project

[CanvasGroupReport.zip](https://github.com/godotengine/godot/files/10045791/CanvasGroupReport.zip)