sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: `count` + `o` fired on_lines `count` times
Labels: performance

### Neovim version (nvim -v)

0.7.2

### Vim (not Nvim) behaves the same?

no

### Operating system/version

ArchLinux

### Terminal name/version

Alacritty

### $TERM environment variable

alacritty

### Installation

build from repo

### How to reproduce the issue

cat mini
```lua
local bufnr = vim.api.nvim_get_current_buf()
vim.schedule(function()
    vim.api.nvim_buf_attach(bufnr, false, {
        on_lines = function(name, bufnr, changedtick, firstLine, lastLine, lastLineUpdated, byteCount)
            print(firstLine, lastLine, lastLineUpdated)
        end
    })
    vim.cmd('norm! 1000o')
end)
```
nvim --clean -u mini.lua src/nvim/screen.c +1


### Expected behavior

output: `0 1 1001`

### Actual behavior

output:
```
1 1 2
1 2 3
....
1000 1001 1001
```

It's slow when plugins want to sync the lines for the buffer. Like treesitter enabled.
Repository: next.js
Issue: 500 error page throws client-side exception if it has a getStaticProps and there is a middleware.ts file
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 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.13.2
      npm: 8.7.0
      Yarn: 1.22.15
      pnpm: 6.11.0
    Relevant packages:
      next: 12.2.3-canary.12
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0


### What browser are you using? (if relevant)

n/a

### How are you deploying your application? (if relevant)

using `next start`

### Describe the Bug

In production, if my app has a 500.tsx file that has getStaticProps exported and it also has a middleware.ts file, **and the URL visited contains a query parameter,** the app will throw a client-side exception after rehydrating, but before any ErrorBoundary defined in _app could catch it.

The 500 page is first correctly rendered serverside, then is replaced by this message in the browser:

> Application error: a client-side exception has occurred (see the browser console for more information).

A number of superfluous requests seem to be being made:

<img width="1166" alt="Screenshot 2022-07-18 at 14 12 21" src="https://user-images.githubusercontent.com/156385/179518923-5c091ab8-2bad-4fca-afb4-0fc55bba23ff.png">

The issue only exists on 12.2 and above, it works correctly if I downgrade to 12.1.6 and convert back to the pre-release middleware usage. When the url did not have a query parameter, this issue was resolved in 12.2.4.

### Expected Behavior

I expect to see the static error page render successfully.

### Link to reproduction

https://codesandbox.io/s/gifted-alex-0hlens?a=b

### To Reproduce

- create a pages/500.ts file that has a getStaticProps
- create a middleware.ts file, it does not need to do anything (but also tested with always returning a NextResponse.next())
- throw in pages/index.ts when visiting the page with a query parameter
Repository: godot
Issue: Interpolating modulate with int is not signalled in debug mode but fails in release mode
Labels: bug,topic:core,topic:export

### Godot version

3.4.4-stable

### System information

Windows 10

### Issue description

Interpolating the "modulate" property, which is a Color, with int values does not yield a warning or error, and does nothing in debug mode. In release mode, it renders the CanvasItem black.

### Steps to reproduce

See project below

### Minimal reproduction project


