sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: testing: writeProfiles is not called after panic
Labels: NeedsInvestigation

### Go version

go1.21.4

### Output of `go env` in your module/workspace:

```shell
GO111MODULE='auto'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/user/Library/Caches/go-build'
GOENV='/Users/user/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS='-count=1'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/felixge/go/pkg/mod'
GONOPROXY='github.com/Org'
GONOSUMDB='github.com/Org,go.orgbuild.io'
GOOS='darwin'
GOPATH='/Users/user/go'
GOPRIVATE='github.com/Org'
GOPROXY='binaries.orgbuild.io,proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.21.4/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.21.4/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/user/go/src/github.com/felixge/dump/trace-panic/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/0t/nwrdnfnd2mjdgr0z_p_f6xww0000gq/T/go-build2519625148=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

Debug a test that hit a panic using `go test -trace`. Below is a greatly simplified example that reproduces the problem. Run it with `go test -trace go.trace`.


```go
package main

import (
	"context"
	"fmt"
	"runtime/trace"
	"testing"
)

func TestTracePanic(t *testing.T) {
    // This simulates some trace buffers getting flushed before the test panics.
	for i := 0; i < 100000; i++ {
		trace.Log(context.Background(), "log", fmt.Sprintf("%d", i))
	}
	panic("panic")
}
```

### What did you see happen?

```
$ go tool trace go.trace 
2024/01/17 10:56:02 Parsing trace...
failed to parse trace: no EvFrequency event
```

### What did you expect to see?

A valid trace file that I can open.

### Additional Thoughts

This reproduces with tip.

The problem seems to be that the [`after()`](https://github.com/golang/go/blob/8e658eee9c7a67a8a79a8308695920ac9917566c/src/testing/testing.go/#L2248-L2250) func that is supposed to call `writeProfiles` doesn't get called when a test panics because [`tRunner()`](https://github.com/golang/go/blob/master/src/testing/testing.go/#L1742) runs in a different goroutine.
Repository: PowerToys
Issue: [feature request] File Explorer - Skip extra window when clicking "Extract all" for a zip file
Labels: Idea-New PowerToy,Product-File Explorer

### Description of the new feature / enhancement

A window "Extract compressed (zipped) folders" opens whenever trying to extract zip files.

![image](https://github.com/microsoft/PowerToys/assets/18724661/83a99eb1-0d56-438e-9a5e-d2d966f1a956)

It's tiresome when having to extract multiple files (yes I know 7-zip).

Would be good to have the option to skip it to extract directly (in current folder), maybe by replacing the button "Extract All" with "Extract Here" (or simply extract).

### Scenario when this would be used?

When extracting a zip file to current folder.

### Supporting information

_No response_
Repository: neovim
Issue: Lua: vim.g and nvim_set_var() handle nil differently
Labels: documentation,api

### Problem

Setting `vim.g.myvar` to `nil` removes the variable, as per vimscript `:unlet`.
Setting `myvar` to `nil` using `nvim_set_var()` sets it to `nil` (lua) and `v:null` (vimscript).

The same is true of `vim.b.myvar` and `nvim_buf_set_var()`.

### Steps to reproduce

```
:lua vim.g.TEST = "test"
:echo exists("TEST")
" 1
:lua vim.g.TEST = nil
:echo exists("TEST")
" 0
:lua vim.g.TEST = "test"
:echo exists("TEST")
" 1
:lua vim.api.nvim_set_var("TEST", nil)
:echo exists("TEST")
" 1
: echo TEST
" v:null
```

### Expected behavior

Having used vim.g and vim.b for some time I was used to "unletting" variables by setting them to `nil`. I expected, perhaps naively, that `nvim_set_var()` would behave the same. I suspect there are good technical reasons for why they do not, in which case it would help inexperienced users if the help documentation for these features explained how they differ.

### Neovim version (nvim -v)

0.9.5

### Vim (not Nvim) behaves the same?

cannot test lua commands in vim

### Operating system/version

debian linux 6.5.13-1 (2023-11-29)

### Terminal name/version

alacritty 0.12.2

### $TERM environment variable

screen-256color

### Installation

appimage
Repository: godot
Issue: 'MODE_COPY_SECTION_SOURCE': undeclared identifier in copy_effects.cpp when build the project	
Labels: bug,topic:rendering

### Tested versions

Current master

### System information

Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.3619) - 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 Threads)

### Issue description

When build the project, I got `MODE_COPY_SECTION_SOURCE : undeclared identifier in drivers\gles3\effects\copy_effects.cpp`

![image](https://github.com/godotengine/godot/assets/8315986/e60fd46f-4c65-46cd-b0cd-a7ba9a033ba4)

It looks like in certain cases the `copy.glsl.gen.h` did not generate the definition for `MODE_COPY_SECTION_SOURCE`

```
	enum Uniforms {
		COPY_SECTION,
		SOURCE_SECTION,
		COLOR_IN,
		PIXEL_SIZE,
	};

	enum ShaderVariant {
		MODE_DEFAULT,
		MODE_COPY_SECTION,
		MODE_GAUSSIAN_BLUR,
		MODE_MIPMAP,
		MODE_SIMPLE_COLOR,
		MODE_CUBE_TO_OCTAHEDRAL,
	};
