sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: [Bug]: Infinite loop when adding an iframe to the DOM using devtools when devtools protocol is active
Labels: bug :beetle:,platform/all,status/confirmed,has-repro-gist,32-x-y,33-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

32.1.1

### What operating system(s) are you using?

Windows

### Operating System Version

Windows 11 Enterprise 22H2

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

When having activated the devtools protocol, an iframe that's injected to the DOM using devtools by running: 
```
const ifr = document.createElement('iframe');

document.body.appendChild(ifr);
```

should successfully inject it once without sideeffects.

### Actual Behavior

When having activated the devtools protocol, an iframe that's injected to the DOM using devtools by running: 
```
const ifr = document.createElement('iframe');

document.body.appendChild(ifr);
```

is creating an infinite loop, causing the eventloop to be completely blocked in the related renderer process.

### Testcase Gist URL

https://gist.github.com/41184d95ea650b5337f5dcba4afa7317

### Additional Information

- The problem happens both when on a local file (index.html) or an external page loaded with loadURL.
- If the injection happens within a setTimeout, this problem does not occur.
- If the injection happens in a script tag in the html file, this problem does not occur.
- If injection happens from sending a protocol command like `Runtime.evaluate` this problem does not occur.
- If injection happens from sending a protocol command like `Runtime.compileScript` and then `Runtime.runScript` this problem does not occur.

The issue seems to be limited to it being executed within devtools. However this is also able to be reproduced with webdriverio when injecting the script with executeAsync.
Repository: deno
Issue: deno compile error [ERR_TYPES_NOT_FOUND]
Labels: compile,types

deno 2.0.0-rc.4 (release candidate, release, aarch64-apple-darwin)
v8 12.9.202.13-rusty
typescript 5.6.2

```
{
  "name": "test_deno",
  "version": "1.0.0",
  "main": "index.js",
  "description": "",
  "devDependencies": {
    "eslint-plugin-vue": "^9.28.0"
  }
}

```

```
import plugin from "eslint-plugin-vue";
```

```
➜  test_deno deno compile main.ts
error: Failed resolving types. [ERR_TYPES_NOT_FOUND] Could not find types for 'file:///Users/XXXX/test_deno/node_modules/eslint-plugin-vue/index.js' imported from 'file:///Users/zhouqili/test_deno/main.ts'
    at file:///Users/XXXX/test_deno/main.ts:1:20
```
Repository: transformers
Issue: support schedule sampling
Labels: trainer,Feature request

### Feature request

To solve the exposure bias problem, can schedule sampling be supported?
https://arxiv.org/abs/1906.07651
https://github.com/deep-spin/scheduled-sampling-transformers

### Motivation

For the same data, the training loss is very low but the inference result is not good.

### Your contribution

no
Repository: vscode
Issue: SCM Graph - add "share" and "vscode.dev" actions to the history item context menu
Labels: feature-request,scm

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Repository: rust
Issue: Error when unsizing types with thin pointers that turn fat
Labels: A-diagnostics,T-compiler

### Code
```rust
use std::fmt::Debug;

struct ListItem<T: ?Sized> {
    next: Option<Box<Self>>,
    item: T,
}

fn main() {
    let _ = Box::new(ListItem {
        next: None,
        item: [42, 24],
    }) as Box<ListItem<dyn Debug>>;
}
```

### Current output
```text
error[E0605]: non-primitive cast: `Box<ListItem<[i32; 2]>>` as `Box<ListItem<dyn Debug>>`
  --> src/main.rs:9:13
   |
9  |       let _ = Box::new(ListItem {
   |  _____________^
10 | |         next: None,
11 | |         item: [42, 24],
12 | |     }) as Box<ListItem<dyn Debug>>;
   | |__________________________________^ an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object

For more information about this error, try `rustc --explain E0605`.
error: could not compile `playground` (bin "playground") due to 1 previous error
```
### Desired output
```text
error[E????]: type `Box<ListItem<[i32; 2]>>` cannot be unsized to `Box<ListItem<dyn Debug>>`
  --> src/main.rs:9:13
   |
9  |       let _ = Box::new(ListItem {
   |  _____________^
10 | |         next: None,
11 | |         item: [42, 24],
12 | |     }) as Box<ListItem<dyn Debug>>;
   | |__________________________________^
note: the struct `ListItem<[i32; 2]>` would change size if unsized to `ListItem<dyn Debug>`
3  │ struct ListItem<T: ?Sized> {
4  │     next: Option<Box<Self>>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^ this field's type would change from a thin pointer to a fat pointer
5  │     item: T,
6  │ }

For more information about this error, try `rustc --explain E????`.
error: could not compile `playground` (bin "playground") due to 1 previous error
```
### Rationale and extra context

