sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: opencv
Issue: The Viz3d window seems to have broken.
Labels: bug,category: viz

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.2
- Operating System / Platform => Ubuntu 17.04
- Compiler => g++
-->

- OpenCV => 3.2
- Operating System / Platform => Ubuntu 17.04
- Compiler => g++

##### Detailed description

The 3D Visualizer module seems to have broken with a recent update to Ubuntu 17.04. The Viz3d window was behaving normally last week, but now just displays a blank, blue window. I also tested one of the tutorials from the documentation, and I get the same result. It seems like I can set the background color with setBackgroundColor(), but other commands I've tried have no effect. The console only prints this line of text:

```.txt
../../../../src/intel/isl/isl.c:1370: FINISHME: validate row pitch of stencil surfaces
```

##### Steps to reproduce

Open a viz::Viz3d window and start the update loop to reproduce the bug. Bellow is the tutorial I've been using to check the issue.

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
```.cpp
#include <opencv2/viz.hpp>
#include <opencv2/calib3d.hpp>
#include <iostream>

using namespace cv;

int main() {
    viz::Viz3d myWindow("Coordinate Frame");
    myWindow.showWidget("Coordinate Widget", viz::WCoordinateSystem());

    viz::WLine axis(Point3f(-1.0f, -1.0f, -1.0f), Point3f(1.0f, 1.0f, 1.0f));
    axis.setRenderingProperty(viz::LINE_WIDTH, 4.0);
    myWindow.showWidget("Line Widget", axis);

    viz::WCube cube_widget(Point3f(0.5, 0.5, 0.0), Point3f(0.0, 0.0, -0.5), true, viz::Color::blue());
    cube_widget.setRenderingProperty(viz::LINE_WIDTH, 4.0);
    myWindow.showWidget("Cube Widget", cube_widget);

    Mat rot_vec = Mat::zeros(1, 3, CV_32F);
    float translation_phase = 0.0, translation = 0.0;

    while (!myWindow.wasStopped()) {
        rot_vec.at<float>(0, 0) += CV_PI * 0.01f;
        rot_vec.at<float>(0, 1) += CV_PI * 0.01f;
        rot_vec.at<float>(0, 2) += CV_PI * 0.01f;
        translation_phase += CV_PI * 0.01f;
        translation = sin(translation_phase);

        Mat rot_mat;
        Rodrigues(rot_vec, rot_mat);
        Affine3f pose(rot_mat, Vec3f(translation, translation, translation));

        myWindow.setWidgetPose("Cube Widget", pose);
        myWindow.spinOnce(1, true);
    }

    return 0;
}
```
Repository: go
Issue: cmd/compile: incorrect type assertions on conflicting package names
Labels: NeedsFix

This is a bug that has existed since Go1.0.

Consider the following packages:
```go
package iface // import "github.com/dsnet/example/iface1/iface"

import "fmt"
import "reflect"

func CheckInterface() {
	type iface interface { unexported() }
	var v interface{} = foo{}
	t := reflect.TypeOf(v)

	t1 := reflect.TypeOf((*iface)(nil)).Elem()
	t2 := reflect.TypeOf((*interface { unexported() })(nil)).Elem()
	fmt.Println("reflect implements named interface:  ", t.Implements(t1))
	fmt.Println("reflect implements interface literal:", t.Implements(t2))

	_, ok1 := v.(iface)
	_, ok2 := v.(interface { unexported() })
	fmt.Println("type assertion on named interface:   ", ok1)
	fmt.Println("type assertion on interface literal: ", ok2)

	fmt.Println()
}

type foo struct{}
func (foo) unexported() {}
```

