sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Indexed ^= (XOR in-place) operation doesn't work as expected on MPS backend
Labels: high priority,triaged,module: correctness (silent),module: mps

### 🐛 Describe the bug

The ^= (XOR in-place) operation produces incorrect results on the MPS backend. The behavior is inconsistent with other backends, such as CPU. Specifically, the operation appears to modify unintended values in the tensor.

```
import torch

# On CPU
zeros = torch.zeros((10, 2), dtype=torch.int16, device="cpu")
zeros[:, 0] ^= 1
print(zeros)  # Expected and correct output:
# tensor([[1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0]], dtype=torch.int16)

# On MPS
zeros = torch.zeros((10, 2), dtype=torch.int16, device="mps")
zeros[:, 0] ^= 1
print(zeros)  # Incorrect output:
# tensor([[1, 1],
#         [1, 1],
#         [1, 1],
#         [1, 1],
#         [1, 1],
#         [0, 0],
#         [0, 0],
#         [0, 0],
#         [0, 0],
#         [0, 0]], device='mps:0', dtype=torch.int16)

# Non-in-place workaround
zeros = torch.zeros((10, 2), dtype=torch.int16, device="mps")
zeros[:, 0] = zeros[:, 0] ^ 1
print(zeros)  # Correct output:
# tensor([[1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0],
#         [1, 0]], device='mps:0', dtype=torch.int16)
```

### Versions

PyTorch version: 2.5.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 15.2 (arm64)
GCC version: Could not collect
Clang version: 16.0.0 (clang-1600.0.26.4)
CMake version: Could not collect
Libc version: N/A

Python version: 3.12.3 | packaged by conda-forge | (main, Apr 15 2024, 18:35:20) [Clang 16.0.6 ] (64-bit runtime)
Python platform: macOS-15.2-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Max

Versions of relevant libraries:
[pip3] numpy==2.1.2
[pip3] onnx==1.17.0
[pip3] torch==2.5.1
[pip3] torchaudio==2.5.1
[pip3] torchvision==0.20.1
[conda] numpy                     2.1.2           py312h801f5e3_0    conda-forge
[conda] pytorch                   2.5.1                  py3.12_0    pytorch
[conda] torchaudio                2.5.1                 py312_cpu    pytorch
[conda] torchvision               0.20.1                py312_cpu    pytorch

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @kulinseth @albanD @malfet @DenisVieriu97 @jhavukainen
Repository: godot
Issue: Set window Borderless True causes weird stretch in Windows force native: true
Labels: bug,needs testing,topic:gui

### Tested versions

Reproducable in: 4.3 stable

### System information

Godot v4.3.stable - Windows 10.0.22631 - GLES3 (Compatibility) - Intel(R) Iris(R) Xe Graphics (Intel Corporation; 30.0.100.9836) - 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (8 Threads)

### Issue description

When toggling the borderless option on a Window Node with force_native: true, the window appears to stretch incorrectly. The screen stretches upward to the window title bar, creating a distorted appearance.

Note:
I only tested on Windows 11. It would be helpful if others could confirm this behavior on different operating systems.

https://github.com/user-attachments/assets/2506243a-640b-4d37-b862-2f688adf952b


### Steps to reproduce

1. Create WindowNode, set force native: true, visible: false
2. Set WindowNode visible=true at func _ready function
3. Toggle WindowNode's Borderless On and Off
4. WindowNode's Screen is Stretched

### Minimal reproduction project (MRP)


How to Reproduce:

