sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: No Auto-completions / Suggestions for Custom `styled` components!
Labels: docs,typescript,package: material-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Steps:

1. Created a custom component using `styled` utility.
2. Added variants using `createTheme` function.


### Current behavior 😯

I was trying to compose a Flex component for all the flexbox related layouts in my application.

I had a look at the documentation, and it worked.

However, the developer experience isn't great, and I'm not getting any auto-completions in my VS Code for this custom component, neither in my component nor in the Custom Component section of `createTheme()` block.

Here's my implementation.


### Component.

```js
import { styled } from "@mui/material";

const Flex = styled("div", {
  shouldForwardProp: (prop) =>
    prop !== "direction" && prop !== "justifyContent" && prop !== "sx",
  name: "Flex",
  slot: "Root",
  overridesResolver: (props, styles) => [
    styles.root,
    props.direction === "column" && styles.directionColumn,
    props.justifyContent === "space-between" && styles.spaceBetween,
  ],
})({
  display: "flex",
});

export default Flex;
```

### Variants

```js
  components: {
    // No auto-completions/suggestions here  ☹️
    Flex: {
      styleOverrides: {
        root: {
          flexDirection: "row",
        },
        directionColumn: {
          flexDirection: "column",
        },
        spaceBetween: {
          justifyContent: "space-between",
        },
      },
    },
  },
```


While using it, I'm not getting the prop autocompletion on **direction** or **justifyContent** props.

### Expected behavior 🤔

