sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: runtime: failure in `TestRaiseException` on windows-amd64-2012
Labels: ExpertNeeded,OS-Windows,NeedsInvestigation

```
--- FAIL: TestRaiseException (0.02s)
    crash_test.go:106: C:\Users\gopher\AppData\Local\Temp\1\go-build1560626842\testprog.exe RaiseException exit status: exit status 2989
    syscall_windows_test.go:636: No stack trace: 
FAIL
FAIL	runtime	68.703s
```

`greplogs --dashboard -md -l -e 'FAIL: TestRaiseException'`

[2021-11-18T02:19:50-f1cc529/windows-amd64-2012](https://build.golang.org/log/9ac0c12bf106b7f5f1d7589cbe972e562aed2296)

The test dates from 2014. I can find only one such faillure in the logs, and it is very recent — marking as release-blocker until we can determine whether this is a regression (CC @bufflig).
Repository: svelte
Issue: Allow directives (actions/transitions/animations) to be more dynamic
Labels: feature request,runtime

### Describe the problem

Svelte encourages reactivity at many levels, but when it comes to actions, transitions, or animations, it's rather static:
- you are not allowed to swap out one directive for another at runtime. Doesn't work for actions, does work for transitions/animations only when they are not rendered
- you can't conditionally apply a directive by setting it to undefined; it will throw a runtime error
- attributes are not always updated, related to #3633


### Describe the proposed solution

Support swapping out directives

### Alternatives considered

Workaround code involving `#if`s

### Importance

nice to have
Repository: yt-dlp
Issue: Showing ffmpeg postprocessing progress
Labels: enhancement,core:post-processor

### Checklist

- [X] I'm reporting a feature request
- [X] I've verified that I'm running yt-dlp version **2021.11.10.1**. ([update instructions](https://github.com/yt-dlp/yt-dlp#update))
- [X] I've searched the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues including closed ones. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Description

Problem: When ffmpeg is running it doesn't show any progress.

Solution: Could https://github.com/CrypticSignal/better-ffmpeg-progress/ or something like it be used to show how far along ffmpeg is at processing a video?  Only possible problem is older versions of ffmpeg and if they had different progress formats.

yt-dlp shows the progress it's download so doing a similar 2nd progress of a video's processing should fit in.

The project mentioned above is still active.  I had them add a callback to it recently.
Repository: go
Issue: runtime: "panic during panic" on plan9 builders
Labels: OS-Plan9,NeedsInvestigation,compiler/runtime

```
#!watchflakes
post <- builder ~ `^plan9.*` && `panic during panic`
```

```
plan9-386-0intro at e8cda0a6c925668972ada40602ada08468fa90dc

:: Running /tmp/workdir-gnot/go/src/make.rc with args ["/tmp/workdir-gnot/go/src/make.rc"] and env ["home=/usr/glenda" "path=.\x00/bin" "*=" "type=host-plan9-386-0intro" "rcname=gobuildlet" "pid=169" "fn#term%=fn term% {$*}\n" "fn#newworkdir=fn newworkdir {if(test -d $workdir){for(i in `{du -a $workdir|awk '{print $2}'})chmod u+w $i;rm -rf $workdir};mkdir $workdir}\n" "status=" "fn#cd=fn cd {builtin cd $* && awd}\n" "GOROOT_BOOTSTRAP=/tmp/workdir-gnot/go1.4" "workdir=/tmp/workdir-gnot" "objtype=386" "fn#sigexit=" "cflag=" "0=/bin/gobuildlet" "WORKDIR=/tmp/workdir-gnot" "GO_BUILDER_NAME=plan9-386-0intro" "GOBIN=" "GOROOT_BOOTSTRAP=/usr/go-plan9-386-bootstrap"] in dir /tmp/workdir-gnot/go/src

Building Go cmd/dist using /usr/go-plan9-386-bootstrap
Building Go toolchain1 using /usr/go-plan9-386-bootstrap.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
# runtime
fatal error: unexpected signal during runtime execution
[signal sys: trap: fault read code=0x0 addr=0x0 pc=0x57001]

runtime stack:
fatal error: unexpected signal during runtime execution
panic during panic
[signal sys: trap: fault read code=0x0 addr=0x0 pc=0x4dc6a]

