sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Importing directory of images over-extends Godot's RAM usage
Labels: topic:editor,needs testing

### Tested versions

4.2.2

### System information

Windows 7

### Issue description

If you import a directory with lots of images, Godot will "helpfully" try and do it in parallel; makes sense for most game assets. However, the import process for even one large image file uses huge amounts of RAM, so when Godot tries to do multiple files in parallel, it can easily end up using far more RAM than the system has.

Godot does this self-induced lack of RAM well. It can crash Godot (not predictably reproduceable), crash Windows (not predictably reproduceable), and do weird stuff to the interface after the import is completed (below; not predictably reproduceable).

![godot is broken](https://github.com/godotengine/godot/assets/72134064/621cb8e8-ddb2-4b83-9b48-245b7a4e5176)


### Steps to reproduce

1) Create a new Project
2) Import a directory of large images.  In my case I'm using about 22 Hubble Pictures
![Clipboard02](https://github.com/godotengine/godot/assets/72134064/3819d252-a14c-4b66-ac9b-5ed5a68e585f)

3) Godot Analyses the images, using 12GB or so of RAM.

If I double the number of images (copy/paste onto themselves), sure enough, Godot now uses 20GB of RAM, which is more than the 16GB on my system, so lots of paging and Bad Things (tm) can happen.

I expect if I had a directory filled solely with a couple dozen of the very largest of those images, Godot would do awful things to my RAM. Someone else can test that. :-)
You can get some Hubble pictures from here if you're struggling for large images to test against: https://hubblesite.org/images

### Minimal reproduction project (MRP)

N/A
Repository: deno
Issue: "Uncaught SyntaxError: Unexpected token '<'" when using primitive as parameter in arrow function declaration
Labels: bug,cli,repl

`deno --version`:
deno 1.43.5 (release, x86_64-pc-windows-msvc)
v8 12.4.254.13
typescript 5.4.5

I did not find this issue after searching in the issues tab for this repository.

--- 

about: deno gives a confusing error message when incorrectly declaring an arrow function. 
example from REPL:
```ts
> (0) => 1
Uncaught SyntaxError: Unexpected token '<'
```

This can be extremely confusing in normal development because there is no `<` in the source code for the user to refer to. 

- Can be replicated with regular `deno run` as well as the REPL
- Can be replicated when using a number, string, boolean, or `null` as the parameter
- Can _not_ be replicated when using an object as the parameter (e.g. `Infinity`, `[]`, `{}`, `undefined`, etc. all successfully create an anonymous function)
- Can be replicated when mixing object and non-object parameters (e.g. `(1, undefined) => 0` replicates this)
- Can _not_ be replicated if the parameter is not wrapped in parenthesis (e.g. 0 => 1 gives back `parse error: Expected ';', '}' or <eof>`)

This appears to happen regardless of context. Attempting this with a non-arrow function results in a much more helpful error message. Browsers and `tsc` each give a different error message, and none of them mention `<` anywhere (browsers tried were chromium-edge and firefox).

---

Please let me know if this is the wrong bug report format or if this is the wrong place to submit this report, as this is my first issue report in a long time :)
Repository: go
Issue: build: make.bash fails for GOOS=plan9 GOARCH=386
Labels: OS-Plan9,NeedsInvestigation,arch-386

As reported by the plan9-386-0intro builder and legacy misc-compile-plan9-386 trybot, the plan9/386 port fails to bootstrap:

```
gotip $ git rev-parse HEAD
e7bf9959fd9ea649e1513cef16f91f81b136045f
gotip $ cd src                           
src $ GOOS=plan9 GOARCH=386 ./make.bash
Building Go cmd/dist using /usr/local/go. (go1.22.3 darwin/arm64)
Building Go toolchain1 using /usr/local/go.
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.
Building commands for host, darwin/arm64.
Building packages and commands for target, plan9/386.
go tool dist: unexpected stale targets reported by /Users/gopher/gotip/pkg/tool/darwin_arm64/go_bootstrap list -gcflags="" -ldflags="" for [cmd/asm cmd/cgo cmd/compile cmd/link cmd/preprofile] (consider rerunning with GOMAXPROCS=1 GODEBUG=gocachehash=1):
	STALE cmd/compile: not installed but available in build cache

src $ echo $?
2
```

Also see https://build.golang.org/log/f237bed35a32f61819468d4cfd1b28946cb3e4d1 and https://storage.googleapis.com/go-build-log/ecc40e66/misc-compile-plan9-386_f210191c.log.

