sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: RNN/GRU/LSTM fail to export()/dynamo_export
Labels: oncall: export

### 🐛 Describe the bug

nn.RNNBase.flatten_parameters function should be a no-op for export. 
Otherwise, export()/dynamo_export fail inside it with this error:
```
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/rnn.py", line 196, in <setcomp>
    unique_data_ptrs = {p.data_ptr() for p in self._flat_weights}
RuntimeError: Cannot access data pointer of Tensor (e.g. FakeTensor, FunctionalTensor). If you're using torch.compile/export/fx, it is li\
kely that we are erroneously tracing into a custom kernel. To fix this, please wrap the custom kernel into an opaque custom op. Please se\
e the following for details: https://docs.google.com/document/d/1W--T6wz8IY8fOI0Vm8BF44PdBgs283QvpelJZWieQWQ
```
Here is a short repro. Monkey-patching nn.RNNBase.flatten_parameters fixes the issue. Real fix should be a conditional inside  flatten_parameters. 
```
import numpy as np
import torch
import torch.nn as nn

def noop(self):
    pass

# That fixes the issue                                                                                                                    
# nn.RNNBase.flatten_parameters = noop                                                                                                    

class Model(nn.Module):
    def __init__(self):
        super().__init__()
        # same for LSTM, GRU                                                                                                              
        self.rnn = nn.RNN(16, 16, batch_first=True)

    def forward(self, x):
        return self.rnn(x)

device = torch.device('cuda')
model = Model().to(device)
x = torch.rand(1024, 20, 16).to(device)
# This does not help - fails same way in export()                                                                                         
# model = torch.export.export(model, (x,)).run_decompositions()                                                                           
onnx_program = torch.onnx.dynamo_export(model, x).save('model.onnx')
```


### Versions

PyTorch nightly 05/14

cc @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4
Repository: electron
Issue: [Bug]: Electron window resizes when displat scaling is less than 100% on wayland
Labels: platform/linux,bug :beetle:,status/reviewed,wayland,stale

### 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 bug report that matches the one I want to file, without success.

### Electron Version

30.0..1

### What operating system are you using?

Other Linux

### Operating System Version

Arch Linux Plasma 6 Wayland

### What arch are you using?

x64

### Last Known Working Electron version

22.3.27

### Expected Behavior

For the window to not resize when focus is changed and to fill screen properly when maximized.

### Actual Behavior

I have a 2 screen setup where the secondary screen to 90% to better align with the size of the primary screen(125%).  On the 90% screen when Electron is on it will not properly scale to fill the screen and when I click on another window the electron window shrinks. Alternating between the 2 windows will continue to resize it smaller and smaller.  The window also  does not maximized properly.  This behavior does not occur when fractional scaling to at 100% or 125%.

Tested :
Working correctly 
22 22.3.27-6

Broken:
l25 25.9.8-5
28 28.3.1-2
29 29.3.1-2
30.0.1-2


### Testcase Gist URL

_No response_

### Additional Information

Tested on Plasma 6.0.4 wayland. 

AMD 5900x
Nvidia 4080 (driver 550.78)
6.8.9-273-tkg-linux-tkg
Repository: pytorch
Issue: Break the dependency between torch.nn and torch.distributed
Labels: oncall: distributed,triaged

### 🚀 The feature, motivation and pitch

We are seeing several import issues when compiling distributed modules. And the root cause is there are circular dependencies between `torch.nn` and `torch.distributed`. Some examples:
1. `torch.nn` will import DDP, which will rely on many `torch.distributed` modules.
2. `torch.nn` will import `pytorch/torch/_jit_internal.py`, which rely on `torch.distributed.rpc`. 

While right now we work around these circular dependency issues, but these issues recurrently happen when compiling the distributed modules. We need to ensure lazy dependencies on `torch.distributed` for `torch.nn`

### Alternatives

_No response_

### Additional context

