sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: SDPA 2.5 Issue tracking
Labels: triaged,module: sdpa

# Summary
Track and burn down all issues with 2.5 release for sdpa:
## CUDNN backend issues: Mitigated
#### Issues
1. https://github.com/pytorch/pytorch/issues/138529
2. https://github.com/huggingface/diffusers/issues/9704
3. https://github.com/pytorch/pytorch/issues/138340 / https://github.com/pytorch/pytorch/pull/138354
4. https://github.com/pytorch/pytorch/issues/139586

In light of the above we are going to make the CuDNN backend Opt-in by default.
This can be done easily with the context manager for choosing backends I.e.:
```Python
from torch.nn.attention import sdpa_kernel, SDPBackend    

with sdpa_kernel(SDPBackend.CUDNN_ATTENTION):
    out = F.scaled_dot_product_attention(q, k, v)
 ```
 #### PRs
 1. https://github.com/pytorch/pytorch/pull/138522
 2. https://github.com/pytorch/pytorch/pull/139450 Fixes htod sync
 
 
 ## SDPA  + Compile Issues: WIP
1. https://github.com/pytorch/pytorch/issues/133974

##### Fixing PR:
https://github.com/pytorch/pytorch/pull/138624. Verified on the repro as well as locally an E2E repro using [benchmark.py](https://github.com/huggingface/pytorch-image-models/blob/main/benchmark.py)

Command: `python benchmark.py --model samvit_base_patch16 --torchcompile  -b 32  --amp --img-size 256 --num-classes 10 --no-retry`

#### 2. Illegal memory access with memory efficient attention
https://github.com/pytorch/pytorch/issues/138772

#### Workaround:
https://github.com/pytorch/pytorch/blob/0a38c0ec89ab393be91619393063ea30908a5d55/torch/_inductor/config.py#L398 Set this flag to False
Repository: react
Issue: [Compiler Bug]: Lint plugin is too strict about passing hooks as values
Labels: Type: Bug,Status: Unconfirmed,Component: Optimizing Compiler

### What kind of issue is this?

- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://github.com/adobe/react-spectrum/issues/7220

### Repro steps

In React Aria, we have several instances where we use dependency injection to reduce bundle size impact and allow global configuration.

