sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: ONNX broken for identity function
Labels: bug,category: dnn,category: dnn (onnx)

### System Information

OpenCV python version: 4.10.0.82
PyTorch version: 2.0.0+cu117
Operating System / Platform: Ubuntu 22.04
Python version: 3.10.6

### Detailed description

I have been having some issues with ONNX files lately.
Decided to check that the simplest function of them all works: _the identity ..._

Here is a script that shows for what input shapes ONNX is broken (0, 1 and 3 dimensional inputs).
I redirect stdout when exporting the ONNX file to make the output more readable.

I suspect that this is the underlying error to https://github.com/opencv/opencv/issues/25762

### Steps to reproduce

```python
import torch
import cv2 as cv
from contextlib import redirect_stdout

class Identity(torch.nn.Module):

    def __init__(self):
        super().__init__()

    def forward(self, X):
        return X

model = Identity()
shape = (2,3,5,7,11,13,17,19)

for i in range(1 + len(shape)):
    X = torch.zeros(shape[:i])
    with open('/dev/null', 'w') as f:
        with redirect_stdout(f):
            torch.onnx.export(model, X, '/tmp/model.onnx', output_names=['Y'])

    Y = model(X)
    ok = X.shape == Y.shape
    print('OK   ' if ok else 'ERROR', 'PyTorch', tuple(X.shape), '->', tuple(Y.shape))

    net = cv.dnn.readNetFromONNX('/tmp/model.onnx')
    X = X.numpy()
    net.setInput(X)

    Y = net.forward(['Y'])[0]
    ok = X.shape == Y.shape
    print('OK   ' if ok else 'ERROR', 'OpenCV ', X.shape, '->', Y.shape)
```

which gives me the following output (format: Dimension, OK/ERROR, PyTorch/OpenCV, SourceShape, TargetShape)

```
0 OK    PyTorch () -> ()
0 ERROR OpenCV  () -> (1, 1)
1 OK    PyTorch (2,) -> (2,)
1 ERROR OpenCV  (2,) -> (2, 1)
2 OK    PyTorch (2, 3) -> (2, 3)
2 OK    OpenCV  (2, 3) -> (2, 3)
3 OK    PyTorch (2, 3, 5) -> (2, 3, 5)
3 ERROR OpenCV  (2, 3, 5) -> (2, 3)
4 OK    PyTorch (2, 3, 5, 7) -> (2, 3, 5, 7)
4 OK    OpenCV  (2, 3, 5, 7) -> (2, 3, 5, 7)
5 OK    PyTorch (2, 3, 5, 7, 11) -> (2, 3, 5, 7, 11)
5 OK    OpenCV  (2, 3, 5, 7, 11) -> (2, 3, 5, 7, 11)
6 OK    PyTorch (2, 3, 5, 7, 11, 13) -> (2, 3, 5, 7, 11, 13)
6 OK    OpenCV  (2, 3, 5, 7, 11, 13) -> (2, 3, 5, 7, 11, 13)
7 OK    PyTorch (2, 3, 5, 7, 11, 13, 17) -> (2, 3, 5, 7, 11, 13, 17)
7 OK    OpenCV  (2, 3, 5, 7, 11, 13, 17) -> (2, 3, 5, 7, 11, 13, 17)
8 OK    PyTorch (2, 3, 5, 7, 11, 13, 17, 19) -> (2, 3, 5, 7, 11, 13, 17, 19)
8 OK    OpenCV  (2, 3, 5, 7, 11, 13, 17, 19) -> (2, 3, 5, 7, 11, 13, 17, 19)
```

As you can see, it's broken for 0, 1 and 3 dimensional inputs.

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: PowerToys
Issue: Keyboard mapping stops working in WSLg windows.
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.81.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

I have only seen this once, and do not know how to reproduce it. I have my caps lock key mapped to Ctrl (Left). Normally this works fine in a WSLg window. But today it simply stopped working, even with closing and opening new windows. I shut down and restarted WSL, and they key remapping was working again. 


### ✔️ Expected Behavior

Key remapping is obeyed in WSLg windows.

### ❌ Actual Behavior

They key remapping was ignored.

### Other Software

```WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3737
```
Repository: rust
Issue: Struct update syntax doesn't reborrow mut references
Labels: T-lang,C-bug,C-discussion

