sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: rust build on ARMv8 fails in test macro-stepping.rs, other debuginfo-gdb tests.
Labels: A-debuginfo,T-compiler,C-bug,O-AArch64

I built rust on a 96-core ARMv8 machine, and "make -j check" failed in one test:

```
test [debuginfo-gdb] debuginfo-gdb/macro-stepping.rs ... FAILED
```

I expected to see everything pass.

A second time through, I got this, with four failures:

```
thread 'main' panicked at 'Some tests failed', /home/emv/src/rust-lang/rust/src/tools/compiletest/src/main.rs:296
make: *** [tmp/check-stage2-T-aarch64-unknown-linux-gnu-H-aarch64-unknown-linux-gnu-debuginfo-gdb.ok] Error 101
```

```
test [debuginfo-gdb] debuginfo-gdb/issue13213.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/cross-crate-type-uniquing.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/cross-crate-spans.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/macro-stepping.rs ... FAILED
test result: FAILED. 95 passed; 4 failed; 6 ignored; 0 measured
```
## Meta

```
$ ./aarch64-unknown-linux-gnu/stage2/bin/rustc --version --verbose
rustc 1.14.0-dev (6dc035ed9 2016-10-15)
binary: rustc
commit-hash: 6dc035ed911672c6a1f7afc9eed15fb08e574e5b
commit-date: 2016-10-15
host: aarch64-unknown-linux-gnu
release: 1.14.0-dev
```

```
% uname -a
Linux armv8hello.local.lan 4.4.0-38-generic #57-Ubuntu SMP Wed Sep 7 10:19:14 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
```

```
[    0.000000] Linux version 4.4.0-38-generic (buildd@bos01-arm64-006) (gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.2) ) #57-Ubuntu SMP Wed Sep 7 10:19:14 UTC 2016 (Ubuntu 4.4.0-38.57-generic 4.4.19)
```
Repository: go
Issue: x/build: set up builders simulating old processors
Labels: help wanted,Builders,new-builder

We occasionally get a bug report from users that some assembly code (often in runtime or crypto or compression) causes a SIGILL.

We should run builders (perhaps in qemu?) simulating older processors so we can exercise all the assembly fallback paths and CPU detection code.
Repository: angular
Issue: Optional Parameters for  angular2 routes
Labels: feature,area: router,feature: under consideration

<!--
IF YOU DON'T FILL OUT THE FOLLOWING INFORMATION WE MIGHT CLOSE YOUR ISSUE WITHOUT INVESTIGATING
-->

**I'm submitting a ...**  (check one with "x")

```
[ ] bug report => search github for a similar issue or PR before submitting
[X ] feature request
[X ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
```

I don't see a option for supporting Optional Parameters, don't want to use query params

**Current behavior**
right now,  adding multiple routes for the same component

{ path: 'test/:p1', component:component },
{ path: 'test/:p1/:p2', component:component },
{ path: 'test/:p1/:p2/:p3', component:component },

**Expected behavior**
Here i want to specify the optional parameters something like
{ path: 'test/:p1/:p2?/:p3?', component:component }, (optional ? )

I don't want to use query params

_Minimal reproduction of the problem with instructions_*
// Angular2 Module
import { NgModule, ModuleWithProviders}   from '@angular/core';
import { Route, RouterModule }      from '@angular/router';
import { BrowserModule }                      from '@angular/platform-browser';
import { FormsModule }                      from '@angular/forms';
// Components and pipes

import { TestComponent }            from './landing/landing.component';

// Setup routing
export const routes: Route[] = [
  { path: 'develop/:p1', component: TestComponent },
  { path: 'develop/:p1/:p2', component: TestComponent },
];

@NgModule({
  imports: [
    BrowserModule,
    FormsModule,
    RouterModule.forRoot(routes),
  ],

  providers: [
  ],
  declarations: [
    TestComponent,
  ]
})

export class TestModule {
  static forRoot(): ModuleWithProviders {
    return {
      ngModule: TestModule
    };
  }
}

I would like my Route Configuration to Change

export const routes: Route[] = [
  { path: 'develop/:p1', component: TestComponent },
  { path: 'develop/:p1/:p2', component: TestComponent },
];

**What is the motivation / use case for changing the behavior?**