_No response_

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @wconstab @yf225 @chauhang @d4l3k
Repository: pytorch
Issue: Revamp PT2 TroubleShooting tutorial
Labels: module: docs,triaged,oncall: pt2

### 📚 The doc issue

https://pytorch.org/docs/stable/torch.compiler_troubleshooting.html is pretty out of date

### Suggest a potential alternative/fix

Will update it and create a process to update it every release

cc @svekars @brycebortree @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang
Repository: electron
Issue: [Feature Request]: Properly align window content during MacOS window animation
Labels: enhancement :sparkles:,has-repro-gist

### 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 bug report that matches the one I want to file, without success.

### Electron Version

29.1.0

### What operating system are you using?

macOS

### Operating System Version

MacOS Sonoma 14.0

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

Many Mac apps have sidebar UIs that act like drawers -- you can open and close them, and the desired behaviour is that the window expands on the left or right side to accommodate the sidebar content.  So, opening a left-side sidebar would cause the left edge of the window to expand, displaying sidebar content.  The content itself would stay in the same visual location.  You can see this effect in the Raycast AI app:


https://github.com/electron/electron/assets/2133518/1fded013-7272-4805-a922-75cac18a0385

### Actual Behavior

I am trying to write an Electron app that does this.  The attached fiddle shows the closest I've gotten: in the fiddle, the content div size is fixed while the window animation occurs.  The end result is that the right sidebar opens and closes as expected, but the left sidebar does not:

https://github.com/electron/electron/assets/2133518/54a300de-f4e5-4867-924c-d150adf49f90

It appears as though the electron content is left-aligned, so while the window resize animation is running the content gets "pushed right", and the browser rendering runs a few frames behind.

I'd like some way to get the end UI effect I'm looking for -- the ability to animate the window resize in a way that is synchronized with the browser content resizing, so that the main content doesn't move while the animation is occurring.

Is there a way to pin the content to the right side while the animation is running?  That might solve this, as I could temporarily pin the content to the right edge of the window while the left window edge is resizing.  If not, I am willing to look into implementing this, if it's something the Electron team would be willing to accept as a feature.

Thank you!

### Testcase Gist URL

https://gist.github.com/matthewjamesadam/ed16e517839534149c0ee001db6af256

### Additional Information

_No response_
Repository: flutter
Issue: [Feature Request] Implement Cross-Compilation for Linux Arm64 on Linux x86_64
Labels: tool,platform-linux,c: proposal,a: desktop,P3,team-linux,triaged-linux

### Use case

The current Flutter build process allows creating apps for Linux Arm64 on Linux Arm64 machines. However, developers might need to build for Linux Arm64 from a Linux x86_64 machine.