When using struct update syntax to copy a struct's `&mut` fields, the compiler will complain about the field being moved, even though it could logically be reborrowed.

Here's a minimal example:

```rust
struct Foobar<'a> {
    s: &'a str,
}

// Works fine
fn take_foobar(foobar: Foobar<'_>) {
    let foobar2 = Foobar {
        ..foobar
    };
    dbg!(foobar.s);
}

struct FoobarMut<'a> {
    s: &'a mut str,
}

// COMPILE ERROR - error[E0382]: use of moved value: `foobar.s`
fn take_foobar_mut(foobar: FoobarMut<'_>) {
    let foobar2 = FoobarMut {
        ..foobar
    };
    dbg!(foobar.s);
}
```

[(Playground link)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ff4aaf7a43593e9f3cff5e480980af45)

I'm not familiar with compiler internals, but from a very rough guess, this doesn't seem like a use-case that would need architectural changes to handle. If we replace the use of struct update syntax with copying the individual fields, the code works fine:

```rust
fn take_foobar_mut_2(foobar: FoobarMut<'_>) {
    let foobar2 = FoobarMut {
        s: foobar.s
    };
    dbg!(foobar.s);
}
```

### Meta

```
rustc 1.78.0 (9b00956e5 2024-04-29)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: x86_64-unknown-linux-gnu
release: 1.78.0
LLVM version: 18.1.2
```
Repository: kubernetes
Issue: Cronjob Should have limit on Active Jobs
Labels: kind/feature,sig/apps,lifecycle/rotten,needs-triage

### What would you like to be added?

we should have some variables to limit the no of active jobs for a cronjob. concurrencyPolicy is not enough.
maybe something like maxJobCount.

### Why is this needed?

We recently found out ,when you have very huge no of pending job it will make the entire process of creating jobs very slow.

We run large cluster on GKE with shared projects in namespaces. We have quota for each of them , we found some of the projects reached the quota and then their cronJob ended  up creating 2k jobs ,it happen with some other ns well now all of the job creation is very slow because the job queue is flooded with pending jobs.


One option  to fix it with concurrencyPolicy but that's can fix this issue but we will taking feature from our users.
if we can put limit on active jobs with variable we can force job controller to li it this flooding also it will put less pressure on it as well.
Repository: vscode
Issue: Silence the "Comments are not permitted in JSON." error for the emmet snippets.json to match parsing behavior
Labels: bug,help wanted,emmet,confirmation-pending

Type: <b>Bug</b>

The emmet snippets.json is tolerant to comments since #33818. This means that a `snippets.json` like this would still be parsed correctly and work as expected:

```
{
  // Hello!
  "html": {
    "snippets": {
      "hw": "{Hello world}"
    }
  }
}
```

However any comment in `snippets.json` will still be marked as an error by VSCode. In contrast, any comment in the VSCode `settings.json` is ignored.