<!-- Describe the motivation or the concrete use case -->

its annoying to create multiple routes for same component  with different parameters, if there is a option for optional paramters, i would make it dynamic

**Please tell us about your environment:**

<!-- Operating system, IDE, package manager, HTTP server, ... -->
- **Angular version:** 2.0.1
- **Browser:** [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  
  <!-- All browsers where this could be reproduced -->
- **Language:** [TypeScript 2.0.1 | ES5]
- **Node (for AoT issues):** `node --version` =   6.7.0
Repository: opencv
Issue: Regression issue with Calib3dTest.findFundamentalMat
Labels: bug,test,category: calib3d,category: java bindings

<!--
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.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->
- OpenCV => 3.1 upstream/master (505c19bc20b971288f321f6092f9dfc479001e2b)
- Operating System / Platform => Mac OSX 10.11.5 (15F34)
- Compiler => Xcode Version 8.0 (8A218a)
##### Detailed description

<!-- your description -->

Java unit test is failing the test case  **Calib3dTest.testFindFundamentalMatListOfPointListOfPoint** with the following message:

```
Max difference between expected and actiual Mats is 0.6962482904638616, that bigger than 0.001

junit.framework.AssertionFailedError: Max difference between expected and actiual Mats is 0.6962482904638616, that bigger than 0.0001
at org.opencv.test.OpenCVTestCase.compareMats(Unknown Source)
at org.opencv..test.OpenCVTestCase.assertMatEqual(Unknown Source)
at org.opencv.test.calib3d.Calib3dTest.testFindFundamentalMatListOfPointListOfPPoint(Unknown Source)
at org.opencv.test.OpenCVTestCase.runTest(Unknown Source)
```

The test is running the following code:

```
    public void testFindFundamentalMatListOfPointListOfPoint() {
        int minFundamentalMatPoints = 8;

        MatOfPoint2f pts = new MatOfPoint2f();
        pts.alloc(minFundamentalMatPoints);

        for (int i = 0; i < minFundamentalMatPoints; i++) {
            double x = Math.random() * 100 - 50;
            double y = Math.random() * 100 - 50;
            pts.put(i, 0, x, y); //add(new Point(x, y));
        }

        Mat fm = Calib3d.findFundamentalMat(pts, pts);

        truth = new Mat(3, 3, CvType.CV_64F);
        truth.put(0, 0, 0, -0.577, 0.288, 0.577, 0, 0.288, -0.288, -0.288, 0);
        assertMatEqual(truth, fm, EPS);
    }
```
##### Steps to reproduce

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->

Compile OpenCV with java enabled and run the autotests from the build folder using the following command:

```
python ../modules/ts/misc/run.py . -t java
```

Results of autotests can be seen on this page: opencv/build/modules/java/pure_test/.build/testResults/junit-noframes.html
Repository: nvm
Issue: Run Travis tests on OS X
Labels: testing,pull request wanted

Should be a fairly simple tweak to `.travis.yml` and will test in what I would expect would be a pretty common (if not the most common) environment that `nvm` will normally run in.

Also has the benefit of testing against BSD tools instead of GNU tools.

The downside is it'll run all the current tests twice so effectively double the build time, not sure if that would be a deal breaker as I know the builds already take a long time.

Travis seem to be having issues with OS X builds atm where it takes a while for them to start. They're aware of this and are working on it.

If you're interested I'm happy to put a PR together.
Repository: opencv
Issue: VideoCapture() doesn't work (blocks) when running in a separate thread
Labels: priority: low,category: videoio,platform: ios/osx,category: 3rdparty

##### System information (version)
- OpenCV => 3.1.0_4 (via `brew install opencv3 --with-python3`)
- OS => OSX Yosemite
- Platform => python3.5.2
##### Detailed description

When using `cv2.VideoCapture(0)` in a thread, it doesn't work, but it does work when running in the main thread. It doesn't raise an Exception, merely blocks until the programme exits.
##### Steps to reproduce

Using this script as a minimum viable example:

``` python
from threading import Thread
import cv2
from time import sleep
from PIL import Image

def main():
    print("Running in main thread")
    cam = cv2.VideoCapture(0)
    print("Starting capture")
    sleep(2)
    _, img = cam.read()
    print("Acquired image")
    sleep(2)
    Image.fromarray(img).save("tmp.jpg", "JPEG")
    cam.release()
    print("End process")

th = Thread(target=main, name="Testing Thread")
th.daemon = True
th.start()
th.join()
```

When this is run on OSX Yosemite, the only thing that gets printed out is "Running in main thread". The rest of the `main()` function does not get executed. Stepping into `VideoCapture()` with `pdb` just hangs as well. If the `main()` function is run normally (without threading) then it works fine.

N.B. I originally had this working on macOS Sierra, which I had to install via `brew install opencv3 --with-python3 --HEAD` (note the extra `--HEAD` option) as installing it without `--HEAD` wouldn't work on Sierra. Similarly, installing _with_ `--HEAD` does _not_ work on OSX Yosemite.
Repository: vscode
Issue: Feature Request: Show all errors and warnings in project for all JavaScript and TypeScript files, not just opened ones
Labels: feature-request,typescript

I am using VS Code on a project at work that has hundreds of files and many layers of nested sub-directories. I frequently make changes that break many files, such as changing the call signature of a commonly used method. Since the project is entirely typescript, it is useful to be able to open the "Problems" view and see the errors and warnings my change caused in the files I have open. However, because of the size of the project, I still need to go to my terminal and run our own make commands to see the list of problems. I then need to perform the fun dance between my terminal and VS Code, searching for the right line in the right file before I can fix the problem.

What I need is a way to tell the "Problems"  view to show me all errors and warnings across all open and closed files in my project. This would allow me to see all problems in a single list and quickly click through and fix them.
Repository: flutter
Issue: DropDownButton.style is busted
Labels: framework,f: material design,a: quality,P3,team-design,triaged-design

DropDownButton.style is intended to handle the special font size (and style?) of drop down buttons in data tables: https://material.google.com/components/data-tables.html#data-tables-specs

However, right now it breaks if you change the theme at the same time.
Repository: vscode
Issue: Virtual Space is not implemented.
Labels: feature-request,editor-core,editor-columnselect

https://blogs.msdn.microsoft.com/zainnab/2010/02/28/understanding-virtual-space/

This is a much needed productivity option that has been available in Visual Studio and other editors for many years.

See also the column select issue that requires it:
https://github.com/Microsoft/vscode/issues/5402

---

*Addition from @hediet:*

This is (still) the current behavior of VS Code. Only text that exists in the text buffer is selected:

![recording](https://user-images.githubusercontent.com/2931520/137472294-6333109f-44bb-4053-9d32-7e589fa68112.gif)

However, the column selection mode should support rectangular selection like this (adding whitespace on demand):

![recording](https://user-images.githubusercontent.com/2931520/137472471-d06f55b3-0db1-4700-b4b1-e206e82cec07.gif)

This would fix #5940 (which is just about copy&pasting such blocks) and #115559.
Repository: flutter
Issue: Automated testing infra doesn't test Flutter in landscape
Labels: a: tests,team,framework,t: flutter driver,P3,team-framework,triaged-framework

I could be wrong, but I believe we're only doing automated infra testing in portrait. Flutter is designed to support both landscape and portrait orientations, and its widgets should work in both.
Repository: react
Issue: [Fiber] Formalize States
Labels: Type: Enhancement,Component: Reconciler,React Core Team

In Fiber there are a number of states that a component can be in. However, it is not formalized in the code right now. Instead, the state is inferred. This leads to hard to follow code. Instead we can organize the code in terms of explicit states - which is what the original prototype did.

Before componentDidMount (i.e. `current === null`):
- Never begun.
- Have been begun before but never completed.
- Have been completed before, not committed, but hasn't begun this time around.
- Begun but not yet completed.
- Completed but not yet committed.

After componentDidMount (i.e. `current !== null`):
- Haven't begun an update yet
- Have been begun before but never completed.
- An update have been completed before, not committed, but hasn't begun this update.
- Begun update but not yet completed.
- Completed update but not yet committed.

The "children" set of a component also have some states:
- Never reconciled.
- The current set last committed.
- A previously reconciled set that hasn't committed yet.
Repository: opencv
Issue: runtime asserts could be compile-time
Labels: feature,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.
-->
##### System information (version)
- OpenCV => 3.1, git
- Operating System / Platform => any
- Compiler => any
##### Detailed description

OpenCV throws a lot of compile-time asserts that could as well be detected at compile-time. In particular the `InputArray` type strips down all information regarding array element type, size, even if it's known. Examples encourage use of `Mat`, and `Mat` has no element type information either.

While bounds checking can't feasibly be done at compile-time in most cases, enumerating `Mat` element types without having the information available at compile-time prevents any early checks.

I understand that calls such as `getMat` happen all the time in the codebase. But this can be factored out incrementally.

Even lack of C++11 support in the compiler doesn't preclude early checks. Partial specialization and the "classic" form of  `static_assert` are enough.

<!-- your description -->
##### Steps to reproduce

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: rust
Issue: LLVM pointer range loop / autovectorization regression part two
Labels: A-LLVM,I-slow,C-enhancement,T-compiler,A-autovectorization

This is a follow up to #35662. The optimizer regression that resulted in that bug is still not fixed.

That bug created a simplified test case, and fixed it for that case. That's good. However, I have not been able to remove my workaround, so the issue still persists in the original code.

The issue appears for an 8x8 kernel and disappears if the kernel is shrunk to 4x4, so it's somehow related to the sheer size of the function, or the length it goes to in loop unrolling.

Preamble for the code that produces the desired codegen:

``` rust
let mut ab: [[f32; 8]; 8];
ab = ::std::mem::uninitialized();
loop8!(i, loop8!(j, ab[i][j] = 0.));
```

What the loop8 macros do is that they expand the expression statically, so it corresponds to 64 assignments.

Initialization part for code which is not optimizing well:

``` rust
let mut ab: [[f32; 8]; 8];
ab = [[0.; 8]; 8];
```

Another example which is not optimizing well:

``` rust
let mut ab: [[f32; 8]; 8];
ab = ::std::mem::uninitialized();
for i in 0..8 {
    for j in 0..8 {
        ab[i][j] = 0.;
    }
}
```

Full reproducer in the next comment.
Repository: rust
Issue: Specify and possibly reconsider the precise semantics of #[no_mangle]
Labels: A-linkage,A-stability,T-lang

This internals post describes how people are exploiting the underspecified aspects of `#[no_mangle]` to practical effect: https://internals.rust-lang.org/t/precise-semantics-of-no-mangle/4098 . We may want to specify what guarantees the attribute actually has, and possibly introduce new attributes to represent the fine-grained roles that `#[no_mangle]` is currently being used for.
Repository: rust
Issue: Poor error message related to higher rank lifetimes
Labels: C-enhancement,A-diagnostics,A-closures,T-compiler,A-higher-ranked

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/6d739f4781c90be95ac47e067562471b0c52f9f8/src/lib.rs?at=error&fileviewer=file-view-default

After I try to use the tool.rs implementation of `second` I get this error message:

```
   Compiling fizzbuzz v0.0.1 (file:///C:/Users/Igor/Documents/rust/fizzbuzz)
error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second::<_>}` implements the trait `std::ops::FnMut<(_,)>`, but the trait `for<'r> std::ops::FnMut<(&'r _,)>` is required (expected concrete lifetime, found bound lifetime parameter )

  --> src\lib.rs:52:11
   |
52 |            .filter(apply(second, i))
   |                    ^^^^^
   |
   = note: required by `apply`

error[E0271]: type mismatch resolving `for<'r> <fn(_) -> _ {tool::second::<_>} as std::ops::FnOnce<(&'r _,)>>::Output == _`
  --> src\lib.rs:52:11
   |
52 |            .filter(apply(second, i))
   |                    ^^^^^ expected bound lifetime parameter , found concrete lifetime
   |
   = note: concrete lifetime that was found is lifetime '_#11r
   = note: required by `apply`
```

I still don't quite understand this error message. The lifetimes are anonymous, so I don't know what it's talking about. The `'r` lifetime is elided, I assume? There's no error code to help me understand the issue with concrete lifetimes vs. bound lifetime parameters.
Repository: go
Issue: tour: clarify when to use pointer receivers
Labels: Documentation,NeedsFix

There appears to be a confusion (at least to me) on what the appropriate receiver type ought to be by default. 
Looking at; https://tour.golang.org/methods/8 
That tutorial encourages new go users that: 
`There are two reasons to use a pointer receiver.`
`The first is so that the method can modify the value that its receiver points to.`
`The second is to avoid copying the value on each method call.` 

this seems to imply that you should default to using pointer receivers in only those two cases. 
whereas looking at; https://github.com/golang/go/wiki/CodeReviewComments#receiver-type and a few other credible go sources eg; https://twitter.com/rob_pike/status/788743046280077313 
we see that actually, pointer receivers should be the default while value receivers are the exception. 

So to summarize; the tour.golang notes makes it appear as if pointer receivers are the exception(that was my impression when I went through those notes as a new go user some months back) whereas in actual sense they are (or ought to be) the default.
Repository: go
Issue: x/tools/cmd/eg: does not support variadic functions
Labels: NeedsFix,Tools

### What version of Go are you using (`go version`)?

Go 1.7.1
eg 69f6f5b782e1f090edb33f68be67d96673a8059e
### What operating system and processor architecture are you using (`go env`)?

MacOSX 10.12 Sierra (Darwin) x64
### What did you do?

Given the template

```
package egtemplates

import (
    "fmt"
    "github.com/Sirupsen/logrus"
)

func before(vlog logrus.Logger, format string, args ...interface{}) {
    vlog.Errorf(fmt.Sprintf(format, args...))
}

func after(vlog logrus.Logger, format string, args ...interface{}) {
    vlog.Errorf(format, args...)
}
```

and the test file

```

package test

import (
    "fmt"

    "github.com/Sirupsen/logrus"
)

func articleCIPQ(vlog logrus.Logger) {
    vlog.Errorf(fmt.Sprintf("Table %s: %s", "something", "err"))
}
```

I executed `eg -t egtemplates/logrus-errorf.go -v ./egtemplates/test/myfile.go`.
### What did you expect to see?

```
=== egtemplates/test/myfile.go (1 matches)
package test

import (
    "fmt"

    "github.com/Sirupsen/logrus"
)

func articleCIPQ(vlog logrus.Logger) {
    vlog.Errorf("Table %s: %s", "something", "err")
}
```
### What did you see instead?

No substitutions, but no errors either.
Repository: kubernetes
Issue: kubectl exec escape sequence (tilde-dot)
Labels: area/kubectl,kind/feature,sig/cli,lifecycle/frozen

As a big user of `kubectl exec` _and_ a big commuter to and from work, I often am in situations where I have some `exec` instance open, but the connection is flaky.

When that happens, I _know_ that the connection will eventually timeout, but until then, that terminal window has become useless.

ssh has a nice `~.` (tilde-dot) escape sequence that instantly terminates the connection in those situations.

Perhaps `kubectl` can use the same technique? For someone like me, that would be a great UX improvement.
Repository: flutter
Issue: Test Android back button is functional
Labels: a: tests,c: new feature,team,platform-android,framework,P3,team-android,triaged-android

We should add a regression test that verifies that we don't break the back button on Android.
Repository: youtube-dl
Issue: Add support spuul.com
Labels: site-support-request,account-needed

Please add site support for free videos at spuul.com.
Example:
https://spuul.com/videos/1420-ladies-vs-ricky-bahl
Repository: go
Issue: x/text/currency: TestLinking fails on ppc64le, s390x
Labels: NeedsFix

Please answer these questions before submitting your issue. Thanks!
### What version of Go are you using (`go version`)?

1.7.3
### What operating system and processor architecture are you using (`go env`)?

It's a ppc64le system running Ubuntu (various versions, version not important)
### What did you do?

go test -v -p 1 golang.org/x/text/...
### What did you expect to see?

Tests passing
### What did you see instead?

--- FAIL: TestLinking (1.68s)
    currency_test.go:155: size(symbols)-size(base) was 772; want > 2K

This was part of building for the distribution, you can see the full log at:

https://launchpadlibrarian.net/290258937/buildlog_ubuntu-zesty-ppc64el.golang-x-text_0.0~git20161013.0.c745997-1ubuntu1~ppa1_BUILDING.txt.gz

This passes with Go 1.6. But in general this test seems to be a bit of a hostage to the future. I think I'm going to add a distro patch disabling this (and  the one in dict_test.go) for now.