sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: AnimationMixer immediately emits animation_finished upon traveling to AnimationNodeBlendSpace1D when blend_point changes while the blendspace node is not playing.
Labels: bug,needs testing,topic:animation

### Tested versions

- Reproducible in v4.2.2.stable.official [15073afe3]

### System information

Godot v4.2.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GT 730 (NVIDIA; 30.0.14.7414) - Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (8 Threads)

### Issue description

In some situations, a AnimationNodeBlendSpace1D node can fire animation_finished immediately after traveling to it without first playing the animation.

### Steps to reproduce

Given an AnimationTree with two nodes: "idle", an AnimationNodeAnimation, and "attack", an AnimationNodeBlendSpace1D with 3 points, one at 0.0 for animation "attack_1" and one positive point and one negative point each for animation "attack_2".  There is also an animation_finished handler that calls travel("idle") when it fires.

1) Set the "attack" blend point to a value that would call one of the animations, ie 1.0 for "attack_2"
2) travel("attack")
3) await animation_tree.animation_finished.  The animation_finished handler calls travel("idle")
4) Optionally wait an arbitrary amount of time
5) Set the "attack" blend point value to a different "zone" so another blend point is used that would call the other attack animation, ie 0.0 for "attack_1"
6) Optionally wait an arbitrary amount of time
7) travel("attack")
8) Note that animation_finished fires for "attack_1" the next frame.

A way I've found to get around the problem is to add blend points in code, not the editor.  Even removing each editor-created blend points and immediately re-adding them will make this work as expected.

**Side comment**
It would be great to have a signal like "animation_node_finished" that would emit at the same time that the "At End" transition would normally occur.  Otherwise, it appears we have to test for any one of the animations within the blendspace to have finished.

### Minimal reproduction project (MRP)