```go
package iface // import "github.com/dsnet/example/iface2/iface"

import "fmt"
import "reflect"

func CheckInterface() {
	type iface interface { unexported() }
	var v interface{} = foo{}
	t := reflect.TypeOf(v)

	t1 := reflect.TypeOf((*iface)(nil)).Elem()
	t2 := reflect.TypeOf((*interface { unexported() })(nil)).Elem()
	fmt.Println("reflect implements named interface:  ", t.Implements(t1))
	fmt.Println("reflect implements interface literal:", t.Implements(t2))

	_, ok1 := v.(iface)
	_, ok2 := v.(interface { unexported() })
	fmt.Println("type assertion on named interface:   ", ok1)
	fmt.Println("type assertion on interface literal: ", ok2)

	fmt.Println()
}

type foo struct{}
func (foo) unexported() {}
```
In the setup, we have two packages both named `iface` where the source code of both packages is identical, but they have different absolute package paths. 

Running the following program:
```go
package main
import (
	iface1 "github.com/dsnet/example/iface1/iface"
	iface2 "github.com/dsnet/example/iface2/iface"
)

func main() {
	iface1.CheckInterface()
	iface2.CheckInterface()
}
```
Prints the following (on Go1.0 to Go1.8):
```
reflect implements named interface:   true
reflect implements interface literal: true
type assertion on named interface:    true
type assertion on interface literal:  true

reflect implements named interface:   true
reflect implements interface literal: false
type assertion on named interface:    true
type assertion on interface literal:  false
```
The output slightly differs on Go1.9, but is still wrong.

We expect that calling `iface1.CheckInterface()` and `iface2.CheckInterface()` to produce the exact same results. However, that is not what we see. In `iface2`, type assertions via a interface literal on unexported fields no longer works properly, but it works as expected in `iface1`.

\cc @ianlancetaylor @josharian @mdempsky @neild
Repository: flutter
Issue: Refactor "pop" so that BackButton can quit the app on Android
Labels: framework,f: routes,P2,team-framework,triaged-framework

