sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: net: TestUDPServer/2 failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "net" && test == "TestUDPServer/2"
```

Issue created automatically to collect these failures.

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

    === RUN   TestUDPServer/2
        server_test.go:258: udp [::ffff:0.0.0.0]:0<-127.0.0.1
        server_test.go:322: server: read udp [::]:56739: i/o timeout
        server_test.go:315: client: read udp 127.0.0.1:50097: i/o timeout
    --- FAIL: TestUDPServer/2 (3600.00s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: next.js
Issue: Prefetched PPR page segments stay suspended when navigated to after a rebuild
Labels: Partial Prerendering (PPR),dynamicIO

### Link to the code that reproduces this issue

https://github.com/bradleydsmith/reproduction-next-prefetch-rebuild-ppr-suspended

### To Reproduce

1. Build the application with npm run build
2. Start the server with npm run start
3. Navigate to http://localhost:3000 and do not click anything or close the page
4. Stop the server
5. Run npm run build
6. Start the server again with npm run start
7. Click the Prefetched link on the page

### Current vs. Expected behavior

When following the steps the suspended segment stays suspended and does not get resolved and rendered. I expected the page to do an MPA navigation and reload due to detecting a change in the response build ID

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:09:52 PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64
  Available memory (MB): 8192
  Available CPU cores: 8
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: N/A
  pnpm: 9.6.0
Relevant Packages:
  next: 15.2.0-canary.14 // Latest available version is detected (15.2.0-canary.14).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A
```

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

dynamicIO, Partial Prerendering (PPR)

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

Vercel (Deployed), next start (local), next build (local)

### Additional context

The issue is being caused by an incorrect check in listenForDynamicRequest. The issue occurs after a rebuild of the server, this could be a local rebuild and restart of the server but also affects a deployment to Vercel without skew protection. Also note how the issue does not happen on the Not Prefetched link, it only affects prefetched pages
Repository: rust
Issue: new build_helper::compiletest module for safer invocations of compiletest by bootstrap
Labels: C-cleanup,T-bootstrap,A-compiletest

currently bootstrap just uses strings to represent various compiletest arguments, such as mode.

obviously it would be better to use enums for these, as they are much less vulnerable to typos.

`compiletest` already has enum definitions for these (in `common.rs`), and the two already have a shared dependency (`build_helper`), and `build_helper` already has access to `serde`.

i would be willing to work on this refactor, if people think it would be a good idea.
Repository: rust
Issue: universally directly depend on serde_derive instead of accessing it through serde.
Labels: C-cleanup,T-bootstrap

bootstrap does this in order to flatten its dependencies and improve build times, but since other crates (like `compiletest` and `rustdoc`) use the `derive` feature flag, i believe this means `serde` has to be built twice to use any of these programs.

wouldn't it be best to always use the same set of feature flags to serde?
Repository: deno
Issue: Error when using TS Decorators
Labels: needs investigation

Version: Deno 2.1.6

Error when using argument decorators