[AnimationTreeTest2.zip](https://github.com/godotengine/godot/files/15382681/AnimationTreeTest2.zip)
Repository: rust
Issue: rustc from homebrew produces SIGBUS: access to undefined memory when -v is provided
Labels: C-discussion

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
use std::path::{Path,PathBuf};
use std::{env,fs}; 

//TODO
// read src folder into a vec
// convert to typst
// compile to pdf

fn main() ->Result<(), AppError>{
   println!("Hello, world!");
    Ok(())
}

cargo build -v
```

I expected to see this happen: *explanation*
code checked and compiled

Instead, this happened: *explanation*
crash only when -v is provided
```
Caused by:
  process didn't exit successfully: `CARGO=/opt/homebrew/Cellar/rust/1.78.0/bin/cargo CARGO_BIN_NAME=rst CARGO_CRATE_NAME=rst CARGO_MANIFEST_DIR=/Users/drgo/local/code/booker/rs CARGO_PKG_AUTHORS='' CARGO_PKG_DESCRIPTION='' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=rst CARGO_PKG_README='' CARGO_PKG_REPOSITORY='' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.1.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' CARGO_PRIMARY_PACKAGE=1 DYLD_FALLBACK_LIBRARY_PATH='/Users/drgo/local/code/booker/rs/target/debug/deps:/Users/drgo/lib:/usr/local/lib:/usr/lib' rustc --crate-name rst --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=98 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C split-debuginfo=unpacked -C metadata=a4aaf64bcde3c91c -C extra-filename=-a4aaf64bcde3c91c --out-dir /Users/drgo/local/code/booker/rs/target/debug/deps -C incremental=/Users/drgo/local/code/booker/rs/target/debug/incremental -L dependency=/Users/drgo/local/code/booker/rs/target/debug/deps` (exit status: 1)
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
ustc 1.78.0 (9b00956e5 2024-04-29) (Homebrew)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: aarch64-apple-darwin
release: 1.78.0
LLVM version: 18.1.4
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

backtrace is not produced probably because of the crash
Repository: PowerToys
Issue: [Run] IndexOutOfRangeException: Index was outside the bounds of the array
Labels: Issue-Bug,Product-PowerToys Run,Needs-Triage,Severity-Medium

### Microsoft PowerToys version

0.80.1.0

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

Occurred during start-up

```
Version: 0.80.1.0
OS Version: Microsoft Windows NT 10.0.22631.0
IntPtr Length: 8
x64: True
Date: 21/05/2024 8:32:40 AM
Exception:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at System.Windows.Input.PenThreadWorker.ThreadProc()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
```

![PowerToysRun-IndexOutOfRangeException](https://github.com/microsoft/PowerToys/assets/8622454/fe2b136d-39c7-4771-93fb-9cfbbafe928f)

[2024-05-21.txt](https://github.com/microsoft/PowerToys/files/15382890/2024-05-21.txt)

### ✔️ Expected Behavior

Silent startup

### ❌ Actual Behavior

`System.IndexOutOfRangeException`

### Other Software

I have recently upgraded from Win10 to Win11

Am able to start PowerToys manually (post start-up), here is the General Settings page
![PowerToys-General](https://github.com/microsoft/PowerToys/assets/8622454/74d7c14c-42ce-466f-8988-594c9e1731f7)
Repository: tauri
Issue: [bug] [updater] the updater will install new version to perMachine after changing installer mode from currentUser to both
Labels: type: bug,platform: Windows,status: needs triage

### Describe the bug

the updater will install new version to perMachine after changing installer mode from currentUser to both

In my app ([ALCOM](//github.com/vrc-get/vrc-get/tree/master/vrc-get-gui)), previously installer type is default (currentUser) and I changed to both but it installs new version to perMachine location.

### Reproduction

1. create Tauri app with currentUser configuration and updater
2. build nsis installer and install the app
3. change installer mode to both
4. upgrade the app with updater
5. the updater will install to perMachine location

### Expected behavior

the updater should install to currentUser location

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.22631 X64
    - tauri-build [RUST]: 1.5.2
    - wry [RUST]: 0.24.9
    - tao [RUST]: 0.16.9
    - tauri-cli [RUST]: 1.5.10
    - @tauri-apps/api [NPM]: 1.5.6
    - @tauri-apps/cli [NPM]: 1.5.14

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: out
    - devPath: http://localhost:3000/
    - framework: React (Next.js)
    - bundler: Webpack
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: neovim
Issue: asynchronous :make, :grep, etc
Labels: enhancement,async

### Problem

Current `:make` `:grep` and others block, it would be nice if these commands ran asynchronously and allowed us to use the editor. (similar to how emacs does it)

### Expected behavior

Use `:make` to start an async compilation and while the compilation is happening we could have a special buffer `compile://` which will be collecting the output and once the compilation has finished this output could be sent to the quickfix list.

One particular thing we should take care of is jumping to the first error message, we do not want this to happen in async mode as the user might be doing something while the compilation has finished and suddenly be jumped to somewhere else, it would be annoying.
Repository: ant-design
Issue: Bad perf with mix theme usage in Table
Labels: Inactive,unconfirmed

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/p/sandbox/zen-sanderson-6m4s3h)

### Steps to reproduce

Scroll the screen

### What is expected?

Smooth scroll

### What is actually happening?

Long lagging

| Environment | Info |
| --- | --- |
| antd | 5.17.3 |
| React | 18.3.1 |
| System | IOS |
| Browser | chrome |

---
Maybe the perf issue on the Theme render logic. Need check this.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: godot
Issue: C# script does not list non-exported properties unlike GDScript
Labels: bug,discussion,topic:dotnet

### Tested versions

v4.1.3.stable.mono, All 4.2.2 release candidates, 4.2.2.stable.mono

### System information

Godot v4.2.2.stable.mono - Desktop

### Issue description

Non exported C# properties do not show up in GDScript autocomplete.
They can be set and get, just fine though.

This is a problem for a few reasons:
1) It's tedious to have to add export to every member I want to be added to autocomplete.
2) I often have to use @warning_ignore("unsafe_property_access") on non-exported properties (for no good reason)
3) When I have C# scripts that extend RefCounted, I cannot even put [Export] on Node properties for autocomplete due to "Error GD0107 : Types not derived from Node should not export Node properties"