[window_borderless_bugreport.zip](https://github.com/user-attachments/files/18473215/window_borderless_bugreport.zip)
Repository: rust
Issue: Tracking Issue for `unchecked_disjoint_bitor`
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(disjoint_bitor)]`

This is a tracking issue for the `unchecked_disjoint_bitor` method on integer types (and the associated intrinsic implementing it).

This is a method for cases where `a | b` and `a + b` return the same value, named after the [`disjoint` flag in LLVM](https://llvm.org/docs/LangRef.html#or-instruction).

ACP: https://github.com/rust-lang/libs-team/issues/373 

### Public API

```rust
impl u8/.../u128/usize {
    pub const unsafe fn unchecked_disjoint_bitor(self, other: Self) -> Self;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #135760
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: neovim
Issue: vim.snippet.expand: insertion at wrong place when using virtualedit + tab indentation
Labels: snippet

### Problem

Insertion starts at the wrong place when expanding a snippet, when
1. Tabs are used for indentation, and
2. using :set virtualedit=all

Note: this is a different issue from https://github.com/neovim/neovim/issues/30953, which does not refer to indentation / virtualedit but rather the order of text edits.

Original issue: https://github.com/Saghen/blink.cmp/issues/889

### Steps to reproduce

:set virtualedit=all
:set list

Then expand a snippet to the right of a few tab symbols. See the following short video:

https://github.com/user-attachments/assets/ea755013-0814-4584-a585-b1fa7d8ed407

### Expected behavior

The snippet itself is expanded at the correct location. The cursor should be placed at the correct location in the expanded snippet as well.

### Nvim version (nvim -v)

NVIM v0.11.0-dev-1594+g5f527f24f0

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

no, vim doesn't have lua-based snippet support at all

### Operating system/version

macOS 

### Terminal name/version

kitty 0.38.1

### $TERM environment variable

xterm-kitty

### Installation

build from repo
Repository: rust
Issue: Using a bare trait as a field type in a struct gives subpar suggestion
Labels: A-diagnostics,T-compiler

### Code

```Rust
trait Trait {}

struct Foo {
    a: Trait,
    b: u32,
}
```

### Current output

```Shell
error[E0782]: expected a type, found a trait
 --> src/lib.rs:4:8
  |
4 |     a: Trait,
  |        ^^^^^
  |
help: you can add the `dyn` keyword if you want a trait object
  |
4 |     a: dyn Trait,
  |        +++

For more information about this error, try `rustc --explain E0782`.
error: could not compile `trait-in-struct` (lib) due to 1 previous error
```

### Desired output

```Shell
error[E0782]: expected a type, found a trait
 --> src/lib.rs:4:8
  |
4 |     a: Trait,
  |        ^^^^^
  |
help: you might be missing a type parameter
  |
3 | struct Foo<T: Trait> {
  |           +++
4 |     a: T,
  |        ^

For more information about this error, try `rustc --explain E0782`.
error: could not compile `playground` (lib) due to 1 previous error
```

### Rationale and extra context

Currently this just suggests using `dyn` which also works if the field is the last field int the struct so can be unsized. However the suggestion is also given when the field is not in the last position, so applying the fix fails.

For most cases I think it makes more sense to either add a generic or Box the value.

### Other cases

```Rust

```

### Rust Version

```Shell
rustc 1.86.0-nightly (8361aef0d 2025-01-14)
binary: rustc
commit-hash: 8361aef0d7c29b1501a316a208ed84cd8a2ae5da
commit-date: 2025-01-14
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.6
```

### Anything else?

_No response_
Repository: godot
Issue: 4.4beta1 - Jolt Physics/Physics Interpolation - Skeleton Ragdoll diverges mesh from Physical Bones
Labels: bug,topic:physics,needs testing,topic:3d

### Tested versions

Reproducible in 4.4-beta1, no other versions as Jolt is new in 4.4

### System information

Godot v4.4.beta1.mono - Windows 11 (build 26100) - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 (NVIDIA; 32.0.15.6590) - Intel(R) Core(TM) i7-14700K (28 threads)

### Issue description

![Image](https://github.com/user-attachments/assets/093e1b62-013c-470f-8cf3-5f099b65a44d)

Happy to get a MRP if necessary

Working correctly when using GodotPhysics instead of Jolt

### Steps to reproduce

https://docs.godotengine.org/en/stable/tutorials/physics/ragdoll_system.html

Follow this tutorial

Enable Jolt Physics in Project Settings

Enable Physics Interpolation

Observe the mesh glitching out and away from the physical bones of the skeleton, after activating the physical bone simulation

### Minimal reproduction project (MRP)

Will create if necessary
Repository: ollama
Issue: Network issues with pulling model from ollama
Labels: bug

### What is the issue?

When I trying to pull model from ollama by proxy whatever large model and small model(2g),it seems that redownload again and again and again, just like from 120mb to 160mb and go back to 100mb again and again and finally show "max retries exceeded".This issue persists probably 1 week and it worked well before.I already changed different network to try it but it still not work.:(
Thanks for ur assistant!

### OS

macOS

### GPU

Apple

### CPU

Apple

### Ollama version

0.5.7
Repository: vscode
Issue: Git - "Not Commited Yet" does not bring value
Labels: git,under-discussion

If I change the line, the Git Blame changes to "Not Commited Yet"
This just adds noise, and might conflict with ghost text inline completions.
My suggestion is to simply not show anything on the modified line.

![Image](https://github.com/user-attachments/assets/5d4f7bcf-28f6-4e9b-be02-689f3458856a)
Repository: go
Issue: x/pkgsite: package removal request for (case sensitive) https://pkg.go.dev/github.com/ibm/sarama
Labels: pkgsite,pkgsite/package-removal

### What is the path of the package that you would like to have removed?

github.com/ibm/sarama (case sensitive)

### Are you the owner of this package?

Yes I am the owner of this package under the IBM org.

### What is the reason that you could not retract this package instead?

This is a follow-on from https://github.com/golang/go/issues/71256 where under https://go.dev/cl/642600 I added ibm/sarama --> IBM/sarama under the `knownAlternatives` mechanism in pkgsite, which corrects things at the fetch level, but it looks like the historically fetched data needs to be purged

pkgsite seems to accidentally have an invalid (and outdated) lowercase entry at https://pkg.go.dev/github.com/ibm/sarama whereas the correct module path is https://pkg.go.dev/github.com/IBM/sarama which is correct an up-to-date.

Please can you remove the invalid lowercase entry at https://pkg.go.dev/github.com/ibm/sarama (whilst retaining/keeping the uppercase IBM entry at https://pkg.go.dev/github.com/IBM/sarama)
Repository: vscode
Issue: Terminal selection/scrolling breaks when resizing
Labels: bug,upstream,upstream-issue-linked,terminal-layout

1. Have lots of output in terminal
2. Make a selection
3. Resize terminal

🐛  Selection moves with the resizing

Also:

1. Have lots of output in terminal, make sure you are scrolled all the way down
2. Shrink the terminal, it still appears as you're scrolled all the way down
3. Scroll down in the terminal

🐛 Scroll position will jump and allow you to scroll down

https://github.com/user-attachments/assets/1a4d6004-fc8c-4a83-969c-3c5ed622b2bb
Repository: pytorch
Issue: DISABLED test_aoti (__main__.TestMemoryPlanning)
Labels: module: rocm,triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: rocm

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

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 4 failures and 3 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_aoti`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/pytorch/test/inductor/test_memory_planning.py", line 113, in test_aoti
    ).run(
RuntimeError: Expected to find "int64_t int_array_2[] = {24L + align(12L*s0), };" but did not find it
Searched string:
Auto-tuning code written to /tmp/tmp92c6h0z4/tmp0ptwdcmx.py
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
Output code: 
From CHECK: int64_t int_array_2[] = {24L + align(12L*s0), };


To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_ROCM=1 python test/inductor/test_memory_planning.py TestMemoryPlanning.test_aoti

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `inductor/test_memory_planning.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd @clee2000 @wdvr @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @chauhang @aakhundov
Repository: pytorch
Issue: DISABLED test_remote_cache_load_function_device_cuda_float32_dynamic_False_bundle_triton_False (__main__.TestFxGraphCache)
Labels: module: rocm,triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: rocm

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

Over the past 3 hours, it has been determined flaky in 3 workflow(s) with 4 failures and 3 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_remote_cache_load_function_device_cuda_float32_dynamic_False_bundle_triton_False`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/pytorch/test/inductor/test_codecache.py", line 266, in test_remote_cache_load_function
    self.assertEqual(global_stats.fx_graph, Stats(1, 3, 1))
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 4036, in assertEqual
    raise error_metas.pop()[0].to_error(  # type: ignore[index]
AssertionError: Object comparison failed: _GlobalItemStats(num_put=2, num_get_hit=2, num_get_miss=2) != Stats(num_put=1, num_get_hit=3, num_get_miss=1)

To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_ROCM=1 python test/inductor/test_codecache.py TestFxGraphCache.test_remote_cache_load_function_device_cuda_float32_dynamic_False_bundle_triton_False

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `inductor/test_codecache.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd @clee2000 @wdvr @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @chauhang @aakhundov
Repository: PowerToys
Issue: Move app windows with powertoys
Labels: Needs-Triage

### Description of the new feature / enhancement

Like it is possible to move windows around with win + (up, down, right, left), could it be possible do that inside powertoys run. The difference would be that there would be no suggestions for splitting two programs. Open powertoys run and type right, now your windows is to the right side of the screen. 

I'm mostly looking for these options: middle, right side, left side, upper half, bottom half, the 4 corners, maximize window, divide screen in thirds.

### Scenario when this would be used?

Opening new programs and moving them around quickly. For example: 

In the morning you open your pc to start working but you have to open vscode, browser and teams. I want to move the around quickly, I type in "left third", "middle third", "right third". Now my app windows are moved to their desired spot. 

### Supporting information

[Raycast window manager](https://www.raycast.com/core-features/window-management)
Repository: ollama
Issue: Ollama is working fine with CLI / powershell but goes in loop on API request.
Labels: bug

### What is the issue?

Ollama is able to run model when a message is sent through CLI /Powershell, when Cline or Roocline is used or a prompt is sent through API. Ollama is stuck in loop of previous response.

### OS

Windows

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.5.7
Repository: angular
Issue: Show warning when `withEnabledBlockingInitialNavigation` Is used with `provideClientHydration`
Labels: help wanted,area: core,core: hydration

### Which @angular/* package(s) are relevant/related to the feature request?

router, platform-browser

### Description

The `withEnabledBlockingInitialNavigation` option was designed specifically for use cases involving deferred hydration to prevent UI flickers during initial navigation. However, when used with `provideClientHydration`, which supports standard hydration, the issue of flickering does not arise. To avoid confusion and misuse, a warning should be displayed in the console when these two configurations are used together, as they are not intended to work in tandem.

### Proposed solution

Issue warning when these 2 methods are used togather.
Repository: PowerToys
Issue: The Layout of Virtual Desktops can not be changed
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

1. Open PowerToys and enable the Fancyzones module.
2. Add a new virtual Desktop(VD) and found the layout is the same as the first VD.
3. Open the PowerToys Setting and change the monitor layout to another layout.
4. The layout in the main VD is changed as expected. 


### ✔️ Expected Behavior

The layout of the second  VD is changed to the new layout

### ❌ Actual Behavior

The layout of the second  VD is not changed and the layout is still the last one.

### Other Software

_No response_
Repository: react-native
Issue: Images are cut off/not rendered correctly on new architecture
Labels: Component: Image,Needs: Triage :mag:,Type: New Architecture

### Description

Images are being cut off after enabling the new architecture in Expo SDK 52. The issue seems to be able to reproduce randomly, sometimes the images are shown correctly, sometimes not. The issue is being reproduced also in production version of the apps. The issue is being reproduced even if developing on Windows machine or MacOS. The issue is being able to reproduce also in native react-native app, issue being caused by new architecture.
The issue is still able to reproduce after adding
"resolutions": {
	"@react-native/assets-registry": "0.76.1"
}
in package.json.

### Steps to reproduce

1. Initialize a new application
2. Import some local images using "require" and use them in the <Image/> tag
3. If they are rendered correctly, try to reload the app and observe the issue.

### React Native Version

0.76.6

### Affected Platforms

Build - Windows, Build - MacOS, Build - Linux, Runtime - iOS, Runtime - Android

### Areas

Fabric - The New Renderer

### Output of `npx react-native info`

```text
System:
      OS: macOS 15.1.1
      Shell: 5.9 - /bin/zsh
    Binaries:
      Node: 22.7.0 - /opt/homebrew/bin/node
      Yarn: 1.22.19 - ~/.nvm/versions/node/v16.18.1/bin/yarn
      npm: 10.8.2 - /opt/homebrew/bin/npm
    Managers:
      CocoaPods: 1.15.2 - /opt/homebrew/bin/pod
    IDEs:
      Xcode: /undefined - /usr/bin/xcodebuild
    npmPackages:
      expo: ^52.0.25 => 52.0.25
      react: ^18.3.1 => 18.3.1
      react-native: 0.76.6 => 0.76.6
    npmGlobalPackages:
      eas-cli: 13.2.1
    Expo Workflow: managed
```

### Stacktrace or Logs

```text
No crash for this case.
```

### Reproducer

https://github.com/vl4di99/rn-new-arch-image-bug

### Screenshots and Videos

![Image](https://github.com/user-attachments/assets/3dfad738-0d7a-4993-b44b-a79b1650f916)