All my props should be well typed and should show suggestions just like other MUI components.

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
 System:
    OS: Linux 5.10 Ubuntu 20.04.5 LTS (Focal Fossa)
  Binaries:
    Node: 16.17.1 - ~/.nvm/versions/node/v16.17.1/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 8.15.0 - ~/.nvm/versions/node/v16.17.1/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    @emotion/react: ^11.10.4 => 11.10.4
    @emotion/styled: ^11.10.4 => 11.10.4
    @mui/base:  5.0.0-alpha.101
    @mui/core-downloads-tracker:  5.10.9
    @mui/material: ^5.10.9 => 5.10.9
    @mui/private-theming:  5.10.9
    @mui/styled-engine:  5.10.8
    @mui/system:  5.10.9
    @mui/types:  7.2.0
    @mui/utils:  5.10.9
    @types/react: ^18.0.17 => 18.0.21
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
```
</details>
Repository: neovim
Issue: cmdheight=0 causes hit-enter-prompt in case of `<Cmd>...<CR>` mapping
Labels: bug,ui,messages

### Neovim version (nvim -v)

0.8.0

### Vim (not Nvim) behaves the same?

No

### Operating system/version

EndeavourOS Linux x86_64, 5.19.13-arch1-1

### Terminal name/version

xfce4-terminal

### $TERM environment variable

xterm-256color

### Installation

appimage

### How to reproduce the issue

1. Create config file (called in this example 'cmdheight-init.lua') with the following content:
```lua
vim.o.cmdheight = 0
vim.keymap.set('n', '<M-m>', '<Cmd>lua print("Hello")<CR>')
vim.keymap.set('n', '<M-n>', function() print("Hello") end)
```
2. Execute `nvim --clean -u cmdheight-init.lua`.
3. Type `<M-m>`. It prints "Hello" but with hit-enter-prompt.
4. Clear hit-enter-prompt.
5. Type `<M-n>`. It prints "Hello" without hit-enter-prompt.

### Expected behavior

Both mappings result in identical behavior.

### Actual behavior

https://user-images.githubusercontent.com/24854248/195992096-0184a39d-79c3-41bf-953b-4958338f1eed.mp4
Repository: go
Issue: archive/zip: potential bug with zip64 check
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.19.2 windows/amd64
</pre>

There seems to be a bug with zip64 check on this line:

https://github.com/golang/go/blob/9ddb8ea73724d717a9bbf44be7d585ba5587504f/src/archive/zip/reader.go#L557

Specifically the `d.directorySize == 0xffff` part. Size of central directory is a 32-bit value so it should be compared to 0xffffffff.
Repository: stable-diffusion-webui
Issue: Interesting idea worth implementing: use CLIP guidance to enhance the quality and coherency of images
Labels: enhancement,extension-request

**Is your feature request related to a problem? Please describe.**
sometimes bigger images are not coherent

**Describe the solution you'd like**
See idea behind thi post
https://www.reddit.com/r/StableDiffusion/comments/y4fekg/dreamstudio_will_now_use_clip_guidance_to_enhance/
Repository: vscode
Issue: [html] Ignore html tag in sticky scroll and outline
Labels: feature-request,html

<!-- ⚠️⚠️ 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. -->

Everyone knows when he is coding in html file he is working inside html tag.  
It's annoying to see a `<html>`, `<head>` and `<body>` tag always at the top
Repository: stable-diffusion-webui
Issue: Improving Hypernetwork initialization
Labels: enhancement

This question/issue was first pointed out in

> I have a question, why the hypernetwork is just two linear without activation?

_Originally posted by @vexilligera in https://github.com/AUTOMATIC1111/stable-diffusion-webui/discussions/2284#discussioncomment-3854768_

I also asked myself the same today while reviewing the code and it makes no sense
I get the same/similar results just using one linear function with 4x less space needed for the .pt files.

Right now it is implemented like this
```
self.linear1 = torch.nn.Linear(dim, dim * 2)
self.linear2 = torch.nn.Linear(dim * 2, dim)
```

but if one wants to keep the two linear structure we might take advantage of it to reduce the optimization space by doing something like this
```
self.linear1 = torch.nn.Linear(dim, dim //n)
self.linear2 = torch.nn.Linear(dim //n, dim)
```

where n >= 2

this should also make it easier to combine hyper networks since we will be working in a subspace of the context.

and once we are at it, I would also suggest initializing with XAVIER initialization
std=0.01 / sqrt(dim)

Specifically, I suggest either remove the double linear and have:
```
p = 0.01
self.linear = torch.nn.Linear(dim, dim)
self.linear.weight.data.normal_(mean=0.0, std=p/math.sqrt(dim))
```

or for n >= 2

```
self.linear1 = torch.nn.Linear(dim, dim//n, bias=False)
self.linear2 = torch.nn.Linear(dim//n, dim)

std = math.sqrt(p)*np.sqrt(2/(dim+dim/n))
self.linear1.weight.data.normal_(mean=0.0, std=std)
self.linear2.weight.data.normal_(mean=0.0, std=std)
```
Repository: svelte
Issue: A11y: noninteractive element cannot have positive tabIndex value when using tabindex="0"
Labels: awaiting submitter,a11y

### Describe the bug

I don't really know where to post this bug but I keep getting the same warning when using tabindex="0":

![20221015_104155](https://user-images.githubusercontent.com/14960414/195995347-aebf4155-0001-45df-9528-24a331cfdc9b.png)

![20221015_104249](https://user-images.githubusercontent.com/14960414/195995366-e9637ade-a41e-4450-ad1e-84f5934bbbc2.png)

If you know where I should report this bug, let me know!

### Reproduction

Add a tabindex="0" to any div element and see for yourself :)

### Logs

_No response_

### System Info

```shell
System:
    OS: Linux 6.0 Arch Linux
    CPU: (8) x64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
    Memory: 29.44 GB / 31.31 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 18.11.0 - /usr/bin/node
    Yarn: 1.22.19 - /usr/bin/yarn
    npm: 8.19.2 - /usr/bin/npm
  Browsers:
    Chromium: 106.0.5249.119
```


### Severity

annoyance
Repository: terminal
Issue: drag/drop gives wrong path in Canonical's Ubuntu profiles
Labels: Resolution-External,Issue-Bug,Area-Settings,Product-Terminal

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement
While dragging a file into the terminal the path it generates becomes unusable in wsl. Shouldn't it generate the path from the mount point of wsl?

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
Repository: godot
Issue: Allow assets to define supported platforms
Labels: enhancement,topic:editor,topic:assetlib

### Godot version

3.5beta.3offical android

### System information

Android 11 Samsung Tab-A7 Sm1705

### Issue description

For example, when I want to download the python library, after a 100 mb download, there is a drop in the installation process.

### Steps to reproduce

.

### Minimal reproduction project

_No response_
Repository: vscode
Issue: Source control svg icons stay dark when the repository row is selected.
Labels: bug,ux

<!-- ⚠️⚠️ 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?: N/A

<!-- 🪓 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. -->
Version: 1.72.0 (Universal)
Commit: 64bbfbf67ada9953918d72e1df2f4d8e537d340e
Date: 2022-10-04T23:21:58.256Z
Electron: 19.0.17
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin x64 21.6.0
Sandboxed: No

Steps to Reproduce:

1. Install the [git-graph extension](https://marketplace.visualstudio.com/items?itemName=mhutchie.git-graph)
2. Open a repository
3. Open the source control view
4. Make sure you currently have a light theme
5. Click the repository row so it becomes blue

Expected result:
The git graph icon changes along with the other icons.

Actual result:
The git graph icon stays black

more info here: https://github.com/mhutchie/vscode-git-graph/issues/690

https://user-images.githubusercontent.com/2737650/196002067-29002c28-c71b-42a3-8806-85e5e143fe2f.mp4
Repository: deno
Issue: Feature: Support SIGHUP and SIGBREAK (port libuv support?)
Labels: feat

As deno ramps up to become compatible with node, is there an effort for porting libuv wrapper for console signals from libuv to a rust library compatible with Tokio? Specifically, SIGHUP and SIGBREAK - specifically src/win/signalc?

https://github.com/microsoft/playwright/issues/3146

Thanks for any input on effort towards this. libuv doesn't have to be the source. And this may be a small step towards getting libraries like puppeteer and playwright to work. And other libraries, like https://github.com/atroche/rust-headless-chrome, may supersede the need for these two.

Or possible compatibly on how libuv and tokio setup websockets.

There are two ways for playwright and puppeteer to communicate with chrome/edge. websockets or signals & streams.

Thank you!
-TamusJRoyce
Repository: godot
Issue: Range value_changed signal stuttering and scroll wheel skipping
Labels: bug,regression,topic:gui

### Godot version

4.0.beta3

### System information

MacOS arm64

### Issue description

The Range `value_changed` signal stutters, which is consistant with Godot 3.5x. I worked around it using the Range `changed` signal in 3.5x, which does not stutter, but the `changed` signal is no longer emitted in Godot 4 when the range value changes.

Additionally, when scrolling with the scroll wheel, the `value_changed` signal is intermittent.

Here are videos of a SectionContainer with sticky header in both 3.5.1 and 4.0.beta3:


https://user-images.githubusercontent.com/33969780/196005002-172be292-bf9e-4c82-8a4e-736277b20cb0.mov


https://user-images.githubusercontent.com/33969780/196005015-96832dcb-0fc0-4762-b535-9ba76fe4092c.mov



### Steps to reproduce

Run the project below and scroll up and down.

### Minimal reproduction project


[range_changed_signal_and_scroll_bugs.zip](https://github.com/godotengine/godot/files/9792957/range_changed_signal_and_scroll_bugs.zip)
Repository: stable-diffusion-webui
Issue: The color shift needs to be fixed at the source
Labels: bug-report

**Describe the bug**
A well known bug, that many commits have been trying to **compensate** for, is causing the images to shift towards magenta and darker shadows when doing img2img, even one iteration makes it obvious. This makes any inpainting pretty hard as it ends up creating a magenta heatmap of the places you've inpainted the most for example.

**To Reproduce**
1. Put and image in img2img
2. Generate a variation with prompts
3. Send the results back to the input and do it again
4. Quickly you'll see the image becoming darker and more magenta

OR
1. Do this but automatically with loopback

**Expected behavior**
No color shift at all (at least not consistent like it is there) as apparently was the case on this commit and before: 823cf946ec61896915850d2b1096637ee42b775d

Apparently this also appeared suddenly on hlky ui around the same time this was implemented https://github.com/sd-webui/stable-diffusion-webui/pull/308

I haven't checked this commits but this comes from posts complaining about the bug and referring to the commit where it worked fine.

I've tried to create luts that compensate for this phenomenon and they work alright, but they're a workaround, a correction to a problem, not a solution, and it adds some inconvenience to the process

A color correction option was implemented but it's rather inaccurate as its a histogram match and tends to create banding or turn soft light to hard light on the long run, all of this even after all the fixes that were done to it, as with any consistent correction it's going to shift the image at some point if it's not absolutely perfect.

And that's the thing, **tons of work has been put, by the devs (and myself on the side) trying to compensate for the problem after it happens instead of preventing it to begin with**. It looks like everything was fine and suddenly some shift appeared, which means that's not something that can't be reverted. I'm willing to help in any way since this to me is such a major problem as I don't trust the current color correction band aid fix and my luts can be limited sometimes and force me to get out of the UI, so I'm stuck having my most iterated pieces be magenta and that's no bueno.

If there is any info on why this happens and why it wouldn't be possible to fix at the source (that we know of) I'm willing to hear it and try to make it possible with my little hands to the max of my abilities, but I would need someone to show me the way as the code now is pretty thick
Repository: stable-diffusion-webui
Issue: Option to use separate directory for txt files other than 'next to the generated image'
Labels: enhancement

**Is your feature request related to a problem? Please describe.**
Using the setting "Create a text file next to every image with generation parameters." in combination with "Extra Large Icons" in Windows Explorer yields TXT/PNG/TXT/PNG/TXT/PNG which means that you can only view/review half the generated images in one go.

**Describe the solution you'd like**
An option in _Paths For Saving_ that still creates a text file for every image with generation parameters when that option is checked, but defaults to one level below the images, i.e. outputs/txt2img-images/text-files, rather than next to the images.

**Describe alternatives you've considered**
Creating a directory by hand, Waiting until the image generation is complete, then View->Details, Sort by File Type, Move TXT files to the manually-created textfiles directory by hand.

**Additional context**
![image](https://user-images.githubusercontent.com/3887073/196008508-ce847b3d-f2f9-458d-ad39-ce5c74e63635.png)
Repository: pytorch
Issue: Rewrite `narrow_copy_dense_cpu_out` using `copy_` and `narrow`
Labels: triaged,module: functionalization

### 🚀 The feature, motivation and pitch

Looks like the current implementation of `narrow_copy_dense_cpu_out` wasn't fully reviewed before being merged. Alban suggested a potential alternative implementation [here](https://github.com/pytorch/pytorch/pull/49502#issuecomment-759421583):

```cpp
Tensor& narrow_copy_dense_cpu_out( 
  const Tensor& self, int64_t dim, int64_t start, int64_t length, Tensor& output
) {
  // resize output
  auto output_sizes = self.sizes().vec();
  output_sizes[dim] = length;
  at::native::resize_(output, output_sizes);

  // write the content into output
  return output.copy_(at::narrow(self, dim, start, length));
}
```

I see two advantages:
- the code is much simpler
- it will use the same error checking logic as `narrow` (currently, the checks and error messages are slightly different).

Perf impact of this rewrite needs to be investigated first.

### Alternatives

_No response_

### Additional context

_No response_

cc @bdhirsh @ezyang @soumith
Repository: PowerToys
Issue: 5 Issues in Keyboard-Manager-Settings: combination of keys
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Needs-Triage

### Microsoft PowerToys version

0.63.0

### Running as admin

- [X] Yes

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

the gui works ok-ish to fill in the Settings, no step-description needed (see Screenshot of confirmed settings) but i dont know if the behavior is expected or not by the developers. Anyway, i didnt expect the outcome:

Environment: Windows 11 (Home) version 22H2:

all issues in Keyboard-Manager-Settings: combination of keys

1. when i redirect CTRL+V to WIN+V, the handy clipboard-history shows up, but the chosen clipboard-text will not paste.

2a). when i redirect WIN+E to shortcut 7zFM.exe the explorer will still open up but not 7z-Filemanager. After confirming the setting the mapping key is autmatically set to "Disable". 
2b) When I redirect Win+E and also set a mapping key to "none" for shortcut 7zFM.exe, a warning message shows up on setting confirm, followed by deleting the setting (confirming the warning message). 
2c) When I redirect WIN+E to mapping key "Disable" without a shortcut, the Win+E-combination is disabled (correctly?) for the explorer

3. After confirming the 7z-FM Keyboard-Settings, the process name i filled in, has changed automatically to 7zfm.exe, but i wrote correctly 7zFM.exe as it was listetd in console by command tasklist. the manual read like the naming differences are somewhat important between Application-Name and Process-Name, but case-sensitivity seems ignored by program.

![image](https://user-images.githubusercontent.com/68142280/196008912-1d469127-ead2-4055-991d-bcc68a859d47.png)

4. It is possible to redirect WIN+E to Win(Left)+E, also Win(right)+E to Win(left)+E but it is NOT possible to redirect Win(left)+E to Win(Left)+E.

5. There are Mapping-Keys, which are not on a standard keyboard, so can you please document names and what they do like "execute" (what, where and why, i thought the remapping DOES execute the shortcut in first place?) There is a mapping key "Enter" too, what is the difference?

6. (more a windows 11 bug, i think): setting a Keyboard-shortcut on a desktop-shortcut (.lnk-context-menue: properties) does not work at all (with or without Powertoys active)

But all the other powertoy features are really handy and they make Windows 11 somewhat usable at least. Can I downgrade to windows 10 please? for my bug-report i wrote with ❤️ ?

### ✔️ Expected Behavior

I expect that windows 11 is the final windows before mankind ends.

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: godot
Issue: Exporting a scene to MeshLibrary is extremely slow in 4.0.beta3 compared to 3.5
Labels: bug,topic:editor,needs testing,regression,topic:3d,performance

### Godot version

4.0.beta3_mono

### System information

Windows 10

### Issue description

Exporting a scene to mehslib is extremly slow (1 min+). This was not the case in previous version/s (3.5) before.

### Steps to reproduce

https://streamable.com/xcu67u

### Minimal reproduction project

[MeshLib_MRP.zip](https://github.com/godotengine/godot/files/9794446/MeshLib_MRP.zip)
Repository: rust
Issue: Confusing error message on trait bound not satisfied with supertraits
Labels: A-diagnostics,T-compiler,D-confusing,D-newcomer-roadblock

I'm not sure about my interpretation but the message is for me a little confusing. I've reproduced a minimal case. In the following code, there is a missing implementation of the trait A for the structure S.

[Link to the playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=3876b71cd084f1e607eb81cd758dd301)

```rust
trait A {}

trait B: A {}
impl<T> A for T where T: B {}

trait C: A {}

struct S {}
impl C for S {}
```

The current output is:

```
error[E0277]: the trait bound `S: B` is not satisfied
 --> src/main.rs:9:6
  |
9 | impl C for S {}
  |      ^ the trait `B` is not implemented for `S`
  |
note: required for `S` to implement `A`
 --> src/main.rs:4:9
  |
4 | impl<T> A for T where T: B {}
  |         ^     ^
note: required by a bound in `C`
 --> src/main.rs:6:10
  |
6 | trait C: A {}
  |          ^ required by this bound in `C`
```

I don't think the Trait B should appear in the error message. 
Ideally the output should look like:

```
the trait bound `S: A` is not satisfied
 --> src/main.rs:9:6
  |
9 | impl C for S {}
  |      ^ the trait `A` is not implemented for `S`
  |
note: required for `S` to implement `A`
 --> src/main.rs:4:9
  |
6 | trait C: A {}
  |          ^ required by this bound in `C`
```
I've tried the stable version: 1.61 and the nightly 1.66 on the playground with the same result. I've seen other issues on confusing error messages on traits but I don't think there are related to this one.