sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: crypto/x509: unrecognized failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "crypto/x509" && test == ""
```

Issue created automatically to collect these failures.

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

    FAIL	crypto/x509 [build failed]


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: godot
Issue: Creating Android additional pack files (DLC) always includes .NET runtime when using Mono version
Labels: bug,discussion,platform:android,topic:dotnet,topic:export

### Tested versions

-Reproducible in Godot 4.2.2 stable [15073afe3], Godot 4.3RC3 [03afb92ef]

### System information

Godot v4.3.rc3.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 Ti Laptop GPU (NVIDIA; 31.0.15.3179) - 12th Gen Intel(R) Core(TM) i9-12950HX (24 Threads)

### Issue description

When using C#, any pack file created for the android platform gets mono included (increasing the size by ~80MB) even if it's just exporting a resource like a texture.

### Steps to reproduce

Probably can do this in any project, but I used KennyNL's open source project (https://github.com/KenneyNL/Starter-Kit-3D-Platformer) as a test bed.  Simply export a pack file with the texture "colormap.png" and notice mono gets included.  Then create a pack file for the Windows platform and notice it does not include mono and is significantly smaller.

![TextureExportSettings](https://github.com/user-attachments/assets/55344b68-e5ce-4ec8-816b-6457b615dd68)
![FileSizeDifferenceBetweenPlatforms](https://github.com/user-attachments/assets/72f79201-9b5a-4799-81d3-dda3aaa627d0)
![MonoBeingIncludedWithAndroid](https://github.com/user-attachments/assets/c8be346f-713d-4e36-ac5e-2ebad668f304)
![NoMonoInWindowsPackFile](https://github.com/user-attachments/assets/a8da2ac1-96ea-430f-b8f7-cfa227fceb5d)



### Minimal reproduction project (MRP)

https://github.com/KenneyNL/Starter-Kit-3D-Platformer
Repository: pytorch
Issue: torch.compile Parsing error results in error
Labels: triaged,oncall: pt2,module: dynamo

### 🐛 Describe the bug

tuple expression parsing error, the expected result is **result0**, torch.compile results are **result1**, look at the code in detail
```python
import sys
import torch
from torch import nn
import numpy as np
class Bottleneck(nn.Module):   
    def __init__(self):
        super().__init__()
    def forward(self, x):
        return x+1

class TempOpModel(nn.Module):
    def __init__(self):
        super(TempOpModel,self).__init__()
        self.bottlenecks = nn.ModuleList([Bottleneck() for _ in range(3)])

    def forward(self,x):
        y = list([x,x])
        y.extend(m(y[-1]) for m in self.bottlenecks) # x为[0,0] y=[[0,0],[0,0],[1,1],[2,2],[3,3]
        # out = y[-1]
        # for m in self.bottlenecks:
        #     out = m(out)
        #     y.append(out)
        # y.extend([m(y[-1]) for m in self.bottlenecks]) # x为[0,0] y=[[0,0],[0,0],[1,1],[1,1],[1,1]
        # input = y[-1]
        # for m in self.bottlenecks:
        #     out = m(input)
        #     y.append(out)
        return y
def test_pytorch():
    torch._dynamo.reset()
    net = TempOpModel()
    net.eval()
    with torch.no_grad():
        net_compile = torch.compile(net)       
        indata0 = torch.zeros((2))       
        result0 = net(indata0)
        result1 = net_compile(indata0)
        print(" net \n",result0,"\n net compile:\n",result1)

if __name__=='__main__':
    test_pytorch()
```


### Versions

torch: version 2.4.0+cpu
```sh
pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cpu
```
numpy: Version 1.24.1
python: version 3.8.10
```[tasklist]
### Tasks
```


cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames
Repository: nvm
Issue: unable to install nvm
Labels: OS: Mac OS,needs followup,pull request wanted,installing nvm


#### Operating system and version:

#### `nvm debug` output:
command not. found
<!-- do not delete the following blank line -->

```sh

```
</details>

#### `nvm ls` output:
command not found 
<!-- do not delete the following blank line -->

```sh