This doesn't happen for other ports. It also doesn't happen for other GOARCH values of GOOS=plan9 like plan9/amd64 and plan9/arm, only for plan9/386.

CC @golang/plan9.
Repository: go
Issue: x/benchmarks, x/build: gVisor startup benchmark doesn't work on builders
Labels: Builders,NeedsFix,compiler/runtime

After reenabling the gVisor benchmarks, I ran into an issue with the 'startup' benchmark failing to write to `/var/run/runsc` which shouldn't be necessary, and doesn't seem to be happening locally. I'm not sure what's causing it, but it seems related to the `runsc run` command in particular, as the sub-benchmarks work just fine (and use `runsc do`).
Repository: deno
Issue: Supporting `vitest` tracking issue
Labels: node compat

This is an issue to track the progress on getting the `vitest` test runner to work. I'm currently using the test suite from [urql](https://github.com/urql-graphql/urql/tree/main) to check our progress.

- ~~Web `MessagePort` not converted to worker_thread `MessagePort` https://github.com/denoland/deno/issues/23828~~
- Node globals missing in `vm.runInThisConext` https://github.com/denoland/deno/issues/23852
- TTY test result reporter not working because of this check https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/utils/env.ts#L1 
  - ~~`signal-exit` is used under the hood. It's likely that this issue causes CTRL+C to not work: https://github.com/denoland/deno/issues/22892~~
- Test run doesn't seem to complete
Repository: godot
Issue: Laptop Memory Access Violation Crash in Godot v4.2.2-stable with AMD Graphics Driver
Labels: bug,needs testing,crash

### Tested versions

4.2.2-stable

### System information

OS Version: Windows 11 Pro, Version 23H2, OS build 22631.3593 CPU: AMD Ryzen 5 5500U with Radeon Graphics, 2.10 GHz Installed RAM: 16 GB GPU: AMD Radeon(TM) Graphics GPU Driver Version: 31.0.12044.3 

### Issue description

When running a project in Godot v4.2.2-stable, the application crashes with a memory access violation error. The crash log indicates an issue with the AMD Vulkan driver (amdvlk64.dll). This issue prevents the project from running and results in an immediate crash.

Crash log:
Faulting application name: Godot_v4.2.2-stable_win64.exe, version: 4.2.2.0, time stamp: 0x00000000
Faulting module name: amdvlk64.dll, version: 31.0.12044.3, time stamp: 0x635817e7
Exception code: 0xc0000005
Fault offset: 0x0000000000052f1b
Faulting process id: 0x0x1F44
Faulting application start time: 0x0x1DAA9501F86BB79
Faulting application path: C:\Users\402\AppData\Roaming\Godot-Manager\versions\4.2.2-stable\Godot_v4.2.2-stable_win64.exe
Faulting module path: C:\WINDOWS\System32\DriverStore\FileRepository\u0387389.inf_amd64_995be970e30b8c79\B385477\amdvlk64.dll
Report Id: cfc401f9-c56b-4c82-93b8-ade5aca3df86
Faulting package full name: 
Faulting package-relative application ID: 

Specs:
HP Laptop
OS Version: Windows 11 Pro, Version 23H2, OS build 22631.3593
CPU: AMD Ryzen 5 5500U with Radeon Graphics, 2.10 GHz
Installed RAM: 16 GB
GPU: AMD Radeon(TM) Graphics
GPU Driver Version: 31.0.12044.3
Rendering Backend: Vulkan

Godot Console:
Godot Engine v4.2.2 OpenGL API 3.3.0 Core Profile Context 22.20.44.221025 - Compatibility - Using Device: ATI Technologies Inc. - AMD Radeos Godot Engine v4.2.2 Vulkan API 1.3.217 - Forward+ - Using Vulkan Device #0: AMD - AMD Radeon(TM) Graphics

