sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: [Possible Regression] Bug in Integrated Terminal using Powerline Glyphs.
Labels: bug,confirmation-pending,terminal-rendering

<!-- ⚠️⚠️ 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.89.0
- OS Version: Windows 11 using WSL: Ubuntu 22.04

Steps to Reproduce:
1. Open VSCode.
2. Use a font that has powerline glyphs.
3. Use a powerline shell, I use https://github.com/b-ryan/powerline-shell
4. Go into a directory, and you'll see how the glyphs are missing (see below)

![image](https://github.com/microsoft/vscode/assets/7562753/87fbd20b-44b7-4d20-8cf3-ada055a4d553)

I'm currently in `<home>/test/somedir/anotherdir`.

### Workaround ###

Change Integrated: Gpu Acceleration to a different setting, then back again, and it should refresh.
Change this setting to on and then auto (for example):

![image](https://github.com/microsoft/vscode/assets/7562753/ff86efc9-6f21-4e3b-b3fa-a58fe9c521f7)

The terminal will then look like this:

![image](https://github.com/microsoft/vscode/assets/7562753/476ee184-7811-44c9-8db6-dca5e69dee54)

Like it was before the most recent update.
Repository: rust
Issue: #![allow(unexpected_cfgs)] does not work for modules
Labels: A-lints,T-compiler,C-bug,S-has-mcve,F-check-cfg,L-unexpected_cfgs

<!--
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
// lib.rs
mod a;
```
```rs
// a.rs
#![allow(unexpected_cfgs)] // for cfg(rustfmt)
#![cfg_attr(rustfmt, rustfmt::skip)]
```

I expected to see this happen: no warning

Instead, this happened: `#![allow(unexpected_cfgs)]` is ignored:

```
warning: unexpected `cfg` condition name: `rustfmt`
 --> src/a.rs:2:13
  |
2 | #![cfg_attr(rustfmt, rustfmt::skip)]
  |             ^^^^^^^
  |
  = help: expected names are: `clippy`, `debug_assertions`, `doc`, `docsrs`, `doctest`, `feature`, `miri`, `overflow_checks`, `panic`, `proc_macro`, `relocation_model`, `sanitize`, `sanitizer_cfi_generalize_pointers`, `sanitizer_cfi_normalize_integers`, `target_abi`, `target_arch`, `target_endian`, `target_env`, `target_family`, `target_feature`, `target_has_atomic`, `target_has_atomic_equal_alignment`, `target_has_atomic_load_store`, `target_os`, `target_pointer_width`, `target_thread_local`, `target_vendor`, `test`, `ub_checks`, `unix`, `windows`
  = help: consider using a Cargo feature instead or adding `println!("cargo::rustc-check-cfg=cfg(rustfmt)");` to the top of the `build.rs`
  = note: see <https://doc.rust-lang.org/nightly/cargo/reference/build-scripts.html#rustc-check-cfg> for more information about checking conditional configuration
  = note: `#[warn(unexpected_cfgs)]` on by default
```

Even if adding `#[allow(unexpected_cfgs)]` to `mod a;`, the result is the same.

cc @Urgau

### 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.80.0-nightly (e82c861d7 2024-05-04)
binary: rustc
commit-hash: e82c861d7e5ecd766cb0dab0bf622445dec999dc
commit-date: 2024-05-04
host: aarch64-apple-darwin
release: 1.80.0-nightly
LLVM version: 18.1.4
```


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"Urgau"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: opencv
Issue: bug when build opencv: QT 6.7, UNICODE, __itt_domain_create
Labels: bug,category: core,category: build/install,category: 3rdparty

### System Information

OpenCV: 4.9.0
Operating System / Platform: WIN 11 Home
Compiler & compiler version: MSVC 1939
CMake version: 3.29.2

### Detailed description

I choose "WITH_QT" (version 6.7.0) and "build_opencv_world" in cmake-gui, part of error logs are as follows:

D:\OPENCV\opencv-4.9.0\modules\core\src\trace.cpp(211,46): error C2664: “__itt_domain *(const wchar_t *)”: 无法将参数 1 从“const char [12]”转换为“const wchar_t *”
D:\OPENCV\opencv-4.9.0\modules\core\src\trace.cpp(211,46):
指向的类型不相关; 转换需要 reinterpret_cast、C 样式强制转换或带圆括号的函数样式强制转换
D:\OPENCV\opencv-4.9.0\modules\core\src\trace.cpp(241,61): error C2664: “__itt_string_handle *(const wchar_t *)”: 无法将参数 1 从“const char *const ”转换为“const wchar_t *”
D:\OPENCV\opencv-4.9.0\modules\core\src\trace.cpp(241,61):
指向的类型不相关; 转换需要 reinterpret_cast、C 样式强制转换或带圆括号的函数样式强制转换

![1](https://github.com/opencv/opencv/assets/40993130/950c3328-67c6-45c2-9ae9-77fc467dbce8)
![2](https://github.com/opencv/opencv/assets/40993130/99bd07d5-b95a-42bf-ad76-a3d1cecb89a6)
![3](https://github.com/opencv/opencv/assets/40993130/154d8fe0-fd4d-4f81-94b8-5efde787b551)

However, everything is fine when I only choose "build_opencv_world" or "WITH_QT".
And in QT assistant, I find that "In Qt 6, the UNICODE and _UNICODE compiler definitions are set by default for targets that link against Qt modules".


### Steps to reproduce

choose "WITH_QT" (version 6.7.0) and "build_opencv_world" in cmake-gui

### 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
- [ ] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: godot
Issue: mouse still moving despite captured on wayland, only hidden within window frame
Labels: bug,platform:linuxbsd,topic:porting,needs testing

### Tested versions

Godot version: v4.2.2.stable.fedora [15073afe3]

### System information

Godot version: v4.2.2.stable.fedora [15073afe3] OS: Fedora Linux 40 (Workstation Edition)

### Issue description

# Observation:
when using 
```
func _ready():
	Input.mouse_mode = Input.MOUSE_MODE_CAPTURED
```
the mouse hides as expected but can be moved outside the window until it hits the screen boundary. 

- look-around-motion is smooth while within the screen but gets cut off at the boundary.
- mouse reappears outside the window frame

# SystemInformation:
Godot version: v4.2.2.stable.fedora [15073afe3]
OS: Fedora Linux 40 (Workstation Edition)
```
echo $XDG_SESSION_TYPE
wayland
```

### Steps to reproduce

hit play, move mouse to look around

- bump cursor into screen boundary
- move mouse outside of window frame

### Minimal reproduction project (MRP)

[fpsController.tar.gz](https://github.com/godotengine/godot/files/15211924/fpsController.tar.gz)
Repository: ollama
Issue: `OLLAMA_NUM_PARALLEL` and multi-modal models lead to `failed processing images` error
Labels: bug

### What is the issue?

When processing multiple requests using multi-modal models such as `llava` or `moondream` generation freezes and an error is printed in the server logs: `failed processing images`

### OS

_No response_

### GPU

_No response_

### CPU

_No response_

### Ollama version

_No response_
Repository: PowerToys
Issue: Duplicate options appear in the right-click menu of win10 when switching from win11
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.80.1

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

General

### Steps to reproduce

Duplicate options appear in the right-click menu of win10 when switching from win11

### ✔️ Expected Behavior

Use the terminal administrator to enter the following command to switch the win10 menu style：reg add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve
![QQ截图20240505162959](https://github.com/microsoft/PowerToys/assets/135140699/364469ce-5fbe-4159-bb16-cad2b46ce7f2)
![QQ截图20240505163015](https://github.com/microsoft/PowerToys/assets/135140699/ec58a723-291a-489f-a78f-a1cf0428863a)


### ❌ Actual Behavior

Right-click in the explorer or right-click the file

### Other Software

_No response_
Repository: bitcoin
Issue: upstream: GUIX closure contains too much unnecessary stuff
Labels: Brainstorming,Build system,Upstream

The minimum guix closure contains X11 libraries, graphviz, as well as LaTeX and associated fonts. They should be unnecessary for minimum set of packages needed to build. Especially on slower CPUs (eg current RISC-V cores, qemu) it results in a large slowdown, it's also bad from a "minimum trusted set" point of view.

They're pulled in by `guix-manual`, as well as sometimes, package-specific documentation. Unfortunately, documentation is not behind an optional flag at the moment so there's nothing we can do at our build system level.  Our `manifest.scm` already contains nothing that depends on them, and they're not part of our build environment.

Upstream issues about it (will update when i come across more):
https://issues.guix.gnu.org/issue/63050
Repository: next.js
Issue: .tsx layout breaks entire site in production, .jsx works fine
Labels: bug,Runtime

### Link to the code that reproduces this issue

https://github.com/dymoo/next-docker-layoutbroken-example

### To Reproduce

1. clone example git repo
2. docker-compose up
3. nav to localhost:3099
4. page doesn't display
5. check console, minified react errors

I fixed this error in my own project by changing the nested layout to a jsx file. I am unable to reproduce the fix in the example repo? 

### Current vs. Expected behavior

While deploying with docker the entire page breaks, outputs minified react errors

```
Uncaught Error: Minified React error #418;
Uncaught Error: Minified React error #423;
DOMException: Failed to execute 'appendChild' on 'Node': Only one element on document allowed
DOMException: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.
Uncaught AggregateError
```

### Provide environment information

```bash
OS: Darwin MacBook-Air-3.local 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:41 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8103 arm64

m1 air 16gb ram

Node docker images used 18-slim, 18-alpine, 20-slim, 20-alpine
```


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

Runtime

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

Other (Deployed)

### Additional context

Ive tried adding removing everything from my next config, .dockerignore, trying different base images, tried yarn, running a shell inside the container to see around, with / without a custom server, downgrading to 14.1, trying latest next version (currently on), different next config output settings, Nothing. -- I've wasted like 2 days on troubleshooting and I'm stumped!
Repository: next.js
Issue: globalThis.fetch patch setting property on self leads to 504s
Labels: bug,Runtime

### Link to the code that reproduces this issue

https://github.com/mhart/nextjs-patch-bug

Live at: https://nextjs-bug-eight.vercel.app/ (try reloading a few times)

### To Reproduce

1. Include any function or module that monkey-patches `globalThis.fetch` after [Next.js has already patched it](https://github.com/vercel/next.js/blob/9ec37c120aba9d5f16e00566a10cba68858e363d/packages/next/src/server/lib/patch-fetch.ts#L779)
2. Observe that Next.js will patch it again, because the `__nextPatched` property no longer exists on the patched fetch and [that's what it checks for](https://github.com/vercel/next.js/blob/9ec37c120aba9d5f16e00566a10cba68858e363d/packages/next/src/server/lib/patch-fetch.ts#L32).
3. So now `globalThis.fetch` is wrapped multiple times with the same Next.js patch, sandwiching any other patches in between.

See [repo](https://github.com/mhart/nextjs-patch-bug) for example reproduction. Reloads result in 504s, errors in the log are:
```
Error: Your function was stopped as it did not return an initial response within 25s
```


### Current vs. Expected behavior

Current behaviour is that fetch gets wrapped multiple times, potentially again and again each request in the edge runtime. One outcome of this is that fetch calls deadlock (unclear exactly why – something to do with the internals of the patch implementation), leading to 504 errors.

Expected behaviour is that it only wraps once, and then fetch calls (even if wrapped by another patch), will succeed.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.12.2
  npm: 10.5.2
  Yarn: 4.1.1
  pnpm: 9.0.6
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: N/A
  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)

Runtime

### Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

### Additional context

Suggestion is to not set a property on the thing you're patching to then check if it's been patched or not. Perhaps set a symbol on globalThis or similar?

Also probably worth looking into why the patch can't be applied recursively in the first place (ie, what's causing the deadlocks).

Also, ideally, remove the patch altogether and provide the functionality in another way 🙏
Repository: godot
Issue: 4.3.dev - Deletion not working in the tilemap layers name input field
Labels: enhancement,topic:editor,usability,topic:2d

### Tested versions

- This problem is in all dev releases after Godot v4.3 dev 2
- It is an issue under both wayland and x11 (linux)
- The latest stable branch (Godot v4.2.2) doesn't have the issue

### System information

Godot v4.3.dev6 - EndeavourOS #1 SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 15:59:47 +0000 - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 6700 XT (RADV NAVI22) () - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

### Issue description

When going into the Name input of a Layer of a Tilemap like the one below, I'm experiencing not being able to delete the first letter of the name.
![image](https://github.com/godotengine/godot/assets/70802809/e8e4a461-e882-4d52-8e42-f1f62abe79c8)

It might sound stupid, but here is a video to show you what I mean because it's really hard to explain:
https://github.com/godotengine/godot/assets/70802809/1568f4fa-e78b-4f3e-9ef2-882f32784cf7

Every time the first letter doesn't go away, that's me trying to delete it. When I try the selection it's also me pressing the delete key when it goes away. I hope this is helpful.

### Steps to reproduce

1. Create a Tilemap.
2. Try to name a layer under the Layers dropdown.
3. Try to write something in the input and then try to delete the whole thing. Another option would be to click Ctrl+A and then try to delete the entire thing, which also doesn't work.

### Minimal reproduction project (MRP)

I don't think this is necessary since it works in any Godot project I've tried. Just create a Tilemap in an empty project and try to name a layer.
Repository: godot
Issue: Search Help shortcut is not working if focus is in any tree
Labels: discussion,platform:macos,topic:editor,topic:input

### Tested versions

v4.3.dev6.official [89850d553]

### System information

Godot v4.3.dev6 - macOS 14.4.1 - Vulkan (Forward+) - integrated Apple M1 Max - Apple M1 Max (10 Threads)

### Issue description

I'm using an external script editor and I often alt tab into Godot to look stuff up in the API reference because of how well organized it is. Unfortunately half of the times pressing Alt+Space doesn't work if the focus is in the wrong place

### Steps to reproduce

Click on some item in FileSystem or Scene dock and press Alt+Space (F1 on windows)

### Minimal reproduction project (MRP)

N/A
Repository: vscode
Issue: VS Code in browser with GitHub makes 1000ths of copies (vscode.dev).
Labels: bug,info-needed,web

<!-- ⚠️⚠️ 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: https://vscode.dev/, version 1.89, April 2024
- OS Version: Google ChromeOS, Version 122.0.6261.118 (Official Build) (64-bit). I'm using my school's Chromebook and working with the files from Google Drive and GitHub.

Steps to Reproduce:

1. Open your Chromebook, go to vscode.dev and open it as an app (the bug also occurs if I just use vscode.dev and don't use the app).

2. Open a GitHub repository and make a new file. Make some edits to the file, or any file really, and with every autosave, your Google Drives main folder will be full of thousands of useless copies of the files. Google Drive makes it really difficult to remove so many files. I couldn't use my chromebook for at least 15 minutes while deleting only a small portions of the files:

![Screenshot 2024-05-05 15 15 07](https://github.com/microsoft/vscode/assets/79015591/742c6201-37f0-44ed-90e0-d887566c3552)
Repository: rust
Issue: Addition to E0582 explanation
Labels: A-diagnostics,T-compiler

### Code

```Rust
trait Foo {
    type Assoc<'a>;
}

#[allow(dead_code)]
struct Bar<X, F>
where
    X: Foo,
    F: for<'a> Fn(X::Assoc<'a>) -> &'a i32
{
    x: X,
    f: F
}
```


### Current output

```Shell
error[E0582]: binding for associated type `Output` references lifetime `'a`, which does not appear in the trait input types
  --> src/lib.rs:23:42
   |
23 |         F: for<'a> Fn(X::Content<'a>) -> &'a i32
   |                                          ^^^^^^^

For more information about this error, try `rustc --explain E0582`.
```


### Desired output

_No response_

### Rationale and extra context

### Problem
This error message could be more helpful.
- While `'a` appears in the parameter for the associated type, there is no guarantee that an `impl` for the associated type actually uses the parameter, therefore `'a` is not guaranteed to be used in the input for any `impl Foo`

### Suggestion
1. Either add extra explanation to the error when with regards to associated type usage (e.g. the above problem annotating the `X::Assoc<'a>` (requires time to implement
2. Update the `rustc --explain E0582` to include this example.
3. No changes, skill issue

### Other cases

_No response_

### Rust Version

```Shell
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
```


### Anything else?

_No response_
Repository: godot
Issue: Setting non-embedded borderless window to always_on_top makes window non-interactible
Labels: bug,topic:porting,topic:input,topic:gui

### Tested versions

reproducible in Godot v4.3.dev6, Godot_v4.2.1-stable

### System information

Godot v4.3.dev6 - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 (NVIDIA; 31.0.15.5186) - AMD Ryzen 5 5600 6-Core Processor (12 Threads)

### Issue description

A sub window that's not embedded and set to borderless bugs out when it's always_on_top property is set to true during runtime. The window remains visible, but the window's entry in the task bar closes. The visible window area cannot be clicked anymore and mouse clicks will go through to windows behind it 
see:
![borderless_always_on_top](https://github.com/godotengine/godot/assets/4991495/49ac16e8-316c-48a4-9c38-3e96471de57e)

A possible workaround is setting the window invisible and then visible again. 

### Steps to reproduce

- Project Settings -> do not embedd sub-windows
- Window node, set borderless flag to true
- set the window's always_on_top flag to true during runtime
-> window gets unresponsive, can be clicked through

usage of the reproduction project:
run -> click button in sub window -> now the sub window is unresponsive, click-through

### Minimal reproduction project (MRP)

[reproduction_project.zip](https://github.com/godotengine/godot/files/15213287/reproduction_project.zip)
Repository: next.js
Issue: Fetch failed loading: GET "http://localhost:3000/dashboard/blog?_rsc=1538b".
Labels: bug

![Screenshot 2024-05-05 at 17 08 50](https://github.com/vercel/next.js/assets/866622/c90ac0ce-0710-40ec-bb64-452a822c3ff2)
![Screenshot 2024-05-05 at 17 09 23](https://github.com/vercel/next.js/assets/866622/f7dc7036-870b-403e-a24d-fea70a767d34)
### Link to the code that reproduces this issue

https://github.com/spacecat/nextjs-04

### To Reproduce

IMPORTANT: You need to enable "Log XMLHttpRequests" in Google Chrome DevTools Console settings:

<img width="552" alt="image" src="https://github.com/vercel/next.js/assets/866622/39caed81-fa87-477f-80d0-c901f9cf5553">

1. npm run dev
2. In Chrome, navigate to http://localhost:3000/dashboard
3. Click the "To Blog" link
4. Click the "To Dashboard" link

### Current vs. Expected behavior

I expected the DevTools console to NOT output any errors or messages that sound like errors.
Instead the DevTools console is outputting Fetch failed loading: GET messages.


### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:41 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8103
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 14.2.3
  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

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

I'm only getting these messages in Chrome on both my Mac and PC. Safari and Firefox don't give me these error messages.