```

Is there any way to debug this?

### Steps to reproduce

Not sure how I get there, but **I checked out to an old branch and rebased it to master** before I encountered this error. Maybe there is some unsync problem here? Also I can make sure that I did not have any local git changes in my repo. 

### Minimal reproduction project (MRP)

N/A
Repository: rust
Issue: fs::create_dir_all doesn't work on other computers
Labels: O-windows,T-libs,A-io

Hi everyone, sorry for my bad english

I have this code:

```

// Here there is a path generation algorithm, i've excluded it because on the two computers the generated path are the same

//The generated path
let new_file_path = "Z:\NUOVO RAPPORTINO ELETTRONICO\2024\1 Gennaio\Name Surname";

match std::fs::create_dir_all(new_file_path) {
    Ok(_r) => {
    
        println!("Creazione cartelle avvenuta con successo!");
        
        //Other things to do if succeeds
      
    },
  
    Err(error) => {
        println!("Errore durante la creazione delle cartelle: {error}");
        println!("GetLastError: {}", unsafe { GetLastError().to_string() });
    },

}
```

that runs fine on my computer, but throws a runtime error on another.

On the other computer, std::fs::create_dir_all throws this error: `failed to create whole tree`
and winapi's GetLastError() gives me: `ERROR_PATH_NOT_FOUND`

The OSs are not the same, mine is Windows 10, the other one is Windows 11, but i don't think that's the problem.

I've compiled it with `cargo build --release`

`Z:\` is a shared network folder on a third computer (Windows 11), but both computer one and two have same permissions

The path `Z:\NUOVO RAPPORTINO ELETTRONICO\2024` already exist, on my computer it generates `\1 Gennaio\Name Surname` in it and then proceed with the other code, on the other one it throws the same errors both if the path "fully" exists (doesn't need to create any folder) or if it needs to create it.

Does anyone have any clue on what's going on?
Repository: storybook
Issue: [Bug]: Vue 3.4 - props and events are not inferred from `defineModel`
Labels: bug,vue3,argtypes,sev:S2

### Describe the bug

Since `defineModel` became stable in Vue 3.4, [this is now the recommended approach](https://vuejs.org/guide/components/v-model.html) for using `v-model`.

Ideally Storybook would understand that `defineModel` is constructing the props/events for these (example below) and display them in the `argTypes` automatically. It would be preferred if both the type and JSDoc comment could be understood also.

_After 3.4:_
```vue
<script setup>
const model = defineModel();
</script>

<template>
  <input v-model="model" />
</template>
```

_Before 3.4:_
```vue
<script setup>
const props = defineProps(['modelValue']);
const emit = defineEmits(['update:modelValue']);
</script>

