sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: "useArgs" hook updates wrong story when rendered in "Stories" block
Labels: bug,help wanted,sev:S3

### Describe the bug

When writing a story for a controlled component, one should expect the `useArgs` hook to update the args being passed to the story it is being called in. However, when used inside a "Stories" block, it updates the page's primary story instead of itself. This isn't an issue when using a "Canvas" block or any other block that selects a specific story. I'm sure this could be user error but I don't see why there would then be a discrepancy between the functionality between the "Stories" block and an individual "Story" block.

### Reproduction link

https://stackblitz.com/edit/github-n2sxrc?file=src%2Fstories%2FInput.tsx

### Reproduction steps

1. Go to the "Input" docs in Storybook.
2. Attempt to edit one of the stories under the "Stories" header.
3. Notice that value of top story is changing, instead of the story being edited.


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


### Additional context

_No response_
Repository: pytorch
Issue: [custom_op] Figure out what to do with random custom ops
Labels: triaged,module: custom-operators,oncall: pt2,module: pt2-dispatcher

opcheck will raise errors on these. But what should a user do if they want to integrate their own randommness with pt2? Need to figure out if our randomness functionalization design works with these

cc @ezyang @anijain2305 @chauhang @bdhirsh
Repository: vscode
Issue: Language type icon overriding file autocompletion
Labels: bug,suggest


