sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Issue Reporter doesn't show me any errors when submitting doesn't work
Labels: bug,issue-reporter

<!-- ⚠️⚠️ 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

I'm banned/blocked from doing anything in a Github organization, so when I was trying to report an issue to one of that org's repos, pressing the "Create on GitHub" button didn't do anything. I think it doesn't work because I'm banned/blocked, so I expect the Issue Reporter to show me an error.

<!-- 🪓 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.85.1 (user setup)
- OS Version: Windows_NT x64 10.0.22621

Steps to Reproduce:

1. Get banned/blocked from a repo/org
2. Try to submit an issue for an extension with the Issue Reporter
3. Now, when you try to submit, it won't work and it won't show you any errors.

![image](https://github.com/microsoft/vscode/assets/44144724/cd0b3d9c-acb6-449b-ad8b-4dd68850eb32)

---

```
Version: 1.85.1 (user setup)
Commit: 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2
Date: 2023-12-13T09:49:37.021Z
Electron: 25.9.7
ElectronBuildId: 25551756
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.22621
```
Repository: godot
Issue: GPUParticles3D billborad emission not shown when not facing light
Labels: topic:rendering,documentation,topic:3d,topic:particles

### Tested versions

v4.2.stable.official [46dc27791]

### System information

Godot v4.2.stable - Windows 10.0.19045 - Vulkan (Forward+) 

### Issue description

GPUParticles3D billborad emission not shown when not facing light

facing light can see the emission:
![圖片](https://github.com/godotengine/godot/assets/24987226/490f256d-67d5-4115-a8ba-ef5210429525)

not facing light:
![圖片](https://github.com/godotengine/godot/assets/24987226/9c621cc4-5ac1-484a-b4ef-4ef858e38575)


### Steps to reproduce

I have made 2 nodes
1 is a simple quad MeshInstance3D with StandardMaterial3D emission material and billboard turn on.
It has emission no matter if is it facing directional light.

Another 1 is GPUParticles3D, I set the similar material with emission material and billboard turn on
But it doesnt have the emission effect when not facing light. (see above comparison)

One thing I found is, for the MeshInstance3D , I have set the color in emission
![圖片](https://github.com/godotengine/godot/assets/24987226/d1c41b37-1aa4-42b2-b5f3-9cb51be280a1)

while in particle3D, I dont
![圖片](https://github.com/godotengine/godot/assets/24987226/fab40d6b-26fe-44d3-886e-06ca2e0bb5f7)

The reason is I want the color is controlled from the particle.
Once I set the emission color, I lost the control from the particle.


### Minimal reproduction project (MRP)

[particle_billboard_emission_bug.zip](https://github.com/godotengine/godot/files/13803705/particle_billboard_emission_bug.zip)
Repository: next.js
Issue:  <script> doesn't work on production when i use app router
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/vercel-next-js-reproduction-template-go8s7s?file=%2Fapp%2Flayout.tsx


### To Reproduce

<img width="756" alt="스크린샷 2024-01-01 오후 4 34 19" src="https://github.com/vercel/next.js/assets/63283076/c5ae6124-c3da-4455-b7f2-b737e9cfe040">


### Current vs. Expected behavior

I can check hello world on dev version but not production

### 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 23.2.0: Wed Nov 15 21:53:34 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T8103
Binaries:
  Node: 18.19.0
  npm: 10.2.3
  Yarn: 1.22.19
  pnpm: 8.6.5
Relevant Packages:
  next: 14.0.5-canary.33
  eslint-config-next: 14.0.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router

### Additional context

_No response_
Repository: TypeScript
Issue: Start following semantic versioning
Labels: Discussion

### 🔍 Search Terms

`semantic versioning`

### ✅ Viability Checklist

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

### ⭐ Suggestion

Start following semantic versioning from now on.

I know TypeScript currently doesn't follow semantic versining, and push breaking changes for every minor version. I could not find any mention as to why it is the case.

There is no reason TypeScript *cannot* follow semantic versioning. There is simply no other major library that doesn't follow semantic versioning in NPM ecosystem. There is also no problem with pushing major version every other months. It just means the version will be incrementing a lot quicker. It means it follows the ecosystem's standard and more predictable for a lot of people.

### 📃 Motivating Example

- Version update is more predictable and follows standard of the Node.js/npm ecosystem. 
- You no longer have to change `^x.y.z` to `~x.y.z` every time you run `npm i -D typescript`

### 💻 Use Cases

1. What do you want to use this for?
   - More predictable and standard versioning when installing TypeScript
2. What shortcomings exist with current approaches?
   - Non-standard versioning in the ecosystem
4. What workarounds are you using in the meantime?
   - Change `^` to `~` in the version specifier
Repository: godot
Issue: When exporting to Meta(Oculus) Quest 2 and running in it, The scene appears rotated 90 degrees on the Y axis.
Labels: bug,topic:porting,topic:xr,topic:3d

### Tested versions

v4.2.1.stable.mono.official

### System information

Windows 11 Pro 22H2, Meta(Oculus) Quest 2, C#

### Issue description
![scene1](https://github.com/godotengine/godot/assets/88044346/cd45a1c7-07a1-4a10-a74f-e82df5ea3d7a)
The position of the sphere is Vector3(0, 0, -5).
When I run it in Meta Quest 2, I see the sphere on the right side.
The scene or camera has been rotated.

[Output Console]
0 param: --remote-debug
1 param: tcp://localhost:6007
2 param: --xr_mode_openxr
3 param: --use_immersive
Uninstalling previous version: Oculus Quest 2
Installing to device (please wait...): Oculus Quest 2
--- Device API >= 21; debugging over USB ---
--- DEVICE API >= 21; DEBUGGING OVER USB ---
Reverse result: 0

[ADB Log]
OVRLibrary null cursor received for query content://com.oculus.ocms.library/apps/com.example.vrtest

### Steps to reproduce

1  Open main.tscn in the MRP.

2 Follow the documentation and tutorial video in the link below.

Exporting for Android
https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_android.html

Getting Started with OpenXR in Godot
https://youtu.be/shbHGhkh4NM?si=LyxELXnidOaWal4n

  - Install OpenJDK 17

  - Install Android Studio and Run
    - SDK Manager /
      - Android SDK Platform: 33
      - Android SDK Build-Tools: 33.0.2
      - Android SDK Command-line Tools: latest
      - Android SDK Platform-Tools: latest
      - CMake: 3.10.2.4988404
      - NDK: 23.2.8568313
  
- Godot Editor
  - Choose a renderer: Compatibility
  - Menu / Editor / Manage Export Templates... / Download and Install
  - AssetLib / Godot OpenXR Vendors plugin / Download and Install
  - Menu / Project / Project Settings / Plugins / GodotOpenXRVendors [v] Enable
  - Menu / Project / Install Android Build Templates
  - Menu / Editor / Editor Settings / Export / Android /
    - Android SDK Path:
    - One Click Deploy Clear Previous Install: [v] On
  - Menu / Debug / Deploy with Remote Debug [v]

3 Connect to Meta Quest 2 with a USB cable.

4 Press the Remote Debug button on the top right and wait.

### Minimal reproduction project (MRP)

[Godot 4.2.1 VR Test.zip](https://github.com/godotengine/godot/files/13804389/Godot.4.2.1.VR.Test.zip)
Repository: vscode
Issue: Laggy rendering all around with GPU enabled
Labels: upstream,windows,gpu,chromium

Type: <b>Bug</b>

Hovering over menus and scrolling editors is noticeably laggy (somewhere around 100ms delay I would guess).

This is on an NVidia Geforce 1080 Ti with latest drivers (536.23), so there's certainly enough "ooomph".

All extensions are disabled.

When starting VSCode with `--disable-gpu`, everything is nice and snappy again (rendering at full 60FPS all the time).

VS Code version: Code 1.85.1 (0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2, 2023-12-13T09:49:37.021Z)
OS version: Windows_NT x64 10.0.19045
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|13th Gen Intel(R) Core(TM) i9-13900K (32 x 2995)|
|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>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled|
|Load (avg)|undefined|
|Memory (System)|63.77GB (39.64GB free)|
|Process Argv|--disable-extensions|
|Screen Reader|no|
|VM|0%|
</details>Extensions disabled
<!-- generated by issue reporter -->
Repository: godot
Issue: Unexpected result when using `String.split()` with `allow_empty=false` and `maxsplit=1`
Labels: discussion,topic:core

### Tested versions

- Reproducible in 4.2.1.stable

### System information

Windows 10 - Godot 4.2.1.stable - gdscript

### Issue description

# Unexpected result when using `String.split()` with `allow_empty=false` and `maxsplit=1`

When the string `"<>One<>Two<>Three"` is split by `"<>"` with `allow_empty=true` and `maxsplit=1`, it is expected that the resulting array is `["", "One<>Two<>Three"]`.

However, when `allow_empty=false`, I would expect that the same split would result in the same array with the leading empty string item removed.  This is not the case and the resulting array is `["One", "Two<>Three"]`, which means that two splits have been made even though the `maxsplit` had been set to 1.

### Steps to reproduce

Run the scene of the provided MRP
Check the terminal output

### Minimal reproduction project (MRP)

[string-split-issue.zip](https://github.com/godotengine/godot/files/13804837/string-split-issue.zip)
Repository: excalidraw
Issue: Whitelist Cawemo URL
Labels: Embeddable

Hello, 

Currently, no tool allows you to combine BPMN (using https://bpmn.io/ for example) and other diagrams.

Would it please be possible to whitelist the URL of the cawemo.com tool? 

Thanks.
J.
Repository: svelte
Issue: Eliminate unnecessary `if` statements
Labels: perf

### Describe the problem

Consider the following code:
```
{#if iconData}
	{#if iconData.paths}
		{#each iconData.paths as path}
			<path {...path} />
		{/each}
	{/if}
{/if}
```

It could be rewritten as:
```
{#each iconData?.paths || [] as path}
	<path {...path} />
{/each}
```

This will save a larger amount of code than what is written in the source because the Svelte compiler must generate about ten lines for each `if` statement. At the very least it shouldn't be too hard to combine consecutive `if` statements into a single `if` statement

This example is from a real project: https://github.com/RobBrazier/svelte-awesome/pull/1058

### Describe the proposed solution

Implement it as an optimization in the compiler

### Alternatives considered

Document it (possibly at https://kit.svelte.dev/docs/performance) and make users handle it themselves

### Importance

nice to have
Repository: transformers
Issue: [i18n-en] Translating docs to Japanese
Labels: WIP

Hi!

Let's bring the documentation to all the Japanese-speaking community 🌐 

Who would want to translate? Please follow the 🤗 [TRANSLATING guide](https://github.com/huggingface/transformers/blob/main/docs/TRANSLATING.md). Here is a list of the files ready for translation. Let us know in this issue if you'd like to translate any, and we'll add your name to the list.

Some notes:

* Please translate using an informal tone (imagine you are talking with a friend about transformers 🤗).
* Please translate in a gender-neutral way.
* Add your translations to the folder called `ja` inside the [source folder](https://github.com/huggingface/transformers/tree/main/docs/source).
* Register your translation in `ja/_toctree.yml`; please follow the order of the [English version](https://github.com/huggingface/transformers/blob/main/docs/source/en/_toctree.yml).
* Once you're finished, open a pull request and tag this issue by including #issue-number in the description, where issue-number is the number of this issue. Please ping @stevhliu and @MKhalusova for review.
* 🙋 If you'd like others to help you with the translation, you can also post in the 🤗 [forums](https://discuss.huggingface.co/).



## Model doc section
- [ ] [deit.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/deit.md) #28302
- [ ] [deplot.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/deplot.md) #28302
- [ ] [deta.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/deta.md) #28302
- [ ] [detr.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/detr.md) #28302
- [ ] [dialogpt.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/dialogpt.md)
- [ ] [dinat.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/dinat.md)
- [ ] [dinov2.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/dinov2.md)#29272
- [ ] [distilbert.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_doc/distilbert.md)

Keep on adding more as you go 🔥
Repository: PowerToys
Issue: "Open", "Launch", "Go to"...
Labels: Idea-Enhancement,Product-Settings,Status-In progress,Area-User Interface

### Description of the new feature / enhancement

According to MS Learn, we're not using these verbs properly.

> Go to • Going to a tab or another particular place in the UI.

> Use open, not start or launch, to describe opening a program or app. Don't use open to describe selecting a command, a menu, an option, or other similar element.

So we should use <kbd>Go to settings</kbd> or <a href="">Go to settings</a> and <kbd>Open \<modulename></kbd>. In the icon menu, it's "Close PowerToys".

### Supporting information

https://learn.microsoft.com/style-guide/a-z-word-list-term-collections/o/open
https://learn.microsoft.com/style-guide/procedures-instructions/describing-interactions-with-ui
Repository: godot
Issue: Android godot 4.2.1 freezes after quitting a scene
Labels: platform:android,topic:porting,needs testing

### Tested versions

4.2.stable and 4.2.1.stable  4.3.dev1

### System information

Godot v4.2.1.stable - Android - Vulkan (Mobile) - integrated PowerVR Rogue GE8322 -  (8 Threads)

### Issue description

it happens when i run ANY project from the main menu or while in the editor, which makes debugging impossible

i might try 4.3 dev1 to see if it gets fixed

### Steps to reproduce

start any project/scene then quit by the back button or by a scripted quit button

### Minimal reproduction project (MRP)

N/A
Repository: electron
Issue: [Feature Request]: provide a typesafe version of ContextBridge.exposeInMainWorld
Labels: enhancement :sparkles:,documentation :notebook:,component/context-bridge

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [ ] 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 feature request that matches the one I want to file, without success.

### Problem Description

ContextBridge.exposeInMainWorld presently allows `any` as the data type for the second parameter.  Also we'd have to declare the exposed values so that it would play nicely with Typescript

### Proposed Solution

```typescript
  interface ContextBridge {

    // Docs: https://electronjs.org/docs/api/context-bridge

    exposeInIsolatedWorld<T>(worldId: number, apiKey: string, api: T): void;
    exposeInMainWorld<T>(apiKey: string, api: T): void;
  }
```

Note I didn't use `T extends Record<string, unknown>` to allow for exposing primitive data as well

```typescript
type Versions = {
  node: () => string;
  chrome: () => string;
  electron: () => string;
};

declare global {
  interface Window {
    versions: Versions;
  }
}

contextBridge.exposeInMainWorld<Versions>("versions", {
  node: () => process.versions.node,
  chrome: () => process.versions.chrome,
  electron: () => process.versions.electron,
});
```

### Alternatives Considered

Don't do any type checks

### Additional Information

_No response_
Repository: TypeScript
Issue: Counterexample to current ReturnType logic with type parameters
Labels: Suggestion,In Discussion

### 🔎 Search Terms

"ReturnType inference any"

### 🕗 Version & Regression Information

 This is the behavior in every version I tried

### ⏯ Playground Link

https://www.typescriptlang.org/play?#code/C4TwDgpgBAKgDFAvFAShYBXATgOxuCAHkJgD4AKYALlgEolSoBrCEAewDNZSBuAWABQAeiFQxAPQD8gwaEhQAogA9IAY2AQAJmky5885C3ZcMOJjjYB3HP2GiJkoA

### 💻 Code

```ts
type T0 = ReturnType<<T>(t: T) => keyof T>; // any

type ExpectedReturnType = keyof unknown; // never
```


### 🙁 Actual behavior

`ReturnType` fails and returns `any`

### 🙂 Expected behavior

Given the fact that the upper bound of the type parameter `T` is `unknown`, I'd expect `keyof unknown` as result, i.e. `never`.

### Additional information about the issue

This is somewhat related to #55667 and it comes from the attempts made to understand why #55714 failed to pass all the test cases.

We have:
```ts
type ReturnType<T extends (...args: any) => any> = T extends (...args: any) => infer R ? R : any
```

The problem seems to be located in `compareSignaturesRelated`, called by `getConditionalType` to resolve the `ReturnType`'s inner conditional type. We have that `source = <T>(t: T): keyof T` is compared against `target = (...args: any): never`. This `never` is, in fact, the correct return type `R` that was successfully inferred.

Because `source` has a type parameter, `instantiateSignatureInContextOf(source, target, ...)` comes into play and we get a new `source`: `(t: any): string | number | symbol`. I'm not 100% sure about the logic of  `instantiateSignatureInContextOf`, but it's worth noting that `target` is the second argument of the call above and the type of `target`'s parameter is `any`. Therefore it seems that, from the `source` point of view, `T` becomes just `any` (and `keyof any` is exactly `string | number | symbol`).

We now have `source = (t: any): string | number | symbol` to be compared against `target = (...args: any): never`. This comparison fails because of the return types: `string | number | symbol` is not assignable to `never`, thus the assignability check also fails and we get the `falseType` as result, i.e. `any`.

&nbsp;

The example in this issue may seem intentionally crafted, and in fact it is, but the point was to highlight the same problem explained by [this comment](https://github.com/microsoft/TypeScript/pull/55714#issuecomment-1732597254). There we have a similar issue with the `source` we get from `instantiateSignatureInContextOf`: `any` has been substituted with `never` inside `ReturnType` definition, therefore if `source` has a type parameter it will be instantiated with `never` and sometimes things don't end well.

This probably undermines the possibility of having an all-encompassing definition for `ReturnType` __if we use a concrete type for the arguments__. However you type the rest parameter inside it, I suppose you can always find a counterexample that uses a not-yet-instantiated type parameter to make the assignability check of the conditional fail.
Repository: PowerToys
Issue: Keyboard Manager - Able to lock key 'status' ?
Labels: Needs-Triage

### Description of the new feature / enhancement

I would like to see the Keyboard Manager be able to lock the 'status' of a (for lack of a better term) 'function-based' key.

For example... be able to set the NUM LOCK to always on and not accept the pressing of the key to accidentally turn it off.

### Scenario when this would be used?

When I am doing '10-key' (using the num pad for entering numbers, whether for business or personal use), I have a habit of hitting the NUM LOCK key and then I start going all over the place with the 'arrows'.

I'd like to find out if the KM can lock the status of a 'function/assigned' key, or could it be easily modified to do so?

I already use it to reassign the CAPS LOCK to the SCROLL LOCK :)

Thanks, and hope you all have a great 2024 :)

### Supporting information

_No response_
Repository: pytorch
Issue: Support float64 step in fused optimizers
Labels: module: optimizer,triaged,actionable

### 🚀 The feature, motivation and pitch

A next step to #110940. We’ve enabled float64 scalar support across foreach implementations of our optimizers. A next step is allowing float64 scalars to enroll in our faster fused impls.

### Alternatives

_No response_

### Additional context

_No response_

cc @vincentqb @jbschlosser @albanD @crcrpar
Repository: rust
Issue: exponential compile times for simple function compositions
Labels: C-enhancement,I-compiletime,T-compiler,T-types

Each additional statement `let x = Apply(x, drop);` surprisingly increases the compilation time by a factor of two:
```rust
struct Apply<X, F: Fn(X)>(X, F);

pub fn main() {
    let x = &();
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let x = Apply(x, drop);
    let _ = x;
}
```

The reason behind this exponential blowup is that the function `drop` has an "early-bound"  generic parameter (`drop::<_>`), making the types of `x` grow exponentially with each level of nesting `type X2 = Apply<X1, drop::<X1>>;`

This should be fixed by removing the distinction between early- and late-bound function generics.