sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: PowerToys Run Calculator Click to 'Copy this number to clipboard' fails, with error dialogue
Labels: Issue-Bug,Product-PowerToys Run,Needs-Repro,Run-Plugin

### Microsoft PowerToys version

0.69.0

### Installation method

GitHub

### Running as admin

No

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

Type a calculation into Run, eg "1+1".
Result is given with an option to click to copy:
![image](https://user-images.githubusercontent.com/65283607/231600114-64c0950d-67d0-4fc2-914e-6fb5b28aa9fb.png)

Clicking to copy to causes the program to freeze, then throws up an error dialogue box.
![image](https://user-images.githubusercontent.com/65283607/231600357-27843e5c-632b-45c7-ac80-6ae63dc833cf.png)



### ✔️ Expected Behavior

Calculation result is copied to clipboard

### ❌ Actual Behavior

Calculation result is NOT copied to clipboard, error given instead:
![image](https://user-images.githubusercontent.com/65283607/231600438-7908df7f-c60b-45ae-965b-5ee9312b77c6.png)


### Other Software

_No response_
Repository: rust
Issue: Documentation for HashMap's FromIterator with duplicate keys in the iterator
Labels: T-libs-api,A-docs,A-iterators

### Location

HashMap

### Summary

HashMap implements FromIterator and Extend, but does not document what happens if there are duplicate keys *in the iterator.* The documentation for Extend does say "When extending a collection with an already existing key, that entry is updated", but
1. that isn't visible anywhere on the HashMap page,
2. FromIterator doesn't have to be implemented using Extend (though HashMap's is), and 
3. that still doesn't specify behavior for duplicate keys in the iterator itself.

The current implementation silently takes the last value in the iterator, which is useful behavior and could easily be justified by saying "`collection.extend(a).extend(b)` should always be equivalent to `collection.extend(a.chain(b))`", but technically that isn't written down anywhere.
Repository: godot
Issue: [dotnet] _Ready, _Process, etc don't fire on node created from external library classes.
Labels: bug,topic:dotnet

### Godot version

4.0.2 stable

### System information

Windows 10

### Issue description

I was looking to split my project into different DLLs as the Godot Project compacts all scripts into one DLL. When project gets bigger the build times will get longer if everything is being compacted into one DLL.

Everything was going great I made separate Classlib with dotnet cli and add the reference to the Godot project, so far so good.

I then went to create a Node3D script in the newly created library with _Ready and _Process, but once I instantiated the new Class Object in a project script and added it to the SceneTree. _Ready and _Process wouldn't fire. I could manually call them in the attached project script. This doesn't seem like it should be doing this. Node3D node is created perfectly the functions/methods are not firing.

I did notice on the Test child node that the script field was empty probably due to it being from an external library (Classlib)

### Steps to reproduce

- Create Godot C# Project.
- Create Classlib with dotnet cli.
- Add GodotSharp package to Classlib.
- Add Classlib reference to Godot C# Project.
- Create main script in Godot Project that extends Node3D.
- Create test script in Classlib that extends Node3D.
- Create test class object from Classlib in main script.
- Add test object to main as a child node.

### Minimal reproduction project

[TestSharp.zip](https://github.com/godotengine/godot/files/11216625/TestSharp.zip)
Repository: flutter
Issue: [video_player_android] add feature to control setAllowedCapturePolicy feature in ExoPlayer 
Labels: c: new feature,platform-android,p: video_player,package,c: proposal,P3,team-android,triaged-android

## Use case

I want to prevent internal sound capture on Android 10+
but I can't access the `setAllowedCapturePolicy`  feature in ExoPlayer to do that.

### Proposal

Provide an API to set the allowedCapturePolicy in Exoplayer.
Repository: storybook
Issue: [Feature Request]: Allow sorted `colors` prop with `ColorItem`
Labels: feature request,typescript,addon: docs,block: other

### Is your feature request related to a problem? Please describe

When using a typescale based on numbers (such as in [tailwind](https://tailwindcss.com/docs/customizing-colors)), we want to have our object keys for colors be numbers:

```ts
...
  neutral: {
    00: "#FFFFFF",
    10: "#F5F6FF",
    20: "#D4D6EC",
    30: "#B1B3CE",
    40: "#878AAE",
    50: "#606384",
    60: "#464862",
    70: "#323346",
    80: "#1F202C",
    90: "#14151C",
  },
  ...
```

However, in typescript this throws a compiler error related to octals being used as object keys. So, a simple solution would be to make the `00` a string: `'00'` - however, this throws off the sorting order in the color palette:

<img width="484" alt="image" src="https://user-images.githubusercontent.com/410558/231612486-fbb7fab6-9de1-4200-a24f-0629870a112b.png">

Another option could be to use the suggested octal syntax:
<img width="742" alt="image" src="https://user-images.githubusercontent.com/410558/231612586-d6748ce4-2466-41fe-b1cd-916af2f4c631.png">

However this then presents the color as a single `0` when rendered (this is sort of a nit):

<img width="514" alt="image" src="https://user-images.githubusercontent.com/410558/231612648-fce84096-99f2-41f7-97f6-ffa924cd511e.png">

The issue persists for `000` as well, or any number of zeros.

### Describe the solution you'd like

I would like to be able to control the sort order arbitrarily while providing a display name for a color.

### Describe alternatives you've considered

accepting that a single 0 is fine for the presentation of this color

### Are you able to assist to bring the feature to reality?

yes, I can

### Additional context

I have a branch here: https://github.com/storybookjs/storybook/compare/next...pm0u:storybook:sorted-color-palette?expand=1

that allows this feature. It's not the most robust implementation but if it's worth opening a PR i can. I'm running into several issues following the contributing guide here: https://storybook.js.org/docs/react/contribute/code

- multiple tests are failing on `yarn test`
- `yarn start` fails to start a sandbox

so I don't really know how to view my changes.
Repository: kubernetes
Issue: Report missing policy or params in status of ValidatingAdmissionPolicyBindings
Labels: sig/api-machinery,triage/accepted

If a ValidatingAdmissionPolicyBinding references a non-existent policy in the `spec.policyName` field the binding silently does nothing.

xref: https://github.com/kubernetes/kubernetes/blob/5550bd5eacc185fac579a7ac6003c7099f8f9d9f/staging/src/k8s.io/api/admissionregistration/v1alpha1/types.go#L363

We have informally referred to a binding in this state as "mis-configured", but there is no way for a user to know that a binding is in this state short of attempting API requests that should be denied and noticing that they are allowed (which is clearly not a good way to check).

Part of the problem is that without a the `matchConditions` of the policy, the policy binding doesn't even know what API requests it should match.

We should report this state into the status of binding resources.

Also, when the policy has a `paramKind` and the `spec.paramRef` refers to a non-existent resource, or the wrong type of resource, there is also a problem. The behavior for this case is different-- the policy is configured mis-configured and the failurePolicy is triggered.  We should still report status for this case though?

A last case:  The policy does _not_ have a `paramKind` but the binding has a `spec.paramRef`.  In this case we ignore the `paramRef` (since it is not needed).  I don't know if we need to report this to status. It is reasonable to add unused `paramRef`s to bindings in preparation for adding a `paramKind` to a policy, so maybe this is OK?
Repository: go
Issue: cmd/compile: better optimization of type switches in instantiated generic functions
Labels: Performance,NeedsInvestigation,FeatureRequest,compiler/runtime

Consider this test case:

```Go
package main

import (
	"fmt"
	"unsafe"
)

func start[S []byte | string](s S) *byte {
	switch s := any(s).(type) {
	case []byte:
		return unsafe.SliceData(s)
	case string:
		return unsafe.StringData(s)
	default:
		panic("can't happen")
	}
}

func F[S []byte | string](s S) {
	fmt.Println(start(s), len(s))
}

func main() {
	F("hi")
	F([]byte("bye"))
}
```

This runs fine.  It instantiates `F` twice: `main.F[go.shape.[]uint8]` and `main.F[go.shape.string]`.  Both versions take a dictionary, and both versions implement the type switch by loading the type descriptor from the dictionary and comparing it to the descriptors for `[]byte` and `string`.

In these instantiations, however, the type descriptor is a constant.  We know this because the constraint does not use a `~`.  It would be nice if the compiler were able to constant fold the dictionary value and eliminate the type switch.

I came up with this example because of #38776.  It would be nice if we could change some of the hash implementations to use generic functions, which largely works until they try to call assembly code.  At that point it's necessary to get the pointer to the slice or string data.  It would be nice to be able to do that reasonably safely, which is what the above code does, and also efficiently, which the above code is not.

CC @randall77 @mdempsky
Repository: storybook
Issue: [Bug]: storyshot doens't work with global decorators in .storybook/preview.js
Labels: bug,addon: storyshots,has workaround,sev:S3

### Describe the bug

I'm using version 7.0.4, I have global decorators for all my stories as many of components require a global IntlProvider etc.

everything works fine till I tried storyshot, it failed because those global context provided by global decorators not there.

If I move the decorators to component level. then it works fine again. 

### To Reproduce

_No response_

### System

_No response_

### Additional context

_No response_
Repository: storybook
Issue: [Bug]: Next.js module transpilation is not supported
Labels: bug,nextjs

### Describe the bug

Despite the [Next.js + Storybook](https://storybook.js.org/addons/storybook-addon-next) addon description claims _"What Next.js supports out of the box, this addon makes possible in Storybook"_ the [Next.js Built-in module transpilation](https://nextjs.org/blog/next-13-1#built-in-module-transpilation-stable) doesn't seem to be working.

I have some un-transpiled ES6 packages that previously used [next-transpile-modules](https://www.npmjs.com/package/next-transpile-modules) and now use the built-in the Next.js configuration. These work fine in Next.js but fail in Storybook after migrating to v7.

Previously I was using the following Webpack custom configuration

```
webpackFinal: async (config) => {
  config.module.rules[0].exclude = [/node_modules\/(?!@my-scope).*/]
  return config
}
```

The Next.js addon doesn't seem to detect the `transpilePackages` attribute from the `next.config.js` nor does the custom Webpack rule work.

### To Reproduce

1. Install a dependency with un-transpiled ES6 code.
2. Add this dependency to be transpiled into Next.js as per https://nextjs.org/blog/next-13-1#built-in-module-transpilation-stable
3. Verify that Next.js runs correctly.
4. Verify that Storybook fails by not transpiling the dependency. You will see an error similar to _"You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file."_

### System

```shell
System:
  OS: macOS 13.2
  CPU: (8) arm64 Apple M1 Pro
Binaries:
  Node: 16.18.1 - /opt/homebrew/opt/node@16/bin/node
  npm: 8.19.2 - /opt/homebrew/opt/node@16/bin/npm
Browsers:
  Chrome: 112.0.5615.49
  Safari: 16.3
npmPackages:
  @storybook/addon-a11y: ^7.0.4 => 7.0.4 
  @storybook/addon-essentials: ^7.0.4 => 7.0.4 
  @storybook/addon-links: ^7.0.4 => 7.0.4 
  @storybook/addon-mdx-gfm: ^7.0.4 => 7.0.4 
  @storybook/manager-api: ^7.0.4 => 7.0.4 
  @storybook/nextjs: ^7.0.4 => 7.0.4 
  @storybook/react: ^7.0.4 => 7.0.4 
  @storybook/theming: ^7.0.4 => 7.0.4
```


### Additional context

_No response_
Repository: go
Issue: x/crypto: preferredKexAlgos in golang.org/x/crypto/ssh includes SHA1
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.20.3 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/scott/.cache/go-build"
GOENV="/home/scott/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/scott/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/scott/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.3"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="0"
GOMOD="/dev/null"
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 -m64 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1232564776=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Built an SSH server using `x/crypto/ssh`, and ran `ssh -vvv` to connect to it.

### What did you expect to see?

I expected the server to present KEX algorithms excluding any using SHA1.

### What did you see instead?

```
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
```

The default algorithms used by the ssh server appears to be configured here:
https://github.com/golang/crypto/blob/1faeef9713563c936e077b84e4c3a0f3cac0fbe4/ssh/common.go#L62-L68

Does it make sense to remove `kexAlgoDH14SHA1` from the preferred KEX algorithm list? I note that NIST has [announced](https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm) SHA1's retirement, and [GitHub discontinued SSH SHA1 support](https://github.blog/2017-02-27-crypto-deprecation-notice/) way back in 2018.
Repository: flutter
Issue: [Impeller] Provide an API for loading FragmentPrograms at runtime (and tooling support for producing them).
Labels: engine,P3,e: impeller,team-engine,triaged-engine

## Use case

We would like to be able to dynamically load shaders at runtime like https://www.shadertoy.com or https://www.alma.sh/. Currently FragmentProgram only has a static method for loading assets, which seems a bit limiting as it is just shader bytecode that is being put into the bundle. For instance, web implements this as such:

```dart
 @override
  Future<ui.FragmentProgram> createFragmentProgram(String assetKey) {
    if (_programs.containsKey(assetKey)) {
      return _programs[assetKey]!;
    }
    return _programs[assetKey] = assetManager.load(assetKey).then((ByteData data) {
      return CkFragmentProgram.fromBytes(assetKey, data.buffer.asUint8List());
    });
  }
 ```
  
## Proposal

The functionality already exists behind the scenes, so I just suggest it becomes part of the top level FragmentProgram api:

For instance this already exists:
```dart
static Future<CkFragmentProgram> fromBytes(String name, Uint8List data)
```
Repository: PowerToys
Issue: Automatically hover mouse over small buttons
Labels: Needs-Triage

### Description of the new feature / enhancement

Move the mouse cursor to the nearest checkbox or button by pressing some key with moving mouse.

### Scenario when this would be used?

Save time spent hovering over small checkboxes.

### Supporting information

_No response_
Repository: go
Issue: test: Test failures with `iterdelete: too slow`
Labels: NeedsInvestigation,arch-riscv,compiler/runtime

```
#!watchflakes
post <- pkg == "test" && test == "Test" && `iterdelete: too slow`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/b86b8ff84b82048014201b8bc6fc02b4c9922a1a)):

    PASS
    PASS
    PASS
    PASS
    PASS
    PASS
    PASS
    PASS
    --- FAIL: Test (0.07s)
        --- FAIL: Test/maplinear.go (53.61s)
            testdir_test.go:117: exit status 2
                panic: iterdelete: too slow: 80000 inserts: 1.920556115s; 160000 inserts: 6.61823371s
    
    
                goroutine 1 [running]:
                panic({0x97840?, 0x3f64108060?})
                	/tmp/workdir-host-linux-riscv64-unmatched/go/src/runtime/panic.go:1016 +0x3a0 fp=0x3f64064ea0 sp=0x3f64064df0 pc=0x3eef8
                main.checkLinear({0xa939e, 0xa}, 0x9c4, 0x3f64052000?)
                	/tmp/workdir-host-linux-riscv64-unmatched/go/test/maplinear.go:59 +0x1b8 fp=0x3f64064f58 sp=0x3f64064ea0 pc=0x89790
                main.main()
                	/tmp/workdir-host-linux-riscv64-unmatched/go/test/maplinear.go:158 +0x15c fp=0x3f64064f80 sp=0x3f64064f58 pc=0x89964
                runtime.main()
                	/tmp/workdir-host-linux-riscv64-unmatched/go/src/runtime/proc.go:261 +0x234 fp=0x3f64064fd8 sp=0x3f64064f80 pc=0x4196c
                runtime.goexit()
                	/tmp/workdir-host-linux-riscv64-unmatched/go/src/runtime/asm_riscv64.s:512 +0x4 fp=0x3f64064fd8 sp=0x3f64064fd8 pc=0x6a1ec
    
    go tool dist: Failed: exit status 1


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: pytorch
Issue: [BUG]Float32 attention mask not working with torch.autocast("cpu")
Labels: module: nn,triaged

### 🐛 Describe the bug

**Here is a minimal example of the bug, torch==2.0.0**

```
import torch
# torch==2.0.0, cuda=11.7
b = 1
n = 64
d = 256

query = torch.randn(n, b, d)
key = torch.randn(n, b, d)
value = torch.randn(n, b, d)
attn_mask = torch.zeros(n, n)

attention = torch.nn.MultiheadAttention(d, 8)
with torch.no_grad(), torch.autocast("cpu"):
    output = attention(query, key, value, attn_mask=attn_mask, need_weights=False)
```

**RuntimeError: Expected attn_mask dtype to be bool or to match query dtype, but got attn_mask.dtype: float and  query.dtype: c10::BFloat16 instead.**


### Versions

[pip3] numpy==1.23.4
[pip3] open-clip-torch==2.16.0
[pip3] torch==2.0.0
[pip3] torchvision==0.15.1
[pip3] triton==2.0.0
[conda] numpy                     1.23.4                   pypi_0    pypi
[conda] open-clip-torch           2.16.0                   pypi_0    pypi
[conda] torch                     2.0.0                    pypi_0    pypi
[conda] torchvision               0.15.1                   pypi_0    pypi
[conda] triton                    2.0.0                    pypi_0    pypi


cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @bhosmer @cpuhrsch @erichan1 @drisspg
Repository: tauri
Issue: [bug] drag and drop not working in webkit
Labels: type: bug,status: upstream,platform: Linux,status: needs triage

### Describe the bug

hi there,

i created a [grapesjs](https://github.com/GrapesJS/grapesjs) project with tauri. i have Arch Linux so to create a tauri application i have to install [webkit2gtk](https://archlinux.org/packages/extra/x86_64/webkit2gtk/) package. after creating a project i noticed that drag and drop functionally not working in that webview. i also tried the same application in different browsers like chrome, Firefox and also in safari too which itself uses webkit the application work's successfully in all other browsers but can't able to work in the webview that was given by the tauri. 

### Reproduction

1. create a simple tauri appliation with `create-tauri-app` CLI
2. run that application with `pnpm tauri dev`
3. when the webview appears. inspact that
4. in the console write `location.replace("https://grapesjs.com/demo.html")` it will open a page where you can see a demo grapesjs editor.
5. try to drag components and drop it in the given canvas. (here is the issue we can't able to do that)

### Expected behavior

the components just simply drag from block manager and drop in the canvas. 

### Platform and versions

```text
Environment
  › OS: Arch Linux Unknown X64
  › Node.js: 18.15.0
  › npm: 9.5.0
  › pnpm: 8.1.1
  › yarn: Not installed!
  › rustup: 1.25.2
  › rustc: 1.68.1
  › cargo: 1.68.1
  › Rust toolchain: stable-x86_64-unknown-linux-gnu
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: godot
Issue: Scenes that are referenced by preloading in an Autoload script reset referenced imported assets on opening project for the first time
Labels: bug,topic:editor

### Godot version

4.0.2.stable

### System information

Windows 10

### Issue description

This bug occurs if you open a project for the first time with no import file for an asset in .godot/imported/. This occurred for me due to cloning a project that has the .godot folder listed in the gitignore.

The bug occurs when a script (or a scene that is attached with said script) is set to be autoloaded for the project, and that script has a preload referencing another scene. Then, when you open that other scene, all of the assets referenced that require importing are reset in the editor. I.e. if a TextureRect had the Godot icon.svg set before, it will now be set to \<empty\> and re-saving the scene will save the scene as that. If you just close the project and open it again before this happens, the scene will be perfectly fine because the asset already has an import file in .godot/imported/.

It's worth noting that this still happens if the autoload is set be disabled (it just has to be in the list) and doesn't occur if load() is used instead of preload().

### Steps to reproduce

1. Create a scene with a TextureRect/Sprite2D and set the image to the Godot icon.svg and save the scene.
2. Create a new script, and within that script add a line like "var scene = preload(...)" where the path is to the scene created in (1).
3. Set the script from (2) as an Autoload.
4. Close the project and delete the .godot/imported folder.
5. Open the project and see that the scene from (1) has the texture set to \<empty\>. Re-saving the scene will make it so the value will also be <empty> from now on.
6. If, instead of (5), just opened the project, closed it without saving anything, and open it again, the scene from (1) loads completely fine.

### Minimal reproduction project

[TestProject.zip](https://github.com/godotengine/godot/files/11218290/TestProject.zip)

Upon opening the project, the scene will have a TextureRect with Texture set to \<empty\>. If you look at the tscn file you will see Texture is actually set to the path of icon.svg. If you are careful to not to save the scene while Texture is \<empty\>, you can close the project and open it again to be met with the Godot icon now being set.