sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Always On Top bugging out?
Labels: Issue-Bug,Product-Always On Top,Needs-Triage,Needs-Team-Response,Area-App Compat

### Microsoft PowerToys version

0.78.0

### Installation method

PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

Always on Top

### Steps to reproduce

Pin a window with Always on Top, click on Open Hardware Monitor's OSD (which is Always on Top by its internal settings).

### ✔️ Expected Behavior

Nothing unusual, just things to happen as they should.

### ❌ Actual Behavior

This pops up in the corner 
![image](https://github.com/microsoft/PowerToys/assets/78157224/52786a77-3388-467e-9b35-4c4f4624465f)
Doesn't even tell what app might be conflicting with it, I suspect it's the OSD's. And started happening suddenly.

### Other Software

_No response_
Repository: go
Issue: runtime: SIGSEGV after performing clone(CLONE_PARENT) via C constructor prior to runtime start
Labels: NeedsInvestigation,compiler/runtime

### Go version

go version go1.22.0 linux/amd64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/root/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/root/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.0'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
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 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build720171492=/tmp/go-build -gno-record-gcc-switches'
```


### What did you do?

The main language of [runc](https://github.com/opencontainers/runc) is `go`, but we are using `c` to enter some linux namespaces. Recently, go 1.22.0 has been released, when we want to bump go version to `1.22.0`(https://github.com/opencontainers/runc/pull/4193), the CI is fail, it seems that after we are calling `clone(2)` in `c`, the children process can't return to `go` if the first process exited in `c`.

The test code is in https://github.com/lifubang/cgoclone2/blob/main/main.go
I think we should see `From main!` in the last line.

### What did you see happen?

root@acmcoder:/home/acmcoder/cgo# go version
go version go1.22.0 linux/amd64
root@acmcoder:/home/acmcoder/cgo# go run main.go
STAGE_PARENT
STAGE_CHILD
STAGE_INIT
This from nsexec

### What did you expect to see?

root@acmcoder:/home/acmcoder/cgo# go version
go version go1.21.1 linux/amd64
root@acmcoder:/home/acmcoder/cgo# go run main.go
STAGE_PARENT
STAGE_CHILD
STAGE_INIT
This from nsexec
From main!
Repository: go
Issue: crypto/x509: TestPlatformVerifierLegacy failures
Labels: Security,NeedsInvestigation

```
#!watchflakes
default <- pkg == "crypto/x509" && test == "TestPlatformVerifierLegacy"
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/3eed9f8db3977aedc24f6cd73c6d718404e575a4)):

    --- FAIL: TestPlatformVerifierLegacy (78.90s)
        root_darwin_test.go:103: tls connection failed: dial tcp 104.154.89.105:443: connect: operation timed out
        --- FAIL: TestPlatformVerifierLegacy/wrong_host_for_leaf (75.06s)
            testing.go:1576: test executed panic(nil) or runtime.Goexit: subtest may have called FailNow on a parent test


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: pytorch
Issue: Tracking: add implementations for ONNX ops in opset 19 and 20 to symbolic_opset19.py and Symbolic_opset20.py
Labels: module: onnx,triaged

### 🐛 Describe the bug

this PR added torch.onnx.export to support export of opset 19 and 20: https://github.com/pytorch/pytorch/pull/118828. It, however does not implement symbolic method for all ops. For those ops without implementation, @skipIfUnsupportedMaxOpsetVersion(17) is added to test/onnx/test_pytorch_onnx_onnxruntime.py to skip test. This issue is to be used to track tasks to add these missing implementations. 

### Versions

this is a tracking issue
Repository: godot
Issue: C# function GetPeer uses wrong integer type
Labels: enhancement,discussion,documentation,topic:multiplayer

### Tested versions

- Reproducible in Godot 4.1.2

### System information

Windows 11

### Issue description

The ENetMultiplayerPeer class has a function get_peer which I was planning to use to get a remote client's IP address. However in C# the function GetPeer takes a 32 bit int instead of a 64 bit long, which is the new type for peer IDs in godot 4, so this function would not work if the peer id is greater than Int32.Max.

### Steps to reproduce

Attempt to call GetPeer on a ENetMultiplayerPeer inside a Multiplayer.PeerConnected callback. The callback takes a long as a peer ID but GetPeer takes an Int as a peer id, so the compiler will complain.

### Minimal reproduction project (MRP)

