sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Removing DropAndReplace MIR allowed more code to compile
Labels: T-lang,A-MIR

Before https://github.com/rust-lang/rust/pull/107844, assignments of `Drop` types were modeled using replaced the `DropAndReplace` MIR terminator. That PR changed the behaviour to use a plain `Drop` followed by a plain `Assign`.

This made more code compile, for instance (https://github.com/rust-lang/rust/pull/107844#issuecomment-1463237147):
```rust
struct Foo<'a> {
    v: &'a mut (),
}

impl Drop for Foo<'_> {
    fn drop(&mut self) {}
}

fn bar() {
    let mut v = ();
    let mut x = Foo { v: &mut v };
    drop(x);
    x = Foo { v: &mut v };
}
```

Steps:
- [ ] List the changes in behaviour;
- [ ] Propose to t-lang to ratify them.
Repository: godot
Issue: Could not find base class "_BASE_" when creating script_templates
Labels: discussion,topic:gdscript,topic:editor,documentation,topic:thirdparty

### Godot version

4.1.stable.mono

### System information

EndeavourOS (Arch Linux) - Godot v4.1.stable.mono  - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3070 Ti (nvidia; 535.54.03) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

### Issue description

**Current Situation:**
Following the [doc](https://docs.godotengine.org/en/stable/tutorials/scripting/creating_script_templates.html)
When trying to create/use script templates, gd language server returns 
```
  Failed parse script res://editor/script_templates/<Node>/default.gd
  Could not find base class "_BASE_"
```
![image](https://github.com/godotengine/godot/assets/6231162/fb44faae-45c8-4594-9b8a-a50f2c526651)

Expected:
Godot to parse _BASE_ correctly and register the script template

### Steps to reproduce

- create script_template folder
- create Node folder
- create default.gd
- write a single line: 
```
extends _BASE_
```

### Minimal reproduction project
[BaseClassErrorReproduce.zip](https://github.com/godotengine/godot/files/11994899/BaseClassErrorReproduce.zip)

[Reproduction Project](https://drive.google.com/file/d/1ep098NPgqmFVElGY5PdlWyCoKrIUnMMn/view?usp=drive_link)

### Additional note:
I dont think the C# version works either, that when i attempt to rewrite the same logic in C# its returning 
```
The type or namespace name '_BINDINGS_NAMESPACE_' could not be found (are you missing a using directive or an assembly reference?)
```
Repository: opencv
Issue: Documentation of Audio support
Labels: category: documentation

### Describe the doc issue

There is no actual explanation of the audio facilities in OpenCV. I believe there ought to be.

Since 2021 there have been several contributions that enable OpenCV to read audio streams from media files. Some of the library releases even mention audio support and link to merged pull requests.

There is no `samples/videoio` directory or anything called "audio" in the `samples` directory itself. I have discovered relevant samples in `samples/dnn`, `samples/cpp`, `samples/python`.

On the docs site, when using the search function (top right), "audio" yields no results. It does not even list the `*_AUDIO_*` flags that exist in the `videoio` module. A substring search could have at least revealed those flags.

The Google search function embedded in the docs site yields results that _mention_ audio. There are no articles having "audio" in the _title_. There are no results explaining the audio facilities. The best result is the documentation of the Video I/O _flags_ related to audio. There is nothing beyond that. The remaining results mention "audio" in unrelated contexts (ffmpeg can..., art installation...).

The [documentation page for `VideoCapture`](https://docs.opencv.org/4.x/d8/dfe/classcv_1_1VideoCapture.html) does not mention "audio" at all.

The documentation on `VideoCapture::retrieve()` mentions a `flag` parameter. Neither its name nor its documentation even hint at the hidden ability to select an audio stream.

> **flag**: it could be a frame index or a driver specific flag

The [documentation page for `VideoCapture::VideoCaptureProperties`](https://docs.opencv.org/4.x/d4/d15/group__videoio__flags__base.html#ggaeb8dd9c89c10a5c63c139bf7c4f5704dab77093f3743970c0900c39e28dc9bac1) gives brief notes on those flags. I find those insufficient to guide me on their use. I would have to figure those out by trial and error, or by guessing their proper use from examples.

### Fix suggestion

I would like...

1. the search function to yield at least one result, when looking for "audio"
2. the API docs to mention "audio" and be descriptive about how to use the APIs related to audio
3. there to be an article that explains the concepts (primitives, operations) of reading audio with OpenCV's Video I/O, culminating in example code that showcases the APIs
Repository: rust
Issue: Inefficient codegen for `eq` of enum with identical variants
Labels: A-LLVM,I-slow,O-wasm,I-heavy

Given an enum:

```
type Pointer = *const ();
#[derive(PartialEq, Eq)]
pub enum MyEnum {
    A(Pointer),
    B(Pointer),
    C(Pointer),
    D(Pointer),
    E(Pointer),
    F(Pointer),
    Any,
}
```

The generated comparison uses jump table despite every jump target being identical:
https://godbolt.org/z/6nWW53eb5
As far as I'm aware, this jump should have been optimized away entirely, probably to something like
```diff
example::compare:
        mov     rax, qword ptr [rdi]
        cmp     rax, qword ptr [rsi]
        jne     .LBB0_1
        cmp     rax, 5
        ja      .LBB0_3
-        lea     rcx, [rip + .LJTI0_0]
-        movsxd  rax, dword ptr [rcx + 4*rax]
-        add     rax, rcx
-        jmp     rax
-.LBB0_5:
        mov     rax, qword ptr [rdi + 8]
        cmp     rax, qword ptr [rsi + 8]
        sete    al
        ret
```

With WASM target, it's even worse, as it doesn't deduplicate the identical match arms at all:
https://godbolt.org/z/Gf16rM4MY

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: stable-diffusion-webui
Issue: [Feature Request]: interrupt batch after
Labels: enhancement

### Is there an existing issue for this?

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

### What would your feature do ?

I can see similar but not actually this.

When doing a batch of images, when you click interrupt it just stops on that step. Is there a way for us to click interrupt and it stops it after that image has been rendered? I know skip just moves on to the next one. But I would like the ability to tell it to end early without the constant watching.

### Proposed workflow

1. Go to interrupt
2. Press right click
3. interrupt process after this image.


### Additional information

_No response_
Repository: godot
Issue: Gravity override of Area3D does not take transform into account
Labels: enhancement,discussion,topic:physics,topic:3d

### Godot version

4.0, 4.1

### System information

Godot v4.1.stable - macOS 13.4.1 - Vulkan (Forward+) - integrated Apple M2 - Apple M2 (8 Threads)

### Issue description

When applying a gravity with Area3D, any rotation to the area does not change the gravity vector. I am assuming this is a bug, because if you use the gravity point feature, that one takes the transform of the area into account (calculated in `servers/physics_3d/godot_area_3d.cpp:GodotArea3D::compute_gravity`; meaning the behavior between the two modes is inconsistent.

For some context as to how/why I'm using this: I have a rotating space station built out of segments and I want the gravity to be applied downwards in each segment. It would be trivial to just duplicate a single area and rotate it to each segment, but right now I have to calculate the correct downward vector, and if I start actually spinning the station that won't work.

I have a patch ready. I do not apply the scale to the gravity vector in my patch, but the case where a gravity point is specified does take the scale into account, I think. I would propose to additionally modify the gravity point mode to not take scale into consideration.

```patch
--- a/servers/physics_3d/godot_area_3d.cpp
+++ b/servers/physics_3d/godot_area_3d.cpp
@@ -327,9 +329,13 @@ void GodotArea3D::call_queries() {
 }
 
 void GodotArea3D::compute_gravity(const Vector3 &p_position, Vector3 &r_gravity) const {
+	// The value returns by get_gravity_vector is reused for the directional and point modes. When the gravity is
+	// specified with respect to a point, it is that point in local coordinate space. When the value is not a point,
+	// it represents the direction of the gravity vector in the local basis.
 	if (is_gravity_point()) {
 		const real_t gr_unit_dist = get_gravity_point_unit_distance();
 		Vector3 v = get_transform().xform(get_gravity_vector()) - p_position;
+		// The strength of the gravity falls off with distance to the specified point.
 		if (gr_unit_dist > 0) {
 			const real_t v_length_sq = v.length_squared();
 			if (v_length_sq > 0) {
@@ -338,11 +344,28 @@ void GodotArea3D::compute_gravity(const Vector3 &p_position, Vector3 &r_gravity)
 			} else {
 				r_gravity = Vector3();
 			}
+		// The strength of the gravity is the same in the whole area, it's just that the direction is with respect to
+		// the given point.
 		} else {
 			r_gravity = v.normalized() * get_gravity();
 		}
+	// The gravity value is just the gravity vector.
 	} else {
-		r_gravity = get_gravity_vector() * get_gravity();
+		r_gravity = get_transform().basis.xform(get_gravity_vector()).normalized() * get_gravity();
 	}
 }
```

### Steps to reproduce

Create an Area3D with a gravity vector, and rotate the Area3D. Notice that the gravity vector is not transformed according to the Area3D rotation.

### Minimal reproduction project

I don't think it's required. Problem is apparent from the diff in the description.
Repository: stable-diffusion-webui
Issue: hope to have a model viewer with higher operational efficiency.
Labels: enhancement

### Is there an existing issue for this?

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

### What happened?

When loading 200-500 models, such as .lora models, there is a significant delay when scrolling through the window, even after the loading process has completed and everything is functioning normally. When loading 500-1000 models, occasional long delays are encountered when switching between models, sometimes taking several minutes to load. In extreme cases, when testing with sample sizes exceeding 20,000, the web UI takes several minutes to initialize, and opening the model library to view covers takes over fifteen minutes. The covers fail to load, accompanied by occasional unresponsiveness, crashes when sharing links, and other issues. hope to have a model viewer with higher operational efficiency.

### Steps to reproduce the problem

This video showcases a test in extreme conditions (accessed on an Android device through sharing) where the server crashed.

https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/28691601/32985ead-fe2c-4560-9f65-22273f9a6845



### What should have happened?

Maybe it's as smooth as cutting through cream with a hot knife?

### Version or Commit where the problem happens

 version: v1.4.0  •  python: 3.10.11  •  torch: 2.0.0+cu118  •  xformers: 0.0.17  •  gradio: 3.32.0  •  checkpoint: 4d07c20218

### What Python version are you running on ?

Python 3.10.x

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

Windows, Android

### What device are you running WebUI on?

Nvidia GPUs (RTX 20 above)

### Cross attention optimization

xformers

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

Google Chrome

### Command Line Arguments

```Shell
no，The test results indicate that the issue occurs in all versions.
```


### List of extensions

no，The test results indicate that the issue occurs in all versions.

### Console logs

```Shell
no，The test results indicate that the issue occurs in all versions.
```


### Additional information

_No response_
Repository: PowerToys
Issue: FancyZones - Keyboard Shortcut to "Unsnap" & Return Windows to Original Size & Position
Labels: Idea-Enhancement,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

**FEATURE REQUEST - Enable a keyboard shortcut for to unsnap a window that has been snapped to a FancyZone and restore the window's original size and position.**  (Win-Shift-Home by default maybe?  Configurable, of course.)

With FancyZones, a window can be "unsnapped" from a zone by click-and-holding (grabbing) the title bar of the window and moving it slightly while holding the <SHIFT> key. (Or, if "Use a non-primary mouse button to toggle zone activation" is selected, by tapping a non-primary mouse button while dragging the title bar).

If the "Restore original size of windows when unsnapping" setting is enabled, the window returns to its original size.

It would be nice to have a keyboard shortcut for this "unsnap-and-restore" behavior.

Thank you for considering this request.

### Scenario when this would be used?

Sometimes I have windows arranged manually (not snapped to FancyZones) and I occasionally want them to snap to a FancyZone for a period of time, then return them to their original size and position.  I'd like to be able to do this with the keyboard.  I can snap them with the keyboard today (with the "Override Windows Snap" set to "On" and "Move windows based on" setting set to "Relative Position"").  But I can't unsnap them with the keyboard,  So I've got to go to my mouse to do this, which interrupts my workflow and, more generally, makes FancyZones less accessible for keyboard-only users. 

### Supporting information

_No response_
Repository: pytorch
Issue: Implement `diag` method for sparse COO tensors
Labels: module: sparse,triaged

### 🚀 The feature, motivation and pitch

## Feature
To implement `diag` method for sparse coo tensors. Currently it raises `NotImplementedError`.

## Motivation
Given a 1-d sparse tensor, I want to make a diagonal out of it to use it in matrix multiplications then.

### Alternatives

Given 1-d sparse tensor `t`, I do:

```python
torch.sparse_coo_tensor(t.indices().repeat(2, 1), t.values())
```

Thankfully, this alternative preserves grad operations, if `t.requires_grad=True`.


### Additional context

_No response_

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer
Repository: godot
Issue: When I debug/breakpoint while connected as a peer, it soon disconnects
Labels: discussion,topic:editor,topic:network

### Godot version

4.1

### System information

Artix (Arch Linux)

### Issue description

Like everyone, I often place breakpoints in the code to find bugs. So you place a breakpoint, watch the values in locals and press F10 slowly to find out where logic is flawed. If you do this for 8 seconds or so, **connection times out**, and if you continue (e.g. F7), game is ultra broken and spammed with essentially this error:
![multiplayer-instance](https://github.com/godotengine/godot/assets/25630803/854a2c37-b289-46d9-ae28-ed5c01c4f04a)

[Video of localhost with 3 players](https://files.catbox.moe/pnnc0b.mkv)

Now, here is an interesting point. If I place the breakpoint on the host/server, and timeout happens, it disconnects all clients (as shown in the above video), but if I place the breakpoint on a client, just the client times out (and theoritically the game is salvageable)

This bug is **not exclusive to localhost,** I did port forwarding to play with a friend far away, and if a breakpoint hits, I have to swiftly continue/F7 so the game won't disconnect for either of us.

If I had to suggest a solution, it would be that on breakpoint, the classic packet ping overrides the pause of godot, so the connection doesn't break. That is, if it doesn't do that by default 

### Steps to reproduce

1. Debug -> Run Multiple Instances -> 2
2. Start the game, host locally with 1 instance, join with any other
3. Place breakpoint on some RPC
4. Trigger above^ RPC
5. Wait like 8seconds
6. Any function inheriting from **multiplayer.** will not work because the instance is deactivated.

### Minimal reproduction project

Look below.
Repository: rust
Issue: Trait resolution stress test.
Labels: A-type-system,C-enhancement,T-types,WG-trait-system-refactor

I have implemented chess in the Rust type system. This requires a massive amount of trait resolution. On my machine running `cargo test` takes about 10 minutes. Nearly 100% of that time would be spent resolving traits.

I don't know if this is something that is needed but I figured it could be a great way to track compiler performance on trait resolution/a way to look for potential performance improvements.

The amount of time taken can easily be scaled by adding or removing tests.

https://github.com/Dragon-Hatcher/type-system-chess
Repository: puppeteer
Issue: [Bug]: Page.screencastFrame is not respecting viewport under new headless
Labels: bug,upstream,confirmed

### Minimal, reproducible example

```js
const { setTimeout } = require('timers/promises')
const puppeteer = require('puppeteer')

;(async () => {
  const browser = await puppeteer.launch({ headless: 'new' })

  const page = await browser.newPage()

  const client = page._client()

  let count = 0
  client.on('Page.screencastFrame', async ({ data, metadata, sessionId }) => {
    require('fs').writeFileSync(`/tmp/frames/${count++}.png`, Buffer.from(data, 'base64'))
    client.send('Page.screencastFrameAck', { sessionId }).catch(() => {})
  })

  await client.send('Page.startScreencast')

  await page.goto('https://example.com')
  await page.evaluate(() => new Promise(resolve => setTimeout(resolve, 5000)))

  await client.send('Page.stopScreencast')
  await browser.close()
})()
```

### Error string

no error

### Background

without passing `{ headless: 'new' }`:

![1](https://github.com/puppeteer/puppeteer/assets/2096101/ff3e0f6b-6eca-4478-ba53-edcf2e7e6fc1)

passing `{ headless: 'new' }`:

![2](https://github.com/puppeteer/puppeteer/assets/2096101/71788a79-ee82-4cf9-b38c-8257eacfc388)


### Expectation

The screenshotted frame should be the same.

### Reality

They are different.

### Puppeteer configuration

_No response_

### Puppeteer version

20.8.0

### Node version

20.4.0

### Package manager

pnpm

### Package manager version

8.4.0

### Operating system

macOS
Repository: node
Issue: Errors emitted on worker are not native errors
Labels: errors,worker

### Version

20.4.0

### Platform

Darwin user 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 arm64 arm Darwin

### Subsystem

worker_threads

### What steps will reproduce the bug?

```js
import {Worker} from 'node:worker_threads'
import {once} from 'node:events'
import types from 'node:util/types'

const worker = new Worker('setImmediate(() => { throw new Error("error"); })', {eval: true})
const [error] = await once(worker, 'message')

console.log(error instanceof Error) // true
console.log(types.isNativeError(error)) // false
```

### How often does it reproduce? Is there a required condition?

Always, as long as the error is emitted by the `error` event on the worker. Any errors sent via `postMessage()` are identified correctly.	

### What is the expected behavior? Why is that the expected behavior?

`types.isNativeError()` returns `true` for the emitted error.

### What do you see instead?

`types.isNativeError()` returns `false` for the emitted error.

### Additional information

The problem seems to be in the error deserialization: https://github.com/nodejs/node/blob/eece8d755c69d393a7bcc14f9c9454020d91ed1d/lib/internal/error_serdes.js#L172

Reading the code, I believe it's roughly equivalent to:

```js
const error = Object.create(Error.prototype, {message:{value:'foo'}})
```

According to the [spec](https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-properties-of-error-instances), merely extending the error prototype does not create a native error.

Of course, because it does extend the Error prototype, `error instanceof Error` returns `true`.

I don't have the context for why the serialization is so complex, but FWIW the built-in `v8` serde does result in proper native error objects.
Repository: TypeScript
Issue: Support "jump to" for literal record keys
Labels: Help Wanted,Possible Improvement

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

- jump to record key

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [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 feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->

Record keys should support "Jump to definition" actions.

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

```ts
type Something = { field: string };

type Somethings<Keys extends string> = Record<Keys, Something>;

type ContainerOfSomethings = Somethings<'a' | 'b'>;

const container: ContainerOfSomethings = {
    a: { field: 'a' },
    b: { field: 'b' }
};

console.log(container.a);
                     // ^---- "Jump to" should bring me to line 5 where 'a' is listed
```

[Playground Example](https://www.typescriptlang.org/play?ts=5.2.0-beta#code/C4TwDgpgBAyg9gWwsAFgSwHYHMoF4oDeUAZmhADYAmAXFAM7ABOmOAvgNwBQnoksiydNjoAeANIQQdKBAAewCBkrSGzbAD48UAEoQAxnEaVxkugBp+SVC3Vce4aAGE4GYAENMERgHli8K0JY0vj+giyiAORuEVAAPlARAEYRttwGGAxQ6e6ejLTOrh4YXr6h1sJaBJxQNVButESkFDQJ0VCsZtW1iQ0kZFS0STGsnBxpLnRw5BAAdORwWAAU2UVeM24AlFy1O7t7tQD0B1AAegC0F2dQAEQAUgCuCGBQwHDX9Chw91RQiWo4SBecCg5E8UAArFAAO4oLzQKIxNDSUEMCCUIA)

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

Enhance Developer Experience.