<template>
  <input
    :value="props.modelValue"
    @input="emit('update:modelValue', $event.target.value)"
  />
</template>
```
Repository: neovim
Issue: mouse support in Git bash (mintty / Windows)
Labels: bug,platform:windows,tui,mouse

### Problem

`nvim` shoud have mouse support (`:set mouse=nvi`) by default.

This works as expected from `cmd.exe` and powershell (I'm testing on Windows 10, with the preinstalled powershell, not powershell core), but does not from `git-bash` (and cygwin, but I'm more concerned with `git-bash`)

### Steps to reproduce

 * open `git-bash` (the shortcut executes `"C:\Program Files\Git\git-bash.exe" --cd-to-home`)
 * execute `'/c/Program Files/Neovim/bin/nvim.exe' --clean`
 * press `i` to enter insert mode
 * write something
 * click with the mouse to try to change the cursor position

NOTE, I've also tried unsetting `TERM`, but it did not make a difference.

### Expected behavior

I would expect mouse support to behave the same in `git-bash`, powershell and `cmd.exe`

### Neovim version (nvim -v)

NVIM v0.9.5

### Vim (not Nvim) behaves the same?

yes (vim for windows, not vim of git-bash, and also after enabling mouse support)

### Operating system/version

Windows 10

### Terminal name/version

mintty 3.7.0 (x86_64-pc-msys)

### $TERM environment variable

xterm-256color

### Installation

Downloaded msi installer
Repository: storybook
Issue: [Bug]: Failed to fetch dynamically imported module
Labels: bug,has workaround,svelte,builder-vite,sveltekit,sev:S2

### Describe the bug

1. Open [storybook.new](https://storybook.new/)
2. Choose SvelteKit (TypeScript)

<img width="1582" alt="截屏2024-01-17 13 39 31" src="https://github.com/storybookjs/storybook/assets/56141162/d5a5d81e-f913-40b1-b89c-be7ecf36f82d">

### To Reproduce

_No response_

### System

```bash
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.18.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm <----- active
    pnpm: 8.14.0 - /usr/local/bin/pnpm
  npmPackages:
    @storybook/addon-essentials: ^8.0.0-alpha.10 => 8.0.0-alpha.10 
    @storybook/addon-interactions: ^8.0.0-alpha.10 => 8.0.0-alpha.10 
    @storybook/addon-links: ^8.0.0-alpha.10 => 8.0.0-alpha.10 
    @storybook/blocks: ^8.0.0-alpha.10 => 8.0.0-alpha.10 
    @storybook/svelte: ^8.0.0-alpha.10 => 8.0.0-alpha.10 
    @storybook/sveltekit: ^8.0.0-alpha.10 => 8.0.0-alpha.10 
    @storybook/test: ^8.0.0-alpha.10 => 8.0.0-alpha.10 
    storybook: ^8.0.0-alpha.10 => 8.0.0-alpha.10