_No response_

### Other cases
```rust
// Removing the `next` field makes the code compile:

use std::fmt::Debug;

struct ListItem<T: ?Sized> {
    // next: Option<Box<Self>>,
    item: T,
}

fn main() {
    let _ = Box::new(ListItem {
        // next: None,
        item: [42, 24],
    }) as Box<ListItem<dyn Debug>>;
}
```
### Rust Version
```text
rustc 1.83.0-nightly (6c6d21008 2024-09-22)
binary: rustc
commit-hash: 6c6d210089e4589afee37271862b9f88ba1d7755
commit-date: 2024-09-22
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0
```
### Anything else?

If more information/explanation is needed, I can provide it, just ask.
Repository: TypeScript
Issue: IsolatedDeclarations: emitted declarations inconsistent between `transpileDeclaration` API and TypeScript Playground
Labels: Needs Investigation

### Acknowledgement

- [X] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

### Example

> NOTE: Enabled `isolatedDeclaration` and `noCheck`

[Playground Link](https://www.typescriptlang.org/play/?target=99&isolatedDeclarations=true&noCheck=true#code/JYWwDg9gTgLgBAbzgYQiEBTAdvAvnAMyjTgHIABANwFcMB6KanUDAWgGNoNSAoHjAB6RYcTlgDO8YONTps8ALxwAFFggATDAC44AOQ0YAlDrWa40lGkw44CgHw84cUxgB0LgCoBPMBlsKlABEAeQBZfU1vX3FXZDDQgFFdDyA)

```ts
// input
import { Comment } from '@vue/runtime-core'
//       ^^^^^^^ https://github.com/vuejs/core/blob/a177092754642af2f98c33a4feffe8f198c3c950/packages/runtime-core/src/vnode.ts#L70
export const comment: Comment 

// .d.ts output
export declare const comment: Comment;
```

This example is correct because the `tsc` checker analyzer `Comment` is a const variable defined in `@vue/runtime-core`. So the `Comment` who referenced by `comment` is actually referenced [lib.dom.d.ts](https://github.com/microsoft/TypeScript/blob/88809467e8761e71483e2f4948ef411d8e447188/src/lib/dom.generated.d.ts#L5811-L5822)'s `Comment`. But the output of this example in `transpileDeclaration` APi will same as the following example.

### Another example

> NOTE: Enabled `isolatedDeclaration` and `noCheck`


[Playground Link](https://www.typescriptlang.org/play/?target=99&isolatedDeclarations=true&noCheck=true#code/JYWwDg9gTgLgBAbzgYQiEBTAdvAvnAMyjTgHIATCDAZwFosIZaMAPYamUgKFcljgDGELB0FpMOAFwpx2eEA)

```ts
// input
import { Comment } from 'does-not-exist'
export const comment: Comment 

// .d.ts output
import { Comment } from 'does-not-exist';
export declare const comment: Comment;
```

This example is also correct because the `tsc` checker can't analyze what `Comment` is, so the `Comment` was kept in the output as it has been referenced by `comment`. 

But If I want to use [lib.dom.d.ts](https://github.com/microsoft/TypeScript/blob/88809467e8761e71483e2f4948ef411d8e447188/src/lib/dom.generated.d.ts#L5811-L5822)'s `Comment` rather than imported it will be incorrect.

### Expect Behaviour

In `IsolatedDeclarations`, Ideally, we shouldn't analyze imports, but if we stop analyzing, this will generate incorrect output. 

So I suggest `tsc` should throw an error about the above cases when `IsolatedDeclarations` is enabled. This is also beneficial for third-party `IsolatedDeclarations` implementations. 

BTW this issue I found when I fix the output mismatch between `oxc-isolated-declarations` and `tsc`
Repository: node
Issue: Stream not destroyed when piped in Duplex.from() writable
Labels: confirmed-bug,stream

### Version

v22.9.0

### Platform

```text
Darwin MBPM.local 24.0.0 Darwin Kernel Version 24.0.0: Mon Aug 12 20:52:31 PDT 2024; root:xnu-11215.1.10~2/RELEASE_ARM64_T6030 arm64
```


### Subsystem

stream

### What steps will reproduce the bug?

```js
const { Duplex, Readable, pipeline } = require('node:stream')

pipeline(
  Readable.from(
    (async function* () {
      try {
        console.log('Readable stream started')
        let i = 32
        while (i-- > 0) {
          yield Buffer.from('Hello, world!')
          console.log('Readable stream resumed')
        }
        console.log('Readable stream ended')
      } catch (err) {
        console.log('Readable stream errored', err)
      } finally {
        console.log('Readable stream destroyed')
      }
    })(),
    { objectMode: false, autoDestroy: true, highWaterMark: 1 }
  ),
  Duplex.from(async function (asyncGenerator) {
    asyncGenerator.return()
  }),
  (err) => {
    if (err) {
      console.error('Pipeline failed', err)
    } else {
      console.log('Pipeline succeeded')
    }
  }
)
```

### How often does it reproduce? Is there a required condition?

Any code used as `Duplex.from(async function () {})` that does not fully consume the input will prevent the input stream to be properly disposed:

```js
  Duplex.from(async function (asyncGenerator) {
    for await (const chunk of asyncGenerator) {
      console.log('Writable stream received', chunk)
      break
    }
  })
```

```js
  Duplex.from(async function (asyncGenerator) {
    asyncGenerator.retrun()
  })
```

```js
  Duplex.from(async function (asyncGenerator) {
    // do nothing
  })
```



### What is the expected behavior? Why is that the expected behavior?

The readable's destroy steps should be called.

### What do you see instead?

The readable is not destroyed.

### Additional information

_No response_
Repository: tauri
Issue: [bug] [ios] [v2] Export method does not work
Labels: type: bug,status: needs triage,platform: iOS

### Describe the bug

Running ` npm run tauri ios build -- --export-method app-store-connect` does not export the app for AppStore. I need to change ExportOptions.plist directly to get it to build correctly.

- Automatic signing is set for all targets.

### Reproduction

` npm run tauri ios build -- --export-method app-store-connect` then try to submit to the AppStore via the Transporter App. "Asset validation failed (90161)
Invalid Provisioning Profile. The provisioning profile included in the yyy bundle [Payload/yyy.app] is invalid. [Missing code-signing certificate]. A distribution provisioning profile should be used when uploading apps to App Store Connect. (ID: xxx)"



### Expected behavior

`--export-method app-store-connect` to work correctly.


### Full `tauri info` output

```text
> tauri info


[✔] Environment
    - OS: Mac OS 14.7.0 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 20.17.0
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.0.0-rc.15
    - tauri-build 🦀: 2.0.0-rc.12
    - wry 🦀: 0.43.1
    - tao 🦀: 0.30.0
    - @tauri-apps/api : 2.0.0-rc.5
    - @tauri-apps/cli : 2.0.0-rc.16

[-] Plugins
    - tauri-plugin-window-state 🦀: 2.0.0-rc.5
    - @tauri-apps/plugin-window-state : not installed!
    - tauri-plugin-store 🦀: 2.0.0-rc.3
    - @tauri-apps/plugin-store : not installed!
    - tauri-plugin-log 🦀: 2.0.0-rc.2
    - @tauri-apps/plugin-log : not installed!
    - tauri-plugin-shell 🦀: 2.0.0-rc.3
    - @tauri-apps/plugin-shell : not installed!
    - tauri-plugin-dialog 🦀: 2.0.0-rc.7
    - @tauri-apps/plugin-dialog : not installed!
    - tauri-plugin-notification 🦀: 2.0.0-rc.5
    - @tauri-apps/plugin-notification : not installed!
    - tauri-plugin-fs 🦀: 2.0.0-rc.5
    - @tauri-apps/plugin-fs : not installed!

[-] App
    - build-type: bundle
    - frontendDist: ../src

[-] iOS
    - Developer Teams: <Redacted>
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: ant-design
Issue: Select: add option data to labelRender props
Labels: 💡 Feature Request,Inactive,🧶 Low Priority

### What problem does this feature solve?

I want to render the label with additional data from the option, not only label and value.

### What does the proposed API look like?

same as "optionRender"

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: compiletest: warn/error on redundant `check-fail` directives
Labels: C-enhancement,T-bootstrap,E-medium,A-compiletest

> check-fail here is redundant

_Originally posted by @compiler-errors in https://github.com/rust-lang/rust/pull/130718#discussion_r1770625658_
            
Some test suites have a *default* test behavior, like `//@ check-fail`, in which case specifying that explicitly in the test is redundant and useless noise. When compiletest directive handling is worked, we should warn or error on redundant directives like these and also explain *why* it's redundant, e.g. "ui test mode is check-fail by default".

Remark: this check should not be added before reworking how compiletest directives are handled as it's not just one test suite or directive.
Repository: vscode
Issue: [html] Vscode detect wrong scope for script with type=module
Labels: bug,html

Type: <b>Bug</b>

1.  create simple html file

        <!DOCTYPE html>
        <html>
        <head>
            <script>let a = 10;</script>
            <script type="module">let a = 10;</script>
        </head>
        </html>

2. get wrong "problems" message: Cannot redeclare block-scoped variable 'a'.

![image](https://github.com/user-attachments/assets/4cffb27c-76f8-4a16-9087-f49ea97bc3f8)
![image](https://github.com/user-attachments/assets/ef336283-9989-4af3-ae86-83a6f2c38aa0)

### Expected behavior

No problems, because script with type="module" have own scope, so in this case no redelared variable.

VS Code version: Code 1.93.1 (38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40, 2024-09-11T17:20:05.685Z)
OS version: Windows_NT x64 10.0.19045
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|AMD FX(tm)-8350 Eight-Core Processor            (8 x 3991)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|15.97GB (3.94GB free)|
|Process Argv|--disable-extensions --crash-reporter-id d754423a-bca8-4bd8-88a2-702aab8631b1|
|Screen Reader|no|
|VM|0%|
</details>Extensions disabled<details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonnoceb:30805159
asynctok:30898717
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
accentitlementst:30995554
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
bdiig495:31013172
a69g1124:31058053
dvdeprecation:31068756
dwnewjupyter:31046869
impr_priority:31102340
nativerepl1:31139838
refactort:31108082
pythonrstrctxt:31112756
flighttreat:31134774
wkspc-onlycs-t:31132770
wkspc-ranged-t:31125599
pme_test_t:31118333
fje88620:31121564

```

</details>

<!-- generated by issue reporter -->
Repository: flutter
Issue: [two_dimensional_scrollables] : Proposal to add `shrinkWrap` to `TableView`
Labels: c: new feature,framework,package,c: proposal,P3,team-framework,triaged-framework,p: two_dimensional_scrollables

### Use case

[two_dimensional_scrollables]

### Proposal

If you can provide a shrinkWrap parameter like a listview, I'd like to put the tableview into a Column. I will be very grateful to you
Repository: godot
Issue: [.Net / GDScript Interop] Cannot Call GDScript-Lambda-Backed `Callable` in C#
Labels: bug,topic:core,topic:gdscript,needs testing,topic:dotnet

### Tested versions

v4.3.stable.mono.official [77dcf97d8]

### System information

Godot v4.3.stable.mono - Windows 10.0.17763 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4060 Ti (NVIDIA; 32.0.15.6109) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)

### Issue description

This is a niche use case, but we should document it if it's not supported.

In C# script, when trying to `Call()` a `Callable` that is backed by a `GDScript` `Lambda Expression`, Godot will produce the following error instead of actually making the call.

```
E 0:00:00:0894   main.gd:4 @ _ready(): Attempt to call callable 'null::null' on a null instance.
  <C# Source>    /root/godot/modules/mono/glue/GodotSharp/GodotSharp/Core/NativeInterop/ExceptionUtils.cs:160 @ void Godot.NativeInterop.ExceptionUtils.DebugCheckCallError(Godot.NativeInterop.godot_callable&, Godot.NativeInterop.godot_variant**, int, Godot.NativeInterop.godot_variant_call_error)
  <Stack Trace>  main.gd:4 @ _ready()
```

### Steps to reproduce

1. Create a C# Godot Project.
2. Create `main.gd`.
3. Create a scene, attach the `main.gd` to the root node, and save it to a file.
4. Create `Helper.cs`.
5. Run the project.

### Minimal reproduction project (MRP)

**main.gd**

```gdscript
extends Node

func _ready():
	Helper.new().CallCallable(func(): print("Hello World"));
```

**Helper.cs**

```csharp
using Godot;

[GlobalClass]
public partial class Helper : Node
{
    public void CallCallable(Callable callable) => callable.Call();
}
```
Repository: go
Issue: crypto: drop pre-AVX2 amd64 assembly
Labels: NeedsDecision

AVX2 was introduced in 2013 by the Haswell architecture, and was supported by all server models and most desktop models. The previous architectures, Ivy Bridge and Sandy Bridge, were discontinued in 2015.

We carry at least four assembly optimized implementations specifically for pre-AVX2 amd64: crypto/sha1, crypto/sha256, crypto/512, and x/crypto/chacha20poly1305. (In other words, we have *both* AVX2 and pre-AVX2 assembly for each of those.) I don't think at this point they are worth their maintenance cost. Performance sensitive workloads are almost certainly running on post-2015 processors.

I think we should drop those assembly implementations and replace them with the generic Go ones. To be clear, we'll still *support* pre-AVX2 machines, they will just be less optimized.

/cc @golang/security @cpu
Repository: pytorch
Issue: Any updates on AsyncCollectiveTensor support for all-gather along non-zero dims?
Labels: oncall: distributed

https://github.com/pytorch/pytorch/blob/e9bfbf78d5d89df1ec59cb82d7f78b85f9014a98/torch/distributed/_functional_collectives.py#L208

cc @XilunWu @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o
Repository: ui
Issue: [bug]: ThemeProvider component does not listen to live color scheme preference changes
Labels: bug

### Describe the bug

The [ThemeProvider component](https://ui.shadcn.com/docs/dark-mode/vite) in the docs does not listen to changes to the user's preference. If the user changes their color scheme preference in their browser/system, they have to refresh the app to get the updated theme.

### Affected component/components

Docs/Dark mode/ThemeProvider

### How to reproduce

1. Go to https://ui.shadcn.com/docs/dark-mode/vite.
2. The code snippet can be found under `Dark mode > 1. Create a theme provider`.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
N/A
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: vscode
Issue: Hide the update button from extension view when the extension is disabled globally
Labels: feature-request,extensions

I was cleaning up my extensions just now and I have this action to update an extension that's disabled:

![Image](https://github.com/user-attachments/assets/57c43ab0-9092-4789-826a-d266c83ebeb8)

Since it's disabled, shouldn't we hide this? I only enable this extension when I'm using the application in question and would expect to update it only when I re-enable it, otherwise I would clikc update, and then maybe need to click it to "dismiss" the update button every week.

I see disabling as a slightly more convenient version of uninstalling if I plan on using it again, such that I don't need to go find it again via search. We could still keep the update in the extension details as the user is drilling in:

![Image](https://github.com/user-attachments/assets/1951b163-aa2c-4e39-845c-dbba076e21d7)