sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: region inference sometimes fails to recognize implied bound in closure 
Labels: T-compiler,A-inference,C-bug

Following a bug sample from @jdm, I encountered this bug. [The compiler errors out in this code](https://is.gd/xTZO0h):

```rust
struct Parser<'i: 't, 't> {
  data: &'t mut Vec<&'i String>
}

fn callback1<'i, 't, F>(parser: &mut Parser<'i, 't>, f: F)
    where F: for<'tt1> FnMut(&mut Parser<'i, 'tt1>)
{
    panic!()
}

fn callback2<'i, 't, F>(parser: &mut Parser<'i, 't>, mut f: F)
    where F: for<'tt2> FnMut(&mut Parser<'i, 'tt2>)
{
    callback1(parser, |input| {
        f(input)
    });
}

fn main() {
}
```

specifically it reports a "cannot infer" lifetime error, complaining about how the lifetime `'tt2` in the call `f(input)` must be some lifetime `'x` where `'i: 'x` and `'x: 'tt1` (where `'tt1` is the lifetime that appears in the type of `input` in the closure). The compiler is upset because it does not know that `'i: 'tt1`. Those constraints are correct, but in fact the compiler should be able to deduce that `'i: 'tt1` based on the type of `input`, which is is `&mut Parser<'i, 'tt1>`. The implied bounds for this type suggest that `'i: 'tt1`. But we fail to see it.

The problem is an interaction with inference. When we call `callback1()` here, we do not specify the lifetime, and so we create a variable `'x` -- that is, the actual type of `input` is `&mut Parser<'x, 'tt2>`, where `'x` is the inference variable. We then recognize that this means `'x: 'tt2`, and we add a "given", which is this hacky bit of code in region inference. Then we infer that `'x` must be `'i`. But when we go to check that `'x: 'tt2`, we substitute `'x` to `'i`, and then report an error, because we never added anything that tells us that `'i: 'tt2`. [If you specify `callback::<'i>` manually, it will work fine.](https://is.gd/QxHOqn)

The most straightforward fix is to use the given logic here too. The better fix is to retool this part of region inference to be more robust, which I am in the process of trying to plan out right now for other reasons anyhow.
Repository: pytorch
Issue: Add support for colors (and maybe other attributes) to NVTX API
Labels: newcomer,module: cuda,triaged

**Summary.** The functions in `torch.cuda.nvtx` can currently be associated with ASCII text only. However, the NVIDIA APIs permit more options, including custom colors. http://docs.nvidia.com/cuda/profiler-users-guide/#nvtx  Your goal in this ticket is to add support for this.

**What you will learn.**

1. How to do pure Python development in PyTorch
2. How to use the ctypes library in Python to pass structures to C functions
3. How to use nvprof and nvvp to view your beautiful annotations

**How to do it.** The relevant code is in `torch/cuda/nvtx.py`. You should add extra arguments for the various extra options, and then write code to call the correct API calls (as per NVIDIA's API documentation). There are various other implementations of colors elsewhere on the web, see also:

* https://github.com/apaszke/torch-nvtx
* https://github.com/cupy/cupy/blob/master/cupy/cuda/nvtx.pyx

cc @ngimel
Repository: youtube-dl
Issue: [vgtv] Add support for authentication
Labels: account-needed

C:\Users\Duiz\Downloads\Movies> youtube-dl.exe http://www.vgtv.no/#!/video/138243/tv-junkie -u ***** -p ********
[VGTV] 138243: Downloading media JSON
[VGTV] 138243: Downloading m3u8 information
WARNING: Failed to download m3u8 information: HTTP Error 403: Forbidden
[VGTV] 138243: Downloading f4m manifest
WARNING: Unable to download f4m manifest: HTTP Error 403: Forbidden
ERROR: This video is not available from your location due to geo restriction
This video is available in Norway.
You might want to use a VPN or a proxy server (with --proxy) to workaround.
Repository: TypeScript
Issue: Suggestion: shorthand syntax for annotating function with type
Labels: Suggestion,Awaiting More Feedback

I like to define types for my functions by separating the type out from the value:

```ts
type id = <A>(a: A) => A;
const id: id = a => a;
```

This helps particularly for longer functions where the parameter list often spans many columns and multiple lines.

However, compared to Elm/Haskell, this code is quite boilerplate-y. I wonder if there is some shorthand syntax we could add to make this pattern more concise. For example, the same code in Elm/Haskell:

``` elm
id : a -> a
id a = a
```

The boilerplate in the current TypeScript syntax is:

- Manual annotation of value (`id`) with type of same name (`id`). Could this be automatic, e.g. matched by name?
- TypeScript requires parameter names for the function type, but are these always required? Could the function type simply by `A => A`, omitting the parameter names? Or would this cause problems?
Repository: rust
Issue: `cfg_target_feature` and `target_feature` don't interact properly
Labels: T-lang,A-SIMD,C-bug,A-target-feature

This should panic but it doesn`t
```
#[target_feature = "+avx"]
pub fn should_panic() {
#[cfg(target_feature = "avx")]
    panic!("have_avx");
}
```

I would like for this to work because I have a macro that generates 2 copys of a function, one with `#[target_feature = "+feat"]` and one without and I want to conditionally use some assembly when the feature is available.

CC #29717
Repository: vue
Issue: transition-group DOM update lag when using css frameworks
Labels: improvement,transition

### Version
2.3.3

### Reproduction link
[http://jsbin.com/fegogus/edit?html,css,js,output](http://jsbin.com/fegogus/edit?html,css,js,output)

### Steps to reproduce
Apply a transition group to v-for when using popular CSS frameworks, most noticeable with Semantic-UI but also apparent with Bootstrap. Example uses table rows but issue also appears with something more simple, such as an unordered list.

### What is expected?
Transition group continues to have similar performance as it does without any CSS applied

### What is actually happening?
There is a considerable amount of update lag, particularly when changing the v-for array using slice

---
This obviously walks the line between a VueJS issue and an issue for one of the involved frameworks. I'm opening the case here though as honestly I don't know that anyone on the Semantic-UI side of things would be able to help.

The example is a little more complicated than needed to reproduce the issue simply because I wanted to show my use case - which is animating additions to the array used by v-for but otherwise having no transitions. This is because the table will also be paginated (sliced) or sorted and I don't want to animate that process at all.

In the example you can toggle using a transition-group on and off. Without the transition group the DOM updates instantly as expect. With it turned on, and even without any transition being active, you can see that toggling between sliced and the full array is very slow to update the visible DOM.

Also sorry for submitting this three times, the new issue vue site was doing something goofy in Chrome, had to switch to Safari.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: node
Issue: When using pipes other than stdin, stdout, stderr for streaming data into a child process, ENOTCONN error is thrown
Labels: child_process,process,stdio

### Version:
tested with 7.5 and 8.0
### Platform:
OSX Sierra; Darwin Kernel Version 16.3.0 root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64
### Example code:
`brew install imagemagick`
```javascript
const request = require('request');
const spawn = require('child_process').spawn;

// const subProcess = spawn('convert', ['fd:0', '-size', '100x100', '-'], {stdio: [null, null, null, 'pipe']});
// request.get('https://tinyurl.com/zyksbz7').pipe(subProcess.stdio[0]); // this works

const subProcess = spawn('convert', ['fd:3', '-size', '100x100', '-'], {stdio: [null, null, null, 'pipe']});
request.get('https://tinyurl.com/zyksbz7').pipe(subProcess.stdio[3]); // this does not

subProcess.stdout.on('data', (data) => {
  console.log('new data: ', data);
});

```
### Details:
I am trying to pipe a stream, which i got from request, to the command line in order to manipulate the received data. When i am sending the data to stdin of the child process, everything works fine. In my example, you can see that result by running the commented code rather than the uncommented.
If I pipe the stream to a pipe other than stdin, stdout or stderr, which should be possible according to the [docs](https://nodejs.org/api/child_process.html#child_process_options_stdio) I get the following exception:

```
events.js:182
      throw er; // Unhandled 'error' event
      ^

Error: shutdown ENOTCONN
    at exports._errnoException (util.js:1026:11)
    at Socket.onSocketFinish (net.js:298:25)
    at emitNone (events.js:105:13)
    at Socket.emit (events.js:207:7)
    at finishMaybe (_stream_writable.js:579:14)
    at endWritable (_stream_writable.js:587:3)
    at Socket.Writable.end (_stream_writable.js:538:5)
    at Socket.end (net.js:490:31)
    at Request.onend (internal/streams/legacy.js:44:10)
    at emitOne (events.js:120:20)
    at Request.emit (events.js:210:7)
    at IncomingMessage.<anonymous> (/Users/ferencbeutel/IdeaProjects/imageprocessing/node_modules/request/request.js:1091:12)
    at Object.onceWrapper (events.js:312:19)
    at emitNone (events.js:110:20)
    at IncomingMessage.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1045:12)
    at /Users/ferencbeutel/IdeaProjects/imageprocessing/node_modules/async-listener/glue.js:188:31
    at _combinedTickCallback (internal/process/next_tick.js:102:11)
    at process._tickCallback (internal/process/next_tick.js:161:9)
```

I tried multiple things, for example passing in the stream object directly when specifying the stdio object (which should be possible too according to the linked doc entry) but then I get a type error, even though I am clearly passing in a stream. I cant see the difference between the two examples I provided and am rather puzzled by the different result.

Thanks for looking into this!
Repository: opencv
Issue: Update OpenCV-Python Bindings to expose internal C function API using capsule
Labels: category: python bindings,RFC

I am trying to use OpenCV 3.2 using the python binding, while moving some of my code to a python extension (implemented in C++). To interpret function arguments correctly, it would be very useful to be able to access to the functions in modules/python/src2/cv2.cpp. This can be done by using capsules, so that my module can access the conversion functions such as "bool pyopencv_to(PyObject* o, UMat& um, const ArgInfo info)"

Currently, the main alternative is to re-implement this functionality in the new module. I believe this is the approach taken by https://stackoverflow.com/questions/12957492/writing-python-bindings-for-c-code-that-use-opencv

For more info see: https://docs.python.org/3.1/extending/extending.html#using-capsules
Repository: go
Issue: image/png: don't ignore PNG gAMA chunk
Labels: help wanted,NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?

go version go1.8.1 linux/amd64

### What operating system and processor architecture are you using (`go env`)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/valentin/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build951360311=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

### What did you do?

Decoded `fruit.png` (which contains a strong gamma value in a gAMA chunk). 

Encoded back to `result.png`.

Opened `result.png` in a gAMA-aware viewer (Chromium)

### What did you expect to see?

A pear.

### What did you see instead?

An apple.

I understand (after reading file `reader_test.go` and part of the PNG spec) that handling ancillary chunks (e.g. gAMA) is not a requirement for a PNG decoder. I also understand that implementing it would require some (unknown to me) amount of work. So, the question boils down to "would it be a good idea or not to take the gAMA chunk into account?".


![fruit](https://user-images.githubusercontent.com/13508141/26928305-f35a9596-4c55-11e7-86e8-af0593d83ccd.png)

![result](https://user-images.githubusercontent.com/13508141/26928317-018e1cfa-4c56-11e7-8732-c72f5042ea89.png)
Repository: go
Issue: encoding/xml: add whitespace normalization from spec
Labels: help wanted,NeedsFix

### What version of Go are you using (`go version`)?
go version go1.8.3 darwin/amd64

### What operating system and processor architecture are you using (`go env`)?
darwin/amd64

### What did you do?

for attribute values, all whitespace characters (#x20, #xD, #xA, #x9), should be normalized to a space character (see https://www.w3.org/TR/REC-xml/#AVNormalize)

go program used to test: (https://play.golang.org/p/mCRrxvyh25)

~~~go
package main

import (
	"encoding/xml"
	"fmt"
	"strings"
)

func main() {
	decoder := xml.NewDecoder(strings.NewReader(`<a p1="v1

v1"/>`))
	t, _ := decoder.Token()
	if e, ok := t.(xml.StartElement); ok {
		fmt.Printf("%q", e.Attr[0].Value)
	}
}
~~~

### What did you expect to see?
~~~
"v1  v1"
~~~

### What did you see instead?
~~~
"v1\n\nv1"
~~~

Tested the same with xmllint program:

~~~bash
$ cat test.xml
<x p1="v1

v2"/>
$ xmllint test.xml
<?xml version="1.0"?>
<x p1="v1  v2"/>
~~~
Repository: TypeScript
Issue: Error inferring tuple type arguments
Labels: Bug

**TypeScript Version:** nightly (2.4.0-dev.20170608)

**Code**

```ts
interface IPromise<T> {
    then<U>(onFulfill: (value: T) => IWhenable<U>): IPromise<U>;
}

interface QPromise<T> {
    then<U>(onFulfill: (value: T) => IWhenable<U>): IPromise<U>;
}

type IWhenable<T> = IPromise<T> | T;

declare function all<A, B>(promises: IWhenable<[IWhenable<A>, IWhenable<B>]>): IPromise<[A, B]>;

declare const prom1: QPromise<[QPromise<string>, QPromise<number>]>;
const x1: IPromise<[string, number]> = all(prom1);

const prom2: IPromise<[IPromise<string>, IPromise<number>]> = prom1;
const x2: IPromise<[string, number]> = all(prom2);
```

**Expected behavior:**

Since `IPromise` and `QPromise` have identical bodies, I would expect these to both work.

**Actual behavior:**

`x1` fails, `x2` succeeds.
```
src/a.ts(14,7): error TS2322: Type 'IPromise<[QPromise<string>, QPromise<number>]>' is not assignable to type 'IPromise<[string, number]>'.
  Type '[QPromise<string>, QPromise<number>]' is not assignable to type '[string, number]'.
    Type 'QPromise<string>' is not assignable to type 'string'.
```
Repository: opencv
Issue: Include LKTracker in Trackers class
Labels: feature,category: video,RFC

LK Tracker is a part of the Optical Flow module. I would like to suggest that we add it as a tracker in the Tracker class. This will also enable its use in MultiTracker and make it easier to switch to.
I can start working on the same if you suggest it's a good idea.
Repository: rust
Issue: Slow "llvm module passes"
Labels: A-LLVM,C-enhancement,I-compiletime,T-compiler

This crate https://github.com/snipsco/rustling-ontology takes a very long time to compile, more than I would expect. -Z time-passes show this culprit:"  time: 269.113	llvm module passes [0]" accounting for ~95% of the compilation time.

From my understanding, it is atypical, so maybe there is something interesting there. I'm not too sure how to investigate more.
Repository: go
Issue: proposal: spec: disallow assigning >32bit untyped constant to variable of type int
Labels: LanguageChange,Proposal,LanguageChangeReview

I propose that the Go language and implementations be changed to reject a constant assignment to a variable of type `int` (or `uint`) if the constant would overflow a **32-bit** `int` (or `uint`), regardless of the size of `int` on the current GOOS.

That is, on `amd64`, this would be rejected:

```go
const MaxInt64 = 1<<63 - 1

var x int = MaxInt64
```

Currently that passes on 64-bit platforms but fails when people cross-compile it to Raspberry Pis or run it on the playground (https://play.golang.org/p/4PK8z_WBKi).

This bites people like in https://github.com/GoogleCloudPlatform/google-cloud-go/issues/648 where it lurks unnoticed by users & continous builds for a long time, until somebody builds the code for the increasingly rare 32-bit machines.

/cc @griesemer
Repository: flutter
Issue: FlutterDriver reports the target device
Labels: a: tests,tool,t: flutter driver,customer: google,P2,team-tool,triaged-tool

Internal: b/124657370

Currently the flutter driver test that collections screenshots (see examples/catalog/bin/screenshot_test.dart.template) incorrectly assumes that if it's running on MacOS, it's targeting an iOS device. 

It would preferable to just ask the FlutterDriver for the target device's deviceId, or OS. 

I've patched the problem for now https://github.com/flutter/flutter/pull/10583
Repository: three.js
Issue: Plane.intersectLine An extension parameter should be added
Labels: Suggestion

##### Description of the problem 

Because the method does not provide bi-directional rays.
So I think it is useful.

in Plane.js line 154:
`
if (!extensionLine && ( t < 0 || t > 1 )) {
	return undefined;
}
`
##### Three.js version

- [ ] Dev
- [x] r85
- [ ] ...

##### Browser

- [x] All of them
- [ ] Chrome
- [ ] Firefox
- [ ] Internet Explorer

##### OS

- [x] All of them
- [ ] Windows
- [ ] macOS
- [ ] Linux
- [ ] Android
- [ ] iOS

##### Hardware Requirements (graphics card, VR Device, ...)
Repository: vscode
Issue: [theme] Request the feature: "editor.lineHighlightForeground".
Labels: feature-request,themes

### Request the feature:  "editor.lineHighlightForeground"  
Sometimes it is essential to adjust the colour of the selected text by:
**'editor.lineHighlightBackground'.**

Colour merges if the highlighting line and text colours are identical.

An example:

`'editor.lineHighlightBackground': '#000000',
'editor.lineHighlightForeground': '#fffffff'`. 

Cheers.
Repository: node
Issue: vcbuild does not always generate field <TargetMachine> in project files.
Labels: confirmed-bug,help wanted,windows,build

<!--
Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help


Please fill in as much of the template below as you're able.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify affected core module name

If possible, please provide code that demonstrates the problem, keeping it as
simple and free of external dependencies as you are able.
-->

* **Version**: v9.0.0-pre
* **Platform**: Windows 10 x64
* **Subsystem**:

<!-- Enter your issue details below this comment. -->

When generating project files for node, gyp does not include <TargetMachine> for librarian but does so for linker. As a result the linking fails as MSBuild will default unknown machine to x64 (on x64 platforms).
The result is as follows:

```
vcbuild.bat debug static vs2017 x86

...
LINK : warning LNK4068: /MACHINE not specified; defaulting to X64 [c:\Users\tamaroth\Downloads\node\node.vcxproj]
Debug\obj\node\async-wrap.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' [c:\Users\tamaroth\Downloads\node\node.vcxproj]
```

This is manually easily fixed by modyfying .vcxproj file to include proper <TargetMachine> inside <Lib>. 

For instance, from the above command, the node.vcxproj file in Debug|Win32 configuration has this entry:

```
    <Lib>
      <OutputFile>$(OutDir)lib\$(ProjectName)$(TargetExt)</OutputFile>
    </Lib>
```
 
If I modify it to 

```
    <Lib>
      <OutputFile>$(OutDir)lib\$(ProjectName)$(TargetExt)</OutputFile>
      <TargetMachine>MachineX86</TargetMachine>
    </Lib>
```

Everything works great.

Inside 

node\tools\gyp\pylib\gyp\msvs_emulation.py

in function GetLibFlags (line: 515) it says to add specific machine, but for some reason it's not added later on to the project file.
Repository: TypeScript
Issue: Mixin classes don't allow constructors of _generic_ 'object' types
Labels: Suggestion,Awaiting More Feedback

**TypeScript Version:**  2.3.4, 2.4.0-dev.20170609

**Code:**

```ts
type Constructor<T> = new (...args: any[]) => T;

const Timestamped = <I extends object, CT extends Constructor<I>>(Base: CT) => {
  return class extends Base {
    timestamp = new Date();
  };
};
```

**Expected behavior:**

Should be able to use the generic `I` as an argument to `Constructor`.

**Actual behavior:**

Compiling this yields the following error:
```
error TS2509: Base constructor return type 'I' is not a class or interface type.
```

**Note:**

This is a variation on https://github.com/Microsoft/TypeScript/issues/13805 where the following compiles successfully:

```ts
type Constructor<T> = new (...args: any[]) => T;

const Timestamped = <CT extends Constructor<object>>(Base: CT) => {
  return class extends Base {
    timestamp = new Date();
  };
};
```
Repository: go
Issue: mobile/app/x11.go: Support mouse events for X
Labels: mobile

### What version of Go are you using (`go version`)?
```
go version go1.8.3 linux/amd64
```
### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/veger/devel/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build373476887=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
```

### What did you do?

Click a mouse button in an X window


### What did you expect to see?

I expect to see a `mouse.Event` on my event channel


### What did you see instead?

I see a `touch.Event` instead.
Repository: angular
Issue: Better syntax checking of index syntax in ngFor
Labels: type: bug/fix,hotlist: error messages,freq2: medium,area: core,area: compiler,core: ng-template and *microsyntax,P3,compiler: template type-checking

**I'm submitting a ...**
```
[x] bug report => search github for a similar issue or PR before submitting
```

**Current behavior**
Silence

**Expected behavior**
Syntax error

**Minimal reproduction of the problem with instructions**

`*ngFor="let elem of elements; let i of index"`

Notice the "of index", which should be "= index".

Got no errors of any sorts, but the behavior is the same as "i = elem", leading to nasty runtime bugs.

**What is the motivation / use case for changing the behavior?**
To avoid spending hours on stupid bugs like that.

**Please tell us about your environment:**
<!-- Operating system, IDE, package manager, HTTP server, ... -->

* **Angular version:** 2.0.X
Latest officially released 4

* **Browser:** 
all
 
* **Language:** 
TypeScript 2