runtime stack:
fatal error: unexpected signal during runtime execution
stack trace unavailable
go tool dist: FAILED: /tmp/workdir-gnot/go/pkg/tool/plan9_386/go_bootstrap install -gcflags=all= -ldflags=all= -a -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status: 'go_bootstrap 293035: 2'
```

`greplogs --dashboard -md -l -e '(?ms)plan9-.*^panic during panic' --since=2021-01-01`

[2021-11-19T00:05:59-e8cda0a/plan9-386-0intro](https://build.golang.org/log/d3edc9b71895e4a29218093bc7e5cb8a155799d5)
[2021-11-11T20:20:50-46b2fc0/plan9-arm](https://build.golang.org/log/47dad729703c78fd8a485a7943af129a4a26025f)
[2021-09-07T19:39:04-d92101f/plan9-arm](https://build.golang.org/log/a5584bf40e3539938a3d08b986e6f6da2f3f1d84)
[2021-09-02T16:26:26-08588e6/plan9-arm](https://build.golang.org/log/e506e1649665b47922e19cb51a4e383df15b739f)
[2021-08-24T22:10:11-5d863f8/plan9-arm](https://build.golang.org/log/117b75ff2745e1fcc3af744ce26279da8d6f2a97)
[2021-04-29T13:24:00-858fdbe-eb3fe28/plan9-arm](https://build.golang.org/log/e06e468f7532e137d767733e33298e49bee4fd40)
[2021-04-26T18:54:39-0d1280c/plan9-arm](https://build.golang.org/log/36eeecb2a80704114f97a6221c0643e3c4a754ab)
[2021-02-23T06:01:29-e521498/plan9-arm](https://build.golang.org/log/5578683ff3bd4b4c4ce6e7b777499f32dea45f16)

@0intro, @millerresearch, @fhs: is this possibly a duplicate of #35456 and/or #22227?
Repository: material-ui
Issue: [Container] Allow `disableGutters` to support breakpoints
Labels: discussion,component: Container

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

The ability to add breakpoints when the show/hide the gutters.

### Examples 🌈

```
<Container maxWidth={"xl"} disableGutters={{ xs: true, xl: false }}>
```

### Motivation 🔦

_No response_
Repository: pytorch
Issue: [ux] F.binary_cross_entropy (and maybe other losses) to auto-cast bool category mask to float
Labels: module: nn,triaged,enhancement,module: ux,Stale

Will remove a bit of boiler-plate...

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345
Repository: react
Issue: React 18 not passive wheel / touch event listeners support
Labels: Type: Discussion,React 18

Hi all, is there any chances React 18 will support not passive wheel / touch event listeners?
In React 17 they are passive so no way to preventDefault and I had to add active listeners manually by ref.
So maybe in v18 there will be some option to make them not passive in react?

I just tested my code with React 18 beta and found some internal order of useEffect calls was changed, so my approach is failing because of desync of changes made in active listener vs other props changes.
Repository: go
Issue: x/build: "unexpected stale targets" on plan9-arm
Labels: OS-Plan9,Builders,NeedsInvestigation,arch-arm

```
#!watchflakes
post <- builder == "plan9-arm" && `unexpected stale targets`
```

`greplogs --dashboard -md -l -e '(?ms)\Aplan9-.*go tool dist: unexpected stale targets' --since=2021-10-09`

[2021-11-05T18:20:07-53bab19/plan9-arm](https://build.golang.org/log/0df20d2f423f89b552b2bcd4d041f7166f41125d)
[2021-11-02T20:59:34-79024cf/plan9-arm](https://build.golang.org/log/1d98a1941fb0b3f86afb43111e023c46188264b0)
[2021-11-02T18:35:22-0b37bd9/plan9-arm](https://build.golang.org/log/99b4593096c02c5fae56c2340af783a60648c4fc)
[2021-11-02T05:35:11-6f327f7/plan9-arm](https://build.golang.org/log/e34ee959ca57374c9451481af50375e0558b3541)
[2021-10-29T22:29:31-c812b97/plan9-arm](https://build.golang.org/log/fceae49a9f7624514b99e4210ca8f55f8c273b1c)
[2021-10-28T20:43:02-e741e2f/plan9-arm](https://build.golang.org/log/04bbc45fd140f07c1f800c94ad9b0d5c9a1f67b6)
[2021-10-26T05:05:24-23fdd7f/plan9-arm](https://build.golang.org/log/31afbe6130875209538777ad28208365e423f554)
[2021-10-25T18:46:45-f47335e/plan9-arm](https://build.golang.org/log/3aaf50f704479389ec7de2dc06fb5d29bce9910b)
[2021-10-25T17:02:16-52b10ab/plan9-arm](https://build.golang.org/log/ff9ee25e577e4b0afb91a92491f9586108a8f62d)
[2021-10-20T19:30:13-3ff39c5/plan9-arm](https://build.golang.org/log/b030dbf8ac7009e3f1e3b18ca06b9ad4464c1efc)
[2021-10-20T19:29:12-4320949/plan9-arm](https://build.golang.org/log/376f3ac9cb3323de0b1e6f9addc8a0f6fdabd0f2)
[2021-10-19T18:43:12-d944984/plan9-arm](https://build.golang.org/log/620d0ced26a644f6eac31630f54b2698a5f1d616)
[2021-10-19T18:18:37-9820602/plan9-arm](https://build.golang.org/log/4b06f52ee8ea17b215fe149a386ae3a9c744ccd4)
[2021-10-19T08:44:22-1e49210/plan9-arm](https://build.golang.org/log/639fca3f982c35a63a64060beca1fa65d7a8b8b3)
[2021-10-14T01:51:22-276fb27/plan9-arm](https://build.golang.org/log/1fe077f3b4dfccb3903fb102d0e1b1ca512d5e7e)
[2021-10-13T16:39:23-3986e5c/plan9-arm](https://build.golang.org/log/6442997adf294ec5fda6e1616741207cce0ad62a)
[2021-10-12T21:15:50-3d051ba/plan9-arm](https://build.golang.org/log/1c1e2a220b45be053d8a6f82f06c5675ab75a5bd)
[2021-10-10T15:11:26-d2d21d9/plan9-arm](https://build.golang.org/log/797919868b8300d057302610252b36c353e92a4f)
[2021-10-09T23:29:26-b99abf3/plan9-arm](https://build.golang.org/log/a519906bb7eb61bd62053cee8fc63b4f68bdc608)

@millerresearch, is this possibly due to a filesystem issue on the builder? I'm not sure how else we would be ending up with mismatched build IDs.
Repository: angular
Issue: Obscure Error at runtime - ASSERTION ERROR: Reached the max number of directives [Expected=> 1 != 1 <=Actual]
Labels: hotlist: error messages,area: core,core: change detection,core: dynamic view creation,P3

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

core

### Is this a regression?

No

### Description

Observables that emit within the angular tick cycle can cause the component to crash.

What appears to be happening is that viewContainerRef.createEmbeddedView is recursively calling itself due to the observable emitting before it gets a chance to return.

This is a contrived example to get to an underlying issue that I've had using *ngrxLet.

Ngrx can probably fix their issue by not relying on createEmbeddedView returning. However, there are other cases where a developer may actually intend to call createEmbeddedView multiple times recursive or not.

I believe this is unexpected behavior, however if there's a reason it shouldn't be able to be called recursively a more helpful error message may be more helpful (pun) and some documentation on this limitation.

The workaround was to emit in a setTimeout or pipe(delay(0,asyncScheduler))


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

https://github.com/e-davidson/angular-issue-reproduction-2021

### Please provide the exception or error you saw

```true
ERROR Error: ASSERTION ERROR: Reached the max number of directives [Expected=> 1 != 1 <=Actual]
    at throwError (core.mjs:326)
    at assertNotEqual (core.mjs:282)
    at initTNodeFlags (core.mjs:10443)
    at resolveDirectives (core.mjs:10199)
    at elementContainerStartFirstCreatePass (core.mjs:14972)
    at Module.ɵɵelementContainerStart (core.mjs:15000)
    at AppComponent_ng_container_0_Template (app.component.html:1)
    at executeTemplate (core.mjs:9637)
    at renderView (core.mjs:9440)
    at TemplateRef.createEmbeddedView (core.mjs:23034)
