sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Inconsistent padding in tab switcher
Labels: bug,polish,quick-pick

<!-- ⚠️⚠️ 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

<!-- 🪓 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.88.0-insider (f7c827a5e0ddbba66425ea54e33430bce8f53c84)
- OS Version: macOS Sonoma 14.4

The padding in the tab switcher (Ctrl + Tab) is too large at the bottom and slightly too small at the top:

![Bottom](https://github.com/microsoft/vscode/assets/1312807/289f0011-41a6-48c6-87fe-a3a9eb9fb278)

For other lists like file search, the padding is equal at the bottom and the left/right, which looks much better:

![Correct](https://github.com/microsoft/vscode/assets/1312807/40d59e00-8614-4f18-9cdc-600de66dae15)
Repository: vscode
Issue: Fold button margins are off between multi- and single-diff 
Labels: bug,multi-diff-editor

<img width="3200" alt="image" src="https://github.com/microsoft/vscode/assets/16353531/912a6e71-308d-4be9-bbce-05017bf9beac">


Version: 1.88.0-insider
Commit: f7c827a5e0ddbba66425ea54e33430bce8f53c84
Date: 2024-03-20T06:01:00.977Z
Electron: 28.2.6
ElectronBuildId: 27476517
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Darwin arm64 23.4.0
Repository: TypeScript
Issue: Command clicking FC's in react doesn't work anymore.
Labels: Needs More Info

<!-- ⚠️⚠️ 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/No

<!-- 🪓 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.87.2
- OS Version: macOS 14.1.1

Steps to Reproduce:

1. Open a react project with functional components
2. CMD Click a functional component from your code
3. It doesn't open the component. It opens the definition for `FC` in react
Repository: material-ui
Issue: [material-ui] Improve density for components
Labels: new feature,design: material,priority: important,package: material-ui

### Summary

Feature to globally set size for component variants. This would enable setting the size of each variant, which would then be applied to all components.

[This](https://stackoverflow.com/questions/59935298/how-to-scale-all-the-elements-in-material-ui) is a related question on Stack Overflow. People have attempted this but have not yet found a proper solution.

### Examples

[MD3 Shapes](https://developer.android.com/jetpack/compose/designsystems/material3#define_shapes)

### Motivation

I would like to scale all the components and font sizes from a single place, preferably with MUI [breakpoints](https://mui.com/material-ui/customization/breakpoints/). This can ensure a consistent appearance of the page regardless of the display size.

On some displays, the default component size is too large and occupies the entire screen. I cannot set the "small" variant for all components since I would like to keep the default variant on bigger screens.



**Search keywords**: global scale factor, shape MD3
Repository: ollama
Issue: Resumable `ollama push`
Labels: feature request,networking

### What is the issue?

When pushing models to ollama.com's registry, if they fail part way through - when you go to continue the push they start from scratch again.

This is quite painful when you've spent hours trying to upload from ~~Australian~~ a slow internet link as it can mean many hours of uploading and hoping for the best.

<img width="1678" alt="SCR-20240321-gzoz" src="https://github.com/ollama/ollama/assets/862951/f3dec809-4445-428e-8b70-3d4f7b9eb1da">

<img width="1675" alt="SCR-20240321-gzvk" src="https://github.com/ollama/ollama/assets/862951/d8d1e4ee-358d-4dd8-815c-c5b9bfc24dd6">



### What did you expect to see?

Errors happen, things fail - but they should be resumable (at least for say 24hrs).

I expected to run the push and have it pickup where it left off (around 8%).

### Steps to reproduce

- Come to Australia, enjoy our fine internet infrastructure.
- Push a large model to ollama.com
- Take pleasure in the chance game which is Australian internet reliability.
- When your upload fails, try to continue the upload by pushing again.
- Tears.

### Are there any recent changes that introduced the issue?

_No response_

### OS

Linux, macOS

### Architecture

arm64, amd64

### Platform

_No response_

### Ollama version

0.1.29

### GPU

Nvidia, Apple

### GPU info

N/A

### CPU

AMD, Apple

### Other software

_No response_
Repository: PowerToys
Issue: Screen ruler crash
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response,Product-Screen Ruler

### Microsoft PowerToys version

0.79.0

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

Screen ruler

### Steps to reproduce

Upon selecting a ruler, clicking anywhere on the screen randomly, and attempting to select the ruler again, the application crashes.

### ✔️ Expected Behavior

Stop measuring after click

### ❌ Actual Behavior

application stops responding. I get a window that says that and i can either close a program or wait until it responds.

### Other Software

_No response_
Repository: deno
Issue: Rewrite Headers, URL, URLSearchParams using CppGc
Labels: ext/web,refactor

Tbd
Repository: flutter
Issue: Configure builder commit batch size in .ci.yaml
Labels: team-infra,P2,triaged-infra

This is a feature request to add the ability to configure the commit batch size for each builder individually in the `.ci.yaml` file. As part of this feature, backfilling during idle periods should continue to happen, and intermediate commits would still be possible to trigger manually.

The desire for this feature is driven by potential impending resource constrains that may arise out of the deprecation of goma in post-submit mac builds. We may need a larger batch size for mac builds than for other builders.

cc @keyonghan @godofredoc
Repository: flutter
Issue: Print lint failure reason to stdout/err for engine android builds
Labels: P2,team-android,triaged-android

I believe that because we configure the android_background_image test app [to print to a file](https://github.com/flutter/engine/blob/98cfd921333273e9fac8a39359b6830f2b1a956f/testing/android_background_image/android/app/build.gradle#L13), the logs don't get printed in the ci output
Ex: https://ci.chromium.org/ui/p/flutter/builders/try/Linux%20Engine%20Drone/2122960/overview

[The docs for lintOptions](https://developer.android.com/reference/tools/gradle-api/4.1/com/android/build/api/dsl/LintOptions) cover how to make it print to stdout/stderr instead
Repository: electron
Issue: [Feature Request]: "blocking" version of setSaveDialogOptions
Labels: enhancement :sparkles:

### 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 feature request that matches the one I want to file, without success.

### Problem Description

I'm writing a file downloader which makes use of `DownloadItem.setSaveDialogOptions()`, and the behavior around it is unintuitive.

- The download / event handlers start during the dialog, when I would expect it to trigger only after the user has confirmed / canceled the dialog
- `item.getFilename()` doesn't update with the filename the user has selected from the dialog
  * `item.getSavePath()` will however
- No way of knowing when the dialog action has completed

### Proposed Solution

This might be difficult due to how `setSaveDialogOptions()` is coupled to the `DownloadItem`, but I'd like to see the following:

- A "blocking" version of `setSaveDialogOptions()` - `asyncSetSaveDialogOptions()`?
- When this version is used, the download is "paused" (since it seems the nature of `DownloadItem` is to just immediately download when created), and "resumed" if the user decides to save the file; `DownloadItem.cancel()` is called if the user cancels the dialog. The value returned from `asyncSetSaveDialogOptions()` would be a boolean to indicate if the user has confirmed or denied save.

### Alternatives Considered

**Edit: The below does not work. See comments on why and an actual fix**

Discovered a workaround: don't use `setSaveDialogOptions()` at all, but `dialog.showSaveDialog()` instead:

```typescript
// item from will-download handler
    item.pause()
    const result = await dialog.showSaveDialog(window, { defaultPath: filePath, ...saveDialogOptions })

    if (result.canceled) {
      item.cancel()
      return
    } else {
      item.setSavePath(result.filePath!)
      item.resume()
    }
```

### Additional Information

_No response_
Repository: vscode
Issue: Auto-load workspace file if it is the only workspace file in the folder root
Labels: feature-request,workbench-multiroot

<!-- ⚠️⚠️ 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. -->

Re-opening https://github.com/microsoft/vscode/issues/153452 and https://github.com/microsoft/vscode/issues/64565

## Problem

VSCode workspaces provide a lot of benefits for development. But sometimes developers on the team don't know about the feature or we forget to open the workspace and lose these benefits. The standard way to open the folder with VSCode or through `code .` will open without using the workspace. For Monorepos the workspace is 100% necessary and we want all developers to use it by default.
## Solution

Already, a prompt will appear saying "Open in Workspace", but this doesn't appear every time. It be preferred to provide a setting that automatically opens the workspace instead of needing to click that every time.

Ideally in `.vscode/settings.json` for the project, we could have:

```
{
  "workbench.openWorkspaceAutomatically": true
}
```

That way there is no user configuration required.
Repository: neovim
Issue: %:p does not work for buffer with no name
Labels: enhancement,needs:vim-patch

### Problem

Helo! I’m running into precisely the issue described in [Vim issue 10311](https://github.com/vim/vim/issues/10311). I’ve been unable to find a workaround yet (although I’m sure one exists).

### Expected behavior

Within filter commands, `%` would expand to an empty string for buffers with no name.
Repository: material-ui
Issue: [material-ui][docs] Links for pre-release versions (v6, v7) redirect to the latest version
Labels: docs,package: material-ui,support: docs-feedback

### Related page

https://mui.com/versions/

### Kind of issue

Unclear explanations

### Issue description

When attempting to access the documentation for pre-release versions such as v6 or v7 of Material-UI, the links redirect to the latest stable version instead of the specified pre-release version. This behavior makes it difficult for users to access the documentation relevant to the version they are interested in, hindering their ability to explore new features, changes, and updates specific to these pre-release versions.

### Context

_No response_

**Search keywords**: is:open is:closed Documentation links for pre-release versions
Repository: pytorch
Issue: DISABLED test_mlp_contiguous_relu_compile_cutlass (__main__.SparseSemiStructuredTensorCompileTest)
Labels: module: rocm,triaged,skipped

Platforms: rocm

This test was disabled because it is failing on main branch ([recent examples](https://torch-ci.com/failure?failureCaptures=%5B%22test_sparse_semi_structured.py%3A%3ASparseSemiStructuredTensorCompileTest%3A%3Atest_mlp_contiguous_relu_compile_cutlass%22%5D)).

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Repository: go
Issue: x/pkgsite: broken source file links for modules without hosted sources
Labels: pkgsite

### What is the URL of the page with the issue?

https://pkg.go.dev/buf.build/gen/go/grpc/grpc/protocolbuffers/go/grpc/service_config

### What is your user agent?

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

### Screenshot

_No response_

### What did you do?

This is an example of a module with its canonical source being a module host (proxy?)

https://pkg.go.dev/buf.build/gen/go/grpc/grpc/protocolbuffers/go/grpc/service_config

We can see it doesn't define source meta tags with:

```sh
$ curl 'https://buf.build/gen/go/grpc/grpc/protocolbuffers/go?go-get=1' 

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<meta name="go-import" content="buf.build/gen/go/grpc/grpc/protocolbuffers/go mod https://buf.build/gen/go">
	<title>Buf | Module buf.build/gen/go/grpc/grpc/protocolbuffers/go</title>
</head>
```

In the "Source Files" section on the page, the links to the filenames are clickable but they are just a self link to the current page.


### What did you see happen?

Link to current page, confused by a page refresh and no source shown.

### What did you expect to see?

The source files should not be clickable.

Or something like https://go-mod-viewer.appspot.com/ is used to show the source files (not sure who owns this but I saw @adonovan use it0
Repository: stable-diffusion-webui
Issue: [Bug]: Interrupt and Skip buttons sometimes disappear in Generate Forever mode
Labels: cannot-reproduce,bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

Sometimes in Generate Forever mode the UI thinks generation stopped, while it's still going on in the background. The Interrupt and Skip buttons will disappear and the Generate button becomes visible in their place. The terminal output indicates that generation is continuing (it shows ongoing progress).

When this happens, you can't cancel generation. You have to wait until it stops.

### Steps to reproduce the problem

1. Start Generate Forever
2. Press Interrupt while the first image is generation
3. Press Interrupt again a short moment later

I think I've seen it outside of Generate Forever mode when interrupting and restarting manually, but it happened less often and can't be reproduced like this.

### What should have happened?

WebUI should always be in sync with the generation.

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

Mozilla Firefox

### Sysinfo

Not anonymous enough.

### Console logs

```Shell
(There's nothing interesting on the console when this happens.)
```


### Additional information

_No response_
Repository: TypeScript
Issue: Improve comparable relation of template literal types to detect more impossible situations
Labels: Suggestion,Awaiting More Feedback

### 🔎 Search Terms

string condition always return false
2367 template

### 🕗 Version & Regression Information

This is the behavior in every version after 4.4.4 (including nightly), and I reviewed the FAQ for entries about "template" or "string"

This issue claims to fix a related problem in 4.5, but 4.5.5 is the first issue that fails for me. Maybe no relation though.
https://github.com/microsoft/TypeScript/issues/45201

In 4.4.4 it it fails correctly though, so maybe that fix is the regression of this issue?! https://www.typescriptlang.org/play?ts=4.4.4#code/C4TwDgpgBAglC8UAGBDAXGgJAbwHYFcBbAIwgCcBfJAKFEigCEFliMcCTyrrbxoANZkgAebPEVKUadaAE0h7CVxrUAxgHtcAZ2BR0sIeizYAjNw3bdrRkNbGzKizqiiogxCLEO1m5yDRQ8h443tQAlgBmUAAUwgjwiCAAlFDY1FBQTuoANhAAdNnqAObRAOTAABZhWlBaFer42QAmUBUoAG7QEShhuU2lSdQUPJExKPGIxClpGVm5BcVl3b01GmRkEKrA2SADQ9RAA

### ⏯ Playground Link

https://www.typescriptlang.org/play?#code/C4TwDgpgBAglC8UAGBDAXGgJAbwHYFcBbAIwgCcBfJAKFEigCEFliMcCTyrrbxoANZkgAebPEVKUadaAE0h7CVxrUAxgHtcAZ2BR0sIeizYAjNw3bdrRkNbGzKizqiiogxCLEO1m5yDRQ8h443tQAlgBmUAAUwgjwiCAAlFDY1FBQTuoANhAAdNnqAObRAOTAABZhWlBaFer42QAmUBUoAG7QEShhuU2lSdQUPJExKPGIxClpGVm5BcVl3b01GmRkEKrA2SADQ9RAA

### 💻 Code

```ts
type A = `a::${number}`
type B = `b::${number}`

type X = `x::${number}`
type Y = `${number}`

const a: A = `a::${1}`
const b: B = `b::${1}`

const x: X = `x::${1}`
const y: Y = `${1}`

if (x === y) {
  console.log('this should have failed')
}

if (a === b) {
  console.log('fails correctly')
}

```


### 🙁 Actual behavior

Comparing x and y generates no complaints from TS for `"x::1"` and `"1"`, but does for `"a::1"` and `"b::1"`. There is no way for a number to evaluate to `"x::` so there is no overlap between these template types.

### 🙂 Expected behavior

I would expect that Typescript shows that error consistently whenever types don't match.

There is no overlap between a string that must start with "x::" and one that must start with a number.

### Additional information about the issue

_No response_
Repository: pytorch
Issue: DISABLED test_relu_cuda_dynamic_shapes_cuda_wrapper (__main__.DynamicShapesCudaWrapperCudaTests)
Labels: module: rocm,triaged,module: flaky-tests,skipped,module: inductor

Platforms: rocm

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_relu_cuda_dynamic_shapes_cuda_wrapper&suite=DynamicShapesCudaWrapperCudaTests&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/22903581530).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 2 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_relu_cuda_dynamic_shapes_cuda_wrapper`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `inductor/test_cuda_cpp_wrapper.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @clee2000 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @amjames @desertfire @chauhang
Repository: godot
Issue: When I release my app on Google Play Console, current scene does NOT switch to next scene. 
Labels: discussion,platform:android

### Tested versions

Godot Engine v4.2.1.stable.official [b09f793f5]

### System information

macOS Sonoma v14.1.2

### Issue description

I'm not sure that this is a bug or my coding error, but I couldn't get what happened to me. 
When I release my app on Google Play Console, current scene does NOT switch to next scene. 
I used `get_tree().change_scene_to_file("res://Src/Start/Start.tscn")` to  switch scene. 
First time to load some scene had no problem, but the second time to load the same scene does NOT work. 

### Steps to reproduce

Note: My app contains some ads. If it is not nice, please let me know and I will fix it to stop ads temporarily. 
1. Clone my app from my [GitHub repository](https://github.com/mattsunkun/mathing). Export android .apk file and install it to local Android evice. 
2. Download the app from [Google Play](https://play.google.com/store/apps/details?id=com.mygame.android.mathing)
3. Play each game(by tapping the button "Beginner" to start) to the scene shown on the picture below. 
<img width="446" alt="image" src="https://github.com/godotengine/godot/assets/83483991/21f55c6d-0073-4e49-8701-c4e22e65f149">

4. Tap any enabled button
5. App from .apk worked, however app from Google Play does Not work. 




### Minimal reproduction project (MRP)

[My Working GitHub Repository](https://github.com/mattsunkun/mathing)
Repository: go
Issue: proposal: cmd/gofmt: permit single line case and statement
Labels: Proposal

### Proposal Details

Sometimes you have relatively simple switch statements that look like:
```go
switch color {
case MintCream:
    return "#F5FFFA"
case Azure:
    return "#F0FFFF"
case AliceBlue:
    return "#F0F8FF"
case GhostWhite:
    return "#F8F8FF"
...
}
```

In terms of total lines, this can get quite long.

I propose that we modify `gofmt` to permit keeping the `case` expression and the following statement on the same line if the statement is also a single line.

Thus, the above can be written as:
```go
switch color {
case MintCream:  return "#F5FFFA"
case Azure:      return "#F0FFFF"
case AliceBlue:  return "#F0F8FF"
case GhostWhite: return "#F8F8FF"
...
}
```
and `gofmt` won't try to rewrite into the expanded form. It will however, column align all vertically adjacent statements.

To be clear, I'm not proposing that `gofmt` rewrite existing expanded switch statements into the compact form,
only that it avoid expanding it if the author deliberately wrote it in the compact form.

The benefit of this is increased readability and consistency:
* Readability: All the color enums vertically appear together as a column without any interspersed color values. Similarly, all the color values appear together in a single column. Also, this representation takes half the lines, and so makes more efficient use of more of the editor pane's width.
* Consistency: There is syntactic similarity with something like a Go map literal:
```go
color := map[Color]string{
    MintCream:  "#F5FFFA",
    Azure:      "#F0FFFF",
    AliceBlue:  "#F0F8FF",
    GhostWhite: "#F8F8FF",
    ...
}
```

As with any formatting change, this can lead to less readable code, but the at least this change allows the programmer to best decide what is most readable and not have `gofmt` expand the whole switch statement. It also avoids the temptation to use a map literal just because it is more compact.