sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: UI test `multiple-reprs` fails on targets that set `c-enum-min-bits`
Labels: A-testsuite,T-compiler,C-bug

[This part of the test](https://github.com/rust-lang/rust/blob/b5741a36a897dd93936d31ea0c1688f1399a2e06/tests/ui/structs-enums/multiple-reprs.rs#L72) assumes that the enum's discriminant has a size of `c_int` which is true for most targets but not for targets that set [`TargetOptions.c_enum_min_bits`](https://github.com/rust-lang/rust/blob/b5741a36a897dd93936d31ea0c1688f1399a2e06/compiler/rustc_target/src/spec/base/thumb.rs#L56) like `thumbv7em-none-eabihf`. The `multiple-reprs` test fails when run on those target.

affected revision: b5741a36a897dd93936d31ea0c1688f1399a2e06

I'll submit a PR fixing the test on those targets shortly
Repository: PowerToys
Issue: [ARM64] EXception 0xD0000701 - PowerToys Run crashing while computer is idle
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

No perceptible steps - Error happens while computer is idle



[2025-01-16.txt](https://github.com/user-attachments/files/18479814/2025-01-16.txt)
[2025-01-17.txt](https://github.com/user-attachments/files/18479817/2025-01-17.txt)
[2025-01-18.txt](https://github.com/user-attachments/files/18479816/2025-01-18.txt)
[2025-01-19.txt](https://github.com/user-attachments/files/18479813/2025-01-19.txt)
[2025-01-20.txt](https://github.com/user-attachments/files/18479815/2025-01-20.txt)

### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: neovim
Issue: Don't include non-essential paths in runtimepath with `nvim --clean`
Labels: defaults,runtime,core,startup

### Problem

Apart from paths coming from `CMAKE_INSTALL_PREFIX`, my `rtp` value contains also (on Debian Sid)
```
/etc/xdg/nvim
/etc/xdg/nvim/after
/usr/local/share/nvim/site
/usr/local/share/nvim/site/after
/usr/share/gnome/nvim/site
/usr/share/gnome/nvim/site/after
/usr/share/nvim/site
/usr/share/nvim/site/after
```
when I run `nvim --clean` and have `CMAKE_EXTRA_FLAGS="-DCMAKE_INSTALL_PREFIX=${HOME}/tmp/nvim/builds/from-src"` used to build and install Nvim. 

### Steps to reproduce

- build and install Nvim with `CMAKE_EXTRA_FLAGS="-DCMAKE_INSTALL_PREFIX=${HOME}/tmp/nvim/builds/from-src"` (or another path under home directory).
- create `/usr/local/share/nvim/site/plugin/echo.lua` with `print('System-wide plugin here!')`
- run `${HOME}/tmp/nvim/builds/from-src/bin/nvim --clean --headless -c q` and see the output. 

### Expected behavior

`rtp` consists only of paths under $CMAKE_INSTALL_PREFIX (or its default equivalent, when empty). 

### Nvim version (nvim -v)

v0.11.0-dev-1565+g43f4290bc6

### Vim (not Nvim) behaves the same?

no, vim --clean does not try to include "not prefixed" paths to rtp

### Operating system/version

Debian Sid

### Terminal name/version

alacritty 0.16.0-dev (c9c41e63)

### $TERM environment variable

alacritty

### Installation

from repo
Repository: ollama
Issue: Support for num_beam and Advanced Decoding Parameters
Labels: feature request

Thanks for creating Ollama. It’s been great getting models up and running quickly. As someone working on developing an LLM, I’d love to see support for advanced decoding parameters like num_beam. It would be very useful for fine-tuning the output. Right now, it seems a little limiting, and being able to tweak the settings. 

> 

>
Repository: godot
Issue: LSP rename of class_name also changes node path
Labels: bug,topic:gdscript

### Tested versions

4.3.stable.arch_linux


### System information

Godot v4.3.stable unknown - Arch Linux #1 SMP PREEMPT_DYNAMIC Sat, 18 Jan 2025 02:26:57 +0000 - Wayland - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 (nvidia; 565.77) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

Child.gd:

```gdscript
extends Node3D
class_name Child
```

Parent.gd:
```gdscript
extends Node3D

@onready var child: Child = $Child
```

In Child.gd, position the cursor over `Child` and request a lsp rename action. Change the name to `Other`.
This changes Parent.gd to:

```gdscript
extends Node3D

@onready var child: Other = $Other
```

It should have changed to:
```gdscript
extends Node3D

@onready var child: Other = $Child
```

Renaming a class in gdscript does not imply you changed the node path.


### Steps to reproduce

Open the example project, use a LSP to rename `Child` to `Other`

### Minimal reproduction project (MRP)

[example.zip](https://github.com/user-attachments/files/18480232/example.zip)
Repository: PowerToys
Issue: Crash After Sleeping For Weekend
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.86.0

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

Awake

### Steps to reproduce

Computer slept over the weekend at work.
Move mouse to awake, 




### ✔️ Expected Behavior

To have it wake without issues.

### ❌ Actual Behavior

When move mouse to awaken.
Shows all my window borders with XP grey colors.
And multiple error pop-ups

[2025-01-20.txt](https://github.com/user-attachments/files/18480481/2025-01-20.txt)

### Other Software

_No response_
Repository: storybook
Issue: [Bug]: A11y addon with `manual: true` gets stuck in loading state
Labels: bug,has workaround,addon: a11y,upgrade:8.5

### Describe the bug

When the A11y addon is configured with `manual: true` it does not work anymore.
The UI got stuck in the loading state with the message:
> Please wait while the accessibility scan is running

### Reproduction link

https://stackblitz.com/edit/github-h1gyzzpc-ab5abiso?file=.storybook%2Fpreview.ts&preset=node

### Reproduction steps

* Go to the Button Primary story
* Switch to the Accessibility tab

### System

```bash
Storybook Environment Info:

  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn <----- active
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @storybook/addon-a11y: ^8.5.0 => 8.5.0 
    @storybook/addon-essentials: ^8.5.0 => 8.5.0 
    @storybook/blocks: ^8.5.0 => 8.5.0 
    @storybook/test: ^8.5.0 => 8.5.0 
    @storybook/web-components: ^8.5.0 => 8.5.0 
    @storybook/web-components-vite: ^8.5.0 => 8.5.0 
    storybook: ^8.5.0 => 8.5.0
```

### Additional context

_No response_
Repository: vscode
Issue: Support for Single-Line Comments with Custom Endings
Labels: feature-request

<!-- ⚠️⚠️ 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.96.4
- OS Version: macOS 15.2

Currently, Visual Studio Code does not natively support single-line comments with custom endings. This limitation affects the ability to properly handle comment syntax in certain templating languages, such as Django HTML, where single-line comments are enclosed with {# at the beginning and #} at the end.

In the configuration file, it is not possible to specify lineComment as:
```json
"lineComment": [
    "{#",
    "#}"
]
```

Instead, it must be specified as:
```json
"lineComment": "{#"
```

Steps to Reproduce:

Create a file with Django HTML syntax.
Attempt to use single-line comments with {# at the beginning and #} at the end.
Notice that the comments are not handled correctly by the editor.

**Expected Behavior:**

Visual Studio Code should support single-line comments with custom endings, allowing for proper handling of comment syntax in templating languages like Django HTML.

**Actual Behavior:**

Visual Studio Code does not support single-line comments with custom endings, leading to incorrect handling of comments in templating languages.

**Example:**
```django-html
{# This is a single-line comment #}
```

**Additional Context:**

This feature would greatly improve the development experience for users working with templating languages that use custom comment syntax.
Repository: electron
Issue: Add "saveImageAt" and "copyImageAt" methods to "WebFrameMain" API
Labels: enhancement :sparkles:,component/webframe

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

It would be beneficial to add context menu items to save images in Electron applications. This is currently not directly supported in the Electron API, which limits the functionality developers can offer to users in terms of image handling.

### Proposed Solution

Introduce two new methods, `WebFrameMain.saveImageAt(x, y)` and `WebFrameMain.copyImageAt(x, y)`, in the Electron API. These methods should internally call the corresponding methods in Chromium's `content::RenderFrameHost` class to enable saving and copying images directly from the application interface.


### Alternatives Considered

An alternative approach would be to implement this functionality manually using existing web technologies, but this could lead to inconsistent implementations and increased complexity for developers who need to implement this feature across different applications.


### Additional Information

Chromium has a C++ class called `content::RenderFrameHost` which contains the functionality required for this feature:
[Chromium Source](https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/render_frame_host.h;l=617-627;drc=61a5359d2a66fc8484ddcad5d7384c98e753f0da)

Electron's `WebFrameMain` API is a JavaScript abstraction of `RenderFrameHost`. By adding `saveImageAt` and `copyImageAt` methods to `WebFrameMain`, developers can easily integrate image saving and copying features into their Electron applications.

**References:**
- [Electron WebFrameMain API Source](https://github.com/electron/electron/blob/main/shell/browser/api/electron_api_web_frame_main.cc)

Adding these methods would allow developers to create context menu items for saving and copying images, enhancing the functionality of Electron-based applications.
Repository: rust
Issue: Binary operators still have worse trait error information than their corrosponding operators.
Labels: A-diagnostics,T-compiler

### Code

```Rust
struct Whatever;

fn main() {
    let _ = Some([1, 2].into_iter()) == &Some([1, 2].into_iter());
}
```

### Current output

```Shell
error[E0369]: binary operation `==` cannot be applied to type `Option<std::array::IntoIter<{integer}, 2>>`
   --> src/main.rs:4:38
    |
4   |     let _ = Some([1, 2].into_iter()) == &Some([1, 2].into_iter());
    |             ------------------------ ^^ ------------------------- &Option<std::array::IntoIter<{integer}, 2>>
    |             |
    |             Option<std::array::IntoIter<{integer}, 2>>
    |
note: the foreign item type `Option<std::array::IntoIter<{integer}, 2>>` doesn't implement `PartialEq<&Option<std::array::IntoIter<{integer}, 2>>>`
   --> /playground/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/option.rs:572:1
    |
572 | pub enum Option<T> {
    | ^^^^^^^^^^^^^^^^^^ not implement `PartialEq<&Option<std::array::IntoIter<{integer}, 2>>>`

For more information about this error, try `rustc --explain E0369`.
```

### Desired output

```Shell
error[E0369]: binary operation `==` cannot be applied to type `Option<std::array::IntoIter<{integer}, 2>>`
   --> src/main.rs:4:38
    |
4   |     let _ = Some([1, 2].into_iter()) == &Some([1, 2].into_iter());
    |             ------------------------ ^^ ------------------------- &Option<std::array::IntoIter<{integer}, 2>>
    |             |
    |             Option<std::array::IntoIter<{integer}, 2>>
    |
    |
    = note: the following trait bounds were not satisfied:
             `std::array::IntoIter<{integer}, 2>: PartialEq`
             which is required by `Option<std::array::IntoIter<{integer}, 2>>: PartialEq`
             `Option<std::array::IntoIter<{integer}, 2>>: Iterator`
             which is required by `&mut Option<std::array::IntoIter<{integer}, 2>>: Iterator`

For more information about this error, try `rustc --explain E0369`.
```

### Rationale and extra context

compare to this code:
```rust
struct Whatever;

fn main() {
    let _ = Some([1, 2].into_iter()).eq(&Some([1, 2].into_iter()));
}
```

that gives the exact trait bounds that were not satisfied (in particular, iterators over arrays do not implement PartialEq).

this isn't the most realistic case, but i wanted to repro it without external dependencies, and there's a different diagnostic that triggers if the type is defined in the same crate as the error.

### Other cases

```Rust
this diagnostic should fire whenever there is a type whose ability to implement a trait is dependent on one of its type variables implementing a trait.
```

### Rust Version

```Shell
rustc 1.85.0-nightly (7442931d4 2024-11-30)
```

### Anything else?

related to https://github.com/rust-lang/rust/issues/125631

this time it would be nice if the logic could be unified somehow.
Repository: deno
Issue: use  `Object.defineProperty` to tamper `Uint8Array`.
Labels: question

Version: Deno x.x.x

Hi, I would like to report a bug. The code below shows that `Unit8Array` properties, such as `length`, can be tampered with.

```javascript

var desc = {
  get: function getLen() {
    return 0;
  }
};

Object.defineProperty(Object.getPrototypeOf(Uint8Array).prototype, "length", desc);

const uint8 = new Uint8Array(2);
uint8[0] = 42;
console.log(uint8[0]); // 42
console.log(uint8.length); // it should give 2, but it gives 0. 
```


The bug would be triggered especially when we use a standard function of Deno: encoding/hex

```javascript 
var desc = {
  get: function getLen() {
    return 0;
  }
};

Object.defineProperty(Object.getPrototypeOf(Uint8Array).prototype, "length", desc);

import { crypto } from "jsr:@std/crypto";
import { encodeHex } from "jsr:@std/encoding/hex";
const readableStream = new TextEncoder().encode("test");


const hashBuffer = await crypto.subtle.digest("SHA-1", readableStream);

const hash = encodeHex(hashBuffer);
console.log("fileHash: ", hash.length, "HashBuffer: ", hashBuffer); //node does not affect the equivalent snippet using 'crypto' pkg. 
```

By running the code above, the output would be an empty string based on tampering `length` property of `Uint8Array`. 

Regards, 

AH
Repository: godot
Issue: Some DirectionalLight2D and PointLight2Ds are incorrectly rendered on Direct3D 12
Labels: bug,platform:windows,topic:rendering,topic:2d

### Tested versions

- Reproducible in: 4.3.stable, 4.4.beta1, 4.4.beta 791c87eb7

### System information

Godot v4.4.beta (791c87eb7) - Windows 11 (build 22631) - Multi-window, 1 monitor - Direct3D 12 (Forward+) - dedicated NVIDIA GeForce RTX 4090 (NVIDIA; 32.0.15.6636) - 13th Gen Intel(R) Core(TM) i9-13900K (32 threads)

### Issue description

Some DirectionalLight2D and PointLight2Ds are incorrectly rendered on Direct3D 12:

### DirectionalLight2D

Vulkan | Direct3D 12
-|-
![Image](https://github.com/user-attachments/assets/d98f861d-7b2b-4363-a79a-0b28c21f7a76) | ![Image](https://github.com/user-attachments/assets/1b7b8b62-36b4-4fbb-8a31-5948f420e1cc)

### PointLight2D

Vulkan | Direct3D 12
-|-
![Image](https://github.com/user-attachments/assets/68f14065-075b-4773-8a75-f615b675b676) | ![Image](https://github.com/user-attachments/assets/7aab2179-e22b-48fc-bbf2-8fb289d8a4fc)





### Steps to reproduce

- Run `test_directional_light_2d.tscn` and `test_point_light_2d.tscn` in the MRP on Windows with a build that has Direct3D 12 enabled.
- Notice how some lights are not present in the resulting image that is saved to `user://`.
- Switch the RenderingDevice driver to `vulkan` in the Project Settings and try again.

### Minimal reproduction project (MRP)

[test-light2d-d3d12.zip](https://github.com/user-attachments/files/18480961/test-light2d-d3d12.zip)
Repository: PowerToys
Issue: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\abood\AppData\Local\Microsoft\PowerToys\PowerToys Run\Plugins\PowerToys Run Plugin Updater\PowerToys Run Plugin Updater.exe'.
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

Just opened PowerToys Run after a reboot

### ✔️ Expected Behavior

PowerToys Run works normally

### ❌ Actual Behavior

A window appears with the following error:

```
Version: 0.87.1.0
OS Version: Microsoft Windows NT 10.0.26100.0
IntPtr Length: 8
x64: True
Date: 20/01/2025 21:02:07
Exception:
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\abood\AppData\Local\Microsoft\PowerToys\PowerToys Run\Plugins\PowerToys Run Plugin Updater\PowerToys Run Plugin Updater.exe'.
   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.Strategies.AsyncWindowsFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.Strategies.FileStreamHelpers.ChooseStrategyCore(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean useAsync)
   at Community.PowerToys.Run.Plugin.UniversalSearchSuggestions.Main.UpdatePlugin()
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_0(Object state)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
```

[Also here's the log (2025-01-20.txt)](https://github.com/user-attachments/files/18481162/2025-01-20.txt)

### Other Software

I have the following plugins installed:

[Everything](https://github.com/lin-ycv/EverythingPowerToys)
[Universal Search Suggestions](https://github.com/Fefedu973/PowerToys-Run-Universal-Search-Suggestions-Plugin)
[Winget](https://github.com/bostrot/PowerToysRunPluginWinget)
[Install](https://github.com/hlaueriksson/Community.PowerToys.Run.Plugin.Install)

Also here are my settings:
[settings.json](https://github.com/user-attachments/files/18481220/settings.json)
Repository: neovim
Issue: `==` should respect injected languages
Labels: treesitter,options

### Problem

I frequently run into annoying issues when I try to format injected languages using `==` because they aren't indented according to my usual settings for those languages. A good example is code blocks containing R, which I indent using treesitter, embedded in markdown documents, which I indent using vim syntax rules. If I try to indent my R code using `==`, Neovim treats it like markdown and the result is always very different from what I want.

### Expected behavior

It would be great if `==` respected injected languages. NB, I found it fairly easy to put together a small [plugin](https://github.com/wurli/contextindent.nvim) which does exactly this using `vim.filetype.get_option("<ft for current line>", "indentexpr")`, but someone suggested that this really should be the default behaviour, hence this issue.

I'd be more than happy to contribute a PR if anyone is willing to support/review.

Thank you!
Repository: rust
Issue: Assembly for Rc::<str>::default() looks quite inefficient
Labels: T-compiler,C-optimization

<!--
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
#[no_mangle]
pub fn rc_str() -> std::rc::Rc<str> {
    std::rc::Rc::<str>::default()
}
```

I expected this to allocate with a known layout and and handle potential allocation errors.

Instead, before the allocation, the assembly contains not one, but two calls to `rc_inner_layout_for_value_layout` (indirect via `call r15`) ([compiler explorer](https://rust.godbolt.org/z/czTh317od)):

```asm
rc_str:
        push    r15
        push    r14
        push    rbx
        mov     r15, qword ptr [rip + alloc::rc::rc_inner_layout_for_value_layout::h02e271ca20ae9f03@GOTPCREL]
        mov     edi, 1
        xor     esi, esi
        call    r15
        mov     rbx, rax
        mov     r14, rdx
        mov     edi, 1
        xor     esi, esi
        call    r15
        test    rdx, rdx
        je      .LBB0_2
        mov     rcx, qword ptr [rip + __rust_no_alloc_shim_is_unstable@GOTPCREL]
        movzx   ecx, byte ptr [rcx]
        mov     rdi, rdx
        mov     rsi, rax
        call    qword ptr [rip + __rust_alloc@GOTPCREL]
.LBB0_2:
        test    rax, rax
        je      .LBB0_4
        mov     qword ptr [rax], 1
        mov     qword ptr [rax + 8], 1
        xor     edx, edx
        pop     rbx
        pop     r14
        pop     r15
        ret
.LBB0_4:
        mov     rdi, rbx
        mov     rsi, r14
        call    qword ptr [rip + alloc::alloc::handle_alloc_error::ha0642996a160fa99@GOTPCREL]

```

The two calls seem to [correspond to the source code (line 257 and 2076)](https://github.com/rust-lang/rust/blob/6a64e3b89724395d87a394ed9ebd954c474b080a/library/alloc/src/rc.rs#L2057), but I would have expected the compiler to be smart enough to see those should be the same, and even to compute that value at compile time.

### 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.86.0-nightly (6067b3631 2025-01-17)
binary: rustc
commit-hash: 6067b36314ab5eb2eb47cecc464545ba58e1ad24
commit-date: 2025-01-17
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.7
Compiler returned: 0
```

</p>
</details>