```


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

```true
Angular CLI: 13.0.3
Node: 14.17.0
Package Manager: npm 7.24.1
OS: linux x64

Angular: 13.0.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1300.3
@angular-devkit/build-angular   13.0.3
@angular-devkit/core            13.0.3
@angular-devkit/schematics      13.0.3
@angular/cli                    13.0.3
@schematics/angular             13.0.3
rxjs                            7.4.0
typescript                      4.4.4
```


### Anything else?

_No response_
Repository: PowerToys
Issue: [KBM] Switching Caps Lock and L Ctrl causes Alt Gr to also behave as Caps Lock
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Issue-Docs,Needs-Triage

### Microsoft PowerToys version

~~0.41.4~~ 0.49.1

### Running as admin

- [X] Yes

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

- Open Keyboard Manager
- Remap Caps Lock to Ctrl (Left)
- Remap Ctrl (Left) to Caps Lock

Bug report log: [PowerToysReport_2021-11-19-20-56-14.zip](https://github.com/microsoft/PowerToys/files/7572676/PowerToysReport_2021-11-19-20-56-14.zip)

Screenshot of Keyboard Manager: ![PowerToys Settings_7hfFnZaOQ9](https://user-images.githubusercontent.com/62175959/142684746-3782d3a9-d061-463b-9560-87e9f411f8ef.png)



### ✔️ Expected Behavior

Caps Lock and L Ctrl are swapped.

### ❌ Actual Behavior

The aforementioned, but Alt Gr now also behaves as Caps Lock.

### Other Software

_No response_
Repository: rust
Issue: MaybeUninit::fill_slice
Labels: T-libs-api,C-feature-request,A-slice,A-raw-pointers

Add a function:

```
impl<T> MaybeUninit<T> {
    pub fn fill_slice<'a>(this: &'a mut [MaybeUninit<T>], src: T) -> &'a mut [T]
        where T: Clone,
    { ... }
}
```

Similarly to `slice::fill`, it allows fast write of the same element to the slice.

Similarly to `MaybeUninit::write_slice_cloned`, it returns initialized slice without unsafe code.
Repository: electron
Issue: [Bug]: Input field becomes unresponsive after window.Alert() and window.confirm()
Labels: platform/windows,bug :beetle:,16-x-y

### 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.

### Electron Version

16.0.1

### What operating system are you using?

Windows

### Operating System Version

Windows 10

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

The input field is clickable and responsive after the user makes a selection from a windows Alert or Confirm.

### Actual Behavior

The input field is unclickable. The workaround is to open/close devtools.

### Testcase Gist URL

_No response_

### Additional Information

It seems like this is a on-going issue from other users.

https://github.com/electron/electron/issues/22923

https://stackoverflow.com/questions/56805920/cant-edit-input-text-field-after-window-alert/56806101#56806101

I'm able to reproduce this issue consistently from windows electron app

I was able to reproduce this issue from `electron-quick-start` repo with the latest electron build `16.0.1` using the following `index.html `code below

```
<!DOCTYPE html>
<!--Display Alert Message on Button Click Event.-->
<html>
    <head>
        <title>Display Alert Message on Button Click Event.</title>
        <script type="text/javascript">
            function showMessage() {
                alert("Hello friends, this is message.");
            }
        </script>
    </head>
    <body>
            <h1>Display Alert Message on Button Click Event.</h1>
            <b>Click on button to display message: </b><br />
            <br />
            <input type="button" id="btnShowMsg" value="Click Me!" onClick="showMessage()" />
            <input type="text"/>
    </body>
