sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: Web components using TS / customElement decorator breaks hotloading in Storybook 7
Labels: bug,documentation,web-components,lit,upgrade:7.x

### Describe the bug

Hey there,

I upgraded from Storybook 6 to 7 and I'm running into an issue with hot reloading tossing an error due to my web components being defined using the customElement decorator. This worked fine in v6, maybe there was a change in how the reloading works?

When setting up a repository to get a minimum reproduction, I saw that the web-component examples defined from Storybook are using a function-style definition for the web-components, but the Lit documentation uses classes with the customElement decorator. There's a bit of a discrepancy there, is Storybook expecting web-component code to be defined in that way? Also, looking at the tutorial documentation for web-components, there are examples rendering the custom tag in a template, but they don't import the source for the component which is a little confusing.

Here's a linked a repro repo with a base form of the configuration I'm using: [link](https://github.com/thaithcock/storybook7-hotreload-decorator-repro/tree/main). Maybe I'm missing something somewhere, any assistance or guidance here would be greatly appreciated. 🙇 

### To Reproduce

https://github.com/thaithcock/storybook7-hotreload-decorator-repro/tree/main

### System

```bash
Environment Info:

  System:
    OS: macOS 13.0
    CPU: (10) arm64 Apple M2 Pro
  Binaries:
    Node: 18.16.0 - ~/.nvm/versions/node/v18.16.0/bin/node
    npm: 9.5.1 - ~/.nvm/versions/node/v18.16.0/bin/npm
  Browsers:
    Chrome: 116.0.5845.179
    Safari: 16.1
  npmPackages:
    @storybook/blocks: ^7.4.0 => 7.4.0 
    @storybook/web-components: ^7.4.0 => 7.4.0 
    @storybook/web-components-webpack5: ^7.4.0 => 7.4.0
```


### Additional context

I did notice when messing around with the repro repo, very rarely the hot reload does not break.
Repository: go
Issue: runtime: deadlock while stopping the world (most recently openbsd/amd64)
Labels: help wanted,OS-OpenBSD,NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- log ~ `SIGQUIT` && log ~ `stopping the world`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/26b6dd8af920293728685c90c2ad7250ae6e1ff5)):

    SIGQUIT: quit
    PC=0x80b76f7 m=14 sigcode=0
    
    eax    0x4
    ebx    0x0
    ecx    0x8407b00
    edx    0x854aa80
    edi    0xb09dfe7c
    esi    0xf
    ebp    0x3
    ...
    	/tmp/workdir/go/src/runtime/proc.go:1262 +0xc7 fp=0x8438e1c sp=0x8438df4 pc=0x8087577
    runtime.stopTheWorldGC(0xa)
    	/tmp/workdir/go/src/runtime/proc.go:1310 +0x45 fp=0x8438e34 sp=0x8438e1c pc=0x8087705
    runtime.StartTrace()
    	/tmp/workdir/go/src/runtime/trace.go:284 +0x1c fp=0x8438e7c sp=0x8438e34 pc=0x80a432c
    runtime/trace.Start({0x8237a2c, 0x847e270})
    	/tmp/workdir/go/src/runtime/trace/trace.go:125 +0x75 fp=0x8438e98 sp=0x8438e7c pc=0x81105e5
    runtime/trace_test.TestTraceFutileWakeup(0x85340f0)
    	/tmp/workdir/go/src/runtime/trace/trace_test.go:510 +0xc5 fp=0x8438f98 sp=0x8438e98 pc=0x81b2315
    testing.tRunner(0x85340f0, 0x8208078)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: godot
Issue: Editor popup buttons behavior is clunky and clicking again on a button sometimes doesn't close the popup
Labels: bug,topic:editor,topic:gui

### Godot version

4.1.1

### System information

linux

### Issue description