```

### Additional context

I have the same problem when I install SvelteKit + TS and Storybook locally.
Repository: material-ui
Issue: [material-ui] Improve `slot.transition` and `TransitionProps` types
Labels: breaking change,typescript,component: transitions,package: material-ui,enhancement,customization: dom

The [`TransitionProps`](https://github.com/mui/material-ui/blob/288863bd2f8681a82c4bfbaf13215b41043bc551/packages/mui-material/src/transitions/transition.ts#L28) is based on the type with the same name coming from `react-transition-group/Transition`. The `children` prop is optional. There are a bunch of places where we do this to make `children` required:

```
TransitionProps & { children: React.ReactElement<any, any> }
```

<img width="528" alt="User Image" src="https://github.com/user-attachments/assets/dbab8bb7-e8d1-4e91-92d1-66e57cc4b9c1">

We should standardize how we treat `children` in `TransitionProps` across the codebase. Potential solutions that can be explored:

- Make `children` required in `TransitionProps` (material-ui).
- Update transition components and make children optional in all of them.

Other things to consider:
- Some `slots.transition` props (Accordion, Backdrop, SpeedDial) have the following type:
  ```
  transition?: React.JSXElementConstructor<
    TransitionProps & { children?: React.ReactElement<any, any> }
  >;
  ```
  The correct type should probably be:

  ```
  transition?: React.ElementType<TransitionProps>;
  ```
- Improving the types should fix this issue in an Accordion demo: https://github.com/mui/material-ui/pull/40284#issuecomment-1869849665

**Search keywords**: slots transition typescript
Repository: stable-diffusion-webui
Issue: [Bug]: Style file defaults to ".csv" when "*.csv" is used to load multiple style files.
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

Using the "dev" branch of webui I used the `--styles-file` command line parameter to specify `*.csv` as the pattern to use to match styles files. Although all the expected files loaded, when I edited any of them the changes were written to a file named `.csv` rather than `styles.csv`.``

### Steps to reproduce the problem

1. Launch webui with the `--styles-file` command line parameter set to `*.csv`
2. Edit & save an existing style
3. Observe that a new file named `.csv` has been created

### What should have happened?

1. Launch webui with the `--styles-file` command line parameter set to `*.csv`
2. Edit & save an existing style
3. The new style should have been saved to `styles.csv` (i.e. the default name for a style)

More broadly, if a wildcard is used to load styles csv files, then we should default to "styles.csv" if there is no CSV present that matches the simplest possible match of the wildcard. That is, if `w*.csv` is used to load style files starting with `w`, and `w.csv` doesn't itself exist, then use `styles.csv` as the fall-back default.

### What browsers do you use to access the UI ?

Microsoft Edge

### Sysinfo

[sysinfo-2024-01-17-14-42.json](https://github.com/AUTOMATIC1111/stable-diffusion-webui/files/13964612/sysinfo-2024-01-17-14-42.json)


### Console logs

```Shell
N/A - no error shown in log & bug reporter is already working on a fix
```


### Additional information

_No response_
Repository: pytorch
Issue: Easier way to add a lot of tests
Labels: triaged,module: devx

CI has a system where it tracks the test time of a given test file, figures out how to shard a given test file across shards, and then limits each shard of a test file to ~30 minutes runtime.

If I suddenly add a lot of tests to a single test file, or make them slower, we run into timeouts. The current workarounds around this are:
- manually update CI's test times file, but this is a bit annoying because 1) that file is not checked into the PyTorch repo and 2) CI will automatically overwrite that file every night. I have not been able to successfully get this to work.
- add tests incrementally so that CI rebalances itself. A change that should have taken 1 PR now takes many PRs and many days.

It would be nice to have some way (maybe a label on a PR?) to say, "hey, don't do test timeouts on this PR" or that makes the test timeout something larger, like 3 hours. We shouldn't be making it difficult for folks to add more tests.

cc @ZainRizvi @kit1980 @huydhn @clee2000 @pytorch/pytorch-dev-infra
Repository: PowerToys
Issue: FancyZones area selection not instant if mouse is not moved
Labels: Issue-Bug,FancyZones-Dragging&UI,Needs-Triage

### Microsoft PowerToys version

0.77.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

FancyZones

### Steps to reproduce

When using right click to trigger the zone selection, the zone directly under the cursor at the time of right click does not select until a short random time between 0 and 2 seconds after or until the mouse moves at least 1 pixel. This makes quick selection when the mouse does not move intermittent resulting in missed zone snapping. I believe this behaviour was introduced within the last few versions.

### ✔️ Expected Behavior

Selection of the zone directly under the mouse should be immediate on right clicking to activate the zone.

### ❌ Actual Behavior

The zone does not immediately select unless moving the mouse at least 1 pixel or until 0-2 seconds after.

### Other Software

_No response_
Repository: youtube-dl
Issue: socks5 with DNS-requests
Labels: request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.12.17. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar feature requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a feature request
- [ ] I've verified that I'm running youtube-dl version **2021.12.17**
- [ ] I've searched the bugtracker for similar feature requests including closed ones


## Description

<!--
Provide an explanation of your issue in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->

Using SOCKS-proxy (e.g. socks5://) is already implemented meanwhile, but unfortunately it does not work with DNS-requests (e.g. socks5h://). Is there a possibility to include this "feature"...?
Repository: electron
Issue: [Feature Request]: Introduce ability to abort an IPC `invoke` call
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Like all async requests I would like the ability to early abort them, so that my application can stop doing the work

### Proposed Solution

Change the signature of `IpcRenderer["invoke"]` to the following

```ts
export interface InvokeOptions {
  signal?: AbortSignal;
}

