sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Extra inlay hints appearing in minimap
Labels: bug,editor-minimap

<!-- ⚠️⚠️ 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.74.2
- OS Version: Ubuntu 22.04

Steps to Reproduce:

This is the most bizarre one of the inlay issues.

1. Launch a simple language server, logging inlay hint requests and responses.
2. Set the server to respond always with a single hint on the second line of the request range, first character of that line (`[{"position":{"line": range.start.line + 1,"character":0},"label":"/* test1 */","tooltip":"test2","kind":2}]` or some such.
`)
3. Set `Editor > Inlay Hints` to offUnlessPressed.
4. Open a file, make it a few hundred lines long, empty.
5. Scroll to somewhere in the middle of the file.
6. Trigger inlay hints.

See that on the minimap, multiple inlay hints appear on different lines. (Although the extra ones are not in the view port, so you can't see them other than on the minimap).


![Captura desde 2023-01-06 18-21-06](https://user-images.githubusercontent.com/1279852/211003789-6404edc7-0b90-4457-b173-51362b21e3cc.png)

![Captura desde 2023-01-06 18-21-16](https://user-images.githubusercontent.com/1279852/211003894-ea67a6f8-2b34-4881-9bab-71e6885e629d.png)
Repository: godot
Issue: Editor: Issues with inner classes and the resource picker
Labels: bug,discussion,topic:gdscript,topic:editor

### Godot version

master

### System information

MacOS 10.15.7

### Issue description

#67614 added checks into create dialog and resource picker. Checks for create dialog were fixed as they were reported in #69889. But resource picker still has same problems "Cannot get class".

### Steps to reproduce

```gdscript
extends Node

class MyResource extends Resource: pass

@export var my_resource: MyResource = null
```

Create a single node and attach this script. Select node and get errors about getting class. This is an example with resource as nested class, but another case is `MyResource` is another non-global script that is preloaded.

### Minimal reproduction project

N/A
Repository: neovim
Issue: Buffer for first command-line file should inherit setglobal options from $MYVIMRC
Labels: enhancement,compatibility,startup

### Problem

As documented in `:help startup`, Nvim first creates buffers for files specified as command-line args (step 2), and only then processes `$MYVIMRC` (step 7). This means that the buffers created in step 2 inherit global options from Nvim's defaults, rather than from the customizations in `$MYVIMRC`:

```bash
$ echo 'setglobal colorcolumn=5' >vimrc
$ nvim -u vimrc foo
# foo shows no colorcolumn, but newly created buffers, e.g. `:e bar`, will.
```

While this behavior is documented (but see caveat below), it tends to be surprising for users (see e.g. [here](https://github.com/neovim/neovim/issues/21004#issuecomment-1307781284) or [here](https://github.com/vim/vim/issues/1712)), who expect that the `foo` buffer *should* in fact inherit options set with `setglobal` in `$MYVIMRC`. I would argue this is a reasonable expectation, because the actual behavior makes `setglobal` basically useless for `$MYVIMRC`.

For most users, this issue gets papered over because they use `set` instead of `setglobal` in their `$MYVIMRC`, and `set` sets both local and global values. However, `set` has the disadvantage that when users run `:source $MYVIMRC` during an editing session, it will reset local values *for the current buffer*. This is undesirable, as these values may have been customized (manually or via a modeline).

Historically, the incentives to use `set` over `setglobal` were 1) documentation / inertia and 2) it's considerably less to type. But `init.lua` and the Lua option interfaces are an opportunity to reset some of that inertia, and Lua makes it easy to define clean aliases, rendering point 2 moot:

```lua
-- I can swap these locals out for vim.o / vim.opt in one place.
local o = vim.go
local opt = vim.opt_global
-- Subsequent option definitions just use o and opt.
```

Also, while the documentation suggests that *all* buffers should ignore global options set in `$MYVIMRC`, in practice, I've observed this only applies to the *first* buffer (hence the title of the issue), all subsequent ones actually *do* inherit said global options. In other words, the current behavior is thus not only counterintuitive, but also inconsistent when passing multiple files to edit at the command line. This holds for both Nvim and Vim, try e.g. the following:

```bash
$ echo 'setglobal colorcolumn=5' >vimrc
$ nvim -u vimrc -O foo bar
# foo shows no colorcolumn, but bar does.
```

### Expected behavior

I think the intuitive and useful behavior would be that the buffer for the first command-line file inherits `setglobal` options from `$MYVIMRC`, like any subsequent ones already do:

```bash
$ echo 'setglobal colorcolumn=5' >vimrc
$ nvim -u vimrc foo
# foo shows a colorcolumn at column 5.
```
Repository: next.js
Issue: [NEXT-706] Turborepo with NextJS 13, error when import server component from package
Labels: bug,linear: next

### Verify canary release

- [x] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.4.0: Mon Feb 21 20:35:58 PST 2022; root:xnu-8020.101.4~2/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.12.1
      npm: 9.2.0
      Yarn: N/A
      pnpm: 7.18.0
    Relevant packages:
      next: 13.0.6
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

### Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true)

### Link to the code that reproduces this issue

https://github.com/matteo2437/turborepo-test

### To Reproduce

With this next.config.js settings:
module.exports = {
  reactStrictMode: true,
  experimental: {
    appDir: true,
    transpilePackages: ["ui"],
  },
};

Run the app called docs and you will see this error message:
Error: Unsupported Server Component type: undefined


### Describe the Bug

The problem is that I can't use any server component exported from a Turborepo package and imported in a Turborepo Next js 13 app with appDir settings to true. 

The problem is caused from the server component called Button inside the UI package that is imported in the docs app.

If you remove appDir from experimental the problem is fixed.
So I'm not finding a way for using server component exported from a Turborepo package in an app that use appDir settings to true.

This is the error:
![image](https://user-images.githubusercontent.com/68251639/211021215-2e4fb7c7-4acc-4b79-8d62-7408970afdb5.png)

And this is the server component exported from Ui package:

```tsx
"use client"

import { useState } from "react";

export const Button = () => {
  const [count, setCount] = useState(0)

  return (
    <button
      onClick={() => {
        console.log(count)
        setCount(count => count + 1)
      }}
    >
      {count}
    </button>
  );
};
```


### Expected Behavior

Import server component from Turborepo package in a Turborepo Next js 13 app without any error.

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

<sub>[NEXT-706](https://linear.app/vercel/issue/NEXT-706/turborepo-with-nextjs-13-error-when-import-server-component-from)</sub>
Repository: stable-diffusion-webui
Issue: [Feature Request]: Put a link functionality (and a chain icon button) between "Upscale by" and "Resize width to" and "Resize height to" sliders.
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

It would put the current (calculated from **width x "Resize by"** and **height x "Resize by"**) values in "Resize width to" and "Resize height to" bars respectively, and the numbers would stay after disabling the lock. It could be, for example, here.

![obraz](https://user-images.githubusercontent.com/55754730/211023234-91450ac4-8d98-4267-9f23-06ee7eb36a77.png)

Then, after deactivating the linking, the user would be able to change the "Upscale by" to 1, thus using only the calculated values.
Is it a beneficial idea?



### Proposed workflow

1. Enable "Hires. fix".
2. Press "Link" or similar checkbox near the "Upscale by" slider.
3. Watch the magic happen. :)


### Additional information

_No response_
Repository: opencv
Issue: GpuMat::convertTo() is unable to convert CV_8U to CV_16F
Labels: feature,category: core,category: gpu/cuda (contrib)

### System Information

OpenCV version: 4.5.4
Operating system: Windows 10
Compiler: Visual Studio 2019



### Detailed description

The conversion result into the GPU memory is only 0s!

The result into cpuTmp contains only zeroes!

Any idea how to solve this, or maybe there is another way for this conversion into the GPU memory?


### Steps to reproduce

Sample code:

cv::Mat cpuTmp, cpuMat(32,32,CV_8UC3,cv::Scalar(255,0,0)); //b,g,r
cv::cuda::GpuMat gpuMat, gpuMat16;
gpuMat.upload(cpuMat);
gpuMat.convertTo(gpuMat16, CV_16F);
gpuMat16.download(cpuTmp);

### Issue submission checklist

- [X] I report the issue, it's not a question
- [ ] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [ ] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: storybook
Issue: [Bug]: Interactions not rerunning on component save
Labels: bug,needs triage

### Describe the bug

Interactions are not rerun on component save.

This means that the interaction could report that there is no issue when there is one, or that an issue persists when it has been resolved.

The behaviour that I expected would be for interactions to rerun on component save, just as they do when the story file is saved.



### To Reproduce

```shell
Project created using `npx storybook repro`, selecting create react app typescript:
https://github.com/iamwillburn/sb-interactions-rerun

Screen recording of reproduction:
https://www.youtube.com/watch?v=fG2pl2R4YUM

Steps:
* Run Storybook.
* Visit the Header story, you will see a successful click interaction.
* Edit the Header.tsx component so that the 'Log in' button has different text, for example 'Nope', and save the file.
* Go back to the Header story, and you will see the 'Log in' button has become 'Nope', but the interaction is still showing as being successful. The interactions have not rerun.
* Edit the Header.stories.tsx file and save it.
* Go back to the Header story. As expected, the interactions will have rerun and the interaction will show as having failed.
```


### System

```shell
System:
    OS: macOS 13.1
    CPU: (8) arm64 Apple M2
  Binaries:
    Node: 18.6.0 - ~/.nvm/versions/node/v18.6.0/bin/node
    Yarn: 3.3.1 - ~/.nvm/versions/node/v18.6.0/bin/yarn
    npm: 8.13.2 - ~/.nvm/versions/node/v18.6.0/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Safari: 16.2
  npmPackages:
    @storybook/addon-actions: ^6.5.15 => 6.5.15 
    @storybook/addon-docs: ^6.5.15 => 6.5.15 
    @storybook/addon-essentials: ^6.5.15 => 6.5.15 
    @storybook/addon-interactions: ^6.5.15 => 6.5.15 
    @storybook/addon-links: ^6.5.15 => 6.5.15 
    @storybook/builder-webpack5: ^6.5.15 => 6.5.15 
    @storybook/manager-webpack5: ^6.5.15 => 6.5.15 
    @storybook/node-logger: ^6.5.15 => 6.5.15 
    @storybook/preset-create-react-app: ^4.1.2 => 4.1.2 
    @storybook/react: ^6.5.15 => 6.5.15 
    @storybook/testing-library: ^0.0.13 => 0.0.13
```


### Additional context

_No response_
Repository: vscode
Issue: Vietnamese typing error in code writing
Labels: bug,editor-input-IME

Type: <b>Bug</b>

I am using windows 11 and using EVKey script, Mode Unicode-Telex. Before updating to the current latest version, I still type normally with no errors but after updating, an error like this occurs.
Picture show error here: https://imgur.com/a/U4NwHOI

VS Code version: Code 1.74.2 (e8a3071ea4344d9d48ef8a4df2c097372b0c5161, 2022-12-20T10:29:14.590Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: No


<!-- generated by issue reporter -->
Repository: storybook
Issue: [Bug]: webpackStatsJson doesn't accept string type
Labels: bug,needs triage

### Describe the bug

This is the same issue that was fix for v7 here: https://github.com/storybookjs/storybook/pull/20296. Fix is also needed in current stable version in order to support Chromatic's Turbosnap functionality.

### To Reproduce

_No response_

### System

_No response_

### Additional context

_No response_
Repository: excalidraw
Issue: Copy as PNG and SVG with transparent background
Labels: bug,export

When you copy single elements, shapes etc. as PNG or SVG it always have a white background. It would be great if it would be possible to copy drawings with transparent background.

I know there is an option in settings to export image with background that can be turned off but it's for saving whole drawing and not single selected element.
Repository: PowerToys
Issue: FancyZones: "Space around zones" slider is infuriating to adjust
Labels: Issue-Bug,FancyZones-Editor,External Dependency,Area-User Interface,Area-Accessibility,Status-Blocked

### Microsoft PowerToys version

0.66.0

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

FancyZones

### Steps to reproduce

1. Open the FancyZones layout editor
2. Select "edit" on a Grid layout
3. Try to adjust the "Space around zones" slider

### ✔️ Expected Behavior

1. There is a way to enter an exact value.
2. The slider behaves normally around the low (0px) end.

### ❌ Actual Behavior

1. There appears to be no way to enter an exact value.
2. ~The slider behaves strangely around the low end, with the size of the window changing as the value changes between roughly 10 and -10, making it nearly impossible to select the value you want. See attached gif:~ Looks like this behavior was fixed in 0.70

![200031336-d811b51f-9f7c-4811-a649-66f819072209](https://user-images.githubusercontent.com/5142299/211036078-435d058d-ec50-40f0-8b79-db7868ad6eac.gif)


### Other Software

_No response_
Repository: next.js
Issue: Fetch being called twice when invalidating
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.15.0
      npm: 8.5.5
      Yarn: 1.22.19
      pnpm: 7.5.0
    Relevant packages:
      next: 13.1.2-canary.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

### Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true)

### Link to the code that reproduces this issue

https://github.com/patrick91/next-cache-exploration

### To Reproduce

Using the repo:

To run, start the backend first, you can do so by using docker:

```
cd backend
docker build -t next-backend-for-cache .
docker run -p 8000:8000 next-backend-for-cache
```

Then in another terminal:

```
cd frontend
pnpm i
pnpm run build
pnpm start
```

Now you can go to http://localhost:3000 and see the requests done
to the backend service in its terminal

### Describe the Bug

I've tried the following code to do a fetch request in a page in the new app dir:

```tsx
export default async function Home() {
  const query = `
    query {
      country(code: "CH") {
        name
      }
    }`;

  const qs = new URLSearchParams({ query });
  // const url = `http://localhost:8000?${qs.toString()}`;
  const url = `http://localhost:8000`;

  const data = await fetch(url, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ query }),
    next: {
      revalidate: 5,
    },
  }).then((res) => res.json());

  return (
    <pre>
      <code>{JSON.stringify(data, null, 2)}</code>
    </pre>
  );
}
```

It seems to work well and cache things as explained in the doc, but when it tries to invalidate it calls the endpoint twice as shown in the video below:

https://user-images.githubusercontent.com/667029/211041628-8bdd4ca2-342c-43f5-8fcb-91dfec0c0b6f.mp4

I'm uncertain if this is expected. I think it should only do a call and I haven't found anything related to this behaviour.

On top of that, the request is a POST request, not sure if we intend to cache them as well 🤔

### Expected Behavior

The backend service should be only called once per invalidation.

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

next start
Repository: go
Issue: runtime, x/mobile: Severe performance regression since 1.18+ on iOS, when combined with Xcode
Labels: help wanted,OS-Darwin,NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?
1.18 and higher

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
ios/arm64

### What did you do?

We’ve been noticing for a while now that starting with Go 1.18, performance for iOS apps that contain libraries written in Go has severely regressed, to the point where such apps  have become unusable under certain conditions. Under those conditions, an otherwise empty app that is calling an .xcframework generated from Go code using gomobile/bind, is experiencing severe fps drops (going as low as 5fps) even though CPU load is close to 0. 

Interestingly, the problem:

- Does not affect Go 1.17 and lower
- Affects all Go version since 1.18 (including git head)
- Is only present when the iOS device is connected to Xcode (either through USB or Wifi)
- Is _not_ present when the iOS device is connected to Xcode but the Xcode profiler is running. 
- Is _not_ present when the iOS device is NOT connected to Xcode

See attached for a very simple Go project, which is then compiled for iOS with gomobile/bind and wrapped in a Swift wrapper project. For convenience and ease of reproducibility, we’ve including both the full Swift Xcode project as well as pre-compiled .xcframework files based on Go 1.16.15 and 1.18.9 (in addition to the full Go source code). The actual Go project does nothing more than simulate some load by calculating a few sha265 hashes and then sleeping. 

To reproduce: simply run the project in XCode, and observe the fps counter. 

Note that the drop in performance doesn't just affect the Go code, but the full app containing the library, even code that does not depend in any way on the code being executed by the Go runtime. 

Perhaps this is in some way connected to the stack frame pointers/new register-based calling convention introduced for ios/arm64 in Go 1.18?

### What did you expect to see?
- Performance to be roughly similar regardless of using Go 1.17 or 1.18+. 
- Performance to be roughly similar regardless of being connected to Xcode or not

### What did you see instead?
Performance being fine with Go 1.17 and lower, while being very bad on Go 1.18 and higher. While CPU load is close to 0. 

### Project to reproduce
[go-ios-performance-regression-project.zip](https://github.com/golang/go/files/10361193/go-ios-performance-regression-project.zip)
Repository: flutter
Issue: Make currentResult of Route class writeable
Labels: c: new feature,framework,f: routes,c: proposal,P3,team-framework,triaged-framework

I want to reopen issue #77599 as I disagree that it is a duplicate of #77599. The latter deals with pushing multiple routes at once and popping a result.  While this one is about setting a result inside one route and a much smaller change.
## Use case

> Return a result from a Scaffold Widget when the user presses the back button.
> Right now the AppBar in the Scaffold uses a BackButton the only pops the current route and does not return a result.
> 
> Using WillPopScope with a willPop callback that calls Navigator.pop(context, someValue) and returns false is quite ugly.

Like the original author said using a `WillPopScope` is quite ugly and additionally disables the iOS back gesture (#14203).
```
WillPopScope(
      onWillPop: () async {
        Navigator.of(context).pop(myValue);
        return false;
      },
...
```

It was mentioned in a [#14203 comment](https://github.com/flutter/flutter/issues/14203#issuecomment-513577409) that there is another way to set the data, but never said how.

## Proposal

> Make currentRoute in the Route class writeable. At the moment currentRoute is read-only and always returns null.
I would like to set the `currentResult` to some value and if the user presses back this result should be returned:
```
ModalRoute.of(context).currentResult = someValue;
```

Modal routes already have a getter for `currentResult` which defaults to `null`. This is not overridden by any of the common route implementations like MaterialPageRoute or CupertinoPageRoute and is never actually used. See [navigator.dart#309](https://github.com/flutter/flutter/blob/507062032fa44678100c46250712f6b9dc07ba4b/packages/flutter/lib/src/widgets/navigator.dart#L309)
Repository: PowerToys
Issue: I think it'd be convenient to have a download progress bar and information like the update size.
Labels: Needs-Triage

### Description of the new feature / enhancement

A progress bar below the 'downloading' text that shows how much time is left. And some information about the update like the update size.

### Scenario when this would be used?

Showing data like the update size will help users decide whether to download the update using mobile data or not. It'll also save a lot of time because the users won't have to visit the website and look for the update size. Also, a progress bar will help users know how much time is left for an update to download.

### Supporting information

_No response_