```
</details>

#### How did you install `nvm`?
<!-- (e.g. install script in readme, Homebrew) -->
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.0/install.sh | bash

output --
Error: the install instructions explicitly say to pipe the install script to `bash`; please follow them

#### What steps did you perform?


#### What happened?
bash has been depreciated on Mac

#### What did you expect to happen?

#### Is there anything in any of your profile files that modifies the `PATH`?
<!--  (e.g. `.bashrc`, `.bash_profile`, `.zshrc`, etc) -->
the usual instructions as mentioned
Repository: deno
Issue: REPL is broken by RegExp literal with character class containing quotes
Labels: bug,repl

Version: Deno 1.45.5

Inputting a RegExp literal with a character class containing single or double quotes breaks Deno's REPL. Identical code works fine in NodeJS's repl.

The following valid code breaks syntax highlighting and fails to execute the code upon pressing <kbd>Enter</kbd>:

```ts
let re = /[']/;
```

Meanwhile, the following valid code displays `Mismatched pairs: [ is not properly closed` upon pressing <kbd>Enter</kbd>:

```ts
function fn() {
    if (/[']/);
}
```

Comparison with NodeJS:

![image](https://github.com/user-attachments/assets/ad0d6630-a144-4e9f-80f2-981d7ce01bd9)
Repository: go
Issue: database/sql/driver: unrecognized failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "database/sql/driver" && test == ""
```

Issue created automatically to collect these failures.

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

    FAIL	database/sql/driver [build failed]


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: next.js
Issue: devIndicators `buildActivityPosition` option doesn't work
Labels: linear: next

### Link to the code that reproduces this issue

https://github.com/Marukome0743/not-work-devIndicator-options

### To Reproduce

1. Run `create-next-app@canary`
2. Add devIndicators options such as `buildActivityPosition: 'top-right'` to `next.config.mjs` like the below.

```javascript
/** @type {import('next').NextConfig} */
const nextConfig = {
  devIndicators: {
    buildActivityPosition: 'top-right',
  },
};

export default nextConfig;
```

3. Run `next dev`
4. devIndicators appear at bottom left even if set `buildActivityPosition: 'top-right'`

### Current vs. Expected behavior

### Current

![Image](https://github.com/user-attachments/assets/7dd13ae7-b18e-45a1-bfb6-7af2aea1b61b)

### Expected

![Image](https://github.com/user-attachments/assets/eb17b1d1-c83d-48b3-8cbf-a501c95fb95b)

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Tue Nov 5 00:21:55 UTC 2024
  Available memory (MB): 15901
  Available CPU cores: 8
Binaries:
  Node: 23.6.0
  npm: 10.9.2
  Yarn: N/A
  pnpm: 9.6.0
Relevant Packages:
  next: 15.2.0-canary.13 // Latest available version is detected (15.2.0-canary.13).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: N/A
Next.js Config:
  output: N/A
```

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

Developer Experience

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

next dev (local)

### Additional context

devIndicators was changed at [Move static indicator into dev overlay #68369](https://github.com/vercel/next.js/pull/68369) and this issue occurred then.

The old devIndicators defined position at below code.
https://github.com/vercel/next.js/blob/db153fbcd60d8f1265ec09a63ddcd7a82e9f5a2b/packages/next/src/client/dev/dev-build-watcher.ts#L14-L33

However devIndicators didn't initialize position anymore because delete below code.
https://github.com/vercel/next.js/blob/c31793fa3bd7085132fc198bc41e7cadefbdac1f/packages/next/src/client/app-index.tsx#L44-L52

It would be good if dev overlay has initialize position function instead.
Repository: TypeScript
Issue: Inconsistency between element access and object destruction
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

destruct object

### 🕗 Version & Regression Information

Before `v4.4.4`, index expression in element access was also not inferred as const. So this issue starts from `v4.4.4`. Reproducible in Nightly build.

### ⏯ Playground Link

https://www.typescriptlang.org/play/#code/DYUwLgBAdhC8EEYIEMDOEDGB7KqwChtdIs4IBvFBALggCIE6V0i8IBffQnNgDzKwBtAAbIAJOSjthAXXwB6eRGUQAegH5uxChBHjJ0mbQCeHAfiA

### 💻 Code

```ts
let n = 1 as const
const o = { a1: "abcd" }

const x = o[`a${n}`]
//    ^? : string
const { [`a${n}`]: y } = o
//           ^? Errors: Type '{ a1: string; }' has no matching index signature for type 'string'.(2537)
```


### 🙁 Actual behavior

<code>\`a${n}\`</code> in object destruction not inferred as const (`"a1"`)

### 🙂 Expected behavior

<code>\`a${n}\`</code> in object destruction should be inferred as `"a1"`, just like the one in element access.

### Additional information about the issue

A possible workaround is to add `as const` after <code>\`a${n}\`</code>. I think the main problem is the inconsistency between element access and object destruction, which is confusing.
Repository: godot
Issue: Random freezing of Godot IDE on Linux. Happens enough times to be disconcerting.  Anyway to determine cause?
Labels: bug,platform:linuxbsd,topic:porting,needs testing

### Tested versions

v4.3.rc2.official [3978628c6]


### System information

Linux Kubuntu 23.04 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8

### Issue description

I am using Linux Kubuntu KDE.

When using the Godot IDE sometimes it freezes or acts erratic/nonsensical as I am editing. I found I can fix this by minimizing Godot  (or clicking away to another application) and then maximize with no losses. I am not sure keyboard still works, as usually my doing something in script or inspector editors.

I am so used to doing this, but I am wondering if anyone else has a similar issue and is there something I should look for when it happens again. 

This has been happening in the past few versions of 4.3. I don't know if it happened in 4.2. I cannot pin point it but it happens frequently enough to be annoying.

### Steps to reproduce

see above

### Minimal reproduction project (MRP)

see above
Repository: deno
Issue: `FormData` from `<input type=file>` with no file selected gives inconsistent results in browser vs Deno (empty file vs empty string)
Labels: bug,web

Version: Deno 1.45.5

Given the following HTML:

```html
<form method=post enctype="multipart/form-data">
    <input type=file name=files multiple>
    <input type=submit>
</form>
```

Assuming no files are selected, calling `FormData#get('files')` on a `FormData` object constructed from this form on the client side (tested latest Chrome, FireFox) gives an empty `File` object. However, calling `(await req.formData()).get('files')` on the `Request` given by `Deno.serve` gives an empty string `""` instead.

Notably, `FormData#getAll('files')` gives an array of length 1 in both Deno and browsers, which hopefully everyone can agree is a horrible way of representing zero files, but the content of that array's element differs (again, it's an empty file on client side vs an empty string on Deno).

Repro: https://dash.deno.com/projects/formdata-no-files-repro
Repository: langchain
Issue: ChatHuggingFace always returns only 100 tokens as response without considering the `max_new_tokens` parameter
Labels: 🤖:bug,investigate

### Checked other resources

- [X] I added a very descriptive title to this issue.
- [X] I searched the LangChain documentation with the integrated search.
- [X] I used the GitHub search to find a similar question and didn't find it.
- [X] I am sure that this is a bug in LangChain rather than my code.
- [X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

### Example Code

from langchain_huggingface import HuggingFaceEndpoint, ChatHuggingFace
from langchain_community.callbacks import get_openai_callback

 llm = HuggingFaceEndpoint(
        repo_id=repo_id, temperature=0.01,max_new_tokens=2048, huggingfacehub_api_token=HUGGINGFACE_API_KEY)
    llm = ChatHuggingFace(llm=llm)

messages = [
        (
            "system",
            "You are a smart AI that understand the tabular data structure.",
        ),
        ("user", f"{prompt}"),
    ]

with get_openai_callback() as cb:
    response = llm.invoke(messages)
    print(cb)
if not isinstance(response, str):
    response = response.content

print(response)****

### Error Message and Stack Trace (if applicable)

Tokens Used: 1668
        Prompt Tokens: 1568
        Completion Tokens: 100
Successful Requests: 1


### Description

I am trying to use the `Mistral-7B` model from the huggingface. While I am using the `HuggingFaceEndpoint` I am getting the expected answer. But while using the `ChatHuggingFace` , I am always getting 100 tokens.  I have gone through the existing issues but couldn't find the solutions yet.

### System Info

System Information
------------------
> OS:  Linux
> OS Version:  #44~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Jun 18 14:36:16 UTC 2
> Python Version:  3.10.0 (default, Mar  3 2022, 09:58:08) [GCC 7.5.0]

Package Information
-------------------
> langchain_core: 0.2.29
> langchain: 0.2.12
> langchain_community: 0.2.11
> langsmith: 0.1.98
> langchain_huggingface: 0.0.3
> langchain_text_splitters: 0.2.2
Repository: godot
Issue: Tooltips do not close itself when hovered to nearby elements that is the same element as before.
Labels: bug,topic:gui

### Tested versions

- Reproducible in: 4.3.rc1, 4.3.rc3
- Non-reproducible in: 4.2.1.stable

### System information

Windows 10.0.22631 (Windows 11) - GLES3 (Compatibility) - NVIDIA GeForce GTX 1050 (NVIDIA; 31.0.15.3734) - 12th Gen Intel(R) Core(TM) i5-12400 (12 Threads)

### Issue description

When cursor is hovered to an element that calls out tooltips, the tooltips appear normally.
However, when the cursor is then move on to nearby element that has the same message (e.g. from top `visibility button` to `visibility button` below), the tooltips do not disappear, stay at the same position as before, and do not appear in the new position.

They will function normally if the hover is then move outside of the button to:
1. Empty space, or
2. Other different button/elements

Other Information:
- Enabling `Single Window Mode` does not do anything.
- Edit: Thought it could be related to settings that narrows the gap in between, but after testing out with a clean Godot install, issue persists.
- Edit 2: Scrolling when tooltips are visible will immediately close the tooltips.



https://github.com/user-attachments/assets/5e0ab15a-88d2-4960-b94a-183896925b76

_Note that the tooltips disappear once during hovering on the scripts, probably because it touched the tooltips instead of the button. The 4 dark-blue scripts are the same script, while the 2 gray scripts at the bottom are different from the dark-blue script._


### Steps to reproduce

1. Hover to an icon.
2. Hover to other icon below or above that is the same as the icon before. Tooltips **do not** function properly here.
1. Hover to other different icon nearby or empty space. Tooltips function properly here.

### Minimal reproduction project (MRP)

n/a
Repository: ant-design
Issue: Cascader expandTrigger hover
Labels: 🐛 Bug,Inactive

### Reproduction link

[![Edit on StackBlitz](https://developer.stackblitz.com/img/open_in_stackblitz.svg)](https://stackblitz.com/edit/react-hnugwf?file=demo.tsx)

### Steps to reproduce

1. 点击 Cascader
2. hover `1`
3. hover `2`


### What is expected?

2 能被 hover 到

### What is actually happening?

2 跑了

| Environment | Info |
| --- | --- |
| antd | 5.20.0 |
| React | latest |
| System | mac |
| Browser | chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: `GPUParticlesCollisionSDF3D` only bakes geometry that has its own parent node as ancestor
Labels: bug,topic:editor,topic:3d,topic:particles

### Tested versions

v4.2.2.stable.mono.official [15073afe3]

### System information

Godot v4.2.2.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4080 (NVIDIA; 32.0.15.5599) - AMD Ryzen 9 7950X3D 16-Core Processor (32 Threads)

### Issue description

The documentation of `GPUParticlesCollisionSDF3D` states:

> Any **visible** [MeshInstance3D](https://docs.godotengine.org/en/stable/classes/class_meshinstance3d.html#class-meshinstance3d)s within the [size](https://docs.godotengine.org/en/stable/classes/class_gpuparticlescollisionsdf3d.html#class-gpuparticlescollisionsdf3d-property-size) will be taken into account for baking, regardless of their [GeometryInstance3D.gi_mode](https://docs.godotengine.org/en/stable/classes/class_geometryinstance3d.html#class-geometryinstance3d-property-gi-mode).

However, currently this is not the case.  Please regard this video:


https://github.com/user-attachments/assets/c2c55ac5-bc68-4ebb-a1a7-607361619bde

In it,  I have a `GPUParticlesCollisionSDF3D` which is in a separate node branch than the actual geometry. When I click the _Bake SDF_ button, I am asked to save the bake texture and then I get a message that no geometry could be found even though there clearly is **visible** geometry within the area of the SDF.  Now I move the `GPUParticlesCollisionSDF3D` into the same branch as the geometry so that both the `GPUParticlesCollisionSDF3D` and the geometry have the same parent node . This seemingly works, however there is still no collision happening. The reason for this is issue #60994, so I restart the editor. Now collision works. As a next step I drag the `GPUParticlesCollisionSDF3D` a bit down in the geometry part of the tree and bake again.  As a result, only the tilted plane is considered for the SDF while the ground plane which is now above the `GPUParticlesCollisionSDF3D` is no longer considered and has no more collision. Particularly this last problem can lead to very long debug sessions trying to find out why some piece of geometry isn't colliding when other geometry within the SDF area is.

### Steps to reproduce

In the attached example project open `sdf_bake_test.tscn` and repeat the actions from the video.

### Minimal reproduction project (MRP)

[reproducer.zip](https://github.com/user-attachments/files/16557098/reproducer.zip)
Repository: pytorch
Issue: `torch.compile` support for `CXX="zig c++"`
Labels: triaged,oncall: pt2

### 🚀 The feature, motivation and pitch

It would be pretty awesome if torch.compile would work with the zig C++ compiler which is invoked as `zig c++` which uses llvm under the hood so should be (mostly?) fine compatibility-wise.

I want to deploy apps that use pytorch with `torch.compile` to systems that don't and won't have a c++ compiler available so I thought that it would be nice to bundle the app together with the zig toolchain to have a portable c++ compiler that can be used by `torch.compile`. Then I can just use the app with the env var `CXX` set to `zig c++`.

But that fails [here](https://github.com/pytorch/pytorch/blob/ea00036841b225330396f8d8f6ecf796f4826786/torch/_inductor/cpp_builder.py#L87C13-L87C56)
```python
subprocess.check_output([cxx, "--version"])
```
where it is assumed that the CXX command doesn't contain spaces I think? That won't work with `zig c++`

Let me know what you think :) Hopefully I'm not alone with this kind of request.

### Alternatives

- I can just write a wrapper bash script around `zig c++` and call it e.g. `zig-c++`
- I could use https://github.com/rsms/llvmbox/ instead
- I could use a conda env which can come with a C++ compiler AFAIU

### Additional context

I think there would also be the need to adjust the [_is_apple_clang](https://github.com/pytorch/pytorch/blob/ea00036841b225330396f8d8f6ecf796f4826786/torch/_inductor/cpp_builder.py#L150C1-L153C53) function which assumes that the version string starts with `Apple`. Although I'm not sure about how this would have to be handled.

Just to illustrate why that would currently not work as intended:
```
➜  ~ zig c++ --version
clang version 18.1.6 (https://github.com/ziglang/zig-bootstrap 98bc6bf4fc4009888d33941daf6b600d20a42a56)
Target: aarch64-unknown-darwin23.6.0
Thread model: posix
InstalledDir: /usr/bin
➜  ~ clang --version
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
```

Also, it has been mentioned in https://github.com/pytorch/pytorch/issues/91537 but I think it would be useful if there would be some documentation on how to use other C++ compilers for `torch.compile`.

cc @ezyang @chauhang @penguinwu
Repository: storybook
Issue: [Bug]: vite build.outDir does not contain all Storybook build files with React Vite (TypeScript) setup
Labels: bug,needs triage

### Describe the bug

Running storybook build for React Vite (TypeScript) setup,

Default behavior:
All generated files are present in `storybook-static` directory

When changing `build.outDir` for vite config:
```ts
viteFinal: async (config, options) => {
  const overrides: Partial<InlineConfig> = {
    build: {
      outDir: 'mydir/storybook',
    },
  };
  const final = mergeConfig(config, overrides);
  return final;
},
```
build.outDir contains iframe + assets:
<img width="265" alt="image" src="https://github.com/user-attachments/assets/4e945696-e80b-4c26-ab77-ad8125153ab1">
storybook-static folder contains index.html + storybook build files:
<img width="269" alt="image" src="https://github.com/user-attachments/assets/bd498308-3857-4ff5-a354-114cb8cffc7d">

Expectation: all generated files must be in **build.outDir (mydir/storybook)**
Current behavior: some generated files are still present in **storybook-static** directory

### Reproduction link

https://stackblitz.com/edit/github-mcfjck-6msrma?file=.storybook%2Fmain.ts

### Reproduction steps

1. Go to above stackblitz link
2. Run `yarn run build-storybook`
3. Expect all build files to be in mydir/storybook, but some files are still generated in storybook-static location

### System

```bash
Storybook Environment Info:

  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm <----- active
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @storybook/addon-essentials: ^8.3.0-alpha.4 => 8.3.0-alpha.4 
    @storybook/addon-interactions: ^8.3.0-alpha.4 => 8.3.0-alpha.4 
    @storybook/addon-links: ^8.3.0-alpha.4 => 8.3.0-alpha.4 
    @storybook/addon-onboarding: ^8.3.0-alpha.4 => 8.3.0-alpha.4 
    @storybook/blocks: ^8.3.0-alpha.4 => 8.3.0-alpha.4 
    @storybook/react: ^8.3.0-alpha.4 => 8.3.0-alpha.4 
    @storybook/react-vite: ^8.3.0-alpha.4 => 8.3.0-alpha.4 
    @storybook/test: ^8.3.0-alpha.4 => 8.3.0-alpha.4 
    storybook: ^8.3.0-alpha.4 => 8.3.0-alpha.4
```


### Additional context

_No response_