N/A
Repository: go
Issue: x/telemetry: cmd/go: report maximum support micro architecture by the host of the compiler
Labels: NeedsInvestigation,telemetry,Telemetry-Proposal

### Proposal Details

More and more architectures are gaining sub-architecture levels under `${GO${GOARCH^^}}` variables.

Often higher levels add new instructions and tweak semantics which allows the compiler to emit better code (which would be incompatible with previous cpus).

It would be nice to know what CPUs should be targeted. For example if we discover that `40%` of cpus support `amd64 v4` considering avx512 routines would be useful.

The main issue with this approach is that the cpu compiling and the cpu running code aren't the same. However I don't think anyone (including me) want to collect telemetry from end binaries.
Repository: TypeScript
Issue: Inconsistent type inference on overloaded function types
Labels: Help Wanted,Has Repro,Possible Improvement

### 🔎 Search Terms

type inference of overloaded functions


### 🕗 Version & Regression Information

The behaviour seemed to change between 4.0.5 and 4.1.5, but it was incorrect nonetheless.

### ⏯ Playground Link

https://www.typescriptlang.org/play?ts=4.0.5#code/C4TwDgpgBAwghgGwQIzgYwNYB4BKA+KAXigAoAnCAZwFcFgAuKHASiIIDcB7ASwBMBuALAAoUJCgB5MMG6cAdpSJQA3lDTzgEAB4MocOSCgBfIcJHawnMsChjoAQUog5aAGLUXM+VntRtmuV5FDww5TgB3OQBtAF0AGkk-HQhAxSkvBQT8JWURKCgAegKoAGVwuDBbAAsqaGBwzigEbjkqW0bKCDqaqAAzDzzSADoRuDIAc0pGKJGh+wT4JFRMXDwY5kYuPlN8klmxyenZ+ckFxBR0bHx1zZ4BERMREX7PWTkoMDJOAFtuSm5eiAfEkAkEoCEwpFYgkJCCUmD0m9KFk8CReoxHM43B40BkfDCUaxlEYnsIXri3n0AIwkOSMOTUb7ICBkBJoRiLC4rBlMll4DZQLb3Mk4jLU2n0xnM1lQTiMRHyZFqDnnZbYHnS-m3bbPUWU3o0-YTKZ6AyxIkksyicAOJwuCRkABynGAWFcBGIrjhqSgmJc7le3havRZUAA+idg6GwxIElGyOHsgB+WxkajQRi9RCdUwiT4-P4AkBoqnMXPW8QAFSpSj9aAdztddk4vWpeFM6gUNmAVMY1aUwDTEFMQA

### 💻 Code

```
type Callback<R> = (result: R) => void;
type Options = { context: any };

export type AsyncFunction<A extends unknown[], O extends Options, R> = {
  // Swap these two lines to see the fun
  (...args: [...A, Callback<R>]): void;
  (...args: [...A, O, Callback<R>]): void;
};

function promisify<A extends unknown[], O extends Options, R>(f: AsyncFunction<A, O, R>) {}

function f1(n: number, c: Callback<number>): void;
function f1(n: number, o: Options, c: Callback<number>): void;
function f1(...args: any[]) {}

type AsyncOrNot<F> = F extends AsyncFunction<infer _A, infer _O, infer _R> ? true : false;

promisify(f1);

type T1 = AsyncOrNot<typeof f1>;
const t1: T1 = true;
```


### 🙁 Actual behavior

In version 4.0.5, either the inference in the function call or the inference in the conditional type succeeds, depending on the order in which the overloads are declared.
In all later versions up to and including 5.4.0 beta, the inference in the conditional type always fails.

### 🙂 Expected behavior

Type inference for the same type against the same generic type to always succeed or always fail, whether it is done for a generic function call or for evaluating the `extends` clause in a conditional type.

### Additional information about the issue

_No response_
Repository: PowerToys
Issue: Add cursor clock
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

With some hotkey. Show the time, date, week, etc. info next to the cursor.

### Scenario when this would be used?

With taskbar in win11 hidden

### Supporting information

_No response_
Repository: pytorch
Issue: DISABLED test_item_to_inputs_kernel_nobreak_cuda (__main__.TestInductorDynamicCUDA)
Labels: triaged,module: flaky-tests,skipped,module: inductor

Platforms: linux, rocm, slow





This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_item_to_inputs_kernel_nobreak_cuda&suite=TestInductorDynamicCUDA&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/21391792477).