Sometimes the crash produces this error window:
![Godot_v4 2 2-stable_win64_Hj2och7n8r](https://github.com/godotengine/godot/assets/45674197/970b3270-973b-4374-a394-fc5623ba2991)

I got lucky once and got the image of the console before it closed:
![WindowsTerminal_9BjR8yG21n](https://github.com/godotengine/godot/assets/45674197/1856656b-6ae9-4ea9-b9fd-8281e6dcf776)

What I've tried:
- Updating Windows
- Updating the AMD drivers

### Steps to reproduce

Our project is 2D and about 1GB in size. It crashes every time now, just in different ways.

- Sometimes by clicking into Editor Settings
- Sometimes by clicking onto a new scene
- Sometimes by adding a scene
- You can imagine other ways it could crash

### Minimal reproduction project (MRP)

NA
Repository: go
Issue: x/build/cmd/golangbuild: provide more useful signal when testing broken ports by using -force flag
Labels: Builders,NeedsFix

This is a tracking issue to port the behavior implemented in coordinator for #61925 to the LUCI side in [golangbuild](https://source.chromium.org/chromium/infra/infra/+/main:go/src/infra/experimental/golangbuild/buildmode.go;l=100-104;drc=816bca63478e90d97e316b342c14bb6971b56848).

By now all supported Go versions support the -force flag in make.bash, so the part of making it depend on the Go version won't be neccessary.
Repository: go
Issue: proposal: all: have a policy for sweeping updates
Labels: Proposal

### Proposal Details

See https://go-review.googlesource.com/c/go/+/586616 for example. There's  nothing wrong with the change in itself, but there is no guidance about whether it should happen. It's a code rewrite with no semantic effect. It's also a reasonable thing to do, but there are surely many places throughout std that could have a similar change applied. That in turn could lead to many tiny CLs coming in, creating an undue load on maintainers and the trybots to check them.

It's reasonable to suggest that new significant packages, such as "slices", be used in std to show how best to use them. The standard library acts as an exemplar of good Go style.

So I propose two things:

1. A policy concisely (if imperfectly) defining when a new package, function, or language feature be deployed throughout std.
2. A decision that when such a possibility arises, it be done wholesale, in one or maybe a handful of big CLs, to get it done quickly and efficiently.
Repository: pytorch
Issue: Avoid calling torch.cuda.synchronize in precompile_config
Labels: triaged,oncall: pt2,module: inductor

### 🐛 Describe the bug

Internal xref: https://fb.workplace.com/groups/6829516587176185/posts/7228787720582401/?comment_id=7231763463618160&reply_comment_id=7235527919908381

I was debugging a deadlock and I noticed one of our threads was deadlocked on this stack:

```
[trainer1|1]:  File "/mnt/xarfuse/uid-236622/e595b196-seed-nspid4026531836_cgpid37271928-ns-4026531841/torch/cuda/__init__.py", line 803 in synchronize
[trainer1|1]:  File "/mnt/xarfuse/uid-236622/e595b196-seed-nspid4026531836_cgpid37271928-ns-4026531841/torch/_inductor/runtime/triton_heuristics.py", line 422 in _precompile_config
[trainer1|1]:  File "/mnt/xarfuse/uid-236622/e595b196-seed-nspid4026531836_cgpid37271928-ns-4026531841/torch/_inductor/runtime/triton_heuristics.py", line 231 in precompile
[trainer1|1]:  File "/mnt/xarfuse/uid-236622/e595b196-seed-nspid4026531836_cgpid37271928-ns-4026531841/torch/_inductor/codecache.py", line 3087 in triton
[trainer1|1]:  File "/tmp/torchinductor_shuaiyang/u6/cu6smvlhusvxdug2bu7lrz3zofdzwkt27gnjniqk2ti6u5jgvm4h.py", line 33 in <module>
[trainer1|1]:  File "/mnt/xarfuse/uid-236622/e595b196-seed-nspid4026531836_cgpid37271928-ns-4026531841/torch/_inductor/runtime/compile_tasks.py", line 44 in _reload_python_module
[trainer1|1]:  File "/mnt/xarfuse/uid-236622/e595b196-seed-nspid4026531836_cgpid37271928-ns-4026531841/torch/_inductor/codecache.py", line 2576 in load_by_key_path
[trainer1|1]:  File "/mnt/xarfuse/uid-236622/e595b196-seed-nspid4026531836_cgpid37271928-ns-4026531841/torch/_inductor/graph.py", line 1680 in compile_to_module
[trainer1|1]:  File "/mnt/xarfuse/uid-236622/e595b196-seed-nspid4026531836_cgpid37271928-ns-4026531841/torch/_dynamo/utils.py", line 273 in time_wrapper
```

The deadlock doesn't technically have anything to do with this synchronize; the real problem is that this rank issued an all_to_all earlier and it has deadlocked. But why are we stuck here? Well, we've asked for a full synchronize, so of course we have to wait for all the comms to finish. This seems... bad for compile time? Like, if we've issued comms, there's no reason to wait for them to all finish before we can run some Triton tuning?!

### Versions

main

cc @msaroufim @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire
Repository: ui
Issue: [bug]: Sheet + Sonner toaster - toasts don't open up on mouseover
Labels: bug

### Describe the bug

When a Sheet is open and there are toasts, hovering over them doesn't expand them

### Affected component/components

Sheet, Sonner

### How to reproduce

1. Go to https://web3-shadcn-playground.vercel.app/ui
2. Click open sheet
3. Click show toast inside the sheet
4. Hover over toasts, doesn't expand to view all of them

### Codesandbox/StackBlitz link

https://stackblitz.com/~/github.com/sergical/web3-shadcn-playground

### Logs

_No response_

### System Info

```bash
Not relevant I don't think
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: node
Issue: Node 22 node-gyp build fails "Text file busy"
Labels: libuv

### Version

v22.0.0

### Platform

Linux laharl 6.9.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 17 May 2024 16:56:38 +0000 x86_64 GNU/Linux

### Subsystem

node-gyp

### What steps will reproduce the bug?

1) Attempted to build thelounge from AUR package
2) sqlite3 submodule fails with two "/usr/bin/env: 'node': Text file busy" errors

### How often does it reproduce? Is there a required condition?

It happens every time. It appears to be a race condition with io_uring with kernel 6.9.x on x86_64.

### What is the expected behavior? Why is that the expected behavior?

The packages should build properly.

### What do you see instead?

Two of the node-gyp build steps fail:

```
/usr/bin/env: 'node': Text file busy
/usr/bin/env: 'node': Text file busy
```

### Additional information

I am re-reporting this issue because it does not involve use of Docker. Currently, thelounge package has added a workaround to disable io_uring in libuv to allow the build to pass.

Edit 1:
Related bug reports have suggested this is only a problem because Arch builds nodejs against the system libuv, which it configures with the defaults, which enable io_uring support.

A kernel fix is slated for 6.9.2 that will likely work around the errors, but will not work around Arch or other distributions which have not disabled io_uring support in libuv like node has for security reasons. However, I am not sure how much of a threat model the io_uring support is, considering it's probably not that wise to be running node suid/sgid in the first place.
Repository: ollama
Issue: Add option to control start of response to generate api
Labels: feature request,api

Using openwebui for ollama or textgenwebui. you can control what the model's response begins with to steer it in a certain direction. It would be very helpful to have this built-in to the api. I have struggled to recreate this effect with the api by trying to include the model's response portion of the template in my initial prompt but have been unsuccessful so far.
Repository: react
Issue: [DevTools Bug]: Version 5.2 shows incorrect source for all the components
Labels: Type: Bug,Status: Unconfirmed,Component: Developer Tools

### Website or app

https://github.com/codedthemes/mantis-free-react-admin-template/

### Repro steps

1. npm install
2. npm run start

Point to any component in the page (for example the text "Hi, Welcome back 👋") , you will see the the source is wrong
it points to the build tool output chunk file and not to the source of the file in the project.
This is how it displays it now
<img width="266" alt="image" src="https://github.com/facebook/react/assets/18378585/4599adf5-42ef-416b-837c-67da92584acc">
This should point to the source in the project, the `fileName` should point to the file inside the `src` directory, as pointing to the output chunk is pointless for debug reasons.
Thank you


### How often does this bug happen?

Every time

### DevTools package (automated)

_No response_

### DevTools version (automated)

_No response_

### Error message (automated)

_No response_

### Error call stack (automated)

_No response_

### Error component stack (automated)

_No response_

### GitHub query string (automated)

_No response_
Repository: PowerToys
Issue: 给键盘管理器功能的建议
Labels: Needs-Triage

### Description of the new feature / enhancement

希望为键盘管理器添加可保存的方案, 并设置单独的开关.
以便我在多个键盘设备间切换.
现在切换了键盘需要重新修改方案, 不是很方便.
![无标题](https://github.com/microsoft/PowerToys/assets/31532582/20626463-11e4-4fee-9d73-c4d8cf24cece)


### Scenario when this would be used?

以便我在多个键盘设备间切换.

### Supporting information

_No response_
Repository: deno
Issue: reduce readFileSync syscall count
Labels: bug,perf

https://x.com/justjs14/status/1791963104881844360

![image](https://github.com/denoland/deno/assets/34997667/319d520c-4050-4b76-9f54-6f1cfe4de62f)

Repro: https://gist.github.com/billywhizz/1d6fee4d3aea1030324a7a93de444d31
Repository: react
Issue: [Compiler Bug]: false positive when using hooks in a nested component
Labels: Type: Bug,Component: Optimizing Compiler

### What kind of issue is this?

- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAgHgBwjALgAgBMEAzAQygBsCSoA7OXASwjvwFkBPAQU0wAoAlPmAAdNvjiswBANoBbaHVwJCAGnxgEudkpWEAuvgC8+KFoDKuMiv7lKWwePyTpBAJJ06CGAGEI8tjeyiZmWr5klJQARmRwANZ29IwsbJ7efgFBCMpCIs4uYQgAoiQkCIz8ecYAfPkShZrauvT6-LgwUAiCANwFLgC+GrIGveL9+DDasGwAPIRMAG41TF4+swD0C8t9EkP4I2N0BVO4M-izAGIQEK6BrDm4xsDpPv73wbgD+Bs1uwPjOi0BjMVj4a4QfiYGAQTBgYRiCSnc6zaGwsAAOikH0ePxq4gGIAGQA

### Repro steps

The ESLint plugin for React Compiler seems to not recognise inner function components as components, so it reports an error when you try to use hooks inside such nested components. `eslint-plugin-react-hooks` does recognise this pattern and doesn’t warn about it.

> Hooks must be called at the top level in the body of a function component or custom hook, and may not be called within function expressions. See the Rules of Hooks (https://react.dev/warnings/invalid-hook-call-warning).

I understand that defining a component like this isn’t ideal because `useMemo` / `useCallback` don’t have strong guarantees or can get invalidated due to dependencies changing, leading to remounts so would be good to know if code should be rewritten away from this pattern or whether this is a false positive that will eventually get resolved. 

### How often does this bug happen?

Every time

### What version of React are you using?

19.0.0-rc-3f1436cca1-20240516
Repository: flutter
Issue: GTK Linux embedder use libcanberra for sounds
Labels: engine,e: embedder,platform-linux,c: proposal,P3,team-linux,triaged-linux

### Use case

Observing the engine source code, I have noticed that only one sound is supported for playing a system sound. That sound is the bell. This is okay for a lot of applications. However, I would like to be able to play different sounds. Being able to use the same API as all other platforms for the sound would be very nice.

### Proposal

Use `libcanberra` to handle sounds with the sound method in the `flutter/platform` method channel in the GTK Linux embedder.
Repository: flutter
Issue: GTK Linux embedder use feedbackd to handle haptic feedback
Labels: c: new feature,engine,e: embedder,platform-linux,c: proposal,P3,team-linux,triaged-linux

### Use case

As popularity in mobile Linux increases, more and more applications will have to be updated to handle a mobile device. Having the experience of mobile Linux become similar to iOS or Android would be great.

### Proposal

Use feedbackd to request a haptic feedback to be triggered in the GTK Linux embedder.
Repository: rust
Issue: Suggest `Some(&v)` rather than `Some(v.clone())` when calling generic owning methods
Labels: A-diagnostics,T-compiler

### Code

```Rust
#[allow(unused)]
fn f() {
    let v = vec![0];
    Some(v).is_some_and(|_| true);
    drop(v);
}
```


### Current output

```Shell
Compiling playground v0.0.1 (/playground)
error[E0382]: use of moved value: `v`
 --> src/lib.rs:5:10
  |
3 |     let v = vec![0];
  |         - move occurs because `v` has type `Vec<i32>`, which does not implement the `Copy` trait
4 |     Some(v).is_some_and(|_| true);
  |          - value moved here
5 |     drop(v);
  |          ^ value used here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
4 |     Some(v.clone()).is_some_and(|_| true);
  |           ++++++++

For more information about this error, try `rustc --explain E0382`.
error: could not compile `playground` (lib) due to 1 previous error
```


### Desired output

```Shell
Compiling playground v0.0.1 (/playground)
error[E0382]: use of moved value: `v`
 --> src/lib.rs:5:10
  |
3 |     let v = vec![0];
  |         - move occurs because `v` has type `Vec<i32>`, which does not implement the `Copy` trait
4 |     Some(v).is_some_and(|_| true);
  |          - value moved here
5 |     drop(v);
  |          ^ value used here after move
  |
help: consider borrowing the value
  |
4 |     Some(&v).is_some_and(|_| true);
  |          +

For more information about this error, try `rustc --explain E0382`.
error: could not compile `playground` (lib) due to 1 previous error
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Rust Version

```Shell
1.80.0-nightly

(2024-05-18 b1ec1bd65f89c1375d2c)
```


### Anything else?

_No response_