sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: yt-dlp
Issue: Issue with LUA and YT-DLP: yt-dlp sends "finished process" to LUA to early?
Labels: external issue

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm asking a question and **not** reporting a bug or requesting a feature
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I have **updated yt-dlp to nightly or master** ([update instructions](https://github.com/yt-dlp/yt-dlp#update-channels))
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar questions **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Please make sure the question is worded well enough to be understood

I needed that yt-dlp, called by a LUA script, when ends all the functions something else si done by the calling script;
In the following example just print the word "END" for cimplicity.

example of LUA code involving yt-dlp
```
var = "yt-dlp.exe --recode mp4 <URL>"
os.execute(var)
print("End")
```

What happens is that
"End" is printed when yt-dlp finishes the download of the file. Not when the `--recode mp4 ` ends up it's "existence".
It means something is not correctly transmitted to LUA code;

Is it possible to impose to yt-dlp to send the END of the process only when all the arguments on the command line are definitely finished to be executed?

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

_No response_
Repository: next.js
Issue: useFormStatus() doesn't work with shadcn/ui Select component
Labels: bug

### Link to the code that reproduces this issue

https://github.com/samstr/shadcn-formstatus-demo

### To Reproduce

1. Clone https://github.com/samstr/shadcn-formstatus-demo
2. npm install
3. npm run dev
4. Go to http://localhost:3000/
5. Click the submit button on the form with an Input (pending state works)
6. Click the submit button on the form with a Select (pending state does not work)

### Current vs. Expected behavior

See the difference between a form using an `Input` vs `Select`. I'm not sure if this is a NextJS issue, a shadcn/ui issue, or an underlying react issue. I suspect it's actually a problem with the current React 19 RC.

https://github.com/user-attachments/assets/340d07cd-5266-42c7-a169-90f761940027



### Provide environment information

```bash
System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:13:04 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6020
  Available memory (MB): 98304
  Available CPU cores: 12
Binaries:
  Node: 18.18.0
  npm: 9.8.1
  Yarn: N/A
  pnpm: 7.22.0
Relevant Packages:
  next: 15.0.1 // Latest available version is detected (15.0.1).
  eslint-config-next: 15.0.1
  react: 19.0.0-rc-69d4b800-20241021
  react-dom: 19.0.0-rc-69d4b800-20241021
  typescript: 5.6.3
Next.js Config:
  output: N/A
```


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

Not sure

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

next dev (local)

### Additional context

The issue started after upgrading to NextJS 15.0.0
Repository: react
Issue: [React 19] useFormStatus() pending doesn't work with Select component
Labels: React 19

## Summary

I recently upgraded to NextJS 15 and I have noticed that react-dom's useFormStatus is no longer working when the Select component is included in the form.

I don't know if this is a shadcn/ui issue, a NextJS issue, or an underlying react-dom issue. My suspicion is it's a problem with how react-dom is handling forms that contain elements that have their own javascript involved (the shadcn/ui `Input` works fine, but the `Select` and `InputOTP` components don't. Those components have their own javascript involved (the Select handles popovers and the InputOTP handles keypresses to move to the next input etc).

Please see the repository where I have a trimmed down form that reproduces the problem.

https://github.com/samstr/shadcn-formstatus-demo

https://github.com/user-attachments/assets/fd493ed3-2b02-4fc5-b5a9-acb2e9c618a0


I've also reported this to the following repos in order to track down the source of the problem.
* https://github.com/shadcn-ui/ui/issues/5574
* https://github.com/vercel/next.js/issues/71895
Repository: tailwindcss
Issue: [v4] Tailwind CSS classes not updating in output when adding previously unused classes - requires server restart
Labels: v4,vite

**What version of Tailwind CSS are you using?**

```
"@tailwindcss/vite": "^4.0.0-alpha.30",
"tailwindcss": "^4.0.0-alpha.30"
```

**What build tool (or framework if it abstracts the build tool) are you using?**

```
"@solidjs/start": "^1.0.9",
"vinxi": "^0.4.3"
```

**What version of Node.js are you using?**

```
"node": ">=18"
```

**What browser are you using?**

Firefox

**What operating system are you using?**

macOS

**Reproduction URL**

Since SolidStart isn't currently working on Stackblitz, please test locally:

1. Clone the repository: `git clone https://github.com/binajmen/bun-solidstart-tw4`
2. Install dependencies and start the dev server: `bun install && bun dev`
3. You should see a colored background on the index page
4. Try changing the background color class in `app.tsx` (e.g., to bg-blue-400) and save the file
5. The background will turn white instead of updating to the new color
6. Only after manually restarting bun dev will the new background color appear

**Describe your issue**

When adding Tailwind classes that weren't previously used anywhere in the codebase, these new classes aren't being included in the generated CSS file. The changes only take effect after manually restarting the development server.
Repository: TypeScript
Issue: Inline conditional JSX props spread warns as if unconditional
Labels: Bug

### 🔎 Search Terms

"is specified more than once, so this usage will be overwritten", "jsx spread"

### 🕗 Version & Regression Information

I observed this in practice on 5.6.3, and it seems to occur in all the versions I tested with the playground. 


### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.6.3#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wG4AoczAVwDsNgJa4BhXSWpWmACjBzABnAFxwUtAJ4BKOAG9ycOERjUozADwATYADcAfOoD02-RQC+lGvRiNmg3EgBidNHwEixkmfMXLVzAAZzSiQAD0hYOCsGJjgYJEFeQQALCGoAG00AeR0kKChgTSRRACMICHTUWm8FODQmRLh7ECQANRR0uABeOB5axXU2cCYuGH7FMS7ZTA7BJAsJiZKpmfS5szhDQzgAIgAVZOBBJv5UTTF0gHcUCWOIXKhLgvjjmEPj-ggwPJgJADodjtxoo0CtZvNgXI-tCeCk0pkcnkCkVIYoAPxyVGLOAlUQwKDUJAAGixigW2MUolkZik5MUhj0tSkFFq9VojQgbzy7U6PR8ExQolWcxJi1xUXBRM221oEDgSOg4zQQsl42hf1hqQy2QeyKQkIx-IpinF+MJouNdImVJpFrMLJBDXg9yRhSQ3SaWoRurd40NWNNBOJkKtNoddSdcUOUE0PI9fUWg3YI24kJQYLWEIpy2m4I2Wzgsvl+UVFNBuczVsUsnVLvybqtDKZ4bZjUwaVgyTjPWaThcPCNYhVmYtJuHIulhblCqgSvHwcW6s18J1rpRFP9xqWeKDo+xVbgNqkduZ5DMQA

### 💻 Code

```ts
import React from 'react';

function Component(props: any) {
  return <div></div>;
}

function someFunc(props: any) {
  return 0;
}

export function test(shouldOverride: boolean) {
  const someVal = (
    <Component
      a={false}
      b={false} // "This spread always overwrites this property.""
      c={false}
      {...(shouldOverride
        ? {
            b: true,
          }
        : {})}
    />
  );

  const otherVal = {
    a: false,
    b: false, // no error
    c: false,
    ...(shouldOverride
      ? {
          b: true,
        }
      : {}),
  };

  const override = shouldOverride
    ? {
        b: true,
      }
    : {};

  const thirdVal = (
    <Component
      a={false}
      b={false} // no error
      c={false}
      {...override}
    />
  );

  const fourthVal = someFunc({
    a: false,
    b: false, // no error
    c: false,
    ...(shouldOverride
      ? {
          b: true,
        }
      : {}),
  });
}
```


### 🙁 Actual behavior

Only in the case when the spread is inline and in the props of a JSX component, spreading an object that conditionally may or may not have a property warns as if the property was unconditionally set, with `'b' is specified more than once, so this usage will be overwritten. (2783)` / `This spread always overwrites this property.`

### 🙂 Expected behavior

As in the other test cases (spread into an object that's not into component props/spread of a value that's not defined inline into component props), the inferred type of the overriding `b` should be optional and there shouldn't be a warning.

### Additional information about the issue

No idea what to title this to make it more clear, sorry. Also, I see a fair number of other issues involving inline spread type inference being weird, but none seemed to specifically point to JSX and it's not clear to me how to narrow this one down further.
Repository: tauri
Issue: [bug] Tauri v2 is missing Zoom predefined menu item (MacOS)
Labels: type: bug,platform: macOS,status: needs triage

### Describe the bug

V1 has this 
https://docs.rs/tauri/1.8.1/tauri/enum.MenuItem.html#variant.Zoom

Nowhere to be seen in v2
https://docs.rs/tauri/2.0.6/tauri/menu/struct.PredefinedMenuItem.html

### Reproduction

N/A

### Expected behavior

API should have access to this native macos menu item.

### Full `tauri info` output

```text
Tauri 2.0.6 on macos
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: react
Issue: [Compiler]: All comments removed from source code
Labels: Type: Question,Component: Optimizing Compiler

### What kind of issue is this?

- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [X] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] 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://playground.react.dev/#N4Igzg9grgTgxgUxALhAgHgBwjALgAgBMEAzAQygBsCSoA7OXASwjvwFkBPAQU0wAoAlPmAAdNvhgJcsNgB4AfOPwr8cgMIQAtloR1cYblIBKCLRABuCQvgD0SiSo3bd+w1IAKUsAhhWb9spq9gDc4gC+4uK0DMys+Jo6egZGCKbm-kIiQXYAVPi4MGR0YJRkuDhgyPgApFX4UD4wdGS6AHT4ACoAFkxg+HAuyfgA7kyUlPgARgiSZpbW+Lm2QYMlBLgYBAC8+AD6e-wA5AASCBMQtWBHgmF0Qba2Xb39g0n6o+OTZJSQ07NSDLWNrKIJSGTNNSEJgWBTATboXDhOS2aGwu6Re50GKMFhsRKuFKeby+TLCMQSUQgRqzOiXXTmKl3FQPfKFYqlcqVap1ao05qtBAdHp9AZDD5jCb4OkEGZzIE2ZarVhgDZbfC7A7HM4XK43O45R7PUVvQmfKU-P5ygDWCEwuBBlIk4NkUJhcIRSJRaIUGJA4SAA

### Repro steps

I setup my Babel & webpack config to preserve comments, specifically comments for translators.

In systems like WordPress, i18n strings & comments are directly in the source code and must be preserved.

When React Compiler optimizes a component, all comments will be stripped.

When React Compiler is disabled, e.g. with `use no memo` or when it encounters a disabled lint rule, then the component won't be touched at all and comments are preserved as expected.

Unfortunately the Playground link doesn't show this, as it seems to strip all comments no matter what.

### How often does this bug happen?

Every time

### What version of React are you using?

17

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

0.0.0-experimental-34d04b6-20241024
Repository: terminal
Issue: Tab bar RMB glitches
Labels: Issue-Bug,Area-UserInterface,Product-Terminal

### Windows Terminal version

1.21.2911.0

### Windows build number

10.0.26100.0

### Other Software

_No response_

### Steps to reproduce

Open Windows Terminal. Do Right Mouse Button click multiple times on the tab, shifting a cursor along tab header area. Note that sometimes you get Windows titlebar standard context menu (like on Alt+Space) instead of context menu of the current tab with completely different set of actions and design.
Also note, that in Dark Mode this system titlebar context menu is always white, while some Windows apps do change system menus to dark mode too (like VSCode, Notepad++, HWiNFO64).

### Expected Behavior

While doing right mouse button click on the tab header area, correct type of context menu must be shown.

### Actual Behavior

While doing right mouse button click on the tab header area, about 1 in 5 clicks shows Windows titlebar standard context menu (like on Alt+Space) instead of context menu of the tab clicked.

![Image](https://github.com/user-attachments/assets/0bbbb140-1866-4b43-8df6-fdfb0f495b61)
![Image](https://github.com/user-attachments/assets/a7d94dfe-a84d-4611-8a05-9080c34c0f95)
Repository: angular
Issue: Proposal: Native Component for Dynamic Metadata in Angular – Essential for SSR in SEO context
Labels: area: server

Introduce a component in Angular that functions similarly to the [`<Head>`](https://nextjs.org/docs/pages/api-reference/components/head) component in Next.js, allowing developers to manage metadata (title, meta tags, etc.) for individual pages or components directly within the Angular template.

### Why?
As Angular continues to evolve towards server-side rendering, the current `Title` and `Meta` services feel outdated and insufficient for modern applications. These services offer limited flexibility, especially for SSR-focused applications where managing tags like `<link>` or dynamic metadata updates is crucial. Currently, <ins>**there is no clean way to create `<link>` tags in SSR context**</ins> that are hydrated, defined at the component level, and integrated with Angular’s lifecycle. A new, declarative component e.g. `<ng-head>` would enhance the developer experience by providing a more intuitive and comprehensive way to handle metadata and head elements in an Angular project.

While it is possible to create a custom library to address this problem, it feels like this functionality should be available out of the box in Angular. Features like adding `<link>` tags to the header or automatically handling title and meta tags (adding and removing them when a component is created or destroyed) should not require writing a custom service to manage. Having these capabilities natively would greatly enhance Angular’s usability in SSR contexts and make metadata management simpler and more consistent.

### Proposed solution

```html
<ng-head>
  <title>Example</title>
  <meta name="description" [attr.content]="example$ | async" /> <!-- with observables -->
  <link rel="canonical" [attr.href]="example()" /> <!-- or with signals -->
</ng-head>
```

### Alternatives considered

While a new service for head management supporting [all elements](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/head#see_also) could be an option, I personally don’t find this approach ideal.


### Current approaches 
Currently, I'm aware of two indirect approaches to achieve this, both of which feel very developer-unfriendly:

1. **Creating a Service**: A custom service can be created that listens to `RouterEvents`, loading metadata from the `data` property on the route and handling automatic removal. This approach requires custom event handling and can become complex to maintain.
   
2. **Managing Metadata in Each Component**: Another method is to add and remove meta tags directly within each component, using `ngOnInit` to add tags and `ngOnDestroy` to remove them. This requires repetitive code in each component and increases the risk of metadata inconsistencies.
Repository: pytorch
Issue: Error loading ".venv\Lib\site-packages\torch\lib\c10_xpu.dll" or one of its dependencies
Labels: module: windows,triaged,module: xpu

### 🐛 Describe the bug

When attempting to import `torch` with version `2.5.1+xpu`, I encounter the following error:
```
Error loading ".venv\Lib\site-packages\torch\lib\c10_xpu.dll" or one of its dependencies
```

I've followed the instructions from:
- https://pytorch.org/docs/stable/notes/get_start_xpu.html
- https://www.intel.com/content/www/us/en/developer/articles/tool/pytorch-prerequisites-for-intel-gpu/2-5.html

Installed and set up the oneAPI environment:

```
:: initializing oneAPI environment...
   Initializing Visual Studio command-line environment...
   Visual Studio version 17.11.5 environment configured.
   "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\"
   Visual Studio command-line environment initialized for: 'x64'
:: compiler -- processing etc\compiler\vars.bat
:: debugger -- processing etc\debugger\vars.bat
:: dpl -- processing etc\dpl\vars.bat
:: mkl -- processing etc\mkl\vars.bat
:: tbb -- processing etc\tbb\vars.bat
:: oneAPI environment initialized ::
```

I have additional questions for the Intel Teams. What is the recommended way to use an Intel GPU on Windows 11?
   - IPEX `2.3.1+xpu` on WSL2
   - `torch.compile` with OpenVINO backend
   - `torch 2.5` for support xpu

Thank you for your assistance.

### Versions

```
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 家用版 (10.0.22631 64 位元)
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A

Python version: 3.12.6 (tags/v3.12.6:a4a2d2b, Sep  6 2024, 20:11:23) [MSC v.1940 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-11-10.0.22631-SP0
Is CUDA available: N/A
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

CPU:
Name: Intel(R) Core(TM) Ultra 9 185H
Manufacturer: GenuineIntel
Family: 1
Architecture: 9
ProcessorType: 3
DeviceID: CPU0
CurrentClockSpeed: 2300
MaxClockSpeed: 2300
L2CacheSize: 18432
L2CacheSpeed: None
Revision: None

Versions of relevant libraries:
[pip3] numpy==1.26.3
[pip3] onnx==1.17.0
[pip3] torch==2.5.1+xpu
[conda] Could not collect
```

cc @peterjc123 @mszhanyi @skyline75489 @nbcsm @iremyux @Blackhex @gujinghui @EikanWang @fengyuan14 @guangyey
Repository: TypeScript
Issue: Regular Expression - improve on-hover notation for literal expressions
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

regex, regular expression, syntax highlighting

### ✅ Viability Checklist

- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

I would like to be able to hover my mouse over a variable holding a regular expression and see the `literal string` or `/expression/` that was used in its construction (if known).

### 📃 Motivating Example

This feature adds the ability to view the regular expression that went into a variable, meaning that you can abstract regular expressions away into separate files without losing the meaning behind what the regular expression represents. This is a quality of life improvement that does not solve the million problems that most regular expression examples look to solve, meaning that it won't parse or try to understand the context of the `RegExp`, but it will no longer disadvantage users who hoist their expressions rather than inline them.

### 💻 Use Cases

1. What do you want to use this for?
- For projects where regular expressions would be better served by being hoisted to a different file (like a shared module)

2. What shortcomings exist with current approaches?
- Current approaches require augmenting every regular expression with detailed comments, which is a lot of unnecessary boilerplate (which is more aligned with JSDoc rather than TypeScript) and can get messy when doing things like renaming capture groups and needing to update the comments accordingly.

3. What workarounds are you using in the meantime?
- I'll show you what I've done, which works well for string-literal based regular expressions, but requires converting ALL `/forward slash/` regular expressions to be manually refactored to their string literal equivalents, which is very time consuming and shouldn't be necessary for the end user. Here's what I've developed to solve my own problem, but that still requires not using `/notation/`:

```ts
/**
 * A regular expression that remembers the string literals used in its creation.
 */
export interface TypedRegExp<S extends string, F extends string> extends RegExp {
    source: S;
    flags: F;
}

export const createTypedRegExpr = <T extends string, M extends string = ''>(
    stringExpr: T,
    flags?: M
) => new RegExp(stringExpr, flags) as TypedRegExp<T, M>;
```
Repository: react
Issue: [React 19] Unnecessary and unremovable `data-precedence` and `data-href` attributes on hosted `<style>` and `<script>`.
Labels: Resolution: Stale,React 19

## Summary

https://codesandbox.io/p/devbox/28rwmr

```tsx
import { Writable } from "node:stream";
import React, { StrictMode } from "react";
import { renderToPipeableStream } from "react-dom/server";

async function renderJsx(children: React.ReactNode): Promise<string> {
  return new Promise((resolve, reject) => {
    let { pipe } = renderToPipeableStream(<StrictMode>{children}</StrictMode>, {
      onAllReady: (err: unknown) => {
        if (err) {
          console.error("onAllReady", err);
          reject(err);
          return;
        }

        pipe(
          new (class extends Writable {
            #chunks: any[] = [];

            _writev(chunks: any, callback): void {
              this.#chunks.push(...chunks.map((c: any) => c.chunk));
              callback();
            }

            _final(callback: (error?: Error | null) => void): void {
              callback();
              resolve(new Blob(this.#chunks).text());
            }
          })()
        );
      },

      onShellError: reject,
    });
  });
}

renderJsx(
  <StrictMode>
    <html>
      <body>
        <style href="foo" precedence="medium">{`
          .my-p {
            color: purple;
          }
        `}</style>
      </body>
    </html>
  </StrictMode>
).then(console.log, console.error);
```

Output:

```html
<!DOCTYPE html><html><head><style data-precedence="medium" data-href="foo">
          .my-p {
            color: purple;
          }
        </style></head><body></body></html>
```

As expected this moved the style to the head but it has added unnecessary `data-precedence` and `data-href` attributes.

I don't know if these are required for rehydration but if so they should be optional for static components or static output.

Version: `19.0.0-rc-b8ae38f8-20241018`