![Screenshot from 2024-06-24 20-32-52](https://github.com/microsoft/vscode/assets/109205677/f121ce65-5cf7-4019-82d7-48046a2f7e07)
Type: <b>Bug</b>

edit a file in C and increase the font size, then try including a header file and activate the autocompletion.

VS Code version: Code 1.90.2 (5437499feb04f7a586f677b155b039bc2b3669eb, 2024-06-18T22:33:48.698Z)
OS version: Linux x64 6.1.0-21-amd64
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz (8 x 982)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<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: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: disabled_off|
|Load (avg)|1, 1, 1|
|Memory (System)|15.41GB (10.96GB free)|
|Process Argv|--crash-reporter-id 6f97c42c-909d-47ee-a60c-bafb01b1258c|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|gnome|
|XDG_CURRENT_DESKTOP|GNOME|
|XDG_SESSION_DESKTOP|gnome|
|XDG_SESSION_TYPE|wayland|
</details><details><summary>Extensions (16)</summary>

Extension|Author (truncated)|Version
---|---|---
catppuccin-vsc|Cat|3.14.0
arm|dan|1.7.4
esp-idf-extension|esp|1.7.1
cortex-debug|mar|1.12.1
debug-tracker-vscode|mcu|0.0.15
memory-view|mcu|0.0.25
peripheral-viewer|mcu|1.4.6
rtos-views|mcu|0.0.7
cmake-tools|ms-|1.18.42
cpptools|ms-|1.20.5
cpptools-extension-pack|ms-|1.3.0
hexeditor|ms-|1.10.0
stm32-vscode-extension|STM|2.0.1
gnu-mapfiles|tro|1.1.0
cmake|twx|0.0.17
linkerscript|Zix|1.0.4

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonnoceb:30805159
asynctok:30898717
pythonregdiag2:30936856
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
accentitlementst:30995554
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
jchc7451:31067544
chatpanelc:31048052
dsvsc021:30996838
01bff139:31013167
pythoncenvpt:31062603
a69g1124:31058053
dvdeprecation:31068756
dwnewjupyter:31046869
legacy_priority:31077528

```

</details>

<!-- generated by issue reporter -->
Repository: terminal
Issue: Cursor disappears when AtlasEngine and Software Rendering are used together
Labels: Help Wanted,Needs-Repro,Issue-Bug,Product-Terminal,Area-AtlasEngine

### Windows Terminal version

1.20.11381.0

### Windows build number

Microsoft Windows NT 10.0.22631.0

### Other Software

_No response_

### Steps to reproduce

Open a Terminal with AtlasEngine and Software Redering active together

### Expected Behavior

For the cursor to be shown

### Actual Behavior

Cursor is invisible
Repository: TypeScript
Issue: Filter with "something is smallerType" don't work as negative
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

filter is type narrow negative

### 🕗 Version & Regression Information

- This starts on version 5.5

### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.5.2#code/C4TwDgpgBAggdgSwLYEMA2UC8UDeAoKKAIwCcIVgALALimBIFcIAaPAXwG489RIoAlAPYBjANZZcBYmQo0oAM3QBnFuy49w0AMqCkEKgjgBzCfGTooAHwEjR6+QzjDgCQXCgIlZ1GgAUS3X1KQyNaHT0DYwBKWgCI4OMPJVhEH0lCMmAGEnc4oJCAOlJyKnZuYTclYDoIKoBGMMDIk2x8QmLZWnomVjZyyurgWuAAJkb4kIk26RK5RTQVXvUKuCq6YKUASSUAeXFsAG0h+uYaqpGAXQL5BDQhkl9qzAA+JO90R6iorgB6H8IAYQAHoAfhS5jQBwu-VWgw22wA6iQ3C0oEdhnVTsdRlcbncIA8nq8AISed5+YBfX7-QHAsG+clWGxiKJQvBAA

### 💻 Code

```ts
type Animal = {
  breath: true,
};

type Rock = {
  breath: false,
};

type Something = Animal | Rock;

function isAnimal(something: Something): something is Animal {
  return something.breath
}

const test1: Something = {
  breath: true,
}

const test2: Something = {
  breath: false,
};

const thisIsOk = [test1, test2].filter(t => isAnimal(t));
//       ^? Animal[]

const thisIsWrong = [test1, test2].filter(t => !isAnimal(t));
//       ^? (Animal | Rock)[]

```


### 🙁 Actual behavior

```ts

const thisIsOk = [test1, test2].filter(t => isAnimal(t));
//       ^? Animal[]

const thisIsWrong = [test1, test2].filter(t => !isAnimal(t));
//       ^? (Animal | Rock)[]

```

### 🙂 Expected behavior

```ts

const thisIsOk = [test1, test2].filter(t => isAnimal(t));
//       ^? Animal[]

const thisIsShouldBe = [test1, test2].filter(t => !isAnimal(t));
//       ^? Rock[]

```

### Additional information about the issue

Filtering is working only if "positive", but if the "is" is used as a negative then it don't type narrow.
Repository: flutter
Issue: `generate_gradle_lockfiles.dart` skips tests that don't use a `lib/main.dart`
Labels: P2,team-android,triaged-android

... but instead use a differently named main, such as https://github.com/flutter/flutter/blob/master/dev/integration_tests/external_textures/lib/frame_rate_main.dart.

We should modify the script so that it handles all tests, no matter what they name their main file.
Repository: godot
Issue: Skeleton Heavy CPU Bottleneck
Labels: bug,topic:rendering,needs testing,topic:animation,topic:3d,performance

### Tested versions

Tested 4.3 beta 1

### System information

Windows 11, i3-10105f, RX6600 24.5.1, Forward+

### Issue description

Skeletons seem to absolutely trash CPU performance.
Editor reports over 30ms cpu frame time with skeletons vs 3ms for non skeletal copy of the scene

Only one thread is above 5% utilization, and the one that is being utilized keeps switching between 60% and 100% utilization despite locked frequency (so the utilization percentages aren't falsely being reported as 100% when the frequency drops)

This has been reported on before (https://github.com/godotengine/godot/issues/90943), but Hasn't provided samples for testing, so that's what I'm doing here.

do note, I've observed Shadows to be especially hard on the CPU, which is how I've first encountered this issue in my Project with only about a 100 skeletons and half a dozen omni lights and a sunlight casting shadows, while in the MRP to keep it simple I just threw 2 thousand skeletons to make the bottleneck more apparent and easier to diagnose.

### Steps to reproduce

Open MRP

Compare Non Skeleton vs Skeleton Scene CPU Performance Metrics

### Minimal reproduction project (MRP)

[Perf test.zip](https://github.com/user-attachments/files/15960225/Perf.test.zip)
Repository: godot
Issue: `GPUParticlesCollisionBox3D` and `GPUParticlesCollisionHeightField3D` produce different results in the same setup
Labels: documentation,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

I have set up two identical particle systems. Both spawn cubes and have collision enabled and set to rigid. Under both particle systems I have a CSG cube representing a surface. The left cube has an `GPUParticlesCollisionBox3D` enclosing the cube, the right one has a `GPUParticlesCollisionHeightField3D` looking at the cube. The height field works very nicely, while the collision box "leaks" particles. I would expect both setups to behave the same way (ideally like the height field).


https://github.com/godotengine/godot/assets/327257/a1414ae7-645d-4f45-be4d-3db0f08d2bbc





### Steps to reproduce

Open `particle_collisions_test_2.tscn` in the attached reproducer project. There you can see the setup from the video and play with it.

### Minimal reproduction project (MRP)

[reproducer2.zip](https://github.com/user-attachments/files/15960406/reproducer2.zip)
Repository: go
Issue: cmd/go: set the Go Version for command-line files to be the containing module's Go Version
Labels: GoCommand

### Current behavior

The Go version for a file passed in via command-line uses the local version.
e.g. `$ go vet -x main.go`
will set the Go Version to be the local version.

This happens in 3 places (maybe more):
1. [vet](https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/exec.go;l=1183?q=src%2Fcmd%2Fgo%2Finternal%2Fwork%2Fexec.go&ss=go%2Fgo)
2. [compiler](https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/gc.go;l=69?q=src%2Fcmd%2Fgo%2Finternal%2Fwork%2Fgc.go&ss=go%2Fgo)
3. [init.go](https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/modload/init.go;l=896?q=src%2Fcmd%2Fgo%2Finternal%2Fmodload%2Finit.go&ss=go%2Fgo)

This ignores whether or not the file has a containing module.
e.g. current go version running is 1.23
-> main.go
-> go.mod (1.21)

`$ go vet -x main.go`
will set the Go Version to be 1.23

### New behavior

As discussed offline and in [https://go-review.googlesource.com/c/go/+/567435](https://go-review.googlesource.com/c/go/+/567435) we have come to the decision to set the Go version to use the containing go.mod's version.
In the above example, `$ go vet -x main.go`
will set the Go Version to be 1.21
Repository: go
Issue: x/crypto/ssh/test: TestSSHCLIAuth failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "golang.org/x/crypto/ssh/test" && test == "TestSSHCLIAuth"
```

Issue created automatically to collect these failures.

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

    === RUN   TestSSHCLIAuth
    *** Test killed with quit: ran too long (11m0s).
    signal: killed


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: neovim
Issue: vim.system zombie process with detach=false
Labels: bug,job-control,lua,has:plan

### Problem

I'm experiencing zombie process when exiting neovim even though detach is set to false.
```pstree -p``` when neovim is still open: 

![image](https://github.com/neovim/neovim/assets/8473233/d2d52ecd-3878-4c3a-be2a-b6757a007a80)

```pstree -p``` when neovim is closed:

![image](https://github.com/neovim/neovim/assets/8473233/99351765-ac01-435b-94b2-7be3486e8269)

### Steps to reproduce

nvim --clean
:lua vim.system({ "kubectl", "proxy", "--port=0" }, {detach = false})
:q!

### Expected behavior

I'm expecting the child process to be terminated when the parent is terminated if detached is set to false.
If I'm understanding the docs about detached correctly, I need to set it to true to make it live beyond the parents lifetime:
```
• detach: (boolean) If true, spawn the child process in a
detached state - this will make it a process group
leader, and will effectively enable the child to keep
running after the parent exits. Note that the child
process will still keep the parent's event loop alive
unless the parent process calls |uv.unref()| on the
child's process handle.
```

I have a workaround to manually kill it on VimLeavePre but I doubt that will run if neovim crashes:
```lua
  vim.api.nvim_create_autocmd("VimLeavePre", {
    callback = M.stop_kubectl_proxy(),
  })
```

### Neovim version (nvim -v)

v0.11.0-dev

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

I don't know

### Operating system/version

Windows 11 (WSL)

### Terminal name/version

Wezterm/20240203-110809-5046fc22

### $TERM environment variable

xterm-256color

### Installation

sudo apt-get install neovim
Repository: kubernetes
Issue: Job API: Relax validation enforcing Pod Failure Policy is only compatible with pod restart policy of "Never"
Labels: kind/feature,sig/apps,needs-triage,wg/batch

### What would you like to be added?

Relax [validation](https://github.com/kubernetes/kubernetes/blame/b510f785e6f65cf10ed80b0eb032e867676c49a7/pkg/apis/batch/validation/validation.go#L290-L290) enforcing Pod Failure Policy is only compatible with pod restart policy of "Never"

### Why is this needed?

[JobSet](https://github.com/kubernetes-sigs/jobset) is a Kubernetes SIG project which provides a unified k8s native API for distributed ML training and HPC workloads. 

When any worker in a distributed ML training workload fails, generally all workers must restart and resume training from the latest checkpoint. This is currently implemented by deleting and recreating all Jobs, forcing all pods to be recreated, but recreating and rescheduling tens of thousands of pods becomes a bottleneck at scale and slows down failure recovery.

One major initiative we are working on is reducing failure recovery time by restarting pod's containers in place as much as possible, minimizing the number of pods which must be recreated and rescheduled. I'm prototyping a few approaches for this, but they all involve an external controller forcibly killing the container processes in some way, forcing Kubelet to recreate them, thus "restarting" the worker processes. This is because we want to minimize writes to etcd and apiserver involvement in this process, which can become bottlenecks at scale. 

For this to work, we need to be able to use a [podFailurePolicy](https://kubernetes.io/docs/tasks/job/pod-failure-policy/) to ignore pod failures which occur due to the SIGKILL exit code (9), with a pod `RestartPolicy: OnFailure`, thus allowing Kubelet to restart these pods' containers without counting against the Job's `backOffLimit` (causing the Job to fail). 

### Why does this validation exist in the first place

In the Pod Failure Policy KEP the justification for this validation is that it [precludes the need to handle certain race conditions between Kubelet and the Job controller](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/3329-retriable-and-non-retriable-failures/README.md#relationship-with-podspecrestartpolicy). However, now that we have a concrete use case for podFailurePolicy used with pod restart policy of `"OnFailure"`, I'm hoping we can enumerate those race conditions and find ways to handle them gracefully, rather than preventing `"OnFailure"` from being used ata
Repository: pytorch
Issue: line-length of ruff, black and isort are not the same in pyproject.toml
Labels: module: lint,triaged

### 🐛 Describe the bug

line-lengths in pyproject differ: ruff (120), black (88) and isort (88). Causing inconsistent formatting.

Technically not a bug, more of an aesthetic issue.

Already made a PR for this: https://github.com/pytorch/pytorch/pull/129406

### Versions

n/a
Repository: go
Issue: cmd/compile: seemingly valid generic interface rejected
Labels: NeedsInvestigation,early-in-cycle,compiler/runtime

I don't see a good reason why the following interface should be invalid:

```Go
type Element[E Element[E]] interface {
	Less(E) bool
}
```
Yet the compiler reports an invalid recursive type.
See example application [here](https://go.dev/play/p/aOu91dCCztg?v=gotip).
Repository: ollama
Issue: Support Multiple Types for OpenAI Completions Endpoint
Labels: feature request

Allow v1/completions to handle []string, []int and [][]int, in addition to just a string
Repository: godot
Issue: `GPUParticlesCollisionSDF3D` does not seem to have any visible effect on particles
Labels: bug,topic:rendering,topic:editor

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

I have two identical particle systems. Both are set up to have collision mode rigid. Both particle systems are above a cube with which they are supposed to collide. The left particle system interacts with a `GPUParticlesCollisionBox3D` which shows some tunneling issues as identified in https://github.com/godotengine/godot/issues/93570. The right particle system is supposed to interact with a `GPUParticlesCollisionSDF3D`.  This is set up to calculate an SDF for a box with the same extents as the `GPUParticlesCollisionBox3D` on the left side. However, no matter which resolution is baked, the particles just go right through the `GPUParticlesCollisionBox3D`. This problem persists even if I double the thickness of the geometry.  Also the AABB is set up correctly so it's not an instance of https://github.com/godotengine/godot/issues/93567 :

https://github.com/godotengine/godot/assets/327257/ce0be673-e66b-41e5-8e55-73129812e8ad


 

### Steps to reproduce

In the attached reproducer project, open `particle_collisions_test3.tscn` to inspect and play around with the setup.

### Minimal reproduction project (MRP)

[reproducer3.zip](https://github.com/user-attachments/files/15961444/reproducer3.zip)
Repository: TypeScript
Issue: Warn when regular expression is used in conditional
Labels: Suggestion,Experience Enhancement

### 🔍 Search Terms

- conditional
- regular expression
-  regex

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

When a regular expression literal appears in a conditional, such as:

```ts
if (/abc?/) {
    foo()
} else {
    bar()
}
```

It would be helpful warn that `bar()` is unreachable. The programmer likely meant to call `/abc?/.test(...)`

TypeScript could help catch this easy to make mistake

### 📃 Motivating Example

We recently were bitten by this in VS Code. It slipped through code review too

### 💻 Use Cases

Help programmers catch an easy to make mistake
Repository: flutter
Issue: [flutter_engprod] LUCI timing out a step should allow tests to clean themselves up
Labels: team-infra,P2,triaged-infra

Notably, flutter devicelab tests could take a screenshot.

If a test is running `flutter drive ...` with the --screenshot flag, it will capture signals and take a screenshot during cleanup (https://github.com/flutter/flutter/pull/114118), I don't think these signals ever reach the tool because we are running them via several layers of wrapper scripts.
Repository: pytorch
Issue: functionalization should run underneath python decomps
Labels: triaged,module: functionalization,oncall: pt2,oncall: export,module: pt2-dispatcher

Today, functionalization runs in the dispatcher, **before** proxy tracing (but after, e.g. tensor subclass desugaring).

One consequence is that `ProxyTorchDispatchMode` takes in a decomp table to that gets applied during tracing, and this decomp table runs underneath/after functionalization. This imposes a restriction: any decompositions that you use during compile **must** not desugar into mutable ops.

This bit us recently, see ([internal post](https://fb.m.workplace.com/groups/pytorch.edge.users/permalink/1537923917077896/)).

Now that functionalization is in python, it should be relatively trivial to run these decomps during functionalization so we can functionalize the decomps properly: pass the same decomp table into `FunctionalTensorMode`, and have the mode run any decomps it sees.

One small downside worth calling out is: it is within the realm of possibility that we might want to move functionalization back to C++ for compile performance, and features like the decomp table are a lot more of a pain to re-implement in C++ compared to python. I'm not sure this is enough of a reason not to make this change though, which is a nice UX improvement for people adding new decomps into compile/export.

cc @ezyang @chauhang @penguinwu @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4 @zou3519 @anijain2305
Repository: pytorch
Issue: OperatorBase.py_impl should support with_keyset=True extra argument.
Labels: triaged,oncall: pt2,oncall: export,module: pt2-dispatcher

### 🚀 The feature, motivation and pitch

In export, we want to override Autograd alias keys so that we don't decompose via CIA. As a result, we would want to error when someone tries to run autograd while tracing (like running to joint graph). To do this correctly, we want to re-use the logic that we use for custom ops which relies on op.redispatch behaviour which requires us to pass in DispatchKeySet. This doesn't work today with python dispatchers today and we should implement it. 

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @chauhang @penguinwu @avikchaudhuri @gmagogsfm @zhxchen17 @angelayi @suo @ydwu4 @zou3519 @bdhirsh