sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: mime/multipart: add method Reader.SetRejectContentTransferEncoding(bool) to support net/http rejecting multipart form parts with "Content-Transfer-Encoding" header which is explicitly deprecated by RFC 7578 Section 4.7
Labels: Proposal

### Proposal Details

## Suggestion
This issue proposes adding the method `Reader.SetRejectContentTransferEncoding(v bool)` which if set, serves the purpose of rejecting multipart form parts that contain the "Content-Transfer-Encoding" header for binary data, including HTTP and that serves to fix security issue #63855

## Motivation
To fix net/http security bug #63855, for multipart requests whose content is streamed and not yet ready until one invokes `req.MultipartReader()` or `req.ParseMultipartForm(MAX)`, it is inefficient and non-elegant to trawl the bytes being streamed in. Instead it is much better to a method on the Reader which will be set by the net/http caller.

```go
// SetRejectContentTransferEncoding toggles whether to decode parts if
// the "Content-Transfer-Encoding" header is present or not.
// If set to true, trying to decode a part will return an error if that header is present.
func (r *Reader) SetRejectContentTransferEncoding(v bool) {
        r.rejectContentTransferEncoding = v
}
```

## Rationale
Internet Engineering Task Force (IETF) [RFC 7578](https://www.rfc-editor.org/rfc/rfc7578) circa 2015 is the current/prevailing advice for parsing multipart/form-data and it obsoletes the prior standing [RFC 2388](https://www.rfc-editor.org/rfc/rfc2388) from 1998.
[RFC 7578 Section 4.7](https://www.rfc-editor.org/rfc/rfc7578#section-4.7) recommends that we should reject multipart/form-data carrying the header "Content-Transfer-Encoding" and it mentions that currently no deployments supporting that legacy configuration have been discovered.
![IMG_1097](https://github.com/golang/go/assets/4898263/58772ac5-7e81-4c96-b617-0ed37216528d)


## Action
I have CLs (CL [573195](https://go-review.googlesource.com/c/go/+/573195) and [573196](https://go-review.googlesource.com/c/go/+/573196)) available to smoothly experiment and show how this would appear ergonomically.

@neild who was advised by the bug reporters Qi  Wang and Jianjun Chen, mentions that not rejecting such rejects can serve as a content smuggling vector and the current state of affairs would allow this code to print out "Joe owes €100." per
https://go.dev/play/p/wG5hidF_Uhh or inlined below

<details>

```go
package main

import (
	"io"
	"net/http"
	"strings"
)

func main() {
	req := &http.Request{
		Header: http.Header{"Content-Type": {`multipart/form-data; boundary=xxx`}},
		Body: io.NopCloser(strings.NewReader(`--xxx
Content-Disposition: form-data; name="file"
Content-Type: text/plain
content-transfer-encoding: quoted-printable

Joe owes =E2=82=AC100
--xxx--`)),
	}

	mr, err := req.MultipartReader()
	if err != nil {
		panic(err)
	}

	part, err := mr.NextPart()
	if err != nil {
		panic(err)
	}
	defer part.Close()
	blob, err := io.ReadAll(part)
	if err != nil {
		panic(err)
	}
	println(string(blob))
}
```
</details>
Repository: godot
Issue: Sync property of Animation Nodes only works with single Animation Nodes. More complex branches are stopped.
Labels: bug,confirmed,topic:animation

### Tested versions

Reproducible in Godot 4.3 Dev 5

### System information

Ubuntu 22.04

### Issue description

The sync property of Animation Nodes are supposed to let both connected branches to go on even at extreme blend amount values. However this only works if such branchs are single animation nodes. This does not work if a branch is more complex, e.g., has Blend2 or other connected nodes.
In the video, we can see that the Blend2 node sync option is enabled. The first connected branch has another blend2 node (Blend2 2). We can see that this first branch is stopped when setting the blend amount to 1 although the sync option is enabled.

This is a problem when trying to synchronize different animation trees, e.g., synchronizing camera and player animation trees.

https://github.com/godotengine/godot/assets/8985409/19d0217a-1d21-4e35-8ba7-dd96d5ad2336



### Steps to reproduce

Download the attached project and play with the Blend2 node values to the extremes.

### Minimal reproduction project (MRP)

[syncanimationnode.zip](https://github.com/godotengine/godot/files/14681144/syncanimationnode.zip)
Repository: ant-design
Issue: feat: add form item help render type
Labels: Inactive,unconfirmed

### What problem does this feature solve?

I want to use help feature as guide message for the input. but, when i use help props, I cant't see the validate error .
i want to use help and validate together.

### What does the proposed API look like?

https://github.com/ant-design/ant-design/pull/47753

i contribute about this issue, please check

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: deno
Issue: `node:fs` APIs are not actually using file descriptors
Labels: bug,node compat,node API

Version: upstream (2f7b9660)

`deno` seems to show a significant different behavior when it comes to accessibility of resources between main instance and workers. In `node` and `bun` you can open a file, send the file descriptor resp. RID to the worker and access its content in this other context. Using deno, you will get just an `BadResource` Error. The received RID isn't present in the resource table of the client.

Here a small demonstration script:
```js
import { isMainThread, parentPort, Worker } from "node:worker_threads";
import fs from "node:fs";


if (isMainThread) { // --- code running on the main instance ---
 
  // open a File in the contex if the Main Thread
  const fd = fs.openSync(import.meta.filename);

  globalThis.Deno && console.log("ResourceTable (Main):\n", Deno.resources());

  // run this script also as 'node:worker_thread'
  const w = new Worker(import.meta.filename);

  // send file descriptor to the worker side
  console.log(`Send open file RID: ${fd}`);
  w.postMessage(fd)

} else { // --- code running on the worker side ---

  // receive file descriptor and try to read file content
  parentPort.on("message", (msg) => {
    const received_fd = msg;
    console.log(`Received RID:  ${received_fd}`);

    globalThis.Deno && console.log("ResourceTable (Worker):\n", Deno.resources());

    fs.read(received_fd, (err, br, buf) => {
      if (err) {
        console.log(`ERROR: ${err}`)
      } else {
        console.log(`READ: ${br} bytes`)
      }

      // cleanup and exit worker
      globalThis.Deno ? close() : parentPort.unref();
    });
  });
}
```

the output using `deno`:
```sh
❯ ../deno/target/debug/deno run -A cross_realm_fd_reuse.mjs
ResourceTable (Main):
 { "0": "stdin", "1": "stdout", "2": "stderr", "3": "fsFile" }
Send open file RID: 3
Received RID:  3
ResourceTable (Worker):
 { "0": "stdin", "1": "stdout", "2": "stderr" }
ERROR: BadResource: Bad resource ID
```

on `node`:
```sh
❯ node cross_realm_fd_reuse.mjs
Send open file RID: 17
Received RID:  17
READ: 1133 bytes
```

and `bun`:
```sh
❯ /tmp/bun cross_realm_fd_reuse.mjs
Send open file RID: 12
Received RID:  12
READ: 1133 bytes
```

Although I understand `deno`s radical different answer in this case very well, because it helps to prevent all sort of thread related troubles, it's still a significant different behavior resp. incompatibility.

The `deno_core` docu states about `Resources`:
>Resources are not thread-safe - they can only be accessed from the thread that the JsRuntime lives on.

I'm not sure if this explanation inevitable applies to `node:worker_threads`, therefore I'm asking here, how we should work around this incompatibility?

Otherwise I would have to write rather complex adaptations for an existing software to bypass this differences in behavior (https://github.com/bytecodealliance/jco/issues/400).
Repository: godot
Issue: Crazy error with ENetMultiplayer
Labels: bug,needs testing,topic:multiplayer

### Tested versions

v4.2.2.rc1.official [c7fb0645a]

### System information

Windows 10/64 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 Desktop GPU (NVIDIA; 31.0.15.4633)

### Issue description

I have been having issues trying to get my multiplayer working, and have been battling many bugs. One bug is the garbled mess shown below. This is exactly as it comes from the console. Some errors are legible (as in not a crazy aztec language) but even the legible ones (ERROR: Condition "!pinfo" is true. Continuing.) confuse me. I can't narrow down what is causing them to apear.

My scene setup is pretty like this:
root
- World
- MultiplayerSpawner (only to spawn scenes under "Level")
- - Level
- - - Map1
- - - - Players
- - - - - 1 (server)
- -   - - - ServerSynchronizer (position, rotation, etc.)
- - - - - 1837827 (client) (same as server)
- - - - MultiplayerSpawner (Spawns everything in "Map1")
- - - - MultiplayerSpawner2 (Spawns only players in "Players")
- - - - etc. map stuff

```
ERROR: Condition "paproesnitt-i>ohans:_ n(o3d2e.(5n3a5m4e8),"  7i7s1 .t5r2u5e8.,  R-e2tu5r7.n0i0n4g4:)
ERR_INVALID_DATA
ERROR: ID 5 not found in cache of peer 1.
   at: (modules/multiplayer/scene_cache_interface.cpp:278)
ERROR: ID 6 not found in cpaocshiet iofo np:e e(r3 21..5
35 4 8 ,a t7:7 1(m.o5d2u5l8e,s /-2m5u7l.t0i0p4l4a)y
er/scene_cache_interface.cpp:278)
ERROR: ID 7 not found in cache of peer 1.
   at: (modules/multiplayer/scene_cache_interface.cpp:278)
ERROR: ID 8 not found in cache of peer 1.
   at: (modules/multiplayer/scene_cache_interface.cpp:278)
ERROR: ID 5 not found in cache of peer 1.
   at: (modules/multiplayer/scene_cache_interface.cpp:278)
ERROR: ID 6 not found in cache of peer 1.
   at: (modules/multiplayer/scene_cache_interface.cpp:278)
ERROR: ID 7 not found in cache of peer 1.
   atp:o s(itimoond:u l(e3s/2m.u5l3t5i4p8l,a y7e7r1/.s5c2e5n8e,_ c-a2c5h7e._0i0n4t4e)r
face.cpp:278)
ERROR: Condition "!pinfo" is true. Continuing.
   at: _remove_node_cache (modules/multiplayer/scene_cache_interface.cpp:57)
```

### Steps to reproduce

I don't know the exact steps to reproduce.

### Minimal reproduction project (MRP)

I was unable to create a small, simple reproduction of this bug, I don't know what is not working correctly, but I tried 10 different configurations.
Repository: vscode
Issue: [linked rename] Linked Editing does't work well
Labels: bug,editor-synced-region

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes
<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.87.2
- OS Version: macOS 14.3.1 (23D60)

Steps to Reproduce:

1. set up the linked editing option as true
2. crate an HTML tag with one or two attributes, like `<div class="main"></div>`
3. modify the name of the tag on the opening tag, you would find out that the closing tag is automatically deleted while not added automatically.
![2024-03-21 13 06 27](https://github.com/microsoft/vscode/assets/143488669/f408d9f6-cf90-4770-8bee-bda7a60b407f)
Repository: pytorch
Issue: DISABLED test_output_match_nn_functional_poisson_nll_loss_cpu_int32 (__main__.TORCH_NN_MODULECPU)
Labels: module: onnx,triaged,module: flaky-tests,skipped

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_output_match_nn_functional_poisson_nll_loss_cpu_int32&suite=TORCH_NN_MODULECPU&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/22912136700).

Over the past 3 hours, it has been determined flaky in 10 workflow(s) with 0 failures and 10 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_output_match_nn_functional_poisson_nll_loss_cpu_int32`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `onnx/test_fx_op_consistency/TestOnnxModelOutputConsistency_opset_version_18_model_type_TorchModelType.py` or `onnx/test_fx_op_consistency`

cc @clee2000
Repository: rust
Issue: Which functions are "reachable", and therefore subject to monomorphization-time checks, is optimization-dependent
Labels: T-compiler,C-bug,A-monomorphization

This is a variant of https://github.com/rust-lang/rust/issues/107503, but with a different underlying cause and hence not fixed by https://github.com/rust-lang/rust/pull/122568. @tmiasko provided this magnificent example (comments by me, they may be wrong):
```rust
//! This used to fail in optimized builds but pass in unoptimized builds. The reason is that in
//! optimized builds, `f` gets marked as cross-crate-inlineable, so the functions it calls become
//! reachable, and therefore `g` becomes a collection root. But in unoptimized builds, `g` is no
//! root, and the call to `g` disappears in an early `SimplifyCfg` before "mentioned items" are
//! gathered, so we never reach `g`.
#![crate_type = "lib"]

struct Fail<T>(T);
impl<T> Fail<T> {
    const C: () = panic!(); //~ERROR: evaluation of `Fail::<i32>::C` failed
}

pub fn f() {
    loop {}; g()
}

#[inline(never)]
fn g() {
    h::<i32>()
}

// Make sure we only use the faulty const in a generic function, or
// else it gets evaluated by some MIR pass.
fn h<T>() {
    Fail::<T>::C;
}
```

The symptom here is the opposite of https://github.com/rust-lang/rust/issues/107503: `cargo build` succeeds but `cargo build --release` fails. This is because *more* things become roots in optimized builds and therefore we evaluate more things.

I can think of two ways of fixing this:
- Making the set of collection roots opt-level-independent. This is what I tried in https://github.com/rust-lang/rust/commit/a303df006a5be15f799fdb9f987ac083f8de191d. It caused a ~2% slowdown on some benchmarks; it's hard to get the full picture as we only benchmarked it together with the rest of https://github.com/rust-lang/rust/pull/122568. There may be ways to reduce this cost.
- Make sure `g` is considered "mentioned" in `f`. This requires either collecting (some of) the mentioned items very early during MIR building, or making `SimplifyCfg` preserved unreachable blocks. This likely has lower perf impact, but it means we'd still miss const-eval failures reachable from dead private monomorphic functions.
Repository: PowerToys
Issue: PowerToys Run Calculator plugin Incorrectly displays results for 2 ^ 64
Labels: Issue-Bug,Product-PowerToys Run,Needs-Triage,Run-Plugin

### Microsoft PowerToys version

0.79.0

### Installation method

WinGet

### Running as admin

No

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

1. Open PowerToys Run
2. Enter 2 ^ 64
3. Observe result



The picture below show both the native calculator app and powertoys run in the same image

![IncorrectAns](https://github.com/microsoft/PowerToys/assets/155340932/898b46bb-69ff-426e-85ca-3882b86521d5)


### ✔️ Expected Behavior


The result should show 18446744073709551616

### ❌ Actual Behavior

The result shown is: 18446744073709600000

Note: You can also get incorrect answers by typing in 2^ 51, 2^ 52 ... etc

### Other Software

_No response_
Repository: godot
Issue: Soft Lock of editor when canceling a save dialog opened by Focus Lost flow.
Labels: bug,topic:editor,topic:input

### Tested versions

- Reproducible in: v4.2.1.stable.mono.official [b09f793f5]

### System information

Godot v4.2.1.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 (NVIDIA; 31.0.15.5176) - AMD Ryzen Threadripper 3960X 24-Core Processor (48 Threads)

### Issue description

When the Save On Focus Lost flow has to save an new file it will open the Save as dialog box, if you close that box you soft lock the editor.

### Steps to reproduce

Setup:
Have the Interface -> Editor -> Save on Focus Loss setting set to On

Steps:
1. Open a project
2. Add a new node
3. Click off of the editor to lose focus
4. Click `cancel` on the Save As dialog

Observations: 
The editor will no longer accept any input, but it does gain focus. You can see a repeated error in the Output tab when the editor loses focus the next time.

### Minimal reproduction project (MRP)

[SoftLock.zip](https://github.com/godotengine/godot/files/14691712/SoftLock.zip)

The project is empty but does reproduce the error with the given steps.
Repository: ui
Issue: [Bug]:When adding any element and the position of this element is at the top of the sheet or dialog box, then clicking on this element whose position is at the top of the page and then close the sheet or dialog close
Labels: bug

### Describe the bug

When adding any element and the position of this element is at the top of the sheet or dialog box, then clicking on this element whose position is at the top of the page and then close the sheet or dialog close
ex:
For example, when adding an error message to a toast when closing that toast  it closes to drag it directly closed sheet or dialog box

Or when adding a button in the top position 999 when the sheet or dialog box is open, it closes to drag it directly

### Affected component/components

sheet and dialog 

### How to reproduce

I've added two pictures to explain how I do
In the two images, you will find that the toast is above the sheet. When you click on it, the sheet closes automatically
I also put a Feedback button in the User Snap Library, and when you click on it, it closes the sheet immediately.
![Screenshot 2024-03-21 101001](https://github.com/shadcn-ui/ui/assets/96750484/add34bfb-262f-4377-807e-1a31aa05eca7)
![Screenshot 2024-03-21 101000](https://github.com/shadcn-ui/ui/assets/96750484/a873637f-bc04-44e1-8286-1e2da9c5caac)


### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
I am test on all OS mac and windows and Linux and test in fire fox and chrome
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: opencv
Issue: Possible bug / precision issue in normalize()
Labels: question (invalid tracker)

### System Information

OpenCV Python version: 4.8.1
Operating system: Windows 10
Python version: 3.12.0

### Detailed description

Results differ between OpenCV normalization and one made manually with numpy. Difference persists with float64 as well.

Another issue is that the maximum that the function outputs is larger than the beta parameter that is supplied.

### Steps to reproduce

Example code to reproduce:

```python
data = np.array([0, 1.4, 20.003, 103.9983, 240.2342, 15.9687195], dtype=np.float32)

norm_opencv = cv2.normalize(data, None, 0, 255, cv2.NORM_MINMAX)
norm_opencv = np.ravel(norm_opencv)
norm_numpy = (data - np.min(data)) / (np.max(data) - np.min(data)) * 255.0

print(norm_opencv)
print(norm_numpy)
print(np.max(np.abs(norm_opencv-norm_numpy)))
```

Output:
```
[  0.          1.4860499  21.232468  110.39047   255.00002    16.950224 ]
[  0.          1.4860498  21.232468  110.390465  255.         16.950224 ]
1.5258789e-05
```

Output when data is of type float64:
```
[  0.           1.48604986  21.23246815 110.39047105 255.  16.95022388]
[  0.           1.48604986  21.23246815 110.39047105 255.  16.95022388]
2.842170943040401e-14
```

### 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
- [ ] 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: opencv
Issue: Buildroot cross compile on Debian12 + ccache: fatal error: stdlib.h: No such file or directory 
Labels: bug,category: build/install

### System Information

Debian 12
Buildroot 2024.02 (Opencv 4.9.0)

Freshly installed Debian 12. Try to build with Builroot 2024.02 on imx8mm platform (cross compile). 
The same setup on older Debian works well.

### Detailed description

```
[ 29%] Building CXX object modules/core/CMakeFiles/opencv_core.dir/src/directx.cpp.o
In file included from /home/runner/buildroot-2024.02/output/host/opt/ext-toolchain/aarch64-none-linux-gnu/include/c++/13.2.1/bits/stl_algo.h:71,
                 from /home/runner/buildroot-2024.02/output/host/opt/ext-toolchain/aarch64-none-linux-gnu/include/c++/13.2.1/algorithm:61,
                 from /home/runner/buildroot-2024.02/output/build/opencv4-4.9.0/modules/core/include/opencv2/core/base.hpp:55,
                 from /home/runner/buildroot-2024.02/output/build/opencv4-4.9.0/modules/core/include/opencv2/core/utils/buffer_area.private.hpp:7,
                 from /home/runner/buildroot-2024.02/output/build/opencv4-4.9.0/modules/core/src/buffer_area.cpp:5:
/home/runner/buildroot-2024.02/output/host/opt/ext-toolchain/aarch64-none-linux-gnu/include/c++/13.2.1/cstdlib:79:15: fatal error: stdlib.h: No such file or directory
   79 | #include_next <stdlib.h>
      |               ^~~~~~~~~~
compilation terminated.
```

### Steps to reproduce

Minimum scenario to reproduce:

Download and unpack: `buildroot-2024.02.tar.gz`

Go to BR dir.

```bash
make freescale_imx8mmevk_defconfig

./utils/config --enable CCACHE

./utils/config --enable TOOLCHAIN_EXTERNAL

./utils/config --enable PACKAGE_OPENCV4

./utils/config --enable PACKAGE_OPENCV4_WITH_TBB

make olddefconfig

make opencv4
```


### 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
- [ ] 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: godot
Issue: Hover on texture button has a "random" work
Labels: needs testing,topic:gui

### Tested versions

Godot 4.2.1 Mac version

### System information

My configuration is : * Mac mini (late 2014) * Processeur 2,6 Gaz Intel Core i5 * memory : 8 Go 1600Mhz DDR3 * graphic card : Intel Iris 1536 Mo * SSD : 800 Go

### Issue description

Hover texture button work well in a simple project but is inconsistent in bigger project. Sometime work and without changing code don't work (even if the button is lauch in single scene). It works again one time when I make a transitory "change" (ex : select pressed and deselect pressed) in the editor and don't work in the next run scene. Using the signals I see that it don't respond to mouse_exit or mouse_enter, but respond to button_pressed and detect mouse move in the input. I test my project on a PC and every thing works fine. It seems to be a bug mac specific...

### Steps to reproduce

Texture button in a "big" project...

### Minimal reproduction project (MRP)

Minimal project work fine