</html>
```
Repository: godot
Issue: Project setting changes aren't always saved to `project.godot` when pressing Ctrl + S
Labels: bug,topic:editor,confirmed

### Godot version

3.4.stable, 4.0.dev (84f59c60b), 4.3.stable, 4.4.dev https://github.com/godotengine/godot/commit/84dcdde9088d512efebb0033fb881d8f7fd9c107

### System information

Fedora 34, GeForce GTX 1080 (NVIDIA 470.74)

### Issue description

Project setting changes aren't always saved to `project.godot`. If I change a setting, close the Project Settings dialog, press <kbd>Ctrl + S</kbd> then run the project, the new project setting's value isn't always taken into account by the running project. This seems to happen sporadically, but I've had it happen dozens of times by now. Pressing <kbd>Ctrl + S</kbd> multiple times in a row can sometimes ensure the value is saved correctly, but pressing it twice isn't always enough.

This occurs both on 3.4-stable and `master`. I've seen this happen as far back as 3.3 and may be linked to https://github.com/godotengine/godot/pull/31747.

So far, I've only reproduced this on Linux, but I don't use the editor on Windows often enough to notice the issue there.

### Steps to reproduce

- Open **Project > Project Settings**.
- Change any setting's value (for instance, **Fullscreen** or **Print Fps**). It doesn't matter whether the editor *needs* to be restarted after the setting is changed.
- Close the editor settings.
- Run the project.

### Minimal reproduction project

N/A
Repository: rust
Issue: Improve diagnostics of calling unimplemented trait method if a different one of same name is in scope
Labels: A-diagnostics,A-trait-system,T-compiler

If there are two trait methods of the same name and different parameters and only one is implemented for a type but the user tries to call the other (using different parameters) rustc complains about number/type of parameters without any hint of possible different problem.

Given the following code: [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6c184630c6f07812c1582cd9c8733fac)

```rust
trait Foo {
    fn do_stuff(&self);
}