![img_20170802_125117](https://user-images.githubusercontent.com/551196/28892026-641e774c-7781-11e7-8466-dd95e072e0d9.jpg)

Specifically:

* Remove the call to `SystemNavigator.pop` from the `didPopRoute` handler in the `WidgetsApp`.
* Make `WidgetsApp` call `maybePop` instead of `pop` on the Navigator. (Or, make it call another method that then calls `maybePop`, so that we don't break `maybePop` users.)
* Make `maybePop` (or probably the aforementioned new method that calls `maybePop`) default to calling `pop` if it can pop and there's more than one route around, otherwise, call `onPopFirst` or `onExit` on the Navigator widget (if such a callback was provided). This is a `VoidCallback` property.
* Have `WidgetsApp` provide such a callback to its `Navigator`, which calls an `onExit` callback that _it_ also provides. That callback should return a boolean. If that callback returns false, it does nothing, otherwise it calls `SystemNavigator.pop`.
Repository: TypeScript
Issue: Support for a built-in "constructable" type or "class type"
Labels: Suggestion,Awaiting More Feedback

<!-- BUGS: Please use this template. -->
<!-- QUESTIONS: This is not a general support forum! Ask Qs at http://stackoverflow.com/questions/tagged/typescript -->
<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

**TypeScript Version:**  2.4.0

It would be interesting to allow type hinting for class type.

Something like

```ts
function generateMyClass(myClass: class) {
    return new myClass();
}

class Foo {}

generateMyClass(Foo); // Should work
generateMyClass('something else'); // should NOT work
```

Currently, the closest we have is

```ts
type Instantiable = {new(...args: any[]): any};

function doSomethingWithMyClass(myClass: Instantiable ) {
    // some code that doesn't matter
}

class Foo {}
abstract class Bar {}

doSomethingWithMyClass(Foo); // It works :)
doSomethingWithMyClass('something else' ); // It doesn't work and it's OK
doSomethingWithMyClass(Bar); // It doesn't work and it's NOT OK
```

It is of course logical that the abstract class causes an error with the code above, this is why it could be nice to have something to handle this case.

To go further, we can think about adding some genericity on it.

```ts
// With the actual implementation
type Instantiable<T = any> = {new(...args: any[]): T};
function foo<T>(myClass: Instantiable<T>): T { /* ... */ }

// With the new class type hint
function foo<T>(myClass: class<T>): T { /* ... */ }
```
Repository: rust
Issue: -Zdump-mir is incomplete for dead functions
Labels: I-needs-decision,T-compiler,C-bug

Given the following program
```
fn main() {
    let _closure = |x: i32| x+x;
}
```
I would expect `rustc filename.rs -Zdump-mir=all` to dump all stages of the MIR of all functions. What happens instead is that for the closure, only the `000-*` and `001-*` passes are emitted; the `002-*` are missing. That's probably because they are not actually emitted into the binary, so they never get generated. I think that's a bug; one should expect `-Zdump-mir` to generate the MIR of all phases of all code.

(I noticed this because I was adding a mir-opt test and it told me it couldn't find the file.)
Repository: vscode
Issue: [folding] show comment first line for folded sections
Labels: feature-request,editor-folding

I think it could be really useful to change the multiline comment folding.

When you fold a comment like this (like above php function) : 
```
/**
 * Print person name on terminal
 *
 * @param person $p
 * @return void
 */
```

You see this : 
```
/** ...
```
In some editors like phpStorm or Eclipse, it's folded like this : 
```
* Print person name on terminal ...
```
That's very more useful  ;)

Is it possible to implement this kind of folding ?
Repository: go
Issue: net/http: still return the content on malformed MIME header line
Labels: NeedsDecision

Please answer these questions before submitting your issue. Thanks!

### 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`)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/jsilva/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.8.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.8.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_n/q8bzrfk93ss0nf_0fbk2ns8c0000gn/T/go-build250479046=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
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?

Fetch "http://107-182-231-168.webnow.net.br/status2.xsl?mount=/98fm.aac" or a similar URL from another Icecast server using http.Client.

Source: https://gist.github.com/joaolsilva/d24b7bf5602f0d6615eb5d385fd0ffdc
https://play.golang.org/p/MiokU7tQgI

### What did you expect to see?

The content of the URL

### What did you see instead?

err: Get http://107-182-231-168.webnow.net.br/status2.xsl?mount=/98fm.aac: malformed MIME header line: Content-Disposition = attachment; filename=file.asc

The MIME header might indeed be malformed, but other http clients such as cURL, browsers, etc. work (they seem to ignore the malformed line) and return the content.
Repository: TypeScript
Issue: Extending string-based enums
Labels: Suggestion,Waiting for TC39

Before string based enums, many would fall back to objects. Using objects also allows extending of types. For example:
```ts
const BasicEvents = {
    Start: "Start",
    Finish: "Finish"
};

const AdvEvents = {
    ...BasicEvents,
    Pause: "Pause",
    Resume: "Resume"
};
```

When switching over to string enums, it"s impossible to achieve this without re-defining the enum.

I would be very useful to be able to do something like this:

```ts
enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
enum AdvEvents extends BasicEvents {
    Pause = "Pause",
    Resume = "Resume"
};
```

Considering that the produced enums are objects, this won"t be too horrible either:
```ts
// extend enum using spread
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};
```
Repository: angular
Issue: Component/declarative error handling (ala React 16's <ErrorBoundary/>)
Labels: feature,area: core,core: error handling,feature: under consideration


## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[x] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

React recently introduced a concept called "Error Boundaries" (https://facebook.github.io/react/blog/2017/07/26/error-handling-in-react-16.html). Basically you wrap key areas of your app with <ErrorBoundary> .... </ErrorBoundary> and any component/template errors within can be handled at that level. I've run into issues with my Angular 4 app where an error in a component will cause the app to break ... sometimes the app is still navigable but often times rendering is messed up and the app just needs a restart. Most blog posts (and the Angular documentation) on error handling don't deal with rendering issues, just logging/handling any exceptions that may occur. What are strategies for gracefully handling "breaking errors" in an Angular app? Would something like <ErrorBoundary/> make sense for Angular?

Edit: after discussing with @robwormald, it seems the current proscribed solution for handling uncaught errors would be to log them and then reload the entire app via the `ErrorHandler` mechanism already in Angular. This is still less than ideal (although ideally there would be no errors :-)). As applications grow, and as third party components are added/upgraded - it would be useful to introduce an the concept of an ErrorBoundary for two primary reasons:
1) allows more graceful and selective degradation of the app (if a child components underneath an ErrorBoundary fail, they can be restarted)
2) Error boundaries will introduce 'bulkheads' that ensure a single error won't sink the entire ship (forcing an app reload/restart), which will be more important the more likely errors are to occur (size of app, # external components, etc)
Repository: go
Issue: testing: collect performance counters for benchmarks
Labels: Proposal,Proposal-Accepted

Performance counters may be helpful for benchmarking:
- it can provide more information like cache misses, branch misprediction, etc.
- number of cycles may be more stable than wall clock time.

It may be hard to do it in a portable way. But doing it only on platforms that are available would still be nice.

@aclements
Repository: TypeScript
Issue: Don't allow `this` in decorator expressions
Labels: Bug,Domain: Decorators,ES Next

e.g. `@this.method()` is invalid
Repository: react
Issue: Too much unnecessary updates when a child element is moved to the front
Labels: Type: Discussion,Component: Reconciler

**Do you want to request a *feature* or report a *bug*?**

Not sure if it's a bug or an 'accepted' behavior. But this can affect performance in some situations or even 'break the expectations' in others (e.g. animating moved elements [i.e. simple moves]) 

**What is the current behavior?**

When a child element moves from the end of the list to the front  React actually moves all the other elements after the moved/last element instead of simply inserting the moved element at the front of the list.

This also can be stated more generally for an element or a block of elements moving backward with a significant shift.

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/84v837e9/).**

Here is a [demo](https://codesandbox.io/s/wjZkrGVzJ) that shows the DOM operations performed on DOM nodes (moves & insertions) during reconciliation. To reproduce the issue

- type '0123456789x' in the input field then click `Patch!`

- now type 'x0123456789' (move the last 'x' to the front) then click `Patch!` again

Here's the output

![image](https://user-images.githubusercontent.com/5453835/28969007-affc2dae-791a-11e7-951a-37856bc53f00.png)

Instead of moving the 'x' to the front. React actually moves all the other elements after the 'x'

*Note: the demo uses MutationObserver api to find out the operations. But you can also verify this behavior directly by commenting out the code that activates the dom observer (in componentDidMount) and watch the dom operations manually in the devtools element inspector*

**What is the expected behavior?**

React should perform the minimal number of operations. I know that the 'minimum' will vary for each situation and not trivial to infer for the general case. But for some common cases like this one it should be feasible.

For info this use case is handled in most of the other virtual dom libs like preact, snabbdom. Inferno is a remarkable case as it will always infer the minimum number of operations (it uses an algorithm to find the [longest increasing subsequence](https://en.wikipedia.org/wiki/Longest_increasing_subsequence) on an array containing the indexes of the old elements).

I found this behavior while working on a demo to find out how vdom libs rearrange nodes during children reconciliation. For example here is the same output for other libs ([demo](https://codesandbox.io/s/BkLpXYQn))

![image](https://user-images.githubusercontent.com/5453835/28969902-567219c0-791e-11e7-9f3d-29bf988cdab1.png)

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

The demo uses the 0.16 version. But I tried with 0.15 and it has the same behavior
Repository: go
Issue: x/build/cmd/gopherbot: don't fight humans
Labels: Builders,NeedsFix

In #20892, I re-opened an issue, only to have @gopherbot re-close it. This is an issue to follow-up on what happened there. cc @andybons @kevinburke
Repository: rust
Issue: Tuples of functions do not coerce to tuples of function pointers
Labels: A-type-system,T-lang,C-feature-request,T-types

Hi

Following code does not compile in current nightly even though error message does not seem to have valid meaning. Returning single function in both match arms compiles successfully.

```
fn m(i:i8) {
  let (l, r) = match i {
     0 => {
        fn f1()-> bool { true };
        fn f2()-> bool { true };
        (f1, f2)
     }
     1 => {
        fn f1()-> bool { true };
        fn f2()-> bool { true };
        (f1, f2)
     }
  };
}

fn main() {
  m(0)
}

error[E0308]: match arms have incompatible types
  --> src/main.rs:2:16
   |
2  |     let (l, r) = match i {
   |  ________________^
3  | |      0 => {
4  | |         fn f1()-> bool { true };
5  | |         fn f2()-> bool { true };
...  |
12 | |      }
13 | |   };
   | |___^ expected fn item, found a different fn item
   |
   = note: expected type `(fn() -> bool {m::f1}, fn() -> bool {m::f2})` (fn item)
              found type `(fn() -> bool {m::f1}, fn() -> bool {m::f2})` (fn item)
note: match arm with an incompatible type
```
Repository: rust
Issue: Compiler unable to match types with trait implementation
Labels: A-type-system,T-compiler,C-bug,T-types

`rustc 1.19.0 (0ade33941 2017-07-17)`

The following piece of code:

```rust
pub struct Foo {
	pub data: [u8; 64],
}

pub struct FooRef<'a> {
	pub data: &'a [u8; 64],
}

impl<'a> From<&'a Foo> for FooRef<'a> {
	fn from(foo: &'a Foo) -> Self {
		FooRef {
			data: &foo.data,
		}
	}
}

impl Foo {
	pub fn do_something<'a, F>(&self, _foo: F) where FooRef<'a>: From<F> {
		let _test_foo = FooRef::from(self);
	}

	pub fn do_something2<F>(&self, _foo: F) {
		let _test_foo2 = FooRef::from(self);
	}
}
```

fails with:

```
error[E0308]: mismatched types
  --> foo/src/lib.rs:19:32
   |
19 | 		let _test_foo = FooRef::from(self);
   | 		                             ^^^^ expected type parameter, found &Foo
   |
   = note: expected type `F`
              found type `&Foo`

error: aborting due to previous error(s)
```

Because of additional lifetime or template at line 19, compiler is no longer able to resolve `FooRef::from(self);`

Link to the repo:

https://github.com/debris/borrowchecker_test

run with `cargo check -p foo`

It may not be an issue, but in that case, it needs better error message. And also, please tell me how to make it work ;)
Repository: go
Issue: cmd/compile, runtime: add and use go:nosplitrec compilation directive
Labels: NeedsFix,compiler/runtime

A key error leading to #21306 was a call from a nosplit function to a function not marked nosplit, permitting preemption at a point where it was not permitted.

Therefore, just as we have `go:nowritebarrierrec` meaning that such a function may not call any function that permits write barriers, we should have `go:nosplitrec` meaning that such a function may not call any function that permits preemption.

Since `nosplit` is now a misnomer--the stack no longer splits--we could also consider a name like `go:nopreemptrec`.
Repository: go
Issue: x/build: set up alerts for errors reported to stackdriver
Labels: Builders

Currently we get a bunch of errors reported, eg:

9/4/17 7:53AM: buildID: B32739cd61, name: windows-amd64-2016, hostType: host-windows-amd64-2016, error: failed to get a buildlet: Error creating instance: &{Code:QUOTA_EXCEEDED Location: Message:Quota 'CPUS' exceeded. Limit: 500.0 ForceSendFields:[] NullFields:[]}

8/4/17 7:53AM: buildID: B059b7649c, name: openbsd-amd64-60, hostType: host-openbsd-amd64-60, error: failed to get a buildlet: Failed to create instance: googleapi: Error 403: Quota 'CPUS' exceeded. Limit: 500.0, quotaExceeded
at main.(*buildStatus).reportErr (coordinator.go:1951)

... etc

Probably not a pressing issue, as the coordinator's retry logic is at least enough to ensure the builds eventually run.

EDIT:
we need to figure out which errors are noise, and alert on the rest.
Repository: opencv
Issue: Absence of GridAdaptedFeature detector, dense adapted feature detector 
Labels: category: features2d,RFC

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->
It appears that the following detectors were removed - 
DenseFeatureDetector, OpponentColorDescriptorExtractor, DynamicAdaptedFeatureDetector, PyramidAdaptedFeatureDetector

in this commit - https://github.com/opencv/opencv/commit/31df47b6eaeb753a77f4d0cc3f4225c5c40682f6
Is there any chance that these methods will be brought back into OpenCV?