sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Unclear Text on section guide and other parts in settings
Labels: bug,linux,gpu,upstream-issue-linked,chromium

Type: <b>Bug</b>
When Extensions are Enabled
![Screenshot from 2023-01-15 22-23-54](https://user-images.githubusercontent.com/77064772/212555686-41990ee7-173f-4e8e-a2d8-1b1a702f9095.png)

When Extensions are Disabled
![Screenshot from 2023-01-15 22-26-28](https://user-images.githubusercontent.com/77064772/212555708-6fdb5637-aede-415f-a2dc-ecec08a35f49.png)


Unable to identify steps to reproduce

VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T16:57:40.428Z)
OS version: Linux x64 5.15.0-58-generic
Modes:
Sandboxed: No

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (8 x 1821)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<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_renderer: enabled_on<br>video_decode: disabled_software<br>video_encode: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: disabled_off|
|Load (avg)|1, 1, 1|
|Memory (System)|15.36GB (10.60GB free)|
|Process Argv|--unity-launch|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|gnome|
|XDG_CURRENT_DESKTOP|GNOME|
|XDG_SESSION_DESKTOP|gnome|
|XDG_SESSION_TYPE|x11|
</details><details><summary>Extensions (24)</summary>

Extension|Author (truncated)|Version
---|---|---
better-comments|aar|3.0.2
path-intellisense|chr|2.8.4
regex|chr|0.4.0
vscode-markdownlint|Dav|0.49.0
vscode-eslint|dba|2.2.6
competitive-programming-helper|Div|5.9.2
prettier-vscode|esb|9.10.4
code-runner|for|0.11.8
shell-format|fox|7.2.2
vscode-pull-request-github|Git|0.56.0
python|ms-|2022.20.2
vscode-pylance|ms-|2023.1.20
jupyter|ms-|2022.11.1003412109
jupyter-renderers|ms-|1.0.12
cpptools|ms-|1.13.9
hexeditor|ms-|1.9.9
sqlite-viewer|qwt|0.1.5
java|red|1.13.0
LiveServer|rit|5.7.9
open-in-browser|tec|2.0.0
lorem-ipsum|Tyr|1.3.1
highlight-matching-tag|vin|0.10.1
intellicode-api-usage-examples|Vis|0.2.6
vscodeintellicode|Vis|1.2.30


</details>
<!-- generated by issue reporter -->
Repository: PowerToys
Issue: Swapping capslock/ctrl causes false pen actions on Surface Laptop Studio
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Needs-Repro,Priority-2

### Microsoft PowerToys version

0.66.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

Swap capslock and control (screenshot), then remove the pen from docked position on a Surface Laptop Studio.  Then return it.

<img width="800" alt="image" src="https://user-images.githubusercontent.com/3851891/212555465-c4701845-513c-4db4-a914-97c44277ef2a.png">

### ✔️ Expected Behavior

I'm expecting nothing to happen when I dock and undock the pen.

### ❌ Actual Behavior

Keyboard capslock is turned off when I remove the pen. When I put the pen back, capslock is always turned on, and the screen snip interface pops up.  I've configured my single click pen action to do a screen snip.  

This never happened until a few Windows 11 updates ago.  There was no action when I removed and restored the pen.   

Debug file attached.
[PowerToysReport_2023-01-15-08-46-51.zip](https://github.com/microsoft/PowerToys/files/10420738/PowerToysReport_2023-01-15-08-46-51.zip)



### Other Software

_No response_
Repository: TypeScript
Issue: Generic type gets widened in an unexpected way
Labels: Bug,Help Wanted

# Bug Report

### 🔎 Search Terms

widen

### 🕗 Version & Regression Information

4.9.4

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?jsx=0#code/KYOwrgtgBA8ixQN4CgpQIJQLxQOQENcAaVKAIWzwCNjSBhS3AY12QF9lkmB7EAZwAuUAJZ84wAMrcIwAQAthIAOYBZfAAdKKNAG1xAOnQBdAFxQBAJzDASug2VNQAZvgA2fG6T3x9dR5et2KHw+KB5+IT58AVEnYWBQgCVgHgsAEwAecSIoKm5uV2B8EAA+AG5OAQBPdQQyfMLitXUAFW4AVRBhXgyWqGAADwFQNKSU7nSMwQtFJRy8gqLSkq0vAAURECgAa2Aq7icoFscWnTWjfqGR0ICEAH4oDbN4ADdgCwq2HV39w+OK5DVWpQKQyeSzcSUeqLJoaNqdbogDJA4AHERieCg2QKZTNcqccKCYKUXolAAULzc1jMLQAlNgVpTXNYKoShFQSS1yU4QGYKVTgDT6VgVi0ci8hTSGc4QBTaQC2VAJSDpNiIfBKAZMCEVWCcUpxKzeESXgAmMxaqAAH1gPgYOEtOstNoMdAVxqEFgAjJQqGT8OL5VAAPTB20IYppKAgbhCLHg5SQgC00djl1qTGGaS4HqgFlNlHwcrKIbD8f1kJ1gwzWZzETzAGZff7xaag6GoAjeMFQtWUrW60SLAAWZsB8OGHsTzAuu3tsMAdQm2z4g89AFYxzlHaFy+rgPOQTFXK4oGluAkQLghAB3Zf6B9AA)

### 💻 Code

```ts
enum One {
  A = 'a',
  B = 'b',
  C = 'c'
}

const isOneSomethingMap = {
  [One.A]: true,
  [One.B]: false,
  [One.C]: true
} as const satisfies Record<One, boolean>;

type BooleanMapToUnion<T extends Record<string, boolean>> = {
  [P in keyof T]: T[P] extends true ? P : never;
}[keyof T];

type SomethingOne = BooleanMapToUnion<typeof isOneSomethingMap>;

const a = <T>(value: T) => value;
const b = <T>(fn: (value: T) => T, v: T): T => fn(v);

const v: SomethingOne = One.A as SomethingOne;
const v2: One.A | One.C = One.A as One.A | One.C;

const r1 = b(a, v); // One and not SomethingOne - not expected
const r2 = a(v); // SomethingOne as expected
const r3 = b(a, v2); // Union as expected

const r4 = b(a, One.A as One.A | One.C); // Works
const r5 = b(a, One.A as SomethingOne); // Still doesn't work...
```

### 🙁 Actual behavior

The type gets widened when using `BooleanMapToUnion`... I guess it is the culprit.

### 🙂 Expected behavior

Both union and using `BooleanMapToUnion` should work equally.
Repository: pytorch
Issue: Improve make_fx tracing speed
Labels: module: performance,triaged,module: ProxyTensor

### 🚀 The feature, motivation and pitch

We observed that tracing a model using make_fx is sometimes much slower than actually running a model, and the observation has been consistent across different model sizes. For our big model sometimes we see a 30s+ tracing time.

While we understand tracing is usually only done once throughout the training process, the slow tracing speed has a direct impact on startup time, which leads to a very unpleasant debug-test experience. 

```
import torch
from functorch import make_fx
import time

def main():
    model = ...
    input = ...
    start = time.perf_counter()
    model(input)
    end = time.perf_counter()
    print(f"time to execute {end - start}")
    start = time.perf_counter()
    traced = make_fx(model)(input)
    end = time.perf_counter()
    print(f"time to trace {end - start}")
```

```
time to execute 0.04433171300000005
time to trace 0.47819954299999967
```

### Alternatives

_No response_

### Additional context

_No response_

cc @ngimel @ezyang @SherlockNoMad @soumith @EikanWang @jgong5 @wenzhe-nrv
Repository: pytorch
Issue: Hijacked package names from nightly repository
Labels: module: binaries,triaged,security

### 🐛 Describe the bug

In response to this
https://pytorch.org/blog/compromised-nightly-dependency/
I checked if there are other package names in the pytorch nightly package index. I found two package names that I could register on pypi (torchaudio-nightly, pytorch-csprng).

I reported this to facebook's bugbounty program (as your security policy says), however it seems facebook no longer is responsible here (see also #91570). Facebook's security team came to the conclusion that the issue is not severe.

Nevertheless I now have registered these package names on pypi and I am wondering what to do with them. I would prefer to transmit ownership of the account to the pytorch team so you can decide what to do with them and if you want to keep them registered to block the names.

### Versions

irrelevant/nightly

cc @seemethere @malfet @osalpekar @atalman @ezyang
Repository: flutter
Issue: Add debug tooling for focus and IME connections
Labels: a: text input,c: new feature,framework,engine,a: debugging,c: proposal,f: focus,P3,team-engine,triaged-engine

As I'm working with user interfaces that have more complex focus and IME interactions, I'm finding it difficult to track associated changes.

I think it would be helpful to be able to visualize the focus path, from root, to the widget with primary focus. For example, all widgets in the focus path might be given a border and a tiny number in the corner that shows the tree distance from the root. The widget with primary focus could have a special color.

Also, I'd like to be able to track changes to the IME connection. For example, is an IME connection open right now? Ideally, I'd also like to know which widget owns that IME connection. That later part is more difficult, because there's no requirement that a widget own the IME connection. So maybe that requires an opt-in API. Nonetheless, when debugging issues at moments where one widget's IME connection closes and another is supposed to open, it would be helpful to have some quick toggle-able visual indicators through Flutter Inspector.

**EDIT:**
Here are a couple other ideas as I'm working through focus issues.
 * Log why each focus change happens. Did a node request "unfocus"? Did another node request "focus"? Focus changed in some way that I didn't want it to, but it's unclear how to root cause what happened, because anything in the entire app could be involved with the change.
 * Tap to select a widget that handles gestures. Flutter already has a "tap to select widget" mode in the inspector. But what about when I'm looking for the widget that handles gestures at a particular (x,y)? With things like `Stack`s, it's easy to end up with invisible or translucent widgets that sit on top of the widget that handles a gesture. This makes it difficult to locate which widget is actually handling a tap, for example.
Repository: material-ui
Issue: Add abillity to prevent `CssVarsProvider` from using local storage
Labels: package: system,customization: css

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

The current implementation of `CssVarsProvider` requires the use of local storage to store the theme settings. My suggestion is to make the use of local storage optional. One idea is to add a `mode` property to `CssVarsProvider`, in addition to the existing `defaultMode` property. With this new property, the theme would be controlled solely by the property and would not be affected by local storage. Another suggestion is to delay writing to local storage until the theme is explicitly changed using the setter of the `useColorScheme` hook. That way, if the setter is not used, nothing would be written to local storage.

### Examples 🌈

_No response_

### Motivation 🔦

The current version of `CssVarsProvider` requires the use of local storage, even though it is unnecessary in certain situations. For example, if the theme is only controlled by the system theme, or if there is only one theme, there is no need to use local storage. Local storage adds unnecessary complexity due to statefulness. For example, it adds the need to check how divergent states in local storage and in code interact.
Repository: pytorch
Issue: Add torch::jit::ScriptModule to the C++ API
Labels: oncall: jit

### 🚀 The feature, motivation and pitch

I'd like to implement a model in C++ with some submodules defined in C++ being subclasses of `torch::nn::Module` and a submodule being a `torch::jit::Module`. This is a common use case when your design your own model based around some well known backbone for which a torchscripted version is available.

I'm not sure about the best way to do this, but I believe that I must build my own wrapper subclassing `torch::nn::Module` around the JIT module. Such wrapper would register the parameters of the JIT module, and build recursively wrappers around its submodules. The wrapper would also need to overide `train()`, `eval()`, `to()` ... and delegate them to the JIT module. A bit ugly  but it should work.

The thing is, I'm not really developing in C++, but in Java (or whatever language using a binding to the C++ API). In that case, writing a C++ subclass of `torch::nn::Module` that wraps the `torch::jit::Module` is not an available option.

So is it possible, either to make `torch::jit::Module` inherit from `torch:nn::Module` (I guess not) or provide a ready to be used C++ `torch::jit::ScriptModule` wrapper class, just like the Python counterpart ?


### Alternatives

_No response_

### Additional context

_No response_

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Repository: storybook
Issue: [Bug]: MDX throws `Extraction error on ...mdx: TypeError: this[properties[i].type] is not a function`
Labels: bug,mdx,needs triage

### Describe the bug

I'm running into an annoying bug preventing me from upgrading to v7.

I've got a standalone MDX file with the following content:

```mdx
export function Color({ value }) {
  return <div>{value}</div>;
}

<Color value="test" />
```

Running dev server (it also fails when building), sometimes it works the first time I modify and save the file. But if I save again or reload the storybook tab, I get this error repeated multiple times:

```
Extraction error on src/tokens/__stories__/color.mdx: TypeError: this[properties[i].type] is not a function
```

In contrast, a story like this works fine:

```mdx
export function Color() {
  return <div>test</div>;
}

<Color />
```

Due to the many errors I was running into for the migration, I wiped and force init-ed storybook again, so I've got a clean base config.

### To Reproduce

```shell
Repro here: https://stackblitz.com/edit/github-jwf2gz?file=src/test-fails.mdx
```


### System

```shell
Environment Info:

  System:
    OS: Linux 6.0 Pop!_OS 22.04 LTS
    CPU: (16) x64 Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz
  Binaries:
    Node: 18.8.0 - /tmp/xfs-93d6471e/node
    Yarn: 3.2.2 - /tmp/xfs-93d6471e/yarn
    npm: 8.18.0 - ~/.nvm/versions/node/v18.8.0/bin/npm
  Browsers:
    Chrome: 109.0.5414.74
    Firefox: 108.0
  npmPackages:
    @storybook/addon-actions: ^7.0.0-beta.25 => 7.0.0-beta.25 
    @storybook/addons: ^7.0.0-beta.25 => 7.0.0-beta.25
```


### Additional context

Happened in both webpack and vite.
Repository: godot
Issue: Generating CollisionShape3D with create_trimesh_collision() method results in a collision shape with messed up vertices
Labels: bug,topic:physics

### Godot version

v4.0.beta12.mono.official [3c9bf4bc2]

### System information

EndeavourOS Linux x86_64, Vulkan Forward+, Intel Atom Processor Z36xxx/Z37xxx Series Graphics

### Issue description

i'm making a 3D world map in godot using meshes for countries, and using the `create_trimesh_collision()` function to generate a CollisionShape3D based on the mesh. in this screenshot i enabled "Visible Collision Shapes" from the debug tab, as you can see. it used to work perfectly on my main computer which is more powerful and runs windows 10. however, running the project on my laptop which has inferior perfomance and runs linux, the collision shape generation seems to glitch and mess up the vertices or something. in the screenshot you can see some weird lines going from one point (which is the (0, 0) coordinate) to "infinite and beyond". is this a bug on the engine? is it linux exclusive? or does it really requires a more powerful computer to execute properly?

![image](https://user-images.githubusercontent.com/27783608/212571252-f772ba08-37a6-404c-938f-31a866f07c09.png)

### Steps to reproduce

Parse an big JSON file with all countries data, and get each coordinate point of each boundaries of each country

And this process is repeated for EACH country and territory (there are over 200 countries so you can imagine this process being repeated 200 times):

> 1. Get all the points and convert from geographical coordinate to space coordinate
> 2. Create a new Country object and call a method to generate the mesh passing in the converted points (also, the Country uses an C# script)
> 3. Use a nuget package called "Triangle" to generate a triangulated mesh based on the points given
> 4. Generate CollisionShape3D based on the mesh using the `create_trimesh_collision()` method

This used to work perfectly fine on my main computer, which is more powerful and runs Windows 10. However, when running the project in my low end laptop with Linux running, the collision shape isnt generated properly and all the vertices gets messed up as shown on this screenshot:

![image](https://user-images.githubusercontent.com/27783608/212571636-0bdab19b-a6c7-438c-8c01-38f12ef14170.png)

### Minimal reproduction project

i had to sacrifice a lot of files so you might need to regenerate mono and project files and install triangle as the nuget package again

[world_map.zip](https://github.com/godotengine/godot/files/10421484/world_map.zip)
Repository: godot
Issue: Area2Ds with monitoring and monitorable flags on don't detect Area2Ds that initially overlap and go from monitorable off to on
Labels: bug,topic:physics

### Godot version

4.0 beta 12, 3.5.1
_bugsquad edit_

### System information

Windows 10

### Issue description

Say I have an Area2D (called Area_A) with ```monitoring = true``` and ```monitorable = true```, along with ```collision_mask``` bit 1 set to ```true```.  Now take another Area2D (called Area_B) with ```monitoring = false``` and ```monitorable = false```, along with ```collision_layer``` bit 1 set to ```true```. Now, let's position Area B to overlap Area A. No detection should take place yet since Area B's ```monitorable = false```, currently.  Then, let's set Area B's ```monitorable = true```, and we should see a collision here (assuming that ```has_overlapping_areas()``` has been called or the ```area_entered``` signal has been set up). However, there is no collision.

If we take Area A and set ```monitorable = false``` and try all the same steps again, a collision will be reported.
I would assume based off this behavior, that if both ```monitorable = true``` and ```monitoring = true``` in the detecting Area2D, it should perform in this same way.

This doesn't look to be a regression, as it exists in 3.5.1 as well, but it does seem like a bug.

### Steps to reproduce

Controls for minimal reproduction project:

ui_focus_next (Tab) = Toggle monitorable flag of HitBox (blue)
ui_focus_prev (Shift+Tab) = Toggle monitoring flag of HurtBox (red)
ui_accept (Space) = Toggle monitorable flag of HurtBox (red)
LMB = Toggle monitorable flag of MouseBox (green)

The HitBox is the monitoring area.
The HurtBox and the MouseBox are the monitorable areas.

### Minimal reproduction project

[Area2DTest.zip](https://github.com/godotengine/godot/files/10421604/Area2DTest.zip)
Repository: PowerToys
Issue: Please add a feature to increase the number of items in program jump list on taskbar or on start menu
Labels: Idea-Enhancement,Idea-New PowerToy,Product-Tweak UI Design,Needs-Triage

### Description of the new feature / enhancement

Currently most jump lists are set to 8 or 10 or 12 most recent entries only.

Currently you need to do a registry hack to change this number since Windows 10.  Registry hacks are dirty and unsafe.

It would be great if this simple tweak could be included in Power Toys.

### Scenario when this would be used?

Any time a jump list is accessed, more recent items would appear in jump lists.

### Supporting information

Pease see https://www.windowscentral.com/how-raise-number-items-jump-lists-windows-10
Repository: godot
Issue: Sprite2D doesn't respect sprite boundaries properly when flip_h is set
Labels: bug,topic:2d

### Godot version

4.0 beta 12

### System information

Ubuntu 22.04

### Issue description

While flip_h is checked, Sprite2D does not map its texture correctly, grabbing a column of pixels from the sprite to the right of the current one in the spritesheet at non-integer positions. This differs from the old texture filtering system, where non-integer positions were handled correctly. Changing the filtering mode slightly changes the behavior but doesn't solve the problem.

### Steps to reproduce

1. Create a Sprite2D that uses a sprite sheet
2. Set flip_h to true
3. Slowly move the sprite in sub-pixel increments

### Minimal reproduction project

[texture bug.zip](https://github.com/godotengine/godot/files/10421906/texture.bug.zip)
Repository: vscode
Issue: Git - Offer to pull from origin on failed git push
Labels: feature-request,git


Type: <b>Feature Request</b>

PyCharm allowed me to pull and potentially merge from origin if a push failed due to not being up-to-date on the local branch. Could VSCode do something similar?

VS Code version: Code 1.74.3 (97dec172d3256f8ca4bfb2143f3f76b503ca0534, 2023-01-09T17:05:47.808Z)
OS version: Darwin arm64 21.6.0
Modes:
Sandboxed: No


<!-- generated by issue reporter -->
Repository: PowerToys
Issue: Mouse Left Handed/Right Handed Behavior Toggle
Labels: Needs-Triage

### Description of the new feature / enhancement

Keyboard shortcut that swaps the left mouse button and right mouse button for ambidextrous people/multiple people with different preferences on a shared system.

### Scenario when this would be used?

Ambidextrous people; systems in households/businesses where one Windows Profile can see multiple different people using it, with different left/right-handedness.

### Supporting information

12% of people are left-handed.
Repository: PowerToys
Issue: Default mode for screen ruler
Labels: Idea-Enhancement,Help Wanted,Product-Screen Ruler

### Description of the new feature / enhancement

I most often use the spacing / + tool when using the screen ruler, it'd be good to be able to select which of the 4 modes I could use by default each time

### Scenario when this would be used?

Whenever I use the tool, as a default behaviour.

### Supporting information

_No response_
Repository: godot
Issue: Moving a resource (material) sometimes duplicates it instead of moving it
Labels: bug,topic:editor,regression

### Godot version

4.0 Beta 12

### System information

Windows 10, Vulkan, Nvidia RTX 3060 Ti

### Issue description

When moving a resource to a different folder in the editor's FileSystem panel, there's inconsistent behavior where sometimes it copies it instead of moving it, other times it correctly moves as expected. This bug occurs with both the drag-n-drop method of moving and also when you right-click and select "Move To..."


https://user-images.githubusercontent.com/2095704/212604925-c27ad2d1-1403-4862-9c03-c24b804bf2a6.mp4

Note: Deleting the .godot folder and reloading the editor seems to fix the issue, but this is a perfectly clean new project where the identities of these freshly saved materials immediately get messed up somehow.

### Steps to reproduce

Existing sample project:
- Open the attached sample project
- Try dragging either material into and out of the folder as shown in the above video

Or repro in a brand new project:
- Create 2 mesh instances
- Create a new material for each mesh and save them to the root of the project
- Create a new folder in the FileSystem
- Try dragging either material into and out of the folder as shown in the above video
(Note: If you simply create new material resources directly in the FileSystem they seem to not cause buggy behaviour)

https://user-images.githubusercontent.com/2095704/212605658-3789ab4f-fd1b-4b33-9260-dde2215fafb5.mp4



### Minimal reproduction project

I had to include the `.godot` folder because something in there is causing the issue. Deleting the .godot folder cleans up and fixes the issue.

[Move_Resource_Bug.zip](https://github.com/godotengine/godot/files/10422856/Move_Resource_Bug.zip)