* [RouterProvider](https://react-spectrum.adobe.com/react-aria/routing.html#react-router) accepts a `useHref` prop that allows globally configuring all links in an app. Usually you pass a value directly imported from another library like `react-router-dom`, which should be safe (the function never changes).
* Our implementation of [drag and drop](https://react-spectrum.adobe.com/react-aria/ListBox.html#reorderable) is dependency injected to reduce bundle size. Rather than building the entire drag and drop implementation (which can be quite large) into all components that support it and bloating their bundle size even if you aren't using drag and drop, the drag and drop hooks are injected only if you actually use it. Again, since the actual function implementation of these hooks are static and never change, this can be done safely.

The new lint plugin now causes errors in these cases for users of our library (see https://github.com/adobe/react-spectrum/issues/7220), which I believe to be safe. The [documentation](https://react.dev/reference/rules/react-calls-components-and-hooks#never-pass-around-hooks-as-regular-values) describes a few reasons why this might be avoided in regular app code, such as debuggability and locality of behavior, but does not describe any reason why this would actually break anything. Swapping to a different function at runtime would be one such case, but if you don't do that I think it is safe.

Is it possible to loosen this rule so that the _value_ of the hook that is passed into a component is checked to determine if it is static? For example, if you pass down a function in module scope, or something imported from another module, this should be safe since the value never changes, but if you pass down an unmemoized callback declared within a component as a hook this would not be allowed.

### How often does this bug happen?

Every time

### What version of React are you using?

N/A

### What version of React Compiler are you using?

N/A
Repository: next.js
Issue: Setting a metadata field to undefined prevents falling back to the parent component's metadata value
Labels: bug,Metadata

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/dark-architecture-go8s7s

### To Reproduce

1. Load the repro application in [Codesandbox](https://codesandbox.io/p/devbox/dark-architecture-go8s7s)
2. View source on the homepage - confirm that the "description" meta tag appears in the document <head>
3. Click the link to visit the About page - confirm that the "description" meta tag appears in the document <head>
4. Click the link to visit the Dashboard page - observe that no "description" meta tag appears in the <head>

### Current vs. Expected behavior

Expected behavior:
When the "description" field is either absent, or present but undefined in the metadata object, the value rendered on the page will be the fallback parent's "description" field.

Actual behavior
When the description field is absent from the metadata, the value will use the parent's metadata as expected. But if the field is present but undefined, no fallback will be used, and no description tag will be rendered.

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 15.0.1-canary.2 // Latest available version is detected (15.0.1-canary.2).
  eslint-config-next: N/A
  react: 19.0.0-rc-69d4b800-20241021
  react-dom: 19.0.0-rc-69d4b800-20241021
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


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

Metadata

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

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

### Additional context

It seems like a common use case to try to set a metadata field with a possibly undefined value.

An example:

```typescript
export async function generateMetadata(
  { params, searchParams }: Props
): Promise<Metadata> {
  // read route params
  const id = (await params).id
 
  // fetch data
  const product = await fetch(`https://.../${id}`).then((res) => res.json())

  return {
    title: product.title,
    // use optional chaining to access the subtitle, which will fall back to undefined if the product is not present
    // this may also be undefined if subtitle is an optional field
    description: product?.subtitle
  }
}
```


I would expect that if the value is undefined, the parent metadata value is shown. But instead the field is removed completely from the document. This is unexpected.
Repository: react
Issue: make `react-hooks/exhaustive-deps` respect destructuring assignment
Labels: Status: Unconfirmed

I wanna exhaustive-deps will allow destructuring assignment syntax, for example

```ts
type Props = {
  a: string
  b: number
  c: any[]
}

useMemo(() => {
  const { a, b, c } = props
}, [props.a, props.b, props.c]) // <- should pass ideally
```

You might think I can do by this

```ts
const { a, b, c } = props
useMemo(() => {

}, [a, b, c])
```

But I **don't wanna assign to a new variable in the component-level**, imaging this component have hundred of lines, but also I don't want to write `props.a/b/c` inside hook again and again like this

```ts
useMemo(() => {
  // hard to read code
  props.a *  props.b -  props.c + props.a +  props.b + props.c
}, [props.a, props.b, props.c]) // <- should pass ideally
```

This might related to https://github.com/facebook/react/issues/16265 but I think my issue is slightly different. I think we should still not allowed to call a function inside hook without full `props` as deps

```ts
type Props = {
  a: () => void
}
useMemo(() => {
  const { a } = props
  a() // still not allowed
}, [props.a]) // <- ERROR, should be props
```
Repository: flutter
Issue: `flutter <build> <ios>` regenerates plugins multiple times?
Labels: tool,P2,c: tech-debt,team-ios,triaged-ios,fyi-tool

To reproduce:

```diff
diff --git a/packages/flutter_tools/lib/src/flutter_plugins.dart b/packages/flutter_tools/lib/src/flutter_plugins.dart
index 67e9799087..0f543219f5 100644
--- a/packages/flutter_tools/lib/src/flutter_plugins.dart
+++ b/packages/flutter_tools/lib/src/flutter_plugins.dart
@@ -1011,6 +1011,7 @@ Future<void> refreshPluginsList(
   bool macOSPlatform = false,
   bool forceCocoaPodsOnly = false,
 }) async {
+  print('>>> refreshPluginList() ::: ${StackTrace.current}');
   final List<Plugin> plugins = await findPlugins(project);
   // Sort the plugins by name to keep ordering stable in generated files.
   plugins.sort((Plugin left, Plugin right) => left.name.compareTo(right.name));

```

And then create and run an iOS (and I believe, MacOS) build:

```sh
$ flutter create . --platforms ios

>>> refreshPluginList() :: refreshPluginsList (package:flutter_tools/src/flutter_plugins.dart:1103:51)
#1      FlutterProject.ensureReadyForPlatformSpecificTooling (package:flutter_tools/src/project.dart:373:11)
#2      FlutterProject.regeneratePlatformSpecificTooling (package:flutter_tools/src/project.dart:344:12)
#3      FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:1793:21)

>>> refreshPluginList() ::: #0      refreshPluginsList (package:flutter_tools/src/flutter_plugins.dart:1103:51)
#1      processPodsIfNeeded (package:flutter_tools/src/macos/cocoapod_utils.dart:29:9)
#2      buildXcodeProject (package:flutter_tools/src/ios/mac.dart:280:9)
#3      _BuildIOSSubCommand.runCommand (package:flutter_tools/src/commands/build_ios.dart:701:37)
```

As far as I can tell, every `FlutterCommand` regenerates plugins as long as `shouldRunPub` is set, so when the code was added (again) in https://github.com/flutter/flutter/pull/146256 it might have been duplicate work? Defer to the iOS team, maybe they see something I don't.

(This complicates conditionally removing the `.flutter-plugins` file which is why I'm bringing it up)
Repository: godot
Issue: [4.4.dev3] Forward+ Vertex Lighting clipping on the bottom of viewport/camera/screen for some resolutions
Labels: bug,topic:rendering,needs testing

### Tested versions

- reproducable in v4.4.dev3.official [f4af8201b]

### System information

Linux (Zorin OS) - Godot v4.4.dev3.official [f4af8201b] - Vulkan (Forward+)

### Issue description

When trying the new vertex lighting I noticed an issue with the light clipping along the bottom of my screen.
I have been trying to find out the cause and the only real noticable factor is that if I set the resolution of the game to match the project settings viewport width/height, the clipping dissapears.

Here is a quick video I took, showing the "clipping" that I'm seeing: https://youtu.be/lCEZt4iT70U

Of course I'm also expecting that maybe it's unique to linux but I'm hoping that it's not a significant factor :crossed_fingers: 

### Steps to reproduce

Below are the specific lines that I use to change the resolution within my settings menu.
To reproduce, set the project viewport size to something like "1920x1080" and then use the lines below to set it to something else like "2560x1440" or "1280x720"

```
get_window().set_size(OPTION_LIST_[currentValue])
get_viewport().set_size(OPTION_LIST_[currentValue])
```

Hope this helps, I am of course here for further assistance.

### Minimal reproduction project (MRP)

Here is a small test project I threw together: https://github.com/Momonyaro/vertex-lit-issue
There was another issue on my end with the settings menu, making it a bit flakey but it should help show the effect when you play around with the fullscreen/resolution toggle
Repository: three.js
Issue: Compute Pipeline - incorrect shader computeProgram bindings returned when using WebGL backend
Labels: WebGL Backend

### Description

I've been loving all the great new uses for compute shaders now available, however, I've been battling many issues when using the WebGL backend.

When using different, unique buffers inside of unique instances of compute node functions with the webgl backend, it seems that a part of the inner caching system will reuse the same shader program (seemingly like we'd want), but, then also use the same buffer... causing all kinds of weird things to happen as multiple calls to compute with different compute nodes end up targeting only a single bound buffer (usually the first one bound/used).

The WebGPU backend handles these situations without any problems and correctly runs the compute program on the correct buffers.

I've found a hacky workaround that fixes things - simply naming each compute node something unique.

The issue can be shown by logging inside the Pipelines.js file:
    getForCompute(computeNode, bindings) {
        const { backend } = this;

        const data = this.get(computeNode);

        console.log("WebGL fallback - getForCompute", computeNode, data);
       // data.pipeline.cacheKey is unique for unique nodes meant to use unique corresponding buffers
       // however, data.pipeline.computeProgram is reused shader with incorrect buffer binding




### Reproduction steps

- use forceWebGL: true, to use WebGL backend
- use a loop to create multiple instanced buffers
(storage(new StorageInstancedBufferAttribute(count, vecPackingSize), vecPackingType, count) as any;)
- create compute Fn using buffers inside loop
- view incorrect results (with particles, or geometry, etc)

### Code

// Inside of a function eventually called multiple times with different buffers...
        const positionBuffer = _input.positionBuffer;
        const parentPositionUniform = this.parentPositionUniform;
        const count = this.count;

        const testUpdate = Fn(({ posBuffer, posSetValue }) => {
            const position = posBuffer.element(instanceIndex);
            position.x = posSetValue.x;
            position.y = posSetValue.y;
            position.z = posSetValue.z;
            return null;
        });
        const testCompute = testUpdate({ posBuffer: positionBuffer, posSetValue: parentPositionUniform }).compute(count);
        testCompute.name = "Test"; // Non-unique name ----> Fails!
        // testCompute.name = "Test" + Helper.generateNewId(); // Unique name ----> Works!
        physicsManager.registerLateFrameCompute(testCompute);



### Live example

(sorry, no live example)


### Screenshots

_No response_

### Version

169

### Device

Desktop

### Browser

Chrome

### OS

Windows
Repository: electron
Issue: Seeing `Hit debug scenario: 4` when loading about:blank into an iframe
Labels: platform/windows,platform/macOS,bug :beetle:,has-repro-gist,32-x-y

### 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

32.0.0

### What operating system(s) are you using?

macOS

### Operating System Version

14.6.1

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

31.7.1

### Expected Behavior

I shouldn't see `ERROR:debug_utils` statements in the console when loading `about:blank` into an iframe.

### Actual Behavior

I see the following when I set `iframe.src` to `about:blank`.

```
[18853:1022/171735.509459:ERROR:debug_utils.cc(14)] Hit debug scenario: 4
```

### Testcase Gist URL

https://gist.github.com/fb33dfbc66d4e5ed49cc5801e2338364

### Additional Information

_No response_
Repository: ui
Issue: [BUG][CLI]: Generating Tailwind Config Radius
Labels: bug

### Describe the bug

After generating via the CLI, which adjusts the tailwind.config.js, some characters are not removed, and the character ` remains in the borderRadius section.

Example:

`tailwind.config.js`
```javascript
  borderRadius: {
  	lg: '`var(--radius)`', <- contains ` in string
  	md: '`calc(var(--radius) - 4px)`', <- contains ` in string
  	sm: 'calc(var(--radius) - 2px)'
  },
```

### Affected component/components

All components using rounded-*

### How to reproduce

1. Generate a new project
2. Initialize shadcn
3. Check `tailwind.config.js`

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
System: macOS 15.0.1 (24A348)
Node: v20.11.0
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: go
Issue: cmd/go: env -changed misses CGO_LDFLAGS, others
Labels: NeedsInvestigation,GoCommand

### Go version

go version go1.23.2 darwin/arm64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/rob/Library/Caches/go-build'
GOENV='/Users/rob/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/rob/.local/share/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/rob/.local/share/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.23.2/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.23.2/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.2'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/rob/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-w'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/ry/6bttgkt51f14fhb1cwsg_6r00000gp/T/go-build1178049255=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

Change the default value of `CGO_LDFLAGS`:

```sh
go env -w CGO_LDFLAGS=-w
```

Then check what values have changed:

```
go env -changed
```

### What did you see happen?

No output

### What did you expect to see?

I expected the output to be:
```
CGO_LDFLAGS='-w'
```

When most env variables are overridden in this way, they correctly show up in the output. Since `CGO_LDFLAGS` is one of the values that shows up in the output of `go env` without any flags, I would also expect it to be reflected with `go env -changed` when the value was non-default.

I have tested this with a few other cases and found inconsistent results, including:
- Some flags like `CGO_ENABLED`, `GOPATH`, `GOPRIVATE`, and `CGO_CFLAGS` are respected
- Other flags like `CGO_LDFLAGS` and `GCCGO` are not respected. It might literally be just these two, but I only tested a handful
- `go env -changed` does not seem to report a value if the corresponding environment variable is exported. To reproduce:
```
$ go env -w CGO_ENABLED=0
$ go env -changed
CGO_ENABLED='0'
$ CGO_ENABLED=0 go env -changed
$ CGO_ENABLED=2 go env -changed
```

I could not find anything in the original proposal (#34208) or in the docs (`go help env`) that would suggest why this would be the expected behavior.
Repository: rust
Issue: Repeated calls to the same `async` fn can cause stack overflow
Labels: T-compiler,C-bug,A-async-await

<!--
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
#[tokio::main]
async fn main() {
    test_buf().await;
    test_buf().await;
    test_buf().await;
    // ... Execute n times, do not use for loop
}
async fn test_buf(){
    let buf = [0;65536];
    test_buf0(&buf).await;
}
async fn test_buf0(_buf:&[u8]){}
```

I expected to see this code can work

Instead, this happened: 
> fatal runtime error: stack overflow


`rustc --version --verbose`:
```
rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-apple-darwin
release: 1.82.0
LLVM version: 19.1.1

```

This issue can also be directly reproduced on [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fd1207e911482b5bf9392e7e7e90fb22), since the stack size on Linux is larger than that on Windows, the `n` times that can reproduce the issue is greater than that on Windows

```
Exited with signal 6 (SIGABRT): abort program

Standard Error

   Compiling playground v0.0.1 (/playground)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.38s
     Running `target/debug/playground`

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
```


The tokio side think this should be a bug of the compiler, https://github.com/tokio-rs/tokio/issues/5909
Repository: excalidraw
Issue: Cmd+C and Cmd+V not working on iPadOS
Labels: bug,safari

The app seems to work pretty flawlessly on Safari with an attached keyboard (iPadOS 17.4.1, iPad 10th Generation), but Cmd+C and Cmd+V don't seem to be caught by Excalidraw outside of text editing mode. 

This would be helpful to copy and paste shapes around diagrams, like you can in Safari + Chrome on macOS. 

I have verified that the key codes that are being sent on iPadOS are the same key codes that are being sent on macOS, so it seems like Excalidraw just isn't catching these keys / key codes out side of text editing mode on iPadOS. 

```
Key: Meta, Key Code: 91
Key: c, Key Code: 67
Key: v, Key Code: 86
```

Is this intentional behavior and is there a workaround if so? 

Please see the attached screen recordings to see this behavior compared on iPadOS and macOS.

https://github.com/user-attachments/assets/9ad5e4d2-f022-4c5e-8fe8-909f5a7513aa

https://github.com/user-attachments/assets/8d2730b4-2e59-4d42-9013-4918ce760407

Thanks
Repository: vscode
Issue: Link with :lineNumber didn't work on Terminal
Labels: bug,help wanted,confirmed,terminal-links

<!-- ⚠️⚠️ 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/No

<!-- 🪓 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.94.2
- OS Version: Windows 11 24H2

Steps to Reproduce:

![Image](https://github.com/user-attachments/assets/006d9fd4-46fa-4ab2-8b49-40e44dc40451)

As you can see, the :lineNumber wasn't included in the link, so I can't click on the link to go to the file with the line number specified.