trait Bar {
    fn do_stuff(&self, bar: bool);
}

impl Bar for u32 {
    fn do_stuff(&self, bar: bool) {
        println!("Bar: {}, {}", self, bar);
    }
}

fn main() {
    42_u32.do_stuff();
}
```

The current output is:

```
error[E0061]: this function takes 1 argument but 0 arguments were supplied
  --> src/main.rs:16:12
   |
16 |     42_u32.do_stuff();
   |            ^^^^^^^^- supplied 0 arguments
   |            |
   |            expected 1 argument
   |
note: associated function defined here
  --> src/main.rs:6:8
   |
6  |     fn do_stuff(&self, bar: bool);
   |        ^^^^^^^^

For more information about this error, try `rustc --explain E0061`.
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0061]: this function takes 1 argument but 0 arguments were supplied
  --> src/main.rs:16:12
   |
16 |     42_u32.do_stuff();
   |            ^^^^^^^^- supplied 0 arguments
   |            |
   |            expected 1 argument
   |
note: you may be attempting to call `do_stuff` method of trait `Foo` which is not implemented for `u32`
  --> src/main.rs:2:8
   |
2  |     fn do_stuff(&self);
   |        ^^^^^^^^- trait `Foo` not implemented for `u32`
   |
note: associated function defined here
  --> src/main.rs:6:8
   |
6  |     fn do_stuff(&self, bar: bool);
   |        ^^^^^^^^

For more information about this error, try `rustc --explain E0061`.
```

The user may be led to wrong direction by this error message. Presenting both possibilities may be helpful. The traits can come from different modules/crates (real world case: `Hash` from `std` and cryptographic `Hash` trait.)

Note that similar problem happens if number of arguments is the same but the types are different (try adding e.g. `&str` to `Foo` and call it with `"foo"`).

Nightly looks same.
Repository: rust
Issue: `-Ccontrol-flow-guard` should raise an error on unsupported platforms
Labels: A-security,T-compiler,C-bug

Right now specifying `-Ccontrol-flow-guard` and targetting a non-msvc platform will silently ignore the `-Ccontrol-flow-guard` option. Given the purpose of the flag and the audience Rust targets, I think this is an ill-considered behaviour. Especially of concern I think is when a non-MSVC windows target is used. An engineer might think the mitigations are enabled and the code would work fine in their testing, possibly only because the mitigations were never really turned on!

I believe that mitigation-related flags are sensitive enough to warrant an error when `rustc` isn't able to implement those mitigations for the artifact.
Repository: rust
Issue: Suggestion for add-assigning chars to u32 could be improved
Labels: C-enhancement,A-diagnostics,T-compiler,D-papercut,D-newcomer-roadblock

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=005f59d63a84412a73cfe88146c11f39

```rust
fn main() {
 let greeting = "Hello, World!";
 let mut output = 0;
 for c in greeting.chars() {
  output += c;
 }
 println!("The values of the characters in \"{greeting}\" sum to {output}");
}
```

The current output is:

```
error[E0277]: cannot add-assign `char` to `{integer}`
 --> src/main.rs:5:10
  |
5 |   output += c;
  |          ^^ no implementation for `{integer} += char`
  |
  = help: the trait `AddAssign<char>` is not implemented for `{integer}`

For more information about this error, try `rustc --explain E0277`.
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0277]: cannot add-assign `char` to `{integer}`
 --> src/main.rs:5:10
  |
5 |   output += c;
  |          ^^ no implementation for `{integer} += char`
  |
  = help: the trait `AddAssign<char>` is not implemented for `{integer}`. You may have meant to use `as u32` or `to_digit` on the `char`.

For more information about this error, try `rustc --explain E0277`.
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->