![Image](https://github.com/user-attachments/assets/6bc5e380-6dde-4770-9ace-cbb72178a9f6)
Repository: rust
Issue: Change in leaf function causes unrelated compilation error in root function
Labels: A-lifetimes,A-trait-system,needs-triage

## Description

I encountered an issue where changing the leaf function causes a compilation error in the root function, but the change doesn't affect types or auto traits of the function.
Commenting out `router()`  makes code to compile.

## Minimal Example

```rust
use axum::routing::{post, Router};

use futures_util::StreamExt;
use std::collections::HashMap;
use std::sync::Arc;

struct Transaction {
    f1: (),
    f2: (),
}

pub(crate) struct SplitAddress(());

async fn handler_inner(ctx: Context) {
    let transactions = vec![];

    // This causes the lifetime issue:
    let iter = transactions
        .iter()
        .map(|x: &Transaction| (x.f1, SplitAddress(x.f2)));

    // This works:
    // let iter: Vec<_> = transactions
    //     .iter()
    //     .map(|x: &Transaction| (x.f1, SplitAddress(x.f2)))
    //     .collect();

    ctx.0.streaming_work(iter.into_iter()).await;
}

async fn handler() -> Result<String, String> {
    let ctx = Context(Arc::new(Service()));
    handler_inner(ctx).await;
    Ok("ok".to_string())
}

// or comment out router
pub async fn router() -> Router {
    Router::new().route("/bla", post(handler))
}

#[derive(Clone)]
pub struct Context(Arc<Service>);

struct Service();

impl Service {
    pub(crate) async fn streaming_work(
        &self,
        data: impl Iterator<Item = ((), SplitAddress)>,
    ) -> HashMap<(), Vec<String>> {
        futures_util::stream::iter(data)
            .map(|_| async move { todo!() })
            .buffer_unordered(100)
            .filter_map(|x| async move { x })
            .collect()
            .await
    }
}

```

[repo](https://github.com/0xdeafbeef/rustc-issue)

## Error Message
```
error: implementation of `FnOnce` is not general enough
  --> src/lib.rs:39:33
   |
39 |     Router::new().route("/bla", post(handler))
   |                                 ^^^^^^^^^^^^^ implementation of `FnOnce` is not general enough
   |
   = note: closure with signature `fn(&'0 Transaction) -> ((), SplitAddress)` must implement `FnOnce<(&'1 Transaction,)>`, for any two lifetimes `'0` and `'1`...
   = note: ...but it actually implements `FnOnce<(&Transaction,)>`

error: could not compile `rust-issue` (lib) due to 1 previous error
```
Repository: pytorch
Issue: torch._C._IncludeDispatchKeyGuard is very broken?
Labels: triaged,module: dispatch

```py
import torch

print(torch._C._meta_in_tls_dispatch_include())
with torch._C._IncludeDispatchKeyGuard(torch.DispatchKey.Meta):
    print(torch._C._meta_in_tls_dispatch_include())
print(torch._C._meta_in_tls_dispatch_include())
```

prints False, True, True, which is completely bogus
Repository: godot
Issue: Camera3D preview may show temporary visual glitch when selected
Labels: bug,topic:editor

### Tested versions

- Godot v4.4.beta1
- related https://github.com/godotengine/godot/pull/90778

### System information

Windows 11 (build 22631) - Single-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 (NVIDIA; 32.0.15.6614) - Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (12 threads)

### Issue description

When there are multiple cameras and you switch between them, there may be a short visual glitch in the camera preview.
It doesn't really need multiple cameras to happen, but it happens less often.

https://github.com/user-attachments/assets/92811fc9-99c5-4873-92e3-15a639ddc09d

Maybe related: the preview updates late in some cases, see https://github.com/godotengine/godot/pull/90778#issuecomment-2395606441

The preview should not show anything until it is ready.

### Steps to reproduce

1. Add 2 Camera3Ds to a scene.
2. Repeatedly switch between them while watching the preview.
3. You may see visual glitches.

### Minimal reproduction project (MRP)

Not really needed but here:
[camera_preview_multiple_2025-01-17_15-18-50.zip](https://github.com/user-attachments/files/18459220/camera_preview_multiple_2025-01-17_15-18-50.zip)
Repository: vscode
Issue: Remote SSH freezing when loading extensions. Enabling remote.downloadExtensionsLocally did not help
Labels: triage-needed,stale


Type: <b>Bug</b>

In the server output I'm seeing:

2025-01-17 14:08:27.683 [error] [network] #1: https://main.vscode-cdn.net/extensions/marketplace.json - error GET read ETIMEDOUT

Yes I know remote SSH can be a problem if the remote server is behind a firewall. However I was hoping that the Extension Host could still work even in this case with a setting to download extensions locally.

Unfortunately this remote file is not working. Can you check to see if this was recently introduced?

VS Code version: Code 1.96.3 (91fbdddc47bc9c09064bf7acf133d22631cbf083, 2025-01-09T18:14:09.060Z)
OS version: Windows_NT x64 10.0.22631
Modes:
Remote OS version: Linux x64 5.14.0-437.el9.x86_64

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) Ultra 7 165U (14 x 2688)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|31.46GB (5.65GB free)|
|Process Argv|--crash-reporter-id 7e9e6a5c-e81d-4f36-9073-13611d70a8a4|
|Screen Reader|no|
|VM|0%|

|Item|Value|
|---|---|
|Remote|SSH: jumphost|
|OS|Linux x64 5.14.0-437.el9.x86_64|
|CPUs|Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz (2 x 0)|
|Memory (System)|3.82GB (1.96GB free)|
|VM|100%|
</details><details><summary>Extensions (5)</summary>

Extension|Author (truncated)|Version
---|---|---
catppuccin-vsc|Cat|3.16.0
remote-ssh|ms-|0.116.1
remote-ssh-edit|ms-|0.87.0
remote-explorer|ms-|0.4.3
ufuk-bakan-color-themes|Ufu|2.0.1

(3 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
2i9eh265:30646982
962ge761:30959799
pythonnoceb:30805159
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
dvdeprecation:31068756
dwnewjupyter:31046869
nativerepl2:31139839
pythonrstrctxt:31112756
nativeloc2:31192216
cf971741:31144450
iacca1:31171482
notype1:31157159
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530
390bf810:31215807
6074i472:31201624
dwoutputs:31217127

```

</details>

<!-- generated by issue reporter -->
Repository: material-ui
Issue: top-level-imports v5 changing color imports
Labels: bug 🐛,waiting for 👍,package: codemod,ready to take,v5.x

### Steps to reproduce

Steps:
1. Import grey from @mui/material/colors
`import { grey } from @mui/material/colors;`
2. npx @mui/codemod@latest v5.0.0/top-level-imports <path>
3. The import will change to `import { grey } from '@mui/material';`


### Current behavior

Steps:
1. Import grey from @mui/material/colors
`import { grey } from @mui/material/colors;`
2. npx @mui/codemod@latest v5.0.0/top-level-imports <path>
3. The import will change to `import { grey } from '@mui/material';`


### Expected behavior

`npx @mui/codemod@latest v5.0.0/top-level-imports <path>` should not change imports to those that are not valid


### Context

_No response_

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
    System:
    OS: macOS 15.1.1
  Binaries:
    Node: 21.2.0 - ~/node_modules/.bin/node
    npm: 10.7.0 - ~/.nvm/versions/node/v18.20.3/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 132.0.6834.83
    Edge: 131.0.2903.147
    Safari: 18.1.1
  npmPackages:
    @emotion/react: ^11.10.4 => 11.14.0 
    @emotion/styled: ^11.10.4 => 11.14.0 
    @mui/base:  5.0.0-beta.66 
    @mui/core-downloads-tracker:  5.16.11 
    @mui/icons-material: ^5.8.4 => 5.16.11 
    @mui/lab: ^5.0.0-alpha.95 => 5.0.0-alpha.174 
    @mui/material: ^5.10.1 => 5.16.11 
    @mui/material-nextjs: ^5.15.6 => 5.16.8 
    @mui/private-theming:  5.16.8 
    @mui/styled-engine:  5.16.8 
    @mui/styles: ^5.9.3 => 5.16.11 
    @mui/system:  5.16.8 
    @mui/types:  7.2.19 
    @mui/utils:  5.16.8 
    @mui/x-data-grid:  6.20.4 
    @mui/x-data-grid-pro: ^6.0.4 => 6.20.4 
    @mui/x-date-pickers:  6.20.2 
    @mui/x-date-pickers-pro: ^6.0.0 => 6.20.2 
    @mui/x-license-pro:  6.10.2 
    @types/react: ^18.0.28 => 18.3.16 
    react: ^18.2.0 => 18.3.1 
    react-dom: ^18.2.0 => 18.3.1 
    typescript: ^4.9.5 => 4.9.5 
```
</details>


**Search keywords**: codemod, top-level-import, color imports
Repository: tauri
Issue: [bug] `cargo tauri dev` does not kill the application before recompiling Rust/config changes on Windows
Labels: type: bug,status: needs triage

### Describe the bug

I used `cargo install tauri-cli@2.2.4` with toolchain 1.84 and started migrating a v1 project to v2. Everything seems to be working, except when I run the dev server with `cargo tauri dev` with the file watcher enabled, it no longer kills the child process before trying to rerun `cargo build` when I change the Rust code or the Tauri config. I think it might be due to changing the child process runner to use `cargo run`, and that it's killing the `cargo.exe` process but not the `appname.exe` process spawned by that.

### Reproduction

1. Create a Tauri React app.
2. Install the `tauri-cli` binary locally instead of using the version downloaded by `yarn`.
3. Run `cargo tauri dev`.
4. Touch/save a change to `src-tauri/tauri.conf.json`.

### Expected behavior

Along with killing the web dev server, and like on Unix-flavors, the app should be killed before rerunning `cargo build`. Otherwise, the file will still be in use and the dev server just errors out.

### Full `tauri info` output

```text
[⚠] Environment
    - OS: Windows 10.0.26100 x86_64 (X64)
    ✔ WebView2: 131.0.2903.146
    ✔ MSVC: Visual Studio Enterprise 2022
    ✔ rustc: 1.84.0 [redacted]
    ✔ cargo: 1.84.0
    ⚠ rustup: not installed!
      If you have rust installed some other way, we recommend uninstalling it
      then use rustup instead. Visit https://rustup.rs/
    ⚠ Rust toolchain: couldn't be detected!
      Maybe you don't have rustup installed? if so, Visit https://rustup.rs/
    - node: 22.5.1
    - yarn: 1.22.19
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.2.2
    - tauri-build 🦀: 2.0.5
    - wry 🦀: 0.48.1
    - tao 🦀: 0.31.1
    - tauri-cli 🦀: 2.2.4
    - @tauri-apps/api : 2.2.0
    - @tauri-apps/cli : 2.2.4

[-] Plugins
    - tauri-plugin-fs 🦀: 2.2.0
    - @tauri-apps/plugin-fs : 2.2.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
```

### Stack trace

```text

```

### Additional context

We periodically rebuild the Rust toolchain internally, which is why there's no default `rustup` and why I redacted some of the `rustc` fingerprint in the `tauri info` output. It's also why I always `cargo install tauri-cli` locally and run everything with `cargo tauri` rather than `yarn tauri`.
Repository: PowerToys
Issue: Task Scheduler fails to execute autorun
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

General

### Steps to reproduce

This is one of the "Autorun not working at startup" issues. The issue has only shown up within the past month after using PowerToys the last 4 years. I have been perusing the previous threads without much success, so I am sharing what I have attempted so far. 
- Toggling autorun on/off in the general settings UI.
- Tweaking Task Scheduler's startup condition (e.g., launching at startup regardless of log on behaviour)

Now Task Scheduler is being odd here. It claims to have successfully executed the scheduled task, but the Last Run Result displays the 0x41303 string (Not Running). Running the task manually does start PowerToys. 

![Image](https://github.com/user-attachments/assets/df016e27-af98-45c1-bb15-76d0575b8331)
![Image](https://github.com/user-attachments/assets/673e9f60-664c-4ef3-ab65-318892ac3abd)

### ✔️ Expected Behavior

PowerToys launching on startup

### ❌ Actual Behavior

PowerToys not launching on startup

### Other Software

_No response_
Repository: ui
Issue: [bug]: CLI not respecting settings in components.json
Labels: bug

### Describe the bug

```json
{
  "$schema": "https://ui.shadcn.com/schema.json",
  "style": "new-york",
  "rsc": false,
  "tsx": true,
  "tailwind": {
    "config": "tailwind.config.ts",
    "css": "app/app.css",
    "baseColor": "zinc",
    "cssVariables": true,
    "prefix": "",
    "tsx": true
  },
  "aliases": {
    "components": "~/app/components",
    "utils": "~/app/utilities",
    "ui": "~/app/components/ui",
    "lib": "~/app/utilities",
    "hooks": "~/app/hooks"
  },
  "iconLibrary": "lucide"
}
```

I have this for my components.json and whenever I install a new component the import for `cn` is always `import { cn } from "~/lib/utils"`

### Affected component/components

CLI

### How to reproduce

1. Install shadcn
2. Modify `components.json` with a new `utils` alias
3. Install any component (i.e.: `pnpm dlx shadcn@latest add checkbox`)
4. Open the checkbox and see that the config wasn't respected

### Codesandbox/StackBlitz link

_No response_

### Logs

```bash

```

### System Info

```bash
MacOS, Vite, React Router 7
```

### Before submitting

- [x] I've made research efforts and searched the documentation
- [x] I've searched for existing issues
Repository: PowerToys
Issue: [Github] PRs missing build CI checks
Labels: Issue-Bug,Priority-0,Area-Build,Needs-Team-Response,Status-Reproducible

### Repository Branch

main

### ❌ Actual Behavior

The build ci checks aren't running anymore after updating PRs against current main. Why?

xref: #33703 

![Image](https://github.com/user-attachments/assets/408b3350-22af-45fe-8e6c-d20a5310bcda)

### ✔️ Expected Behavior

Build CI checks are executed after pushing changes.
Repository: langchain
Issue: docs: Replace `initialize_agent` use with langgraph.prebuilt.create_react_agent
Labels: documentation,help wanted,good first issue,🤖:docs

### Privileged issue

- [x] I am a LangChain maintainer, or was asked directly by a LangChain maintainer to create an issue here.

### Issue Content

Currently there's a bunch of tools and other integrations that use `initialize_agent` in their docs page (search langchain/docs for "initialize_agent")

This function has been deprecated since 0.1 and should be replaced with basic langgraph usage as a demo

Deprecated function: https://python.langchain.com/api_reference/langchain/agents/langchain.agents.initialize.initialize_agent.html

Example page using create_react_agent in an example: https://python.langchain.com/docs/integrations/tools/gmail/#use-within-an-agent

This issue doesn't need to be resolved by a single PR and can be tackled incrementally! Just tag this issue for tracking purposes :)
Repository: rust
Issue: Tracking issue for release notes of #135656: Add `-C hint-mostly-unused` to tell rustc that most of a crate will go unused
Labels: T-compiler,relnotes,relnotes-tracking-issue


This issue tracks the release notes text for #135656.

### Steps

- [ ] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Category (e.g. Language, Compiler, Libraries, Compatibility notes, ...)
- [Add `-C hint-mostly-unused` to tell rustc that most of a crate will go unused](https://github.com/rust-lang/rust/pull/135656)
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @joshtriplett, @fee1-dead -- origin issue/PR authors and assignees for starting to draft text
Repository: godot
Issue: [Godot 4.4 Beta1] Big TileMapLayer's tiles disappear and flicker when used inside a CanvasGroup and zooming out
Labels: bug,topic:editor,needs testing,topic:2d

### Tested versions

Reproducible in: 4.4 Beta1, 4.4 dev7.
Not reproducible in: 4.1.4 stable.

### System information

Godot v4.4.beta1 - Windows 10 (build 19045) - Multi-window, 1 monitor - Vulkan (Forward+) - integrated AMD Radeon(TM) Vega 8 Graphics (Advanced Micro Devices, Inc.; 27.20.1028.1) - AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8 threads)

### Issue description

I was switching a project from Godot 4.1.4 to 4.4 when I noticed the minimap I made for it disappeared, it was also flickering in and out every time the character moved.

The setup for it was really simple, so i made a test project to confirm if it also happened from a blank project and it did.

(I made a shader to make this easier to view in the reproduction project and works without it, the TileMapLayer outside the CanvasGroup has black tiles and the one inside the CanvasGroup has white tiles)

![Image](https://github.com/user-attachments/assets/e79b835f-e893-4896-bd01-a922646bbbcf)

Zooming out

![Image](https://github.com/user-attachments/assets/99b015c2-fc5e-4504-916a-33435a0c7ecc)

This works both in the editor and when running the project.

As to why I am using a CanvasGroup with a TileMapLayer this big: I made a shader in 4.1.4 using the texture CanvasGroup gives, it allowed me to make effects I really liked, but I can't do the same effects without it.

Changing the fit margin/clear margin/mipmaps in the CanvasGroup doesn't seem to do anything even when set to ridiculous values.

### Steps to reproduce

-Make a scene with a CanvasGroup.
-Add a TileMapLayer as a child of the CanvasGroup.
-Add a TileSet to the TileMapLayer and put any texture to it to use as tiles.
-Use the Rect Tool to fill a very large area of the world with tiles.
-Zoom the camera out.

### Minimal reproduction project (MRP)

[canvasgroupbigtilemap.zip](https://github.com/user-attachments/files/18460023/canvasgroupbigtilemap.zip)
Repository: go
Issue: cmd/go: `all` pattern in per package flags is inaccurate in module mode
Labels: NeedsInvestigation,GoCommand

`all` has a slightly different meaning in module mode than it does in `GOPATH` mode. In `GOPATH` mode, it's pretty much everything:

> In GOPATH mode, "all" expands to all packages found in all the GOPATH trees.

But in module mode, "all"

> expands to the set of "packages in the main module (or workspace modules) and their dependencies, including dependencies needed by tests of any of those"

according to `go help packages`.

We don't seem to handle this correctly when processing "all" in `-coverpkg` and the per package flags `-asmflags`, `-gccgoflags`, `-gcflags`, and `-ldflags`. The cmd/go/internal/load.MatchPackage function just matches every package for all.
Repository: pytorch
Issue: Obey sm_carveout (limit on number of SMs) in inductor persistent kernel
Labels: triaged,oncall: pt2,module: inductor

### 🚀 The feature, motivation and pitch

See https://github.com/pytorch/pytorch/pull/144974#issuecomment-2599011250

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @aakhundov @eellison @lw 

### Alternatives

_No response_

### Additional context

_No response_