| emmet `snippets.json` | VSCode `settings.json` |
| --- | --- |
| ![A comment on an emmet snippets.json is marked as an error](https://github.com/microsoft/vscode/assets/35560568/7e7bc4b6-d082-46c1-a96c-0a540ac9363c) | ![A comment on a VSCode settings.json is not marked as an error](https://github.com/microsoft/vscode/assets/35560568/31d6837e-ec65-4440-ae6e-1a3ace86d63a) |

I assume that this behavior can be changed, since the emmet `snippets.json` is already being parsed in a way that's tolerant to comments. Can these errors be silenced to match the underlying parsing behavior?

---

Does this issue occur when all extensions are disabled?: Yes

Steps to Reproduce:

1. create an emmet snippet.json file with comments
2. notice the mismatch: the file is being parsed correctly, but the comment is marked as an error ("Comments are not permitted in JSON. (521)")

VS Code version: Code 1.90.0 (89de5a8d4d6205e5b11647eb6a74844ca23d2573, 2024-06-04T19:43:07.605Z)
OS version: Linux x64 6.5.0-35-generic snap
Modes:


<!-- generated by issue reporter -->
Repository: tensorflow
Issue: Segmentation fault in `tf.raw_ops.CollectiveGatherV2`
Labels: stat:awaiting tensorflower,type:bug,comp:ops,TF 2.16

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

tf 2.16

### Custom code

Yes

### OS platform and distribution

Linux Ubuntu 22.04.3 LTS (x86_64)

### Mobile device

_No response_

### Python version

3.9.13

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Under specific input, tf.raw_ops.CollectiveGatherV2 encounters "Segmentation fault (core dumped)".

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

test = tf.Variable([1.0, 2.0, 3.0])

input_dict = {
    'input': tf.constant([], shape=(1, 1, 0), dtype=tf.float64),
    'group_size': tf.constant(1, dtype=tf.int32),
    'group_key': tf.constant(30631, dtype=tf.int32), 
    'instance_key': tf.constant(2, dtype=tf.int32), 
    'ordering_token': [test.handle], 
}


result = tf.raw_ops.CollectiveGatherV2(
    input=input_dict['input'],
    group_size=input_dict['group_size'],
    group_key=input_dict['group_key'],
    instance_key=input_dict['instance_key'],
    ordering_token=input_dict['ordering_token'],
    communication_hint='auto',
    timeout_seconds=0,
    is_stateless=False
)
```


### Relevant log output

```shell
2024-06-13 14:32:37.690567: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
Segmentation fault (core dumped)
```
Repository: tensorflow
Issue: Segmentation fault in `tf.raw_ops.CollectiveAllToAllV2`
Labels: stat:awaiting tensorflower,type:bug,comp:ops,TF 2.16

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

tf 2.16

### Custom code

Yes

### OS platform and distribution

Linux Ubuntu 22.04.3 LTS (x86_64)

### Mobile device

_No response_

### Python version

3.9.13

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Under specific input, tf.raw_ops.CollectiveGatherV2 encounters "Segmentation fault (core dumped)".

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

test = tf.Variable([1.0, 2.0, 3.0])

input_dict = {
    'input': tf.constant([], shape=(1, 1, 0), dtype=tf.float64),
    'group_size': tf.constant(1, dtype=tf.int32),
    'group_key': tf.constant(30631, dtype=tf.int32), 
    'instance_key': tf.constant(2, dtype=tf.int32), 
    'ordering_token': [test.handle], 
}


tf.raw_ops.CollectiveAllToAllV2(
    input=input_dict['input'],
    group_size=input_dict['group_size'],
    group_key=input_dict['group_key'],
    instance_key=input_dict['instance_key'],
    ordering_token=input_dict['ordering_token'],
    communication_hint='auto',
    timeout_seconds=0,
    is_stateless=False,
    name=None
)
```


### Relevant log output

```shell
2024-06-13 14:37:50.256604: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
Segmentation fault (core dumped)
```
Repository: godot
Issue: GDExtension: pointer parameters of type `real` are declared as `float*` in JSON
Labels: bug,discussion,topic:gdextension

### Tested versions

4.2.2

### System information

N/A

### Issue description

The virtual function `PhysicsDirectSpaceState2D::_cast_motion()` uses pointer parameters, and it's unclear if the type is declared correctly in the API spec.

The `extension_api.json` entry for that function looks as follows:
```json
{
    "name": "_cast_motion",
    "is_const": false,
    "is_static": false,
    "is_vararg": false,
    "is_virtual": true,
    "return_value": {
        "type": "bool"
    },
    "arguments": [
        {
            "name": "shape_rid",
            "type": "RID"
        },
        {
            "name": "transform",
            "type": "Transform2D"
        },
        {
            "name": "motion",
            "type": "Vector2"
        },
        {
            "name": "margin",
            "type": "float",
            "meta": "float"
        },
        {
            "name": "collision_mask",
            "type": "int",
            "meta": "uint32"
        },
        {
            "name": "collide_with_bodies",
            "type": "bool"
        },
        {
            "name": "collide_with_areas",
            "type": "bool"
        },
        {
            "name": "closest_safe",
            "type": "float*"
        },
        {
            "name": "closest_unsafe",
            "type": "float*"
        }
    ]
},
```

So both pointers are declared as `float*`.

`float` usually means 64-bit floating point (C++ `double`), **unless** it's accompanied by `meta = float` key-value, see e.g. `margin` argument.

However, the method on C++ side is declared as `real`, which is 32-bit floating point in single precision builds:
https://github.com/godotengine/godot/blob/1567a498cbe0d2aeb73a9d2a67d3ac6b22b340a1/servers/physics_2d/godot_space_2d.h#L54

And I also found this:
https://github.com/godotengine/godot/blob/1567a498cbe0d2aeb73a9d2a67d3ac6b22b340a1/servers/extensions/physics_server_2d_extension.h#L133

CC @Ughuuu, who noticed this and had a crash in this code.

---

I would expect that if a type is declared as `T*` (here `float*`) in the JSON, that it behaves like a pointer to `T`.
Otherwise, a `meta` could be used, just like value types.

Is this assumption wrong?

### Steps to reproduce

Override `_cast_motion` virtual method (e.g. in Rust bindings), try to dereference the `f64` pointers -> UB.

### Minimal reproduction project (MRP)

N/A
Repository: PowerToys
Issue: Bluetooth manager to disable autoconnect
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

Windows does not appear to have a built-in feature to disable autoconnect Bluetooth devices. The only solution seems to be to manually unpair the device each time and then repair it when needed.

### Scenario when this would be used?

All the time to manage all Bluetooth devices to connect them easily (should work like WIFI).

### Supporting information

https://www.reddit.com/r/Windows10/comments/v84syy/is_there_a_way_to_stop_autoconnecting_to/

https://gist.github.com/FabulousCupcake/3cc04eb656f99045e3e7e1c79fcb1fa9
Repository: PowerToys
Issue: Accessibility Issues with PowerToys: Screen Reader Incompatibility with NVDA and JAWS
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.81.1

### Installation method

GitHub

### Running as admin

No

### Area(s) with issue?

PowerToys Run, Settings, Welcome / PowerToys Tour window

### Steps to reproduce

# PowerToy Setting
1. Open PowerToy.
2. Navigate to the right pane after selecting a setting for the tool
3. Attempt to read the text using NVDA or JAWS.
# PowerToy run
1. open PowerToy Run 
2. Attempt to read the text using NVDA or JAWS by using up and down arrow key

### ✔️ Expected Behavior

The text in the suggestion fields should be read aloud by the screen reader.

### ❌ Actual Behavior

 The screen reader announces blank.

### Other Software

_No response_
Repository: next.js
Issue: Writing gzipped data to response stream doesn't write content
Labels: bug,Pages Router

### Link to the code that reproduces this issue

https://github.com/togakangaroo/nextjs-stream-compression?tab=readme-ov-file

### To Reproduce

See [this repo](https://github.com/togakangaroo/nextjs-stream-compression?tab=readme-ov-file) with a full writeup in the README file.

Essentially this pattern within a pages api handler returns 0 bytes

```javascript
const { createGzip } = require(['zlib'](https://nodejs.org/api/zlib.html));
  export default function handler(req, res) {
    res.status(200)
    const gzip = createGzip()
    gzip.pipe(res)
    gzip.write(JSON.stringify({ message: 'fanny fatnugget says hello' }))
    gzip.end();
    res.end();
  }
 ```
 

### Current vs. Expected behavior

This is the correct way of streaming compressed content to a response. The following works fine (example included in repo as well)

```javascript
  const server = http.createServer((req, res) => {
    res.writeHead(200, { 'Content-Encoding': 'gzip' });
    const gzip = zlib.createGzip();
    gzip.pipe(res);
    gzip.write('hello world');
    gzip.end();
  });
```

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:49 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6020
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.4 // Latest available version is detected (14.2.4).
  eslint-config-next: 14.2.4
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Developer Experience, Pages Router

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

In my actual application where I ran into this I actually *do* get 10 bytes in the response, but its always 10 bytes regardless of how much data is written to the response.
Repository: rust
Issue: `struct` documentation should include `Sized` in the listed auto trait implementations
Labels: T-rustdoc,C-bug

This was previously raised in #17606, which was closed when auto-traits were documented in #47833—however, since `Sized` is not a library-implemented auto-trait but rather a compiler-implemented trait, it was omitted from that solution.

The issue appears to have also been previously raised in #41537 (closed as duplicate of the above) and #75413 (I think erroneously closed as duplicate of #24183).

@rustbot label A-docs C-bug
Repository: PowerToys
Issue: FancyZone doesn't want to snap window to the same side twice in a row
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.81.1

### Installation method

WinGet

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

I want to snap window from maximized to side, but every other time I want to snap to the same side, it snaps to the other side, making override windows snap completely useless. I use touchpad gestures and win+arrow key and behavior is the same. 

I have almost every option disabled, except:

- hold shift key to (...),
- override windows snap <- I don't want to disable that, because it doesn't move window from one side to another immidately without it.

Layout is very basic - two rectangles - one on the left and other one on the right, basically splitting screen in half.



### ✔️ Expected Behavior

I want window to be snapped to the same side everytime when coming from maximized window.

### ❌ Actual Behavior

- swipe fingers up, window is maximised, 
- swipe to left, it does snap to left,
- swipe up again and window maximizes again,
- and I swipe left again, but it snaps to the right.

It happens regardless the side or if I use touch geture or win+arrow key, it's like it's forced to not snap window to the same side twice in a row.

### Other Software

_No response_
Repository: next.js
Issue: `Request` object behaves differently in fetch
Labels: bug,Runtime

### Link to the code that reproduces this issue

https://github.com/lennartkerkvliet/next-fetch-request-bug

### To Reproduce

When sending a request body using the `Request` object in a Next.js application while using server actions, the content-length parameter is not included in the request and instead chunked transfer encoding is used. This behavior differs from the expected functionality of the Fetch API, which internally is also constructing a `Request` object.

Steps to reproduce the behavior:
1. Create a `Request` object with a body.
2. Pass the `Request` object to the `fetch` function.

Example code:
```javascript
const body = JSON.stringify({ username: "test", password: "password" });
const request = new Request("https://www.my-site.com/api/login", { 
    method: "POST", 
    headers: { "Content-Type": "application/json" },
    body: body
});
const response = await fetch(request); // Server receives an empty body
```


### Current vs. Expected behavior

I would expect the parameters in `Request` to be identical to when using the more traditional use of fetch API:

```javascript
const body = JSON.stringify({ username: "test", password: "password" });
const response = await fetch("https://www.my-site.com/api/login", { 
    method: "POST", 
    headers: { "Content-Type": "application/json" },
    body: body
});
```

but instead will return the latter

<img width="1505" alt="Screenshot 2024-06-13 at 18 27 51" src="https://github.com/vercel/next.js/assets/5382580/39492428-d95d-412c-9683-5ddac824a7c9">


### Provide environment information

```bash
Operaring System:
  Arch: arm64
  Version: macOS Sonoma 14.4.1

Binaries:
  Node: v22.2.0
  npm: 10.7.0

Relevant Packages:
  next: 14.2.3
```


### Which area(s) are affected? (Select all that apply)

Not sure, Runtime

### Which stage(s) are affected? (Select all that apply)

next dev (local), Vercel (Deployed), Other (Deployed)

### Additional context

- Using plain Node.js, the above code works as expected.

It seems to be somewhat related to the changes NextJS is making to the `Response` object and in particular the `duplex` option.  The Django server I am using for my own project does not support `transfer-encoding`, and will mark the request as a "Bad request syntax".
Repository: PowerToys
Issue: SVGs sometimes blocked in Explorer
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.79.0

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

File Explorer: Preview Pane, File Explorer: Thumbnail preview

### Steps to reproduce

Some SVG files show contents in icon and in preview pane.  Others are blocked and only show associated app icon and in the preview pane the message, "[Some elements have been blocked to help prevent the sender from identifying your computer. Open this item to view all elements.](https://user-images.githubusercontent.com/34771316/79627827-51a40e80-8159-11ea-82e4-d450de0c32f1.png)"

I have found that the SVGs that are blocked on my system are those that contain mesh gradients created in Inkscape, which are coded like this:

```
  <script
     id="script1"
     type="text/javascript">
!function(){const t=&quot;http://www.w3.org/2000/svg&quot;,e=&quot;http://www.w3.org/1999/xlink&quot;,s=&quot;http://www.w3.org/1999/xhtml&quot;,r=2;if(document.createElementNS(t,&quot;meshgradient&quot;).x)return;const n=(t,e,s,r)=&gt;{let 
```
...


### ✔️ Expected Behavior

This is not a security risk and should not be blocked.

### ❌ Actual Behavior

Silently replaces icon with file association.

### Other Software

_No response_