sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Overflow evaluating the requirement when adding const generic bound
Labels: T-compiler,C-bug,A-const-generics

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
use std::{ops::Mul};

struct Quantity<S, const D: usize>(S);

impl<const D: usize, S> Mul<Quantity<S, D>> for f32
where
    f32: Mul<S>,
    Quantity<<f32 as Mul<S>>::Output, D>:
{
    type Output = Quantity<<f32 as Mul<S>>::Output, { D }>;
    fn mul(self, rhs: Quantity<S, D>) -> Self::Output {
        Quantity(self * rhs.0)
    }
}
```
I realize that the second trait bound for the const generic is unnecessary here. I needed it in the code I originally wanted to write (where I had a const expr in its place), but writing it this way got me to reproduce this bug on stable and without needing `generic_const_exprs`.

I expected it to compile. Instead, I get 
```
error[E0275]: overflow evaluating the requirement `f32: Mul<Quantity<_, _>>`
```

It compiles fine without the additional bound:
```rust
use std::{ops::Mul};

struct Quantity<S, const D: usize>(S);

impl<const D: usize, S> Mul<Quantity<S, D>> for f32
where
    f32: Mul<S>,
{
    type Output = Quantity<<f32 as Mul<S>>::Output, { D }>;
    fn mul(self, rhs: Quantity<S, D>) -> Self::Output {
        Quantity(self * rhs.0)
    }
}
```

This seemed similar to https://github.com/rust-lang/rust/issues/79807 but I do not run into the same error if I replace the bound by `<f32 as Mul<S>>::Output: Copy` , for example.

As a side comment, a way to get the code to compile with the const generic trait bound is to write something like `Quantity<(), D>:` or even `Quantity<Vec<Vec<String>>, D>:`. It doesn't seem to matter at all what the first generic of `Quantity` is, which was very confusing to me - if the compiler only cares about the const expr evaluating, then why does that need to be expressed in a bound on `Quantity` and not in a more direct way? 

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: x86_64-unknown-linux-gnu
release: 1.75.0
LLVM version: 17.0.6
```

and on nightly:
```

rustc 1.77.0-nightly (d6d7a9386 2023-12-22)
binary: rustc
commit-hash: d6d7a93866f2ffcfb51828b8859bdad760b54ce0
commit-date: 2023-12-22
host: x86_64-unknown-linux-gnu
release: 1.77.0-nightly
LLVM version: 17.0.6
```
Repository: godot
Issue: tscn created from gltf - in editor node strangeness
Labels: needs testing,topic:import,topic:3d

### Tested versions

4.1.3.stable

### System information

Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 Laptop GPU (NVIDIA; 31.0.15.3713) - 13th Gen Intel(R) Core(TM) i7-13700HX (24 Threads)

### Issue description

Something not right in editor ; unsure how to describe (see images : gltf nodes change color)

. scene 1st opening