[simplescreenrecorder-2023-09-08_21.37.34.webm](https://github.com/godotengine/godot-proposals/assets/71937306/e6c1d1c1-2036-41ff-9d4d-1df98c6213f5)

[simplescreenrecorder-2023-09-08_22.28.49.webm](https://github.com/godotengine/godot/assets/71937306/6b223b43-60c4-497d-883e-9c73af1fa4e4)

clicks should toggle the visibility of the popup.
`OptionButton`s and `MenuButton`s work fine in a godot game, it's only a problem I have in the editor.

### Steps to reproduce

click on one of those buttons

### Minimal reproduction project

editor
Repository: pytorch
Issue: [c10d] fix functional collective reduce op naming convention
Labels: oncall: distributed,triaged,module: c10d

see discussions in https://github.com/pytorch/pytorch/pull/108758#pullrequestreview-1615186895

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
Repository: flutter
Issue: docs_publish is failing due to downloading AARCH64 binary of firebase tool on x64 bot
Labels: team-infra,P3,triaged-infra

On https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20docs_publish/11997/overview

Which ran on an x64 ubuntu bot: https://chromium-swarm.appspot.com/bot?id=flutter-prod-ubuntu-highmem-us-central1-b-4-0kd9

The script failed with:

```
/lib/ld-linux-aarch64.so.1: No such file or directory
```

https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8770491697891583569/+/u/Docs/Deploy_docs/Firebase_deploy/stdout

After it downloaded an AArch64 binary from https://firebase.tools/bin/linux/latest: https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8770491697891583569/+/u/Install_firebase/Install_firebase_bin/execution_details

Our recipes have CURL'd this endpoint since 2020: https://flutter.googlesource.com/recipes/+/59aeb93b9bc8cf5cf6ce9a499cc9703cb734f58f. There have been no recent changes. I'm guessing that the issue is that https://firebase.tools/bin/linux/latest used to serve an x64 binary, but now switched to ARM.
Repository: next.js
Issue: Prefetching dynamic route doesn't work as expected
Labels: bug,Navigation

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/mwildehahn/reproduce-layout-rerender

### To Reproduce

- navigate to https://reproduce-layout-rerender.vercel.app/
- wait for prefetch to finish, switch your network condition to offline
- click nested
- page errors out

### Current vs. Expected behavior


I might be misunderstanding this, but from https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating

> [Dynamic Routes](https://nextjs.org/docs/app/building-your-application/rendering/server-components#dynamic-rendering): prefetch default to automatic. Only the shared layout down until the first loading.js file is prefetched and cached for 30s. This reduces the cost of fetching an entire dynamic route, and it means you can show an [instant loading state](https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming#instant-loading-states) for better visual feedback to users.

I took this to mean that the loading.js file for the route would be prefetched and cached (which makes sense). In practice, it seems like a prefetch does happen, but it doesn't include the loading file and I can't see that file cached when inspecting `window.nd.prefetchCache` after the prefetch has returned.

What I would expect is to instantly see a transition to the loading state and then maybe an error state after that if the navigation fails but now it seems like it requires making the initial server request to display the loading state.

It seems like something is broken with caching in general since even if you don't mess with network conditions, the previous route is never cached even within the 30s window



### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:41 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T8103
    Binaries:
      Node: 18.17.1
      npm: 9.6.7
      Yarn: 1.22.10
      pnpm: 8.7.4
    Relevant Packages:
      next: 13.4.20-canary.22
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3
    Next.js Config:
      output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router, Routing (next/router, next/navigation, next/link)

### Additional context

_No response_
Repository: flutter
Issue: Cleanup embedder vulkan unittests
Labels: engine,good first issue,P2,c: tech-debt,team-engine,triaged-engine

Right now, confusingly, the Vulkan embedder unittests live in `//shell/platform/embedder/tests/embedder_gl_unittests.cc`.  Their coupling with the gl tests makes them not possible to run on macos.

Cleanup includes:
- [ ] Naming the file more appropriately to reflect what is being executed
- [ ] Make the vulkan tests able to be run on macos
Repository: transformers
Issue: More explicit bounding box formats
Labels: Feature request

### Feature request

I am having a difficult time managing different bounding box formats in this library. For example, the DETR model preprocessor input format is COCO (xywh), but the output of the postprocessor is a pascal_voc (xyxy). Why not keep everything the same format? Furthermore, the documentation does not say which format is which so it's required to dig through the source to identify that information.

### Motivation

Ease of use

### Your contribution

Just a request
Repository: rust
Issue: Wrong spans for transmute argument errors
Labels: A-diagnostics,T-compiler,D-incorrect,F-transmutability

### Code

```Rust
#![crate_type = "lib"]
#![feature(transmutability)]
mod assert {
    use std::mem::BikeshedIntrinsicFrom;
    struct Context;

    pub fn is_maybe_transmutable<Src, Dst>()
    where
        Dst: BikeshedIntrinsicFrom<Src, Context>,
    {
    }
}

fn main() {
    pub union Uninit {
        a: [u8; usize::MAX],
    }

    #[repr(C)]
    struct ExplicitlyPadded(Uninit);

    assert::is_maybe_transmutable::<ExplicitlyPadded, ()>();
}
```


### Current output

```Shell
error[E0277]: `ExplicitlyPadded` cannot be safely transmuted into `()` in the defining scope of `assert::Context`
  --> src/lib.rs:22:55
   |
22 |     assert::is_maybe_transmutable::<ExplicitlyPadded, ()>();
   |                                                       ^^ values of the type `ExplicitlyPadded` are too big for the current architecture
   |
note: required by a bound in `is_maybe_transmutable`
  --> src/lib.rs:9:14
   |
7  |     pub fn is_maybe_transmutable<Src, Dst>()
   |            --------------------- required by a bound in this function
8  |     where
9  |         Dst: BikeshedIntrinsicFrom<Src, Context>,
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `is_maybe_transmutable`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` (lib) due to previous error
```


### Desired output

```Shell
22 |     assert::is_maybe_transmutable::<ExplicitlyPadded, ()>();
   |                                     ^^^^^^^^^^^^^^^^ values of the type `ExplicitlyPadded` are too big for the current architecture
```


### Rationale and extra context

seems `adjust_fulfillment_error_for_expr_obligation` fix wrong span for the arguments.

### Other cases

_No response_

### Anything else?

_No response_

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"gurry"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: 3.3>... : Software Skinner doesn't work when skinning a non-triangle mesh on Mali GPUs
Labels: platform:android,topic:rendering,documentation,topic:3d

### Godot version

v3.5.2.stable.official [170ba337a]

### System information

Tested on: Mali-G68 MC4, Mali-G71, Mali-G52 MC1, Adreno 642L & PowerVR Rogue GE8322

### Issue description

In my game, i use a wireframe art style, so i transform some meshes into wireframes using a script. One type of these meshes are static scenario parts, which render ok on all mobile devices, another type is characters, skinned models, which just refused to show up on certain phones.

Upon futher inspections, i discovered that this bug was only happening on Mali gpus, which would be ok, and i'd just forget about it, if they wouldn't be the most used gpus on the market rn (and for some reason, all samsung currently phones use them, _wild_).
The Debugger would throw me this error each time i called surface modifying function on the ArrayMesh Class (e.g. _add_surface_from_arrays_, _surface_remove_, _surface_set_material_) specifically on phones with Mali GPUs:
![image](https://github.com/godotengine/godot/assets/56614267/86a063ef-25d2-41bc-b1c4-7996ea63d8a1)

Upon even further inspections, i discorvered that Software Skinning is turn on by default on mobile - [because the performance of GPU skinning isn't great overall](https://github.com/godotengine/godot/issues/37696) - and when i turned it off, via disabling `software_skinning_fallback `in the ProjectSettings, characters where showing up normally.

### Steps to reproduce

1. Grab any skinned model
2. Add a script to it with the following code:
```gdscript
func _ready():
	var a = mesh.surface_get_arrays(0)
	var m = mesh.surface_get_material(0)
	
	mesh.surface_remove(0)
	
	mesh.add_surface_from_arrays(Mesh.PRIMITIVE_TRIANGLES, a)
	
	mesh.surface_set_material(0, m)
```
3. Export to android and run on any phone with a Mali GPU
4. Go back to the editor, under the ProjectSettings, turn `rendering/quality/skinning/software_skinning_fallback` off
5. Test again

### Minimal reproduction project

N/A
Repository: stable-diffusion-webui
Issue: [Bug]: checking for availability of extensions results in crash of python process on Exception
Labels: bug-report,platform:mac

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

Upon click the "Load From" button in the Available tab of the "Extension" tab, and with the URL set to default, https://raw.githubusercontent.com/AUTOMATIC1111/stable-diffusion-webui-extensions/master/index.json, after a little while, I got an error message from the system:
Python process terminated unexpectedly. (Rough translation from a Chinese message)

### Steps to reproduce the problem

1. Start the webUI;
2. Go to the Extension tab;
3. Go to the Available sub tab;
4. Click on the "Load from" button;
5. Wait a while.


### What should have happened?

The webui should be able to load all available extensions from github and list them in a table.

### Sysinfo

[sysinfo-2023-09-09-01-20.txt](https://github.com/AUTOMATIC1111/stable-diffusion-webui/files/12564352/sysinfo-2023-09-09-01-20.txt)


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

Mozilla Firefox

### Console logs

```Shell
-[IOGPUMetalCommandBuffer validate]:215: failed assertion `commit an already committed command buffer'
./webui.sh: line 255: 70084 Abort trap: 6           "${python_cmd}" -u "${LAUNCH_SCRIPT}" "$@"
```


### Additional information

Image generation seems unaffected.
Repository: godot
Issue: Moving Game Object with Kinect Mode will keep its physics properties
Labels: topic:physics

### Godot version

4.1.stable.official

### System information

Godot v4.1.stable - Windows 10.0.19045 - Vulkan (Compatibility) - NVIDIA GeForce RTX 2060 (NVIDIA; 31.0.15.3699) - AMD Ryzen 9 4900H with Radeon Graphics (16 Threads)

### Issue description

The issue likely be that the physics properties didn't reset after stopping the physics bodies that have kinetic modes. I have tested `AnimatableBody2D` and the same output occurred.

https://github.com/godotengine/godot/assets/89677860/0f74868b-be36-4e9e-909a-53b857245e14

Also, found a prevention that setting the freezing to `false` then `true` (based on the Engine base code, if setter variable is the same as the current variable, no change will happen), which I applied it to the left flipper, while the right flipper doesn't have it.

The turning speed of the flippers are exaggerated to get a difference for testing purpose.

### Steps to reproduce

1. Download Godot v4.1
2. Download/Clone [godot-cpp-4.1](https://github.com/godotengine/godot-cpp/tree/4.1) to the base folder (outside of `godot-workspace`)
3. Run `scons` while in base folder 
4. Then open project found in `godot-workspace`
6. Click play in the editor (main scene already set to `godot-workspace/scene/tests/test_platform.tscn`)
7. Test the flipper by using button `Q`

### Minimal reproduction project

Source codes and project files attached in this zip file.
[Pinbox.zip](https://github.com/godotengine/godot/files/12564422/Pinbox.zip)

Prevention code is at line 110 of `flipper.cpp`
Repository: godot
Issue: in thread, instantiating PhysicsBody2D with a CollisionShape2D child raises error
Labels: bug,topic:core

### Godot version

4.1

### System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - integrated Intel(R) UHD Graphics (Intel Corporation; 31.0.101.4575) - 13th Gen Intel(R) Core(TM) i7-1370P (20 Threads)

### Issue description

In thread, instantiating physicsbody2ds with a collision shape child raises a get_transform error.

According to https://docs.godotengine.org/en/stable/tutorials/performance/thread_safe_apis.html#scene-tree, this isn't the intended behavior.

### Steps to reproduce

see project

### Minimal reproduction project

[gd_thread_instantiate.zip](https://github.com/godotengine/godot/files/12564473/gd_thread_instantiate.zip)
Repository: vscode
Issue: Double clicking in "custom" title bar no longer consistently maximize/restores window in 1.82.0 (feature provided by Rectangle.app)
Labels: help wanted,upstream,electron,confirmation-pending

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.82.0
- OS Version: macOS Ventura 13.4

**- Rectangle Version: 0.70**

Steps to Reproduce:

1. On macOS, install Rectangle and enable the double click window title to maximize/restore feeature.
2. Open vscode, resize windows and double click on the title bar. Expected behavior(window either zooms to fullscreen or if already fullscreen reverts to its original position and size) does not happen except when all these three conditions are met: 

(a) The window is partially out of the monitor. 
(b) The window's right edge is not outside the monitor, or when it is, you are double clicking at an invisible magic area to the left of the title bar (?)
(c) The window's dimensions are different from the fullscreened window dimensions. i.e. it was pulled down from the top by grabbing the title bar without any resizing.

This problem occurs regardless of whether command center is enabled.
Repository: rust
Issue: Support Apple's TvOS Simulator on Apple Silicon
Labels: T-compiler,C-feature-request,O-tvos

Currently it appears that Rust can only compile for TvOS's Simulator running on x86. Apple Silicon need arm64. Specifically we need compile support for this target: https://github.com/apple/swift/blob/ffbc65c8c48cb38db190fa0618fe2b5937a334b8/utils/build-script-impl#L649-L658

Currently there is only:

```
➜  ~ rustc --print target-list | grep tvos
aarch64-apple-tvos
x86_64-apple-tvos
```
Repository: next.js
Issue:  doesnt work with Firefox 
Labels: bug

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/tan-z-tan/GitHubGuessr

### To Reproduce

visit that website:
https://github-guessr.vercel.app/

 blank screen. open console and see:

~~~
TypeError: e is undefined
    NextJS 11
[framework-63157d71ad419e09.js:9:69810](https://github-guessr.vercel.app/_next/static/chunks/framework-63157d71ad419e09.js)
Uncaught TypeError: e is undefined
    NextJS 11
[main-c59a42b9e9a6f445.js:1:11213](https://github-guessr.vercel.app/_next/static/chunks/main-c59a42b9e9a6f445.js)
~~~

### Current vs. Expected behavior

!

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Windows
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Additional context

_No response_
Repository: rust
Issue: Unexpected unsatisfied trait bound
Labels: A-trait-system,A-associated-items,T-compiler,C-bug,fixed-by-next-solver

<!--
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.
-->

I tried this code:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=761c1cce2cdf196f23ef8eab2a59bf6d

There seems to be an issue when resolving a blanket impl through the GAT when an associated type of the T is used - the above code is as far as I could minimize it while keeping the error message the same.

Interesting to note is this line in the error:

> help: the trait `Unsatisfied<()>` is implemented for `GenericStruct<T>`

Which is true(!) but the error states that:

> the trait `Unsatisfied<<GenericStruct<<Counterparty as HasAssoc>::Assoc> as Proto>::Proto>` is not implemented for `GenericStruct<<Counterparty as HasAssoc>::Assoc>`

Which leads me to believe this is similar to https://github.com/rust-lang/rust/issues/41756 or https://github.com/rust-lang/rust/issues/24066? But I'm not sure honestly.

EDIT: I refactored the original (non-minimized) code to not use GATS and encountered this: https://github.com/rust-lang/rust/issues/89910; perhaps the original issue is related?
Repository: go
Issue: proposal: crypto/ed25519: batch verification
Labels: Proposal

I would like to propose the addition of a new feature to support batch verification in ed25519 package, batch verification is more efficient in wide range of use cases.

Some notable ed25519 implementions that already include this feature include:

- [ed25519.cr.yp.to](https://ed25519.cr.yp.to/)
- [ed25519-dalek](https://docs.rs/ed25519-dalek/latest/ed25519_dalek/fn.verify_batch.html)
- [ed25519-donna](https://github.com/floodyberry/ed25519-donna/blob/master/ed25519-donna-batchverify.h)
- [ed25519-zebra](https://github.com/ZcashFoundation/ed25519-zebra/blob/main/benches/bench.rs)
- [ed25519consensus](https://pkg.go.dev/github.com/hdevalence/ed25519consensus#BatchVerifier)
- [curve25519-voi](https://pkg.go.dev/github.com/oasisprotocol/curve25519-voi/primitives/ed25519#BatchVerifier)