Over the past 3 hours, it has been determined flaky in 4 workflow(s) with 12 failures and 4 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_item_to_inputs_kernel_nobreak_cuda`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `inductor/test_torchinductor_dynamic_shapes.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @clee2000 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler
Repository: TypeScript
Issue: Class member incorrectly stripped from .d.ts output if @internal is mentioned in unrelated comment
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

internal, .d.ts, stripInternal

### 🕗 Version & Regression Information

This issue appears to be present in all version of TypeScript (tested down to 3.3.3).

### ⏯ Playground Link

https://www.typescriptlang.org/play?stripInternal=true&ts=5.3.3#code/KYDwDg9gTgLgBAYwDYEMDOa4DEITgbwCg44B6AKnOJPLgGUALCAVyQBM4AjYONGKAJZgwwNtTi0AAgIB2MYFBkok48qWpomrNgCFgdfkJEcAvHACMAbkLVSpOABUA8gBEnALjgBbFAE9u3igA1jwwDAKY0nIKSkgA-LaUqvRa7BIyEDC0AXyCwqKq6iSaLOwAcpl6BnnGcGYATNYAvkA

### 💻 Code

```ts
export class Foo {
  /**
   * Should be stripped
   * @internal
   */
  shouldBeStripped = 1;

  // TODO: maybe make this @internal?
  /**
   * Should *not* be stripped
   */
  shouldNotBeStripped = 2;
}
```


### 🙁 Actual behavior

The compiler should preserve the `Foo.shouldNotBeStripped` property while removing `Foo.shouldBeStripped`.

### 🙂 Expected behavior

Both `Foo.shouldNotBeStripped` and `Foo.shouldBeStripped` are removed.

### Additional information about the issue

If a class member has an unrelated comment mentioning `@internal` preceding it, TypeScript will drop that member from the .d.ts output, even though that's not the intent since there's another comment after it. Only the first comment should be checked for `@internal`.
Repository: PowerToys
Issue: Powertoys Run : The system cannot find the file specified
Labels: Issue-Bug,Product-PowerToys Run,Needs-Triage,Run-Plugin

### Microsoft PowerToys version

0.78.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

Execute the command >wt ssh username@IP


### ✔️ Expected Behavior

Opening a windows terminal executing the command ssh username@IP

the command wt ssh username@IP works find with WIN+R
and also works fine from a command line (CMD or Powershell)
also the command >wt (without parameters) works fine in powertoys run

### ❌ Actual Behavior