export interface IpcRenderer {
  invoke(channel: string, args: unknown[], options?: InvokeOptions): Promise<unknown>;
}
```

And on the main side:

```ts
export interface IpcMainInvokeEvent {
  processId: number;
  frameId: number;
  sender: WebContents;
  readonly senderFrame: WebFrameMain;
  singal: AbortSignal;
}
```

This way if `abort()` is called on the controller for the signal in "renderer" then the `signal` provided to the event handler in "main" will also be aborted.

### Alternatives Considered

This could in theory be implemented in userland by having a side channel for these abort messages but it would have to be separately maintained and is tricky to correctly implement

### Additional Information

_No response_
Repository: godot
Issue: Opening another window won't use canvas items.
Labels: needs testing,topic:gui

### Tested versions

4.2

### System information

Windows 11

### Issue description

When I open second window (Window-node) it won't use the canvas_items and scale the nodes inside.

### Steps to reproduce

Make window with sprite and try to use canva_items inside window node.

### Minimal reproduction project (MRP)

[testing (2).zip](https://github.com/godotengine/godot/files/13965833/testing.2.zip)
Repository: godot
Issue: Pinned RigidBody2Ds act oddly after sleeping if one is the child of the other and the child wakes first
Labels: bug,topic:physics,needs testing,topic:2d

### Tested versions

Reproducible in: 
v4.2.1.stable.official [b09f793f5]
v4.0.3.stable.official [5222a99f5]
v3.5.1.stable.official [6fed1ffa3]

### System information

Godot v4.2.1.stable - Linux Mint 20.2 (Uma) - X11 - Vulkan (Forward+) - integrated AMD Unknown (RADV RENOIR) () - AMD Ryzen 7 5700U with Radeon Graphics (16 Threads)

### Issue description

If two rigidBody2Ds are pinned together with one being a child of the other and they sleep then if they are woken up by the child rigid body being moved, then the PinJoint holding them together behaves oddly (the softness of the pin is changed perhaps?)

In the video the top vehicle has all the rigid bodies as siblings and it behaves as expected.
The bottom vehicle has the wheels as children of the platform.  It behaves normally IF it isn't allowed to sleep.
The first run in the video shows this

If the vehicles are allowed to come to rest and sleep first, the top one (sibling rigid bodies) still does fine upon waking, but the pin connecting the waking child of the bottom one behaves differently upon waking.  Most noticeable when the vehicles are falling.

https://github.com/godotengine/godot/assets/8164842/0f02a770-7a59-440c-b371-d9651f476eb3

More notes:

in testing, it appears the method of the child moving first doesn't matter.  Same result if it is done via apply_torque or apply_force in script or if you set up a separate collider that bumps into the child rigid body

after the rigid bodies start behaving oddly, if they come to rest again and the parent rigid body then wakes first, the issue is fixed until it rests again and the child is woken first



### Steps to reproduce

Condition needed to reproduce:
two rigidBody2D pinned together and one is a child of the other. 
the rigid bodies must come to rest and sleep
the child rigid body must be the one to waken first (can be done via script or by impact from another object)

### Minimal reproduction project (MRP)

[Rigid2DParentChild.zip](https://github.com/godotengine/godot/files/13966295/Rigid2DParentChild.zip)