[modulate_release.zip](https://github.com/godotengine/godot/files/9132244/modulate_release.zip)
Repository: pytorch
Issue: Windows Debug binaries crash on forward: assert fail on IListRefIterator destructor
Labels: oncall: jit

### 🐛 Describe the bug

libtorch 1.12 CUDA 11.6 on windows

I load a saved jit model, run it with the Release binary and it works.

If instead I compile and link with Debug binaries, at the 'forward' call i got an assert fail.

Line 405 of IListRef.h

In the trace i read a lot of box-unbox and a call to 'materialize'.
I believe the crash happens at the end of the forward, bceause some time has passed and the ram has been filled by some Gbs.

### Versions

[pip3] numpy==1.23.1
[pip3] torch==1.12.0+cu116
[pip3] torchaudio==0.12.0+cu116
[pip3] torchvision==0.13.0+cu116
[conda] Could not collect
Repository: godot
Issue: jitter and stuttering when moving kinematic body 2d
Labels: topic:core,needs testing,topic:2d

### Godot version

3.4.4

### System information

windows 11

### Issue description

When using on a battery (unplugged from power source) - any horizontal movement of kinematicbody2D, like

velocity.x+= (a number)

produces a very bad-looking jitter and stuttering

Problem occurs on Lenovo IdeaGaming laptop AMD Ryzen 5 5600H with Radeon Graphics  3.30 GHz

### Steps to reproduce

just unplug the laptop and see how smoothness of motion deteriorates

### Minimal reproduction project

_No response_
Repository: rust
Issue: Tracking Issue for native link modifier `as-needed`
Labels: A-linkage,T-compiler,C-tracking-issue,S-tracking-needs-to-bake

This is a tracking issue for native link modifier `as-needed`, which is a part of RFC "Linking modifiers for native libraries" (https://github.com/rust-lang/rust/issues/81490, https://github.com/rust-lang/rfcs/pull/2951).
The feature gate for the issue is `#![feature(native_link_modifiers_as_needed)]`.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
- [ ] Implement the RFC - #83507
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions

The modifier is not yet implemented for some Tier 1 targets (Apple targets).

### Implementation history
Repository: opencv
Issue: Java Finalize Class is a removal candidate in JDK 18
Labels: category: java bindings,RFC

##### Detailed description

Java Finalize Class is a removal candidate in JDK 18 ([link](https://openjdk.org/jeps/421)) and when I compiling OpenCV there are a lot of warnings about it.

```
    [javac] /Users/user/build/modules/java/jar/opencv/java/org/opencv/core/Mat.java:755: warning: [removal] finalize() in Object has been deprecated and marked for removal
    [javac]     protected void finalize() throws Throwable {
    [javac]                    ^
    [javac] /Users/user/build/modules/java/jar/opencv/java/org/opencv/core/Mat.java:757: warning: [removal] finalize() in Object has been deprecated and marked for removal
    [javac]         super.finalize();
    [javac]              ^
```

##### Issue submission checklist

 - [x] I report the issue, it's not a question
   <!--
   OpenCV team works with forum.opencv.org, Stack Overflow and other communities
   to discuss problems. Tickets with questions without a real issue statement will be
   closed.
   -->
 - [x] I checked the problem with documentation, FAQ, open issues,
       forum.opencv.org, Stack Overflow, etc and have not found any solution
   <!--
   Places to check:
   * OpenCV documentation: https://docs.opencv.org
   * FAQ page: https://github.com/opencv/opencv/wiki/FAQ
   * OpenCV forum: https://forum.opencv.org
   * OpenCV issue tracker: https://github.com/opencv/opencv/issues?q=is%3Aissue
   * Stack Overflow branch: https://stackoverflow.com/questions/tagged/opencv
   -->
 - [x] I updated to the latest OpenCV version and the issue is still there
   <!--
   master branch for OpenCV 4.x and 3.4 branch for OpenCV 3.x releases.
   OpenCV team supports only the latest release for each branch.
   The ticket is closed if the problem is not reproduced with the modern version.
   -->
 - [ ] There is reproducer code and related data files: videos, images, onnx, etc
   <!--
   The best reproducer -- test case for OpenCV that we can add to the library.
   Recommendations for media files and binary files:
   * Try to reproduce the issue with images and videos in opencv_extra repository
     to reduce attachment size
   * Use PNG for images, if you report some CV related bug, but not image reader
     issue
   * Attach the image as an archive to the ticket, if you report some reader issue.
     Image hosting services compress images and it breaks the repro code.
   * Provide ONNX file for some public model or ONNX file with random weights,
     if you report ONNX parsing or handling issue. Architecture details diagram
     from netron tool can be very useful too. See https://lutzroeder.github.io/netron/
   -->
Repository: go
Issue: cmd/go: go work init won't create nested workspaces
Labels: NeedsInvestigation,GoCommand,modules

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.18.1 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/thockin/.cache/go-build"
GOENV="/home/thockin/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/thockin/src/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/thockin/src/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/thockin/src/go-spew/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build907218417=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

CWD is a workspace, with a valid go.work file.

```
$ mkdir d

$ cd d

$ go work init
go: /home/thockin/src/kubernetes/go.work already exists

$ gotip version
go version devel go1.19-c0c1bbde17 Mon Jul 18 15:58:37 2022 +0000 linux/amd64

$ gotip work init
go: /home/thockin/src/kubernetes/go.work already exists
```

I am trying to isolate the deps in a sub-module from the deps in the workspace (as suggested in a different thread).

Manually creating a go.work file does achieve the ffect I wanted.

### What did you expect to see?

I thought it would work

### What did you see instead?

The above error
Repository: opencv
Issue: Lack of function for closing the image in the display-image tutorial
Labels: category: documentation,category: samples

In the Python guide to displaying an image found in the documentation ([link](https://docs.opencv.org/4.x/db/deb/tutorial_display_image.html)) it says:

> Because we want our window to be displayed until the user presses a key (otherwise the program would end far too quickly) ...

I find this statement misleading because in the code given as an example (available [here](https://github.com/opencv/opencv/blob/4.x/samples/python/tutorial_code/introduction/display_image/display_image.py) and shown in the next few lines), there is no call to the destroyWindow function to actually close the window containing the image (which is the behaviour described in the guide and which one would therefore expect).

```python
## [imports]
import cv2 as cv
import sys
## [imports]
## [imread]
img = cv.imread(cv.samples.findFile("starry_night.jpg"))
## [imread]
## [empty]
if img is None:
    sys.exit("Could not read the image.")
## [empty]
## [imshow]
cv.imshow("Display window", img)
k = cv.waitKey(0)
## [imshow]
## [imsave]
if k == ord("s"):
    cv.imwrite("starry_night.png", img)
## [imsave]
```

Am I doing something wrong or can the guide actually be considered misleading?
Repository: rust
Issue: Tracking Issue for linker arguments respecting their relative order with `-l` library options
Labels: A-linkage,T-compiler,C-tracking-issue

This is a tracking issue for link arguments respecting their relative order with `-l` library options, which is a part of RFC "Linking modifiers for native libraries" (https://github.com/rust-lang/rust/issues/81490, https://github.com/rust-lang/rfcs/pull/2951), https://github.com/rust-lang/rfcs/blob/master/text/2951-native-link-modifiers.md#relative-order-of--l-and--clink-args-options specifically.
There's no feature gate for the issue.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
- [x] Implement the RFC - https://github.com/rust-lang/rust/pull/99467
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions

The feature is unlikely to be implementable in the form that is specified in the RFC, i.e. by preserving relative order of `-l` and `-Clink-arg(s)` options.
`-C link-arg` was usable for overriding options previously passed by the compiler for long time, so is pretty much guaranteed to be passed at the end of command line at this point.

The suggested solution (see https://github.com/rust-lang/rust/issues/81490 and below) is to reuse the `-l` option for such arguments and introduce `-l link-arg=arbitrary-link-argument`, which is exactly like `-C link-arg=arbitrary-link-argument`, except that its relative order to other `-l` options is respected.

### Implementation history
Repository: go
Issue: proposal: x/sync/semaphore: expose the size  
Labels: Proposal

In my usages of  `sempahore`, I'm doing something like:
```go 
const maxWeight = ...
sema := semaphore.NewWeighted(maxWeight)
...
for ... {
    size := object.Size()
    if size > maxWeight {
        // Object is too large to fit in memory, switch to a streaming mode.
        object.StreamingMode(true)
        size = maxWeight // use the maximum weight to have exclusive lock over semaphore
    }
    sema.Acquire(size)
    go func() {
        defer sema.Release(size)
        ...
    }
}
```

You will notice that I'm passing around both `sema` and `maxWeight`. However, this is a somewhat unnecessary since the unexported `sema.size` field is exactly the information I need.

I propose adding a `Capacity` method:
```go
// Capacity returns the maximum combined weight this semaphore is constructed with.
func (s *Weighted) Capacity() int64 {
    return s.size
}
```

Alternative names: `Weight`, `MaxWeight`, `MaxSize`. We should choose a name that would not prevent the possible future addition of a something like `Length` where we return the value of `s.cur`. The names of `Length` of `Capacity` would match the names of `len(c)` and `cap(c)` when a channel is used a semaphore.

\cc @jba
Repository: rust
Issue: Improve borrow error when assigning borrowed local value to "argument by mutable reference"
Labels: A-diagnostics,A-lifetimes,A-borrow-checker,T-compiler,D-papercut,D-newcomer-roadblock

Given

```
fn f(mut p: &mut i32) {

    let mut number = 111;
    p = &mut number;

    *p = 2;
    println!("{}", *p);
}
```

we currently emit

```
error[E0597]: `number` does not live long enough
 --> f44.rs:4:9
  |
1 | fn f(mut p: &mut i32) {
  |             - let's call the lifetime of this reference `'1`
...
4 |     p = &mut number;
  |     ----^^^^^^^^^^^
  |     |   |
  |     |   borrowed value does not live long enough
  |     assignment requires that `number` is borrowed for `'1`
...
8 | }
  | - `number` dropped here while still borrowed
```

but it could be more informative:

```
error[E0597]: `number` does not live long enough
 --> f44.rs:4:9
  |
1 | fn f(mut p: &mut i32) {
  |             - let's call the lifetime of this reference `'1`
...
3 |     let mut number = 111;
  |             -----   --- this value is assigned to `number` and lives as long as `f`
  |             |
  |             this binding only lives for the duration of function `f` and gets dropped at the function
4 |     p = &mut number;
  |     ----^^^^^^^^^^^
  |     |   |
  |     |   borrowed value does not live long enough
  |     this assignment to `p` will outlive `f` because it is a `&mut i32` owned by the caller's scope
...
8 | }
  | - `number` dropped here while still borrowed
```
Repository: flutter
Issue: Chrome's "minimum font size" seems to have no effect on web text
Labels: framework,engine,a: accessibility,a: typography,platform-web,e: web_canvaskit,P3,team-web,triaged-web

Changing Chrome's minimum font size setting doesn't seem to end up changing Flutter's text size. 
<img width="753" alt="Screen Shot 2022-07-18 at 11 16 58 AM" src="https://user-images.githubusercontent.com/156888/179576376-c0476f3f-44a1-4470-a146-1c53a173fbc5.png">
<img width="1547" alt="Screen Shot 2022-07-18 at 11 17 07 AM" src="https://user-images.githubusercontent.com/156888/179576413-0a4fdbf5-13b1-4eeb-bc62-8f9cfe6158b1.png">

<img width="747" alt="Screen Shot 2022-07-18 at 11 17 16 AM" src="https://user-images.githubusercontent.com/156888/179576435-3085ea18-4e4b-4a37-9c34-6d5c2f6a0248.png">
<img width="1441" alt="Screen Shot 2022-07-18 at 11 17 22 AM" src="https://user-images.githubusercontent.com/156888/179576453-b8846889-08e0-4ccf-bfb3-460e1943f3e1.png">

See above image. Everything else in the browser changed size, but the rendered text did not
Repository: pytorch
Issue: `sparse_coo.to_dense()` produces different results between CPU and CUDA backends for boolean non-coalesced inputs.
Labels: module: sparse,triaged

### 🐛 Describe the bug

As per title. To reproduce, run the following:

```python
In [1]: import torch

In [2]: idx = torch.tensor([[1, 1, 1, 2, 2, 2], [2, 2, 1, 3, 3, 3]], dtype=torch.long)

In [3]: val = torch.tensor([True, False, True, False, False, True])

In [4]: s = torch.sparse_coo_tensor(idx, val, size=(10, 10))

In [5]: torch.all(s.to('cuda').to_dense() == s.to_dense().to('cuda'))
Out[5]: tensor(False, device='cuda:0')

```

The CPU result seems correct, so I assume a parallelization issue.

### Versions

Current master.

cc @nikitaved @pearu @cpuhrsch @amjames
Repository: pytorch
Issue: Idiom for PrimTorch refs for Tensor methods
Labels: triaged,module: primTorch

### 🐛 Describe the bug

Right now if you want to write a ref for a Tensor method, there's no precedent for how to do this. Some of these right now are getting dumped directly in torch._refs which is wrong (since torch._refs.foo should only exist if torch.foo exists, but some methods do not exist as functions) and getting remapped with `torch_to_refs_map`

The goal would be to create some sort of synthetic class or module for tensor methods, and then automatically map tensor methods to that class, so that TorchRefsMode works out of the box with a new tensor without having to route through a special case mapping.

### Versions

master

cc @ezyang @mruberry @ngimel
Repository: pytorch
Issue: RFC: auto-generated plain Tensor argument only sparse primitives
Labels: module: sparse,triaged

### 🐛 Describe the bug

When we say `at::add(sparse_x, sparse_y)`, this is an operator that takes in two sparse tensors and produces a sparse tensor. This requires a backend compiler to have a model of what it means to be a sparse tensor. Sometimes, this is inconvenient for a backend; the backend would rather have the input all be in terms of dense inputs.

We can help by generating sparse prims that are expressed entirely in terms of dense tensors. So for example, the sparse variant of at::add above would be `sparse_prims::add(self_sparse_dim: int, self_dense_dim: int, self_size: int[], self_indices: Tensor, self_values: Tensor, other_sparse_dim: int, other_dense_dim: int, other_size: int[], other_indices: Tensor, other_values: Tensor) -> (int, int, int[], Tensor, Tensor)`. Essentially, each of the substantive fields in the sparse tensor (sparse dim, dense dim, size, indices and values) has been inlined into the function argument. The new function signature is Tensors only and doesn't have any explicit sparse tensors.

Some notes:

* In many situations, a sparse operation isn't supported in full generality. For example, the add signature above suggests that it is ok to mix different amounts of sparse/dense dims in addition. In actuality, they have to be the same (so the second pair of sparse dense dims could be deleted.) This simplification cannot be done mechanically, you have to know about the preconditions for the function. But we could imagine further decomposing these prims by hand into simpler versions, eliminating the need for backends to do this error checking.
* You need separate sparse prim for multiple dispatch; e.g. dense-sparse addition needs yet another prim. sparse-dense addition should decompose into dense-sparse and thus not require another prim.
* AOTDispatch would be responsible for unpacking and repacking the dense tensors into sparse tensors. 
* This trick applies to all TensorImpl subclasses which ultimately backend to dense tensors

We could also *not* do this and force passes and compilers to know how to deal with sparse tensors directly.

cc @nikitaved @pearu @cpuhrsch @amjames, please tag anyone else relevant   
cc @bdhirsh 

### Versions

master