An error occured
![image](https://github.com/microsoft/PowerToys/assets/15816736/f1f26002-f7a5-495a-bc74-585b93c0e0cb)


### Other Software

_No response_
Repository: PowerToys
Issue: Color picker float format is too imprecise (2 decimal places are not enough)
Labels: Issue-Bug,Product-Color Picker

### Microsoft PowerToys version

0.78.0

### Installation method

WinGet

### Running as admin

No

### Area(s) with issue?

ColorPicker

### Steps to reproduce

Create a custom float color format in the color picker, eg:
![image](https://github.com/microsoft/PowerToys/assets/4066646/2d0ba424-7db0-454a-8e6d-e7c7ca1e618e)
As you can see in the example string, the precision is only 2 decimal places. When you multiply this value with 255 to get back to the byte value, it should be the same value as shown in the byte color format.
Let's say you pick this shade of red:
![image](https://github.com/microsoft/PowerToys/assets/4066646/8f2b4445-e15c-425a-a740-431c2e2dcc5b)
If you multiply the float values with 255, you do not get the same color:
0.93 * 255 = 237.15 // Red channel is correct, but...
0.16 * 255 = 40.8 // Blue channel is only correct if you round, but wrong if you floor the number!
0.22 * 255 = 56.1 // Green channel is wrong, doesn't matter whether you round or floor the number!

### ✔️ Expected Behavior

The float color format should be able to represent all 256 shades of a color channel exactly.




### ❌ Actual Behavior

The picked color is in many cases not exactly represented by the 2 decimal points of the current float color format.
The range from 0.00 to 1.00 contains 101 possible values, while the range from 0 to 255 contains 256 values.
It is impossible to uniquely map 256 values into just 101.
The range from 0.000 to 1.000 contains 1001 values, so there an exact mapping is possible.

### Other Software

_No response_
Repository: material-ui
Issue: [material-ui][List] On applying high contrast themes, the focus indicator on the list items under "Movie" combo box is not visible in all the modes
Labels: accessibility,package: material-ui,component: autocomplete

### Steps to reproduce

Link to live example: 
![MAS4 3 1-Aquatic Mod
![MAS4 3 1-Dusk Mode](https://github.com/mui/material-ui/assets/93735775/024de859-e325-4bb5-91c6-fdd29819fa87)
e](https://github.com/mui/material-ui/assets/93735775/f453ea82-1e2c-4d7e-a1e8-f334beaf90e4)
![MAS4 3 1-Desert Mode](https://github.com/mui/material-ui/assets/93735775/56be8d1a-e543-4c4f-980e-c19b765cfd78)
![MAS4 3 1-Nightsky Mode](https://github.com/mui/material-ui/assets/93735775/262add37-a8e4-47d7-b4a8-e0715971ac47)
![MAS4 3 1-Normal Mode](https://github.com/mui/material-ui/assets/93735775/0b8994dd-6a39-4443-9ebd-aa1bfe5a8b2c)

Steps:
1.Open URL: [heuristic-boyd-zw8xv7 - CodeSandbox](https://codesandbox.io/p/sandbox/heuristic-boyd-zw8xv7)
2.Sandbox editor page appears.
3.Use tab key to reach to "Movie" combo box and select it.
4.Navigate list items under "Movie" combo box using tab keys and observe whether the keyboard focus indicator is visible or not on the list items after applying high contrast themes.


### Current behavior

On applying high contrast themes, the focus indicator on the list items present inside the "Movie" combo box is not visible in all the modes.
 
Observation: 
In normal mode while navigating the list items there is an indication of focus (Represented with hash color) but, on applying high contrast themes no focus indicator is visible.
The issue is with all the four (Aquatic, Desert, Night sky and Dusk) modes.

### Expected behavior

On applying high contrast themes, the focus indicator on the list items present inside the "Movie" combo box should be clearly visible in all the modes.

### Context

Color Sensitive users who rely on High contrast modes would be impacted if the focus indicator or controls are not visible on applying high contrast themes. Due to this they cannot access the page efficiently and face difficulty in accessing the control.

### Your environment

Windows 11 22H2 (OS Build:23620.1000)
Component: @mui/material/Autocomplete

**Search keywords**: high contrast themes
Repository: vscode
Issue: Re-instate swipeToNavigate for Mac
Labels: feature-request,macos,workbench-os-integration,workbench-history

Per [this PR](https://github.com/microsoft/vscode/pull/23663) - original setting was
`   "workbench.editor.swipeToNavigate": true`

I realise that the setting was removed per [this](https://github.com/microsoft/vscode/issues/57629) but that's a long time ago and it looks like it can be supported with [this Electron event](https://www.electronjs.org/docs/latest/api/browser-window#event-swipe-macos)

This is a really nice feature of Mac navigation and is supported across a number of apps - including Electron-based, like Slack.
Repository: go
Issue: proposal: cmp: add Reverse function
Labels: Proposal

### Proposal Details

I propose a small, trivial addition to the cmp package. _(Ed.: This now incorporates an observation from @itchyny [here](https://github.com/golang/go/issues/65632#issuecomment-2060544312).)_

```go
// Reverse takes a comparison function and returns the reverse of it.
func Reverse[T any](fn func(x, y T) int) func(x, y T) int {
	return func(x, y T) int { return fn(y, x) }
}
```

As an example,

```go
package main

import (
	"cmp"
	"fmt"
	"slices"
)

func main() {
	fn := func(x, y int) int { return cmp.Compare(x, y) }
	xs := []int{2, 3, 1}
	fmt.Printf("%v\n", xs)

	slices.SortFunc(xs, fn)
	fmt.Printf("%v\n", xs)

	slices.SortFunc(xs, Reverse(fn))
	fmt.Printf("%v\n", xs)
}

func Reverse[T any](fn func(x, y T) int) func(x, y T) int {
	return func(x, y T) int { return fn(y, x) }
}
```

prints out

```
[2 3 1]
[1 2 3]
[3 2 1]
```

I've found that it's frequently useful to want to assert that something is ordered ascending or descending; writing such a thing down is trivial but feels rather clumsy.

I'm happy to contribute a pull request with tests if this is considered a good idea.
Repository: tensorflow
Issue: tf-nightly: wrong packaging metadata prevents installation using poetry on Linux
Labels: stat:awaiting tensorflower,type:build/install,subtype: ubuntu/linux,TF 2.15

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

binary

### TensorFlow version

tf-nightly 2.16.0.dev20240209

### Custom code

No

### OS platform and distribution

Linux Ubuntu 22.04

### Mobile device

_No response_

### Python version

3.11.7

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

I cannot install `tf-nightly` using `poetry` on Linux.

I'm getting the following error:

```
$> poetry add tf-nightly
Using version ^2.16.0.dev20240209 for tf-nightly

Updating dependencies
Resolving dependencies... (0.0s)

Package 'tf-nightly' is listed as a dependency of itself.
```

I'm using the following versions:
- Poetry: 1.7.1
- Pip: 24.0
- Python: 3.11.7

It looks to me like the package metadata is wrong:

Quoting from https://pypi.org/pypi/tf-nightly/2.16.0.dev20240209/json ,
the `requires_dist` field contains `tf-nightly ==2.16.0-dev20240209 ; platform_system == "Darwin" and platform_machine == "arm64"'`.

If I understand `poetry`s output correctly, this is the self-dependency that is not allowed.

To reproduce this, just create an empty directory, paste the following as your initial `pyproject.toml`

```toml
[tool.poetry]
name = "tf-package-bug"
version = "0.1.0"
description = ""
authors = ["Your Name <you@example.com>"]
readme = "README.md"

[tool.poetry.dependencies]
python = "^3.11"


[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"
```

And then run
- `pyenv local 3.11.7` (this is how I'm activating a Python 3.11 installation)
- `python -m pip install poetry` (make sure Poetry is installed for your Python 3.11)
- `poetry install --no-root` (Creates the virtual env using Python 3.11)
- `poetry add tf-nightly` (Throws the error above)

### Standalone code to reproduce the issue

```shell
The steps to reproduce are noted above.
```


### Relevant log output

_No response_
Repository: TypeScript
Issue: Assign existing interface to global (globalThis)
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

- global
- globalThis
- window

### ✅ Viability Checklist

- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [X] This wouldn't change the runtime behavior of existing JavaScript code
- [X] This could be implemented without emitting different JS based on the types of the expressions
- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Currently, to provide types to `globalThis`, I can update the `global.d.ts` similar to:
```
declare global {
    interface Navigator {
        ...
    }
}
```
However, if I want to set the interface of the global object (e.g. to give it the an interface that extends the`Window` interface, I'd have to do something like this at the top of each `.ts` file that references `globalThis` like the below:
```
interface MyWindow extends Window {}

declare let globalThis: MyWindow;
```

I'd like to see a way where I can modify the whole interface of the global object.

### 📃 Motivating Example

Override the whole ` interface.

### 💻 Use Cases

Working across multiple runtimes which share the same `global` interface without having a large `global.d.ts` with copy/pasted interfaces from utility types.
Repository: tauri
Issue: [bug] Debugging crashes on F12 in app (while Strg+Shift+I works)
Labels: type: bug,status: needs triage

### Describe the bug

Using the default `create tauri app` example app, plus the suggested debugging config (https://tauri.app/v1/guides/debugging/vs-code/), starting the debugging session works fine. But when I press F12 in the app window to open the dev console, I get the following error:

![image](https://github.com/tauri-apps/tauri/assets/1475672/620bd979-1874-4de7-8198-ad3a5215043a)

```Exception has occurred: Exception
Exception 0x80000003 encountered at address 0x7ffe88873060
```

Interestingly this does not happen on STRG + Shift + I. Right click > Inspect also works fine.

### Reproduction

- Create new Tauri app with `npm create tauri-app@latest` (I chose TypeScript/JavaScript, npm, React, TypeScript)
- Add VS Code launch config from https://tauri.app/v1/guides/debugging/vs-code/
- Run the debugger
- Press F12 in the app

### Expected behavior

No crash, debugging console should open

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.22635 X64
    ✔ WebView2: 121.0.2277.106
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.74.0 (79e9716c9 2023-11-13)
    ✔ cargo: 1.74.0 (ecb9851af 2023-10-18)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 20.10.0
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 1.5.4
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.7
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.9

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: React
    - bundler: Vite
PS C:\Entwicklung\repos\tauri_v1\testproj>
```


### Stack trace

_No response_

### Additional context

_No response_