One use case is for in-depth exploration of the Flutter engine. For instance, developers might want to build a custom engine for Linux Arm64. I was encountered this scenario when I tried to reproduce a bug that only occurred on Linux Arm64. (#139293)

As of 2024, consumer-level Linux Arm64 workstations are scarce and most Linux Arm64 machines are low-powered devices like Raspberry Pi or Chromebooks. These devices
 often lack the processing power to build the Flutter engine with its thousands of C++ files. 

Conversely, powerful x86_64 workstations are common and are often used for Flutter engine development. Cross-compilation from Linux x86_64 to Linux Arm64 would greatly benefit developers in this scenario.

### Proposal

Fortunately, Flutter appears nearly ready for cross-compilation from Linux x86_64 to Linux Arm64. I successfully modified the Flutter tool code to support this functionality.

Here's the tested code:
Code: [link](https://github.com/bc-lee/test-flutter-linux/blob/81e444ecc0b43ec1fd49ad518ffd0fe63e13801b/.github/workflows/build.yml#L84)
Patches that I used: [link](https://github.com/bc-lee/test-flutter-linux/tree/81e444ecc0b43ec1fd49ad518ffd0fe63e13801b/patch)
Actual Result: [link](https://github.com/bc-lee/test-flutter-linux/actions/runs/9103709366/job/25026136271)

Required Changes in Flutter:

- [ ] Modify CMake invocation to accept `CMAKE_TOOLCHAIN_FILE` for cross-compilation.
- [ ] Allow users to download the Linux Arm64 engine binaries during `flutter build linux` or `flutter precache` commands.
- [ ] Remove the error message "Cross-build from Linux x64 host to Linux arm64 target is not currently supported." from the `flutter build linux` command.

I believe adding cross-compilation support for Linux Arm64 on Linux x86_64 would significantly benefit Flutter development. Thank you for considering this feature request.
Repository: go
Issue: build: build failure on x_tools-go1.22-windows-arm64
Labels: NeedsInvestigation

```
#!watchflakes
default <- builder == "x_tools-go1.22-windows-arm64" && repo == "tools" && mode == "build"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8747847168280286321)):

    2024/05/15 19:27:58 run starting
    [I2024-05-15T19:27:58.671267Z 27096 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-05-15T19:27:58.671824Z 27096 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-05-15T19:27:58.672349Z 27096 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-05-15T19:27:58.675561Z 27096 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-05-15T19:27:58.675561Z 27096 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-05-15T19:27:58.676098Z 27096 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-05-15T19:27:58.677011Z 27096 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    2024/05/15 19:28:10 installed tools
    [I2024-05-15T19:28:10.133616Z 27096 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    ...
    [E2024-05-15T19:28:17.236937Z 27096 0 errors.go:128] set status: FAILURE: EOF
      with SummaryMarkdown:
    **FAILURE**
    
    * go on release-branch.go1.22 ([commit 3a84293](https://go.googlesource.com/go/+/3a842931184426ebb2d5f8605782991bca8b67b8))
    * tools on master ([commit 069435c](https://go.googlesource.com/tools/+/069435cd8cd3b1a32ff446391162db157f3ab1d7))
    
    Error: `EOF`
    
    Links:


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: godot
Issue: [Source Generator] Unable to disable multiple source generators using `GodotDisabledSourceGenerators` property
Labels: bug,topic:dotnet

### Tested versions

### Godot
*Based on looking at the github, all versions have this bug*
- 4.2.1
### Visual Studio
- 17.9.0
- 17.9.7


### System information

Windows 10 - x64 - vs17.9.7

### Issue description

For some reason C# source generators attempting to access global config properties that have a value with a `;` in them result in said value getting truncated.

For example:
```xml
<Project Sdk="Godot.NET.Sdk/4.2.1">
  <!-- ... -->

  <PropertyGroup>
    <GodotDisabledSourceGenerators>GodotPluginsInitializer;ScriptPathAttribute</GodotDisabledSourceGenerators>
  </PropertyGroup>
</Project>
```

When the source generators run, they only see the value `GodotPluginsInitializer` for the `GodotDisabledSourceGenerators` property even though the generated `GeneratedMSBuildEditorConfig.editorconfig` has `build_property.GodotDisabledSourceGenerators` set to `GodotPluginsInitializer;ScriptPathAttribute`

I wrote my own Source Generator to verify.

This is what's inside the `GeneratorExecutionContext`:
![image](https://github.com/godotengine/godot/assets/29237603/46b510e3-efa5-471a-8d58-394cd71defcf)

But note this is the generated `GeneratedMSBuildEditorConfig.editorconfig` that is created inside the `obj` folder:
![image](https://github.com/godotengine/godot/assets/29237603/5e5b45a4-ee0c-4265-a020-9b053c08de82)

The values of `GodotDisabledSourceGenerators` in the source generator conflict with the values inside the editor config.

To fix this issue, the separator can be changed from a `;` to a `,`.



### Steps to reproduce

1. Edit the `csproj` file of a C# Godot Project to include the following line in between a `<PropertyGroup>` tag in Visual Studio 2022:
```xml
<GodotDisabledSourceGenerators>GodotPluginsInitializer;ScriptPathAttribute</GodotDisabledSourceGenerators>
```
2. Add the following class to the project:
```cs
using Godot;

public partial class DummyClass : Resource
{
}
```
3. Build the C# Godot Project
4. Inspect the C# Godot Project with ILSpy or an equivalent
5. Notice the `GodotPlugins.Game` was not generated
6. Decompile `DummyClass`
7. DummyClass has the `ScriptPathAttribute` on it, even though the `ScriptPathAttribute` source generator was meant to be disabled.

### Minimal reproduction project (MRP)

N/A
Repository: flutter
Issue: [Impeller] Support rendering compressed texture formats / add capability to detect support.
Labels: c: new feature,P3,e: impeller,team-engine,triaged-engine

I _think_ that we could fairly easily add support for compressed image formats to Impeller, at least on the Vulkan and Metal backends.

Vulkan: https://docs.vulkan.org/spec/latest/appendices/compressedtex.html
iOS: https://developer.apple.com/documentation/metal/mtlpixelformat/mtlpixelformatastc_6x6_hdr?language=objc 

I'm not sure what the actual level of device support is on Vulkan and would need to do some research. For iOS, there is a handy feature set table here:  https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf . We could look at the intersection of minimum supported formats as a starting point.

These formats specify how pixel data is compressed, but don't include header information on the format/size like commonly used network image formats like PNG/JPEG. This metadata would need to be provided by the application. I'm not sure if there are other standards here like ASTC in PNG or if the expectation is that the application level logic will handle transport compression/bundling.

For example, a low-level dart:ui API for decompressing.
```dart
import 'dart:ui' as uil
[
void main() {
  Uint8List data = getBytes(...);
  if (!ui.Codec.checkFormatSupport(PixelFormatASTC_4x4_sRGB)) { //Probably a different name
    return;
  }
  var ui.image = await ui.decodeCompressedTexture(data, width: 100, height: 100, format: VK_FORMAT_BC1_RGB_UNORM_BLOCK);
 
```

Then some higher level Image provider API:

```dart
Image.network(
  ...
  compressedFormat: CompressedFormat(PixelFormatASTC_4x4_sRGB, width: 100, height: 100)
 )

```


For testing/evaluating, there is an open source ASTC compressor developed by ARM available at https://github.com/ARM-software/astc-encoder.

Some caveats:
  * We can't support these in the Skia backend as the formats are unsupported as far as I know, unless we wrote separate import code and treated them as external textures (which I'd rather not do).
  * We currently resize images using Skia's software codecs which don't support these formats, so resizing would fail until we switch to GPU based resizing.
Repository: pytorch
Issue: Dynamo ignores frame using yield
Labels: triaged,oncall: pt2,module: dynamo

### 🐛 Describe the bug

OptimizeContext is wrapped, and frame evaluation callback seems to be set to convert_frame. But there's no dynamo logs and the entire frame seems to run in eager.

```
import torch
from torch._dynamo import config

def fn():
    model = torch.nn.Sequential(
        torch.nn.Linear(400, 4),
        torch.nn.Sigmoid(),
    )

    for _ in range(3):
        x = torch.randn([100, 400])

        result = model(x).sum()
        result.backward()
        yield model[0].weight.grad
        yield model[0].bias.grad
        model.zero_grad()

opt_fn = torch.compile(fn)
outs = opt_fn()
res = list(outs)
```

### Versions

main

cc @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng
Repository: vscode
Issue: Can't click on links in streaming chat response
Labels: bug,chat

I wanted to go and see the file that copilot was talking about before its response finished. It seems like links to files and methods are detected in realtime, as they appear in blue in chat, but clicking on them does nothing until the response is finished.
Repository: ollama
Issue: Support RX6600 (gfx1032) on windows (gfx override works on linux)
Labels: bug,windows

### What is the issue?

Hi,
Ollama(0.1.32) is working awesome with Zluda using AMD RX6600 on windows 10.

But I have downloaded and tested the all above versions from"0.1.33 to 0.1.38" Ollama is not working with Zluda.
It gives error "0xc000001d"

So, now I downgraded and using 0.1.32 with Zluda.

Is it Zluda's issue or Ollama's?
Can anyone help me working with newer versions of Ollama?

### OS

Windows

### GPU

AMD

### CPU

Intel

### Ollama version

0.1.32
Repository: go
Issue: build: build failure on x_vulndb-gotip-darwin-amd64_13
Labels: NeedsInvestigation

```
#!watchflakes
default <- builder == "x_vulndb-gotip-darwin-amd64_13" && repo == "vulndb" && mode == "build"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8750469220618232881)):

    2024/04/16 13:28:00 run starting
    [I2024-04-16T13:28:00.736369-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:28:00.739038-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:28:00.739744-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:28:00.739916-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:28:00.740114-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:28:00.740385-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:28:00.740569-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:28:01.995379-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:28:01.995894-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    ...
    [I2024-04-16T13:31:28.213119-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:31:33.502867-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:31:33.504128-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:31:33.504318-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:31:33.505264-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:31:33.505602-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:32:59.250583-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:32:59.251471-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:32:59.251546-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)
    [I2024-04-16T13:32:59.251591-07:00 1114 0 options.go:162] dropping Batch(len(Data): 1, Meta: <nil>)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: build: build failure on x_vulndb-gotip-darwin-amd64_11
Labels: NeedsInvestigation

```
#!watchflakes
default <- builder == "x_vulndb-gotip-darwin-amd64_11" && repo == "vulndb" && mode == "build"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8747839578700784817)):

    Building Go cmd/dist using /Users/swarming/.swarming/w/ir/cache/tools/go_bootstrap. (go1.20.6 darwin/amd64)
    Building Go toolchain1 using /Users/swarming/.swarming/w/ir/cache/tools/go_bootstrap.
    Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
    Building Go toolchain2 using go_bootstrap and Go toolchain1.
    # cmd/vendor/golang.org/x/telemetry/internal/crashmonitor
    ../../w/goroot/src/cmd/vendor/golang.org/x/telemetry/internal/crashmonitor/crash_go123.go:13:19: cannot use debug.SetCrashOutput (value of type func(f *os.File, opts ...debug.CrashOptions) error) as func(*os.File) error value in assignment
    go tool dist: FAILED: /Users/swarming/.swarming/w/ir/x/w/goroot/pkg/tool/darwin_amd64/go_bootstrap install -pgo=off cmd/asm cmd/cgo cmd/compile cmd/link cmd/preprofile: exit status 1


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: build: build failure on x_vulndb-gotip-darwin-amd64_12
Labels: NeedsInvestigation

```
#!watchflakes
default <- builder == "x_vulndb-gotip-darwin-amd64_12" && repo == "vulndb" && mode == "build"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8747839578284138177)):

    Building Go cmd/dist using /Users/swarming/.swarming/w/ir/cache/tools/go_bootstrap. (go1.20.6 darwin/amd64)
    Building Go toolchain1 using /Users/swarming/.swarming/w/ir/cache/tools/go_bootstrap.
    Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
    Building Go toolchain2 using go_bootstrap and Go toolchain1.
    # cmd/vendor/golang.org/x/telemetry/internal/crashmonitor
    ../../w/goroot/src/cmd/vendor/golang.org/x/telemetry/internal/crashmonitor/crash_go123.go:13:19: cannot use debug.SetCrashOutput (value of type func(f *os.File, opts ...debug.CrashOptions) error) as func(*os.File) error value in assignment
    go tool dist: FAILED: /Users/swarming/.swarming/w/ir/x/w/goroot/pkg/tool/darwin_amd64/go_bootstrap install -pgo=off cmd/asm cmd/cgo cmd/compile cmd/link cmd/preprofile: exit status 1


— [watchflakes](https://go.dev/wiki/Watchflakes)