sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: "expected bound lifetime parameter, found concrete lifetime" when passing a 'static reference to a closure that returns a future
Labels: A-diagnostics,A-lifetimes,P-medium,A-closures,T-compiler,C-bug,A-async-await,AsyncAwait-Triaged

```rust
use std::future::Future;

fn main() {
    let _ = wrapper(hello);
}

static GLOBAL: i32 = 42;

async fn wrapper<F, FutResp>(f: F)
where
    F: Fn(&i32) -> FutResp,
    FutResp: Future<Output = ()>,
{
    f(&GLOBAL).await
}

async fn hello(_: &i32) {
    println!("Hello");
}
```

([Playground](https://play.integer32.com/?version=stable&mode=debug&edition=2018&gist=27552741e074086dcc84a6734fe862cc))

Errors:

```
error[E0271]: type mismatch resolving `for<'r> <for<'_> fn(&i32) -> impl std::future::Future {hello} as std::ops::FnOnce<(&'r i32,)>>::Output == _`
  --> src/main.rs:4:13
   |
4  |     let _ = wrapper(hello);
   |             ^^^^^^^ expected bound lifetime parameter, found concrete lifetime
...
9  | async fn wrapper<F, FutResp>(f: F)
   |          -------
10 | where
11 |     F: Fn(&i32) -> FutResp,
   |                    ------- required by this bound in `wrapper`
```

I can make the code work by restricting the closure to only accept `'static` references:

```rust
async fn wrapper<F, FutResp>(f: F)
where
    F: Fn(&'static i32) -> FutResp,
    //     ^^^^^^^
    FutResp: Future<Output = ()>,
```

I did try to add `'static` bounds to the response future (and the closure, for good measure), but this did not help:

```rust
async fn wrapper<F, FutResp>(f: F)
where
    F: Fn(&i32) -> FutResp + 'static,
    FutResp: Future<Output = ()> + 'static,
```

The equivalent(?) synchronous code works as I'd expect:

```rust
fn main() {
    let _ = wrapper(hello);
}

static GLOBAL: i32 = 42;

fn wrapper<F>(f: F)
where
    F: Fn(&i32) -> (),
{
    f(&GLOBAL)
}

fn hello(_: &i32) {
    println!("Hello");
}
```
Repository: flutter
Issue: [fuchsia] Use FIDL types dart:fuchsia as opposed to Handle
Labels: team,engine,platform-fuchsia,P2,team-engine,triaged-engine

We currently expose every exported object in [fuchsia.dart](https://github.com/flutter/engine/blob/master/shell/platform/fuchsia/dart-pkg/fuchsia/lib/fuchsia.dart) as a raw `Handle` type. We can use the FIDL types instead.
Repository: go
Issue: go/parser: bad error message for a badly formed func literal
Labels: NeedsFix

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +8e0be05ec7 Sun Jan 19 14:04:09 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200121200311-d456b1cd8c86
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20200121200311-d456b1cd8c86
</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/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.vim/plugged/govim/go.mod"
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-build878422207=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

The diagnostic for the following file is misleading:

```
package main

func main() {
	_ = func(format string, args ...interface) error {
		return nil
	}
}
```

We get:

```
PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
    URI:         "file:///home/myitcv/gostuff/src/github.com/myitcv/playground/main.go",
    Version:     36,
    Diagnostics: {
        {
            Range: protocol.Range{
                Start: protocol.Position{Line:3, Character:5},
                End:   protocol.Position{Line:3, Character:5},
            },
            Severity:           1,
            Code:               nil,
            Source:             "syntax",
            Message:            "expected expression",
            Tags:               nil,
            RelatedInformation: nil,
        },
    },
}
```

Contrast what we get from the compiler:

```
./main.go:4:43: syntax error: unexpected ), expecting {
./main.go:5:3: syntax error: unexpected return, expecting comma or )
./main.go:7:1: syntax error: non-declaration statement outside function body
```


### What did you expect to see?

A better diagnostic. 

### What did you see instead?

Per above

Marking as `gopls/v1.0.0` because this isn't critical for `v0.3.0`.

---

cc @stamblerre

FYI @leitzler
Repository: flutter
Issue: Unreadable error message, red font in powershell
Labels: tool,platform-windows,a: quality,has reproducible steps,P3,found in release: 3.0,found in release: 3.1,team-tool,triaged-tool

## Steps to Reproduce

<!-- You must include full steps to reproduce so that we can reproduce the problem. -->

1. Run 
```
flutter create bug
cd bug
flutter run -d chrome
```
2. Update the files as follows: Add `var c = 1 + 'a';` in a widget build.
3. Press R in powershell

**Expected results:** readable font colors in errors

**Actual results:** unreadable font colors in errors

Here is a screenshot,

![Capture](https://user-images.githubusercontent.com/6107051/73103924-19d85280-3eed-11ea-8de3-0ecf3129a740.PNG)
Repository: flutter
Issue: URL provided to report issue should not have a dot at the end
Labels: tool,framework,c: proposal,a: error message,a: triage improvements,P3,team-framework,triaged-framework

You can see below that an url to https://github.com/flutter/flutter/issues have been provided. However, it has a dot at the end and so when clicking on it, the browser gave me a 404.

> :\repos\hotcheapdeal>flutter generate
> generating build script...                                         37.6s
> starting build daemon...                                            0.2s
> 
> Sending crash report to Google.
> Crash report sent (report ID: 8e59f442adf107b6)
> Oops; flutter has exited unexpectedly.
>  
> Crash report written to C:\repos\hotcheapdeal\flutter_01.log;
> please let us know at https://github.com/flutter/flutter/issues.
Repository: flutter
Issue: [fuchsia] Write a test for exposed handles in dart:fuchsia
Labels: engine,platform-fuchsia,P2,team-engine,triaged-engine

There are a few handles exposed in`fuchsia.dart` in `dart:fuchsia`. To write tests for these, it would be useful to have the ability to invoke dart fixtures. This will be enabled by the work that @gw280 is doing on shell_unittests on Fuchsia.

The intent of this issue is to track the writing of these tests.
Repository: go
Issue: x/build: get more coverage with the ssacheck builder
Labels: Builders,NeedsInvestigation

The ssacheck builder currently builds only amd64, and with a fixed random seed.

We should improve on both dimensions.

* CL 216418 lets us provide a random seed. We could generate the random seed and print it to stdout before using it, so that any failure will be reproducible from the log.
* We should either run on all architectures, or pick one at random each time from `go tool dist list` (and log it, for reproducibility).

I suspect that doing both of these things is pretty easy, and it'd get us extra test coverage, so it'd be nice to do soon. This would have caught both https://github.com/golang/go/issues/36723 and https://github.com/golang/go/issues/36755.

cc @cherrymui @randall77 @dmitshur @bradfitz
Repository: godot
Issue: parsing a json will pass the json non fatal parse error in the debug
Labels: bug,topic:core

as of #33201 i think json parse errors are returned to the dialogue window, however they are not filtered, making non fatal errors appear there, that actually are a bit misleading to read and do not cause any issue in the paring result dictionary

sometimes when loading _settings from file
(attempting to parse an empty line)

```
E 0:00:03.694   GDScriptFunctions::call: Error parsing JSON at line 0: 
  <C++ Source>  modules\gdscript\gdscript_functions.cpp:1263 @ GDScriptFunctions::call()
```

when calling parse on a http response:
`var jsonresult = JSON.parse(body.get_string_from_utf8())`

(attempting to parse an OK response before the json text)
```
E 0:00:06.298   parse: Error parsing JSON at line 0: Expected 'true','false' or 'null', got 'OK'.
  <C++ Source>  core/bind/core_bind.cpp:3220 @ parse()
  <Stack Trace> HTTPOnlineRecords.gd:65 @ _on_HTTPOnlineRecords_request_completed()
```
Repository: godot
Issue: Reading pixels of an image from two threads causes errors
Labels: enhancement

Godot 3.2 rc3
Windows 10 64 bits

I need to read pixels of an image from multiple threads at once. Since it internally uses a `Write` lock, my expectation was that `lock()` would trigger copy-on-write if it's already locked by another thread. But instead, it produces errors:
```
ERROR: Image must be locked with 'lock()' before using get_pixel().
   At: core/image.cpp:2389
```
I am calling `lock()` and `unlock()` properly so it must be something else (unless I misunderstand how to use `Image`?).

I originally had this issue in C++ while developping a module in a much more heavy reading routine, which resulted in huge error spam and eventual crash, here `alloc` is null:
![image](https://user-images.githubusercontent.com/1311555/73110943-316d0680-3f00-11ea-9e73-a08cf2253e67.png)

I had a peek at the state of the Write struct when `get_pixel` is called: the pointer to pixels became null.

Reproduction project:
[ImageReadInTwoThreads.zip](https://github.com/godotengine/godot/files/4111164/ImageReadInTwoThreads.zip)
Repository: rust
Issue: Add note for to clarify trait restriction for function if we get (in my example "borrow as mutable" error)
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,D-papercut

Code example
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=63c770ffce3c7420dd845653f7250b9f
We can try brute force all implementation, dropping trait restriction:
for generic type 
for concrete type
If we find some implementation which allow you to get rid of this error (or maybe from all errors). 
We can provide note with candidates and fix for restriction
Repository: vscode
Issue: Settings can not show up in search when they are not included in settingsLayout.ts
Labels: bug,debt,settings-editor

- Add a setting, excluded from settingsLayout.ts, e.g. `timeline.showView`
- It shows up when I search `time` but not `timel`
- Make sure that there is no bad underlying bug...
Repository: excalidraw
Issue: suggestion: moving to a border of the viewport while resizing/selecting triggers scrolling
Labels: enhancement
Repository: create-react-app
Issue: Allow `devDependencies` in template.json
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?
N/A
<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

### Describe the solution you'd like
Allow a user to state deveDependencies for a template by setting devDependencies in the template.json
<!--
  Provide a clear and concise description of what you want to happen.
-->


### Describe alternatives you've considered

<!--
  Let us know about other solutions you've tried or researched.
-->


### Additional context

<!--
  Is there anything else you can add about the proposal?
  You might want to link to related issues here, if you haven't already.
-->
Repository: TypeScript
Issue: Revaluate default props behavior in JSX functional components
Labels: Suggestion,Needs Proposal

Regarding the recognition of default initializers as part of type checking on functional components, I believe issues #32402 and #31247 should be reevaluated in the light of #34547 and the potential deprecation of defaultProps, and also on the own merits of both issues. 

**TypeScript Version:**  3.7.5

**Search Terms:**
defaulProps, FunctionalComponent, JSX, React

**Code**
View issues #32402 and #31247

**Expected behavior:**
View issues #32402 and #31247

**Actual behavior:**
View issues #32402 and #31247

**Playground Link:**
View issues #32402 and #31247

**Related Issues:**
Issues #32402 and #31247 =D
Repository: godot
Issue: [GDNative] Misleading godot_x_new_copy/operator_equal functions for array/dictionary/pool arrays
Labels: bug,topic:gdextension

I order to copy an array (same thing for a dictionary and pool array) you should use `godot_array_new_copy` array... but if you want to *copy* the array you should use `godot_array_duplicate` ! :trollface: 

The difference comes from the fact godot_array is a cheap structure pointing on a ref counted vector.
Using `godot_array_new_copy` only copy the cheap structure where `godot_array_duplicate` also copy the vector. In the first case we end up with a single array referenced by two godot_array variables, in the second we have two totally different arrays each referenced by their own godot_array variable.

This is even worst for pool arrays given they don't provide duplicate function, so user reading the api is really enclined to think `godot_pool_x_array_new_copy` *is* the way to do a duplication !

I personally got bitten by this multiple times, so I guess we should try to clarify a bit the naming here.

I guess renaming `godot_x_new_copy` into `godot_x_new_reference` would be enough, what do you think ?
Repository: opencv
Issue: OpenCV java vm crashes should be avoided 
Labels: bug,category: java bindings,incomplete,needs reproducer

##### System information (version)
- OpenCV 3.4.8
- Operating System / Platform => MacOS HighSierra 10.13.6
- Compiler => Oracle Java 1.8.0_152

##### Detailed description

At http://wiki.bitplan.com/index.php/OpenCV#Issues you'll find two issues that crash the Java VM when a problem occurs in the OpenCV dynamically linked library.

The expected behavior would be not to crash the VM but throw a normal java runtime exception. 

##### Steps to reproduce
The second example seems to be simpler to reproduce. Try opening a video-image connection to a server refusing it. E.g. an mjpegstreamer device.
Repository: godot
Issue: Child in ScrollContainer can be moved when its size is not bigger than the ScrollContainer's size
Labels: bug,topic:gui

**Godot version:**
3.2 rc 2

**OS/device including version:**

**Issue description:**

**Steps to reproduce:**
1 add a scrollcontainer, set the rect_size to 1080 X 1080
2 add a colorrect as a child of scrollcontainer, and set the size to 1080 X 1080
3 the colorrect can be  dragged  around a very large distance
Even when the child's size is less than the scrollcontainer's, it still can be dragged.

In 3.1, when the size is the same, the movement is very tiny, it's acceptable if take the size of bar int consideration .

**Minimal reproduction project:**
Repository: pytorch
Issue: Logical AND and OR for Tensors in C++ API.
Labels: module: cpp,triaged,function request

## 🚀 Feature

The `at::Tensor` datatype does not have `&` overloaded the way it is in the python API, thus not allowing for boolean element-wise operations between tensors.

## Motivation

I want to call the `at::where()` function with a boolean tensor that is the outcome of the AND of two conditions.

## Pitch

Something like this should be possible:
``` c++
  auto output = at::where((target > -EPSILON) & (target < EPSILON), all_zeros, whatever_values);
```
## Alternatives

This is ugly and tedious IMO:

``` c++
  auto output = at::where(target > -EPSILON, output_pos, zeros);
  output = at::where(output < EPSILON, zeros, output_pos);
```


cc @yf225 @glaringlee
Repository: go
Issue: net/http: http.Client.Do() sometimes throws INTERNAL_ERROR when using high number of parallel HTTP/2 requests (regression between 1.12 and 1.13.4)
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

```
go version go1.13.4 darwin/amd64
```

(also reproduced with 1.13.6)

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

```
GO111MODULE="off"
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13.4/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/k7/jx2bs5q170z4lvdzbsdt426r0000gn/T/go-build634112063=/tmp/go-build -gno-record-gcc-switches -fno-common"
```

### What did you do?

Create several http.Clients, and call a high number of simultaneous multipart byterange requests on each of them. Make sure the server supports HTTP/2. 

### What did you expect to see?

No errors being thrown. Which is the case on Go 1.12

### What did you see instead?

On Go 1.13.4 and 1.13.6, http.Do() sometimes returns an error of the form `stream error: stream ID 523; INTERNAL_ERROR`. It does seem to happen more often when there is some network congestion, but I've also observed it on very good networks. Typically, I'd say it happens once every 200 requests or so.
Repository: go
Issue: archive/zip: FileHeader struct lacks Unicode Path Extra Field (0x7075)
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version go1.13.6 windows/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>
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\npanin\AppData\Local\go-build
set GOENV=C:\Users\npanin\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\GoProjects
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\npanin\AppData\Local\Temp\go-build726899154=/tmp/go-build -gno-record-gcc-switches

</pre></details>

### What did you do?

Tried to read ZIP file with unicode filename using archive/zip package

### What did you expect to see?

FileHeader struct field to store Unicode Path Extra Field as described in 4.6.9 of https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

### What did you see instead?

No way to retrieve Unicode Path Extra Field except for manually parsing it from FileHeader.Extra field
Repository: go
Issue: crypto/ed25519: doc of Sign should warn not to prehash messages
Labels: Documentation,help wanted,NeedsFix

Typically, digital signature schemas require the user to first hash the payload and then sign it. Correct me if I am wrong, but this should be true for RSA, DSA and ECDSA. 

If my understanding is right, ED25519 seems to be different: it already hashes the message in a way that the collision resistant property is guaranteed even when it becomes feasible to find a collision for SHA512. Thus, prehashing the input messages basically nullifies this collision resistant property of ED25519 itself. In fact, if a possible attacker can efficiently find a collision for the prehashed message, they would be able to carry out a forgery attack.

Also, according to [RFC8032 section 8.7](https://tools.ietf.org/html/rfc8032#section-8.7) , it would be better to mention to avoid signing large messages.

/cc @FiloSottile @katiehockman
Repository: flutter
Issue: Finished with error: Failed to establish connection with the application instance in Chrome.
Labels: tool,dependency: dart,customer: crowd,platform-web,P2,team-web,triaged-web

I am getting this error when running my project on flutter web:

Launching lib\main.dart on Chrome in debug mode...
Building application for the web...
Attempting to connect to browser instance..
Finished with error: Failed to establish connection with the application instance in Chrome.
This can happen if the websocket connection used by the web tooling is unabled to correctly establish a connection, for example due to a firewall.
Repository: go
Issue: gccgo: crash on loop alias reference
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ gccgo --version
gccgo (Ubuntu 8.3.0-6) 8.3.0
</pre>

### Does this issue reproduce with the latest release?

True

### What did you do?

```
type A = *struct {
	A
}
```

### What did you expect to see?

Fails to compile for `invalid recursive type alias`.

### What did you see instead?

Crashes.
Repository: svelte
Issue: Cannot use yielded value in bind:this inside #each
Labels: bug,awaiting submitter,temp-stale

**Describe the bug**
The title is a bit of a mouthful so I think a simple example explains it better:

https://svelte.dev/repl/2dc797d2d76b4663987a165f898fdd92?version=3.17.3

```
<script>
	let name = 'world';
	function* foo() {
		yield {name: "h", value: 123}
		yield {name: 'x', value: 333}
		
	}
	let things = {}
</script>


<h1>Things! {new Date()}</h1>

{#each [...foo()] as f,i}
  <!-- This will crash because of f.name: -->
  <input bind:this={things[f.name]} value={f.value}> 
{/each}

<pre>
	This was bound: {JSON.stringify(things, undefined, 2)}
</pre>
```


**Logs**
No logs, it just hangs

**To Reproduce**
Run the REPL, the bad code is commented out so it wont crash your browser: 
https://svelte.dev/repl/2dc797d2d76b4663987a165f898fdd92?version=3.17.3


**Expected behavior**
I would be expected to be able to bind:this using a yielded value

A strange thing is if I store the list in a new variable which I then use in `#each` it works as expected:

```
const fooList = [...foo()]

... 
{#each fooList as f,i}
```