Which is why non C# exported properties should be included in GDScript autocomplete.

### Steps to reproduce

Have a C# script like this
```csharp
using Godot;

[GlobalClass]
public partial class ACSharpScript : RefCounted
{
	[Export] public int SomeExportedProperty { get; set; }
	public int SomeProperty { get; set; }

	[Export] public int someExportedField;
	public int someField;

	// "Error GD0107 : Types not derived from Node should not export Node properties"
	// [Export] public Node SomeExportedNode { get; set; }
	public Node SomeNode { get; set; }
}

```

Only exported properties (and fields) show up in autocomplete
![image](https://github.com/godotengine/godot/assets/73148864/08522bd5-461f-4a8a-9beb-61c06313e27d)




### Minimal reproduction project (MRP)

[MRP.zip](https://github.com/godotengine/godot/files/15384018/MRP.zip)
Repository: TypeScript
Issue: Syntax highlighting can not resolve @throws of tsdoc
Labels: Bug,Help Wanted,Domain: JSDoc

Type: <b>Bug</b>

Syntax highlighting for typescript has problem for the function that has `@throws` .

TSDoc used `@throws {@link IsbnSyntaxError}` format but VSCode shows broken lint text with break-lines like below:

![image](https://github.com/microsoft/vscode/assets/48498820/a49685ef-bde8-4152-bc34-812dabde81f9)

```ts
// from tsdoc sample: https://tsdoc.org/pages/tags/throws/
type Book = any;

/**
 * @throws {@link IsbnSyntaxError}
 * This exception is thrown if the input is not a valid ISBN number.
 */
function fetchBookByIsbn(isbnCode: string): Book {}
```

I thought vscode does not support tsdoc and using jsdoc but jsdoc does not shows correct info too. (this may be related with: https://github.com/microsoft/vscode/issues/135417 )


I expected it shows a link for the Type, at least shows as simple text without break-line.



I may have to report this on other project (TmLanguage? https://github.com/microsoft/TypeScript-TmLanguage/issues) but I did here from VSCode reporter anyway.

VS Code version: Code 1.89.1 (dc96b837cf6bb4af9cd736aa3af08cf8279f7685, 2024-05-07T05:13:33.891Z)
OS version: Windows_NT x64 10.0.19045
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz (6 x 3000)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|31.78GB (11.72GB free)|
|Process Argv|--disable-extensions --crash-reporter-id ca2a1b94-1896-42fa-87dc-e58738a43fa3|
|Screen Reader|no|
|VM|0%|
</details>Extensions disabled
<!-- generated by issue reporter -->
Repository: pytorch
Issue: [cudagraph] simplify usage of how cudagraph dumps debug file
Labels: triaged,module: cuda graphs

### 🚀 The feature, motivation and pitch

According to the [documentation](https://pytorch.org/docs/stable/generated/torch.cuda.CUDAGraph.html), to dump the structure of a cudagraph into a file, we have to do the following:

```python
import torch
g = torch.cuda.CUDAGraph()
g.enable_debug_mode()

# Placeholder input used for capture
static_input = torch.empty((5,), device="cuda")

# Warmup before capture
s = torch.cuda.Stream()
s.wait_stream(torch.cuda.current_stream())
with torch.cuda.stream(s):
    for _ in range(3):
        static_output = static_input * 2
torch.cuda.current_stream().wait_stream(s)

# Captures the graph
# To allow capture, automatically sets a side stream as the current stream in the context
with torch.cuda.graph(g):
    static_output = static_input * 2

g.debug_dump("cuda_graph_hooked.dot")
```

This is quite long, which involves 4 steps:
- create a graph object `g = torch.cuda.CUDAGraph()`
- enable debug mode `g.enable_debug_mode()`
- capture the graph `with torch.cuda.graph(g):`
- call debug dump `g.debug_dump("cuda_graph_hooked.dot")`

In addition, this will trigger quite a lot warnings, e.g.

```text
/data/xxx/miniconda/envs/vllm/lib/python3.9/site-packages/torch/cuda/graphs.py:82: UserWarning: DEBUG: TORCH_CUDAGRAPHS_DEBUG_PATH detected. graph_ will not be freed until debug_dump is called. (Triggered internally at ../aten/src/ATen/cuda/CUDAGraph.cpp:240.)
  super().capture_end()
/data/xxx/miniconda/envs/vllm/lib/python3.9/site-packages/torch/cuda/graphs.py:112: UserWarning: DEBUG: calling debug_dump() (Triggered internally at ../aten/src/ATen/cuda/CUDAGraph.cpp:294.)
  return super().debug_dump(debug_path)
/data/xxx/miniconda/envs/vllm/lib/python3.9/site-packages/torch/cuda/graphs.py:112: UserWarning: DEBUG: calling cudaGraphDebugDotPrint() with cuda_graph_no_hooked.dot (Triggered internally at ../aten/src/ATen/cuda/CUDAGraph.cpp:296.)
```

Since pytorch only creates cudagraph by stream capture, i think it should be possible to unify these 4 steps into one, e.g.

```python
with torch.cuda.graph(dump_file="cuda_graph_hooked.dot") as g:
    static_output = static_input * 2
```

cc @mcarilli @ezyang @eellison @peterbell10 

### Alternatives

_No response_

### Additional context

_No response_
Repository: storybook
Issue: 🗺️ Public roadmap
Labels: documentation

Excited to announce our **[public roadmap](https://github.com/orgs/storybookjs/projects/20/views/1)**! 🎉 

Follow along to see what projects we've shipped, are currently working on, and are considering for the next major version of Storybook. For more information on the structure of the roadmap and how to contribute, please see our [official documentation](https://storybook.js.org/docs/contribute/roadmap).
Repository: pytorch
Issue: inplace parameter in dropouts should function as expected regardless of the value of training(or train) paramter
Labels: module: nn,triaged

### 🐛 Describe the bug

```
import torch

# functional dropouts
for functional_dropout in (torch.nn.functional.dropout, torch.nn.functional.alpha_dropout, torch.nn.functional.feature_alpha_dropout):
    dropout_input = torch.randn(10, 10)

    dropout = functional_dropout(dropout_input, 0.5, training=False, inplace=False)
    dropout_inplace = functional_dropout(dropout_input, 0.5, training=False, inplace=True)
    dropout_training = functional_dropout(dropout_input, 0.5, training=True, inplace=False)
    dropout_training_inplace = functional_dropout(dropout_input, 0.5, training=True, inplace=True)

    print(id(dropout_input) != id(dropout)) # False, should't this be True?
    print(id(dropout_input) == id(dropout_inplace)) # True, makes sense
    print(id(dropout_input) != id(dropout_training)) # True, makes sense
    print(id(dropout_input) == id(dropout_training_inplace)) # True, makes sense

# torch dropouts
for torch_dropout, torch_dropout_inplace in ((torch.dropout, torch.dropout_), (torch.feature_dropout, torch.feature_dropout_), (torch.feature_alpha_dropout, torch.feature_alpha_dropout_)):
    dropout_input = torch.randn(10, 10)

    dropout = torch_dropout(dropout_input, 0.5, train=False)
    dropout_inplace = torch_dropout_inplace(dropout_input, 0.5, train=False)
    dropout_training = torch_dropout(dropout_input, 0.5, train=True)
    dropout_training_inplace = torch_dropout_inplace(dropout_input, 0.5, train=True)

    print(id(dropout_input) != id(dropout)) # False, should't this be True?
    print(id(dropout_input) == id(dropout_inplace)) # True, makes sense
    print(id(dropout_input) != id(dropout_training)) # True, makes sense
    print(id(dropout_input) == id(dropout_training_inplace)) # True, makes sense

```

dropouts are always inplace when training(or train) is set to False

### Versions

Collecting environment information...
PyTorch version: 2.3.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 14.0 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: version 3.23.2
Libc version: N/A

Python version: 3.10.13 (main, Sep 11 2023, 08:16:02) [Clang 14.0.6 ] (64-bit runtime)
Python platform: macOS-14.0-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] mypy==1.7.1
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.4
[pip3] onnx==1.15.0
[pip3] torch==2.3.0
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] torch                     2.3.0                    pypi_0    pypi

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: godot
Issue: Entire lower part of screen shifts up 2px during textbox actions
Labels: bug,needs testing,topic:gui

### Tested versions

- Reproducible in v4.2.2.stable.official [15073afe3]

### System information

Godot v4.2.2.stable - Windows 10.0.22631 - GLES3 (Compatibility) - AMD Radeon(TM) RX 7700S (Advanced Micro Devices, Inc.; 31.0.22024.17002) - AMD Ryzen 7 7840HS w/ Radeon 780M Graphics (16 Threads)

### Issue description

Some text/menu related actions cause a large section of the screen intermittently shifting up one or two pixels, presumably overwriting 1-2 rows of pixels at about the 403~405 mark. Any dropdown menus experiencing this issue have a shift line at a different height than the main window.

### Steps to reproduce

The issue presents when using my dedicated graphics (AMD Radeon RX 7700S) in conjunction with any of the below triggers:
- Script View: Caret (text cursor bar thing) is in a textbox and there is no mouse movement, the shifting occurs at a consistent roughly half second interval
- 2D View: Moving the mouse over the "Output", "Debugger", etc. buttons
- Any View: Fiddling with the top-left menu buttons (ie. clicking once on Scene, going over the menu, then back up to the menu bar and moving to a different menu without re-clicking the button so that it remains open as you open/collapse the menus on mouseover)

I am unsure of the *specific* triggers, but it may also be a driver issue with my graphics card, as switching to my APU resolves the mentioned issues (that, and I am using a Framework 17, which only began shipping 2 months ago so I am expecting hardware/driver jank.)

I suspect that very few, if any, other graphics cards have the same issue.

### Minimal reproduction project (MRP)

This issue is reproducible in a default project, and a new script/text file will produce this behaviour.
Repository: next.js
Issue: window.history.pushState does not work with transitions
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/arackaf/react-query-rsc-blog-post/blob/special/push-state-with-transition/src/app/components/BookSearchForm.tsx#L23

### To Reproduce

Run app
Browse to http://localhost:3000/react-query 
Type "the" in the search box and hit enter

### Current vs. Expected behavior

The transition is not respect, and the component suspends to the nearest Suspense boundary 

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64
  Available memory (MB): 16384
  Available CPU cores: 16
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: N/A
  pnpm: 8.14.0
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: N/A
  react: 19.0.0-beta-04b058868c-20240508
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


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

Navigation

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

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

### Additional context

This is a crucial feature for shallow routing. I hope it sees its way in, soon! 🙏
Repository: neovim
Issue: systemlist generates errors when buffer number is passed and command expects stdin
Labels: bug

### Problem

Running `systemlist` with a command that expects input from `stdin` prepends the following error messages to the output:

```
error: Unable to read input file: Is a directory
source: Error while reading file '<stdin>'
error: Unable to read input file: Is a directory
source: Error while reading file '<stdin>'
```

I initially encountered this when [formatting](https://github.com/neovim/neovim/blob/b7782daacebf8842bece6e41a20ee9a4859721e6/runtime/autoload/zig/fmt.vim#L31) a Zig file, though it seems to be a general problem, as the same behaviour is reproducible with `cat`.

### Steps to reproduce

nvim --clean --cmd 'echo systemlist("cat", bufnr(""))'


### Expected behavior

No errors in the returned output

### Neovim version (nvim -v)

NVIM v0.11.0-dev-19+g0f4f7d32c and v0.10.0

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

no, vim version 9.0.2018

### Operating system/version

macOS 14.2.1 (23C71)

### Terminal name/version

kitty 0.32.2

### $TERM environment variable

screen-256color

### Installation

Brew and build from source
Repository: ollama
Issue: Please support LoongArch ISA
Labels: feature request

https://github.com/ggerganov/llama.cpp/pull/6454#issuecomment-2119832472