![gltf_tscn_1st_open](https://github.com/godotengine/godot/assets/59080934/2dbaf7b6-e3ba-44f7-bb80-c37a5d05cbec)

. after adding a node

![gltf_tscn_adding_node](https://github.com/godotengine/godot/assets/59080934/630ce63b-f17c-445c-bda3-a9dd8ab0710b)

. after switching back from another scene

![gltf_tscn_switchingto_otherscene](https://github.com/godotengine/godot/assets/59080934/7068238a-c9b3-4226-918b-5e27c8bba699)

### Steps to reproduce

Import a gltf file, select gltf file -> right click -> create instance -> save as tscn.
Open tscn -> add a node to the tree -> switch to another opened scene -> switch back.



### Minimal reproduction project (MRP)

/
Repository: godot
Issue: UDPServer.is_connection_available() UDPServer.take_connection() print existent peer as non-existent peers
Labels: bug,needs testing,topic:network

### Tested versions

v4.2.1.stable.official and v4.1.2.stable.official

### System information

Linux Ubuntu Server 22.04 and Windows 10

### Issue description

My server is spamming that a new player is connected, but in fact the old player is just sending data.
![image](https://github.com/godotengine/godot/assets/81353415/1a8ec019-849b-4ba6-9c35-2b7755b98252)


### Steps to reproduce

1. open router 3568 port for computer's IP
2. start backend on this machine.
3. send some packets to this server from another client (I will attach only the backend project, the folder with the frontend is very large)
Conclusion: every time there is a new peer in backend console

### Minimal reproduction project (MRP)

[back.zip](https://github.com/godotengine/godot/files/13853600/back.zip)
Repository: godot
Issue: C# .Dispose() should free the object from memory
Labels: discussion,topic:dotnet

### Tested versions

-Reproducible in: Godot 4.2.1 Mono

### System information

Godot v4.2.1.stable.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2080 Ti (NVIDIA; 31.0.15.3770) - Intel(R) Core(TM) i9-9900 CPU @ 3.10GHz (16 Threads)

### Issue description

On some godot objects such as TreeItem calling .Dispose() on them does not free them from memory but makes you unable to call any further methods on the item. So you can not even call .Free() to free the item from memory thus creating a memory leak.

In my use case I am filtering a tree by removing certain tree items. I wanted to free these from memory so I used the standard C# way of doing so by calling .Dispose() but this caused memory leaks. You can fix this by calling .Free() instead, however since TreeItem has the .Dispose() method I would assume this would free it from memory as that is normally the case in C#.

I think the best solution here is to make .Dispose() work as you would expect in C# and have it internally call Free() to free up the object. Either that or do not offer .Dispose() as an option at all, in C# you would expect that if an object is disposable then calling .Dispose() will completely dispose of the object from memory.

Unless I am missing something here, with the current implementation, is there any circumstance in which I would want to call .Dispose() on a TreeItem myself? To me it seems like there would never be such a use case.

### Steps to reproduce

Here is some C# code that will cause leaks. Removing the dispose will allow you to free the children as expected.
```
Tree tree = FindChild("Tree") as Tree;
tree.Clear();

tree.Columns = 1;
tree.SetColumnTitle(0, "Name");

var root = tree.CreateItem(null);
root.SetText(0, "Root");
for (int i = 0; i < 10; i++)
{
    var child = tree.CreateItem(root);
    child.SetText(0, $"Child {i}");

    root.RemoveChild(child);
    child.Dispose(); // You now have a memory leak
    child.Free(); // Does not work after dispose
}
```

### Minimal reproduction project (MRP)

[DisposeIssue.zip](https://github.com/godotengine/godot/files/13853805/DisposeIssue.zip)
Repository: rust
Issue: Clarification needed on what happens when `Future::poll` wakes an old waker
Labels: A-docs,A-async-await,AsyncAwait-Triaged,T-libs,WG-async,I-async-nominated

### Location

https://doc.rust-lang.org/std/future/trait.Future.html#tymethod.poll

### Summary

The documentation for `Future::poll` reads:

> Note that on multiple calls to `poll`, only the `Waker` from the `Context` passed to the most recent call should be scheduled to receive a wakeup.

The implications of violating this aren’t specified. One might conclude that it is a bug to wake both the old and new wakers, as it says **only** the new one should be used. On the other hand, it says “should”, not “must”.

Note that there is no way to avoid waking both wakers in certain cases. See for instance the answer to [In async Rust, how can a Future make sure it only calls the most recent Waker?][race hazard], which reads:

> This may cause the old waker to be woken unnecessarily, but that's fine.

I believe the intent of this requirement for `poll` is that there is no guarantee waking old wakers has any effect, but it is not a bug to wake them in addition to waking the most recent one. Is that correct? If so we may want to clarify this, preferably replacing the word “should” with something more concrete.

[race hazard]: https://stackoverflow.com/questions/75959786/in-async-rust-how-can-a-future-make-sure-it-only-calls-the-most-recent-waker
Repository: next.js
Issue: Form Action Set to JavaScript Throw Statement in Dynamically Displayed Form Element
Labels: bug

### Link to the code that reproduces this issue

https://github.com/pini85/form-action-bug-next-js-14

### To Reproduce

1. Start the application using next dev.
2. Click a button to dynamically display a form component.
3. Inspect the form element using browser developer tools.
4. Observe that the form's action attribute is set to javascript:throw new Error(...).

### Current vs. Expected behavior

Expected the form's action attribute to be set correctly. However, the developer tools show the action attribute set to a JavaScript throw statement, indicating an unexpected handling of the form action in dynamically displayed components

### Verify canary release

- [x] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:28:12 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T8103
Binaries:
  Node: 18.17.0
  npm: 9.6.7
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.0.5-canary.42
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: N/A
Next.js Config:
  output: N/A
```


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

App Router

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

next dev (local), next build (local), next start (local), Vercel (Deployed)

### Additional context

_No response_
Repository: godot
Issue: AudioStream's internal `get_stream_name` seems to be entirely unused, rendering `_get_stream_name` pointless.
Labels: bug,topic:audio

### Tested versions

Starting from 4.0

### System information

Windows 10

### Issue description

Opening this issue before doing something hasty.

In the source code, it seems like **AudioStream**'s `get_stream_name` is overridden properly for almost every inherited **AudioStream** type. However, outside of the tests, this method is not ever actually called.

This also makes the exposed, overridable method `_get_stream_name` entirely pointless, as the returned name is not ever used for anything.


The simplest solution to this issue is to expose `get_stream_name`.[^1] The "bad ending" involves deprecating the method outright.

### Steps to reproduce

This requires a look at the source code. Find every reference of `get_stream_name`. Every mention is an appropriate override of the original, but it is never called for any actual purpose.

### Minimal reproduction project (MRP)

No need.


[^1]: Can we, like, stop exposing methods without making sure they're actually useful for something? Please? I'm so peeved about this. "Undocumented" may as well be "not ever utilized" and by extension, engine bloat!
Repository: ollama
Issue: Add Modelfile Linter
Labels: feature request

Similar to [Hadolint](https://github.com/hadolint/hadolint). Ideally, Ollama could provide a pre-commit hook that lints a Modefile and accepts args and a lint config file.
Repository: Web-Dev-For-Beginners
Issue: Adding Roadmap.md would help
Labels: no-issue-activity

This is my request for Roadmap which would help new ones to opt for this course without hesitation. I guess there doesn't exist anything like this, I know there is what you will learn section in Readme but having an seperate Roadmap.md file with checkboxes and course summary would actually help in recording the progress of learners. Hope I was correct in this thought. If I'm wrong correct me, I may have mistaken the reason for not having that.... Learning from expert would help me in way of thinking....

Thank you
Repository: PowerToys
Issue: Will not change "case" of file names
Labels: Issue-Bug,Product-PowerRename,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.76.2

### Installation method

Microsoft Store

### Running as admin

None

### Area(s) with issue?

PowerRename

### Steps to reproduce

select a file or files with capital letters, for example ABCD.pdf
then lets say you click powerrename and then simply click on the lowercase letter formatting, the display preview on the right of the app will show the files to be renamed as "abcd.pdf", but then run and the files are still ABCD.pdf

### ✔️ Expected Behavior

file names should be "abcd.pdf" as shown in the preview on the app

### ❌ Actual Behavior

file remains as "ABCD.pdf"

### Other Software

_No response_
Repository: next.js
Issue: Partial Pre-rendering shows an skeleton (via supsense fallback) from another page
Labels: bug

### Link to the code that reproduces this issue

https://github.com/peibolsang/octotype-site/tree/feature/ppr

### To Reproduce

I have a Preview deployment ready to reproduce: https://octotype-git-feature-ppr-peibolsang.vercel.app

This deployment has PPR enabled and uses RSC and Suspense with skeleton fallbacks.

1. Go to the URL and then navigate to a Blog post from `peibolsang` (any blog post)
2. click `octotype` in the header, which takes you to the main screen.
3. A weird skeleton is displayed while the page is being loaded. First, the skeleton does not correspond to the home page (`app/page.tsx`). It corresponds to the user's home page (`app/[user]/page.tsx`). Second, you can see there is a `__index` text rendered,d which I don't know where it comes from.

If you are not able to reproduce it in the first instance, do a few navigations until you can see it. I have attached a video that reproduces this error.

Note this error does not happen with the same source code but `ppr=false` in `next.config.js`

https://github.com/vercel/next.js/assets/3844521/a89b2041-346f-45cf-98bb-f3282938cd44



### Current vs. Expected behavior

**Current Behaviour**

1. Go to the URL and then navigate to a Blog post from `peibolsang` (any blog post)
2. click `octotype` in the header, which takes you to the main screen.
3. A weird skeleton is displayed while the page is being loaded. First, the skeleton does not correspond to the home page (`app/page.tsx`). It corresponds to the user's home page (`app/[user]/page.tsx`). Second, you can see there is a `__index` text rendered,d which I don't know where it comes from.

**Expected Behaviour**
(Same as when setting `ppr=false`)
1. When navigating back from a blog post to the main page, the right skeleton is shown for `app/page.tsx`  and no `__index` text is rendered

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
- This issue happens after deploying on vercel.com
- This issue didn't happen locally with npm run dev and PPR=true. 

Local machine specs:
- macOS venture 13.6.2
- M1 processor
- Node.js v21.4.0
- NPM v10.2.4
- Next.js v14.0.5-canary.36
```


### Which area(s) are affected? (Select all that apply)

area: data fetching

### Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

### Additional context

_No response_
Repository: deno
Issue: LSP too slow
Labels: perf,lsp

When I’m trying to work on [this project](https://github.com/MTKruto/MTKruto), deno lsp’s memory usage grows up to 1.5 GB in a short amount of time, and IntelliSense, auto-complete, and pretty much everything is getting way slow.

Version: 1.39.1
Repository: PowerToys
Issue: Color Picker | Uninterrupted continuous color picking with the use of a modifier key.
Labels: Idea-Enhancement,Product-Color Picker

### Description of the new feature / enhancement

Hey! 
Firstly I have to convey my appreciation for the awesome work that everyone of you all that are creating this unique, super useful power tool for us nerds are doing. PowerToys in this second incarnation has reached an impressive level of maturity. With it today offering what I truly see as an indispensable tool kit no serious, 🤔 nor unserious Windows user for that matter should, or as in my case can be without. I was really delighted when this project was launched as I've used PowerToys since the Windows 95 days and used it on subsequent Windows releases until it's development ended. PowerToys always offered features and functions that were sorely missing from the OS or it offered further tweaks and configs to improve user experiences.
Which is to say, I thank you all for your work and where you've taken this project and it's really encouraging to see that PowerToys keeps growing and expanding and/or enhancing its feature set in the way that it has.
With that said.

When using Color Picker it would be very useful to be able to continuously keep pick colors without having to reactivate the action with the hotkeys. With the use of a modifier like CTRL then instead of instantly opening the editor as how I've got it configured after picking a color now, I can keep picking those three different color picks or however many, until the release of the CTRL key only then does the editor open.

I could even imagine ove being able to, when using the great zoom function with the Color Picker if one holds left click as an example or if SHIFT is held down you can use the mouse selection function where all the colors inside the selection are picked. However I can also imagine this being a bit more time consuming to implement. Although that's just my assumption as unfortunately I can't code :-(.

### Scenario when this would be used?

When using the color picker with the Color Picker function.

### Supporting information

I don't know how or why the Needs-Triage label was added as it most surely does not.
Repository: rust
Issue: fire debug assertion when `expected` and `found` item look the same in diagnostic?
Labels: A-diagnostics,A-lifetimes,T-compiler,D-confusing

Sometimes rustc outputs silly error hints like
```
   = note: expected trait `for<'a> <for<'a> fn(&'a u32) -> &'a u32 {function2} as FnOnce<(&'a u32,)>>`
              found trait `for<'a> <for<'a> fn(&'a u32) -> &'a u32 {function2} as FnOnce<(&'a u32,)>>`
```

where "expected" and "found" look like they are the same which is quite unhelpful.
(example from https://github.com/rust-lang/rust/issues/114883 ) 

I wonder if we should have a debug assertion in these cases (rustc displaying both types being identical although they shouldn't be) that helps catch these kid of diagnostic mishaps, similar to the "span must not be empty and have no suggestion" and "span must not have overlapping parts" debug assertions.
Repository: godot
Issue: SubViewport with `CLEAR_MODE_NEVER` does not render when using Compatibility renderer
Labels: bug,topic:rendering

### Tested versions

Reproducible in: 4.1.3.stable, 4.2.1.stable, 4.3.dev1

### System information

Ubuntu 22.04.3 LTS 22.04 - X11 - GLES3 (Compatibility) - NVIDIA GeForce RTX 2060 with Max-Q Design () - AMD Ryzen 9 4900HS with Radeon Graphics (16 Threads)

### Issue description

A `SubViewport` with `render_target_clear_mode` set to `CLEAR_MODE_NEVER` does not render anything, when using the Compatibility (GLES3) renderer.

### Steps to reproduce

Run the attached MRP. Observe that it does not render anything.

Changing the Clear Mode to Always or Next Frame makes it render something, and so does changing the renderer to Mobile or Forward+.

### Minimal reproduction project (MRP)

[poisson-disk-sampling.zip](https://github.com/godotengine/godot/files/13854937/poisson-disk-sampling.zip)
Repository: opencv
Issue: OpenCV core shared library load speed is extremely slow
Labels: bug

### System Information

Operating System / Platform: Ubuntu 20.04
Operating System / Platform: Windows 10
Operating System / Platform: MacOS Monterey

Have tried all sorts of OS. 
Have tried both pre built versions of OpenCV and building myself. 
Have tried release and non optimized builds.

### Detailed description

Simply loading the OpenCV core library is slow in all programming languages. 
Even though the dll/dylib is only 3MB, it takes as much as 200ms to load it. 
This is very unusual as other libraries that are over 10MB take 0-1ms.

This load speed is very important for use case such in mobile apps. 
I understand OpenCV is feature complex, so, I have isolated it to just the core. Many uses of OpenCV only involve resizing of images, so it would be beneficial to understand why simply loading it takes so long.

I have attached an example dylib that was compiled on my M1 Macbook.
[libopencv_core.4.9.0.dylib.zip](https://github.com/opencv/opencv/files/13854941/libopencv_core.4.9.0.dylib.zip)

### Steps to reproduce

```java
System.load("path_to_dll_or_dylib");
```

You can load it any way you like in any programming language. It will be the same.

### 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: rust
Issue: Resolving remaining concerns with `Pin` docs
Labels: C-enhancement,T-libs-api,A-docs,T-libs

https://github.com/rust-lang/rust/pull/116129 was landed with some outstanding concerns, since it was considered to be an improvement over the status quo despite those concerns. Would be good to further improve the docs and resolve those concerns. :)  The text also changed a bit since the concerns were originally raised, so we have to re-evaluate if they still apply.

1. [This thread](https://github.com/rust-lang/rust/pull/116129#discussion_r1367728065) is about the concern that the description of `Unpin` focuses too much on describing the effects of `!Unpin` rather than `Unpin`.
2. [This thread](https://github.com/rust-lang/rust/pull/116129#discussion_r1367933947) is about the docs basically re-telling the story of how we arrived at `Pin`, with various twists and turns, which might not be the best way to explain how to work with the final design. The historical part should possibly be moved further down in the docs.
3. [This thread](https://github.com/rust-lang/rust/pull/116129#discussion_r1443987317) is about the interaction of structural pinning and `Unpin`.
4. [This thread](https://github.com/rust-lang/rust/pull/116129#discussion_r1443987088) is about the claim that `Unpin` types will "not expose nor rely on any pinning guarantees", which is not quite correct.
5. [This thread](https://github.com/rust-lang/rust/pull/116129#discussion_r1348707507) is about the "pinboard" analogy not being evocative or necessarily very useful.