sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Turbopack inappropriately compiling recursive function in Azure Maps
Labels: bug,Runtime,Turbopack,linear: turbopack

### Link to the code that reproduces this issue

https://github.com/kipprice-mbh/turbo-azure-maps/tree/main

### To Reproduce

1. Set up an account with [Azure Maps](https://azure.microsoft.com/en-us/products/azure-maps/) to get a subscription key
2. Set an environment var named AZURE_SUBSCRIPTION_KEY to the subscription key you received from Azure
3. Run `pnpm dev` and observe the map successfully loads
4. Run `pnpm dev --turbo` and observe the map fail to load

### Current vs. Expected behavior

Currently, the `react-azure-maps` / `azure-map-controls` fail to load when using turbopack in a Next app (but work without issue when running without turbo). I'm submitting to the turbopack team because I've narrowed down at least some of the issue to an error that appears to be a mis-transpilation of the original recursive code.

The original Azure code is the following:

```js
// azure-map-controls/dist/atlas-esm.js

function leastBadBreaks(lastLineBreak) {
  if (!lastLineBreak) {
    return [];
  }
  return leastBadBreaks(lastLineBreak.priorBreak).concat(lastLineBreak.index);
}
```

As you can see, if the argument is falsey at any point in the recursive call tree, it does not attempt to continue to call `leastBadBreaks`.

This is what turbopack compiles this code to:

```js
return function e(t) {
    return ("TURBOPACK compile-time truthy", 1) ? e(t.priorBreak).concat(t.index) : ("TURBOPACK unreachable", undefined);
```

This no longer actual uses the truthiness of the argument, and instead always tries to get the value of `t.priorBreak`; this is crashing because the value is sometimes null. I would expect that arguments to recursive utilities are not determined at compile time.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:02:45 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8112
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 18.19.1
  npm: 10.2.4
  Yarn: N/A
  pnpm: 9.0.5
Relevant Packages:
  next: 15.0.4 // Latest available version is detected (15.0.4).
  eslint-config-next: 15.0.4
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.2
Next.js Config:
  output: N/A
```


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

Runtime, Turbopack

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

next dev (local)

### Additional context

I was unable to get a locally written dynamically-loaded element with a recursive utility to demonstrate the same behavior, but I also couldn't confirm whether turbo was actually compiling it as it does an external library. 

Thank you for all of the work you do! Turbopack is great and I would love to be able to fullheartedly encourage my team to use in our codebase.
Repository: angular
Issue: Child Form Groups Don't Receive Updated _onCollectionChange() When FormGroupDirective Seeds Parent with Callback
Labels: area: forms

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

No

### Description

We rely on `_onCollectionChange()` to notify its FormGroupDirective to re-bind its FormControlName directives, and FormGroup is smart enough to propagate its `_onCollectionChange()` callback so that Child FormGroups can notify too. This happens in two scenarios
1. [When we first initialize the FormGroup](https://github.com/angular/angular/blob/4a030f7308b1e9c0fe6164f4533107f79004891c/packages/forms/src/model/form_group.ts#L598-L603) (the constructor calls `_setupControl()` which binds `_onCollectionChange()` to the children
2. [When we call](https://github.com/angular/angular/blob/4a030f7308b1e9c0fe6164f4533107f79004891c/packages/forms/src/model/form_group.ts#L233-L239) `registerControl` (and associated methods)

The problem is with scenario 1: we may seed each child control with a default callback (an empty function) on init, but we don't propagate a *new* callback when we eventually bind the FormGroup to a FormGroupDirective. The child FormGroups are still working with the 'default' one. Furthermore the api is private so I don't see any way to fix this on the user side.

If we have a scenario where a child form group adds controls dynamically, and some of those controls are FormControlName directives (see stackblitz), then we fail to trigger `_updateDOMValue()` on the parent FormGroupDirective. The FormControlName directives are left with orphaned form controls.

Ideally, `_registerOnCollectionChange()`  would cascade to its children (or maybe just call `_setupControls()` again).

### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/stackblitz-starters-iatn8h?file=src%2Fbroken-form.ts 

### Please provide the exception or error you saw

```true

```

### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 18.2.0
Node: 20.11.1
Package Manager: yarn 4.4.0
OS: linux x64

Angular: 18.2.0
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, language-service, material, platform-browser
... platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1802.0
@angular-devkit/build-angular   18.2.0
@angular-devkit/core            18.2.0
@angular-devkit/schematics      18.2.0
@angular/flex-layout            14.0.0-beta.41
@schematics/angular             18.2.0
ng-packagr                      18.2.0
rxjs                            7.8.1
typescript                      5.4.5
zone.js                         0.14.10
```

### Anything else?

_No response_
Repository: tauri
Issue: [bug] npm run tauri android build bug unexpected argument 'aarch64' found
Labels: type: bug,status: needs triage

### Describe the bug

pnpm tauri android build --target aarch64
can build apk only arm64-v8a

but，

npm run tauri android build -t aarch64
error: unexpected argument 'aarch64' found

npm run tauri android build -- --apk --target aarch64
error: unexpected argument 'aarch64' found

npm run tauri android build -- --apk --target aarch64-linux-android
error: unexpected argument 'aarch64-linux-android' found

and
npm run tauri android build --target=aarch64-linux-android
the apk is universal 

how can i build a only arm64-v8a lib apk  by  npm？


### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.22631 x86_64 (X64)
    ✔ WebView2: 131.0.2903.70
    ✔ MSVC: Visual Studio Professional 2022
    ✔ rustc: 1.82.0 (f6e511eec 2024-10-15)
    ✔ cargo: 1.82.0 (8f40fc59f 2024-08-21)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 22.11.0
    - pnpm: 9.14.2
    - npm: 10.9.0

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-log 🦀: 2.0.3
    - @tauri-apps/plugin-log : not installed!

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../out
    - devUrl: http://localhost:3000/
    - framework: React (Next.js)
    - bundler: Webpack
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: tauri
Issue: [feat] Drag and drop external web links.
Labels: type: feature request

### Describe the problem

I'm trying to make an asset management app, and want to download images for user if they drag the link of image from their browser. But the cursor turns into a banned icon when I'm dragging the link into app window. Also, the events are not fired.


https://github.com/user-attachments/assets/dfba0b8b-5f6e-497c-b38e-c3a837bc4a19



### Describe the solution you'd like

Add events like `tauri://link-drop` that listens such event.

### Alternatives considered

_No response_

### Additional context

_No response_
Repository: tauri
Issue: [bug] Unable to add files to dmg interface
Labels: type: feature request,platform: macOS

### Describe the bug

The dmg interface now only has application and appicon. How to add additional content?

### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
> omg-ff@0.1.0 tauri
> tauri info


[✔] Environment
    - OS: Mac OS 15.0.1 x86_64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: 1.81-x86_64-apple-darwin (default)
    - node: 20.11.1
    - pnpm: 8.6.11
    - yarn: 1.22.22
    - npm: 10.2.4

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - @tauri-apps/api : 2.1.1
    - @tauri-apps/cli : 2.1.0

[-] Plugins
    - tauri-plugin-fs 🦀: 2.1.0
    - @tauri-apps/plugin-fs : not installed!
    - tauri-plugin-dialog 🦀: 2.0.4
    - @tauri-apps/plugin-dialog : 2.0.1
    - tauri-plugin-shell 🦀: 2.0.2
    - @tauri-apps/plugin-shell : 2.0.1

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: node
Issue: —watch cli option prevents Worker execution 
Labels: windows,watch-mode

### Version

v20.17.0

### Platform

```text
Microsoft Windows x64 [Version 10.0.19045.5131]
```


### Subsystem

_No response_

### What steps will reproduce the bug?

// main.js
import { Worker } from ‘worker_threads’

const w = new Worker(‘./worker.js’)
w.on(‘message’, event => console.log(event))

// worker.js
import { parentPort } from ‘worker_threads’

parentPort.postMessage(‘ayo’)

### How often does it reproduce? Is there a required condition?

In terminal: node ./main.js —watch

### What is the expected behavior? Why is that the expected behavior?

The worker should send a message to the main thread.

### What do you see instead?

No response from the worker.

### Additional information

_No response_
Repository: pytorch
Issue: RFC: Display Supported Versions in API Documentation#
Labels: module: docs,triaged,topic: docs

### 📚 The doc issue

We should have an ability to display supported version in API documentation. This will help PyTorch users understand whether an certain API is currently supported and ensure they are using the correct version for their use case.

How it might look:

| API name | Version | Supported |
|---------|--------------|------------------|
| API    | v2.2   | true/false       | 

### Suggest a potential alternative/fix

Proposed implementation: 
* Display supported version at the bottom of the API pages
* Data for supported versions is provided by the engineering team and stored in an automatically updated .json file stored in a separate branch or other downloadable location. 

cc: @malf

cc @brycebortree @sekyondaMeta @AlannaBurke
Repository: react
Issue: Bug: Regression with defaultProps on class components
Labels: Status: Unconfirmed

React version: 19.0.0

## Steps To Reproduce

According to the React 19 upgrade guide "Class components will continue to support `defaultProps`" but your code might break or behave differently if you are relying on the prop defaulting to happen on element creation (by the JSX runtime).

Consider this example:

```tsx
class Foo extends Component {
  static defaultProps = {
    bar: "baz",
  };
}

const element = <Foo />;
// works in React 18 only
expect(element.props.bar).toBe('baz');
```

This is an contrived and unrealistic scenario but we found actual code in a library where there was a `<Table>` component that read off props of `<Column>` child elements that expected to be defaulted.

Link to code example:

React 18: https://codesandbox.io/p/sandbox/confident-bose-ssmddt
React 19: https://codesandbox.io/p/sandbox/zen-drake-n223m8

## The current behavior

Props are not defaulted on element creation

## The expected behavior

If we are going for backwards compatibility I would say the expected behavior is default props on element create if `isReactComponent`. I can see how that would be ugly and a step backwards through but this quirk and undocument breaking change can definitely cause some hard to track down bugs
Repository: deno
Issue: `deno doc` doesn't usefully render functions with single-object arguments
Labels: suggestion

Version: Deno 2.1.2

I've written several methods that accept a single argument filled with options. Unfortunately when `deno doc` renders docs for these methods then `Parameters` doesn't reflect any info defined as otherwise [valid JSDoc syntax](https://jsdoc.app/tags-param) for these types of method arguments:

**doc-issue.ts**
```ts
import { Base64URLString } from './doc-issue-types.ts';

/**
 * A type alias for `string` to indicate that this isn't just any dull, boring string
 */
export type FancyString = string;

/**
 * A demonstration of a method with an "options blob" consisting of a single object with multiple
 * values
 *
 * @param options
 * @param options.value A random string
 * @param options.thing Another random string
 * @returns Whether the strings are the same
 */
export function doThingOptionsBlob(
  options: { value: Base64URLString; thing: FancyString },
): boolean {
  const { value, thing } = options;
  console.log({ value, thing });
  return value === thing;
}
```

**doc-issue-types.ts**
```ts
export type Base64URLString = string;
```

## Rendered output from `deno doc --html doc-issue.ts`

![Screenshot 2024-12-06 at 7 45 35 PM](https://github.com/user-attachments/assets/e7d4b995-2a2a-4b0a-b18d-3d36ffb3684e)

## Issues

1. **Parameters** doesn't reflect any of the information for each property in the docstrings
2. Types that aren't exported from the file you point `deno doc` aren't captured in the output

## Positional arguments are mostly fine

For sake of comparison, I defined this method using positional arguments; the output was arguably more useful:

```ts
/**
 * A version of the method above with positional arguments instead to demonstrate how `deno doc`
 * displays more info about this method.
 *
 * @param value A random string
 * @param thing Another random string
 * @returns Whether the strings are the same
 */
export function doThingOptionsPositional(value: Base64URLString, thing: FancyString): boolean {
  console.log({ value, thing });
  return value === thing;
}
```

![Screenshot 2024-12-06 at 7 49 12 PM](https://github.com/user-attachments/assets/7d193061-14e2-4563-a8db-5e9bf06e1486)

**Issue 2** above is still a problem, but at least with this the JSDoc comments aren't dropped. Refactoring my methods to use positional arguments isn't tenable right now; I only included this as an example of what I was more-or-less expecting to be rendered for the first method.
Repository: rust
Issue: Revamp `cg_llvm` debuginfo handling to use records
Labels: C-cleanup,A-LLVM,A-debuginfo,T-compiler

Currently, we use debuginfo driven by intrinsics. We will need to use records instead, see the migration doc released with LLVM 19: https://llvm.org/docs/RemoveDIsDebugInfo.html

Some notes:

- Most of the functions we want should be exported in the LLVM-C API already, see #134001 and https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm-c/DebugInfo.h
- We will need to make this logic conditional on what version of LLVM is in use until we raise our LLVM minimum to 19.
- They say "This should happen transparently when using the DIBuilder to construct debug variable information, but will require changes for any code that interacts with debug intrinsics directly." so we may have to do... nothing at all! This issue was filed before determining what specific changes we have to make.
Repository: ui
Issue: [bug]: nxp shacdn init doesn't work on non-typescript project
Labels: bug

### Describe the bug

when running `npx shadcn@latest init` on a non-typescript project (javascript only) generated by using vite and selecting javascript for the flavor of react, I receive the error 
```
No import alias found in your tsconfig.json file.
Visit https://ui.shadcn.com/docs/installation/vite to learn how to set an import alias.
```
but the documentation doesn't say anything about it

### Affected component/components

script

### How to reproduce

run `npm create vite@latest`
choose react
choose javascript
run `npx shadcn@latest init` and see error

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
macOS
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: rust
Issue: Revamp `cg_llvm` debuginfo handling to use the LLVM-C API
Labels: C-cleanup,A-LLVM,A-debuginfo,T-compiler

We currently use C++ code for some of our debuginfo stuff with LLVM. We should port it to the C API, so we don't have to continue maintaining irksome C++ bindings. This is the primary header in question: https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm-c/DebugInfo.h
Repository: angular
Issue: Improve Reactive Forms Documentation
Labels: area: forms,area: docs

### Describe the problem that you experienced

The documentation on reactive forms is comprehensive, but there was minimal guidance on common pitfalls, such as initializing forms with complex nested structures or debugging runtime errors that could cause confusion for developers, especially those new to Angular or reactive forms.

### Enter the URL of the topic with the problem

https://angular.dev/guide/forms/reactive-forms

### Describe what you were looking for in the documentation

I was looking for a section addressing common errors and debugging strategies when working with reactive forms.

### Describe the actions that led you to experience the problem

Looked for possible solutions to runtime errors during form setup or validation that may be encountered.

### Describe what you want to experience that would fix the problem

- Add a section on common pitfalls (ex: incorrectly initialized controls, missing form group keys).
- Provide debugging strategies for runtime errors and form validation issues.

### Add a screenshot if that helps illustrate the problem

N/A

### If this problem caused an exception or error, please paste it here

```true
N/A
```

### If the problem is browser-specific, please specify the device, OS, browser, and version

```true
N/A
```

### Provide any additional information here in as much as detail as you can

```true
N/A
```
Repository: TypeScript
Issue: Error span incorrect when `this` constraint on member function fails
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

- error span
- `this: never`
- this chain
- builder pattern

### 🕗 Version & Regression Information

- This is the behavior in every version I tried (including the latest 5.7.2)


### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.8.0-dev.20241206#code/PQKhCgAIUhZBTAtgI3gJ0gMwK4DsDGALgJYD2ukyAhgM7wAmk+t8UIw4+ANrTZAGJ4iZXACEW9UdmJd66ADwBlQvAAOkeAA8Vuen1zYU6ALwBGAHyQA3lEg0Vq0wApCAC2I0AXJGVqN2+F0+U0gAfkg3D0hvXHgAN3QASm9BAhJycTpJaVkFACZLG0hiyDR4Qmw0Cki+WkgqXABPAG5bAF9bezU8l3cvHwd-HT1IPLCIvujIWIS0ZIEhdLEJKRk5NHkAZkLbYrKKqomouoaW9ttgYDsAa2J1LvVN-1UuYnxiQi5GiNJIOURyPY0FQVBN4Bo0GhSGhOg4ACy9DzeXzqLTDPhw8Y1KYzJIpRYiTIMVa5DYAVh2JVK5Uq1UmJyarWKHQ64FAEGgcCQqAwcSoaGIVGQXHB1CyTBYbA43F4kAAavzBcL4ETsmsFCihoERgYjGgzJS7A5TN4nJq0drguMnIlIMZLAqBUKRaqSet5AUcfEknbIE4bXbDXsaYdsQyzszbeGmUbuqbzQEgqNrbb7fLFc6VSscu7tl7Zqm-QG00USvtaUdarVGe0o9WI5BLjc7rHHs9Xu9Pt9CL9-oDCMDQW5wegoTDig84fHBhak5jwsWHRnla6cwoKfmfcYi6mg9SDnTjvWY206-Ua6z8P2sEI3ehfbEAO4LNKE7PqtA21pNqhcLiQUhMEgAADTBSFIAA6B5nESKCHB6RJgIiWk+GIXAe3PSA8FceAuFUHB-1HaFIEQeAaBoKgAHNWBwAg7zQOC1BgxjVAQliEUSVpOGvPk0Hoh94GfR0lRdd9SS-NkrmHCEx0gVQoVUdAvnqVRFP5PhyGU8hW0gOFwF4+iWOYh42MnL8gA

### 💻 Code

```ts
/**
 * Member function based case
 */
class FunctionBasedBuilder<Step extends number=1> {
  step1(this: Step extends 1 ? this : never): FunctionBasedBuilder<2> {
    return this as any;
  }
  step2(this: Step extends 2 ? this : never): FunctionBasedBuilder<3> {
    return this as any;
  }
  // skip step 3 explicitly to demonstrate the error
  step4(this: Step extends 4 ? this : never): FunctionBasedBuilder<5> {
    return this as any;
  }
}

/**
 * Member variable based case
 */
class VariableBasedBuilder<Step extends number=1> {
  step1: (Step extends 1 ? () => VariableBasedBuilder<2> : never) = (() => {
    return this as any;
  }) as any;
  step2: (Step extends 2 ? () => VariableBasedBuilder<3> : never) = (() => {
    return this as any;
  }) as any;
  // skip step 3 explicitly to demonstrate the error
  step4: (Step extends 4 ? () => VariableBasedBuilder<5> : never) = (() => {
    return this as any;
  }) as any;
}

const funcBuilder = new FunctionBasedBuilder();
// all of `foo.step1().step2()` turns into an unhelpful error message
funcBuilder.step1().step2().step4();

const varBuilder = new VariableBasedBuilder();
// the error properly appears only on step 4
varBuilder.step1().step2().step4();
```


### 🙁 Actual behavior

In the function case, the entire span from `foo.step1().step2()` gets marked as an error instead of only `step4()` which is what actually caused the error

### 🙂 Expected behavior

Just like in the member variable case, it would be better if the error was shown on `step4()`


### Additional information about the issue

I think this ends up being equivalent to #28159 so I'm not sure it can be solved without introducing the "curse" mentioned in #60140
Repository: neovim
Issue: `:buffer \[test\]` does not find buffer on Windows
Labels: bug,platform:windows,bug-vim,completion,cmdline-mode

### Problem

As the title, when I use :b to find a buffer with regexp on windows. It doesn't work well.

You can use the steps to reproduce the error.

The point is it works differently on linux and windows.

On linux, It could be find, but on windows, doesn't.
May be the bug source is here: [here](https://github.com/neovim/neovim/blob/ec94c2704f5059794923777ed51412d80bd26b5b/src/nvim/buffer.c#L2273-L2373)

Thanks to this man to point the bug:
[orign](https://github.com/rmagatti/auto-session/issues/396#issuecomment-2524236462)

### Steps to reproduce

on windows pc:

1. run `nvim --clean`
2. `:e [test]`
3. `buffer \[test\]`

### Expected behavior

Expect neovim will find the buffer and open.
But It doesn't work well.
On linux, It's ok. But it will say no matching on windows.

### Nvim version (nvim -v)

NVIM v0.10.2

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

I dont have vim on my windows pc.

### Operating system/version

windows11 24h2

### Terminal name/version

wezterm 20240203-110809-5046fc22

### $TERM environment variable

wezterm

### Installation

winget