sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: doc: Update documentation on cherry-picking
Labels: Documentation,help wanted,NeedsFix

The current documentation on "Reviewing code by others" in the contribution guidelines is for the old Gerrit UI. The new Gerrit UI does not have the same "Download" button, and when one goes to More/Cherry Pick it appears it needs to be cherry-picked onto another branch on Gerrit.  I was also unable to reverse engineer the provided `git` call to apply in a new situation.

It's reasonable to ask users to test if commits resolve issues, but it would be nice to provide clean documentation on how to do so. My recommendations:

- Making it its own section, possibly above Making a Contribution. Right now, the section is a tiny section at the bottom that is easy to miss.
- Update the documentation to the new Gerrit UI
- Some discussion on how to properly apply a patch given an issue, i.e. given an installation from source at current stable, list the correct steps. Checkout branch? Checkout master, then branch, then apply patch?
Repository: go
Issue: proposal: spec: change int to be arbitrary precision
Labels: LanguageChange,Proposal,Proposal-FinalCommentPeriod,LanguageChangeReview

An idea that has been kicking around for years, but never written down:

The current definition of `int` (and correspondingly `uint`) is that it is either 32 or 64 bits. This causes a variety of problems that are small but annoying and add up:

- overflow when constants like math.MaxUint64 is automatically promoted to `int` type
- maximum size of a byte slice is only half the address space on a 32-bit machine
- `int` values can overflow silently, yet no one depends on this working. (Those who want overflow use sized types.)
- great care must be taken with conversion between potentially large values, as information can be lost silently
- many more

I propose that for Go 2 we make a profound change to the language and have `int` and `uint` be arbitrary precision. It can be done efficiently - many other languages have done so - and with the new compiler it should be possible to avoid the overhead completely in many cases. (The usual solution is to represent an integer as a word with one bit reserved; for instance if clear, the word points to a big.Int or equivalent, while if set the bit is just cleared or shifted out.)

The advantages are many:

- `int` (and `uint`, but I'll stop mentioning it now) become very powerful types
- overflow becomes impossible, simplifying and securing many calculations
- the default type for `len` etc. can now capture any size without overflow
-  we could permit any integer type to be converted to `int` without ceremony, simplifying some arithmetical calculations

Most important, I think it makes Go a lot more interesting. No language in its domain has this feature, and the advantages of security and simplicity it would bring are significant.
Repository: kubernetes
Issue: Feature Request: enable user-managed Pod Migration
Labels: sig/scheduling,sig/apps,lifecycle/frozen

A user wants to extend Kubernetes to allow for application-specific migration in response to pod deletion events, whenever possible.

1. Normally, there should be 1 instance of a pod  -- call it `pod-1`.  
1. However, something (usually the system, e.g. rescheduler or node upgrades) wants to delete `pod-1`, then a replica, `pod-2` should be created.
1. Before `pod-1` is actually terminated, it will discover `pod-2` and they will do an application-level handoff of state.  
1. After handoff, scale down to just 1 pod, for economy.

This issue is created to suggest possible ways to implement this pattern.
Repository: vscode
Issue: `editor.fontFamily` in settings should suggest list of available monospace fonts
Labels: feature-request,settings-editor

_From @letientai299 on March 16, 2017 9:57_



_Copied from original issue: Microsoft/vscode-docs#889_
Repository: rust
Issue: refactor the `AssociatedItem` structures
Labels: C-cleanup,A-associated-items,T-compiler

During the work on https://github.com/rust-lang/rust/pull/40668, there was some discussion about refactoring the `ty::AssociatedItem` and `hir::{Impl,Trait}ItemRef` data structures. The precise plan is a *bit* unclear, so I'm opening this issue to try and discuss and lay it out.

Observations:

- Although `ty::AssociatedItem` lives in `ty`, it has no real dependencies and is based entirely on the HIR, so it would better live in HIR.
    - The existing `ImplItemRef` and `TraitItemRef` are basically specialized variants of `AssociatedItem`, though they add a `Span` and use local-ids (`ImplItemId`) rather than a `DefId`.
- There is a need for a query that given a `DefId` gives you back the `AssociatedItem` (including across crates). The local-crate portion of this query seems like it could live in `hir::map` quite nicely.
- Some of this setup is carefully crafted to avoid incorrect incremental dependencies and can change as we progress on the proposed red/green changes (in particular, the current query goes to some lengths to avoid reading from `Hir(X)` when computing `AssociatedItem(X)`, instead reading from the containing impl/trait; this is because we don't want to require everything that needed even basic information about `X` to have to change when `X` changes).

cc @eddyb @cramertj
Repository: go
Issue: encoding/base64: decoding is slow
Labels: Performance

### What version of Go are you using (`go version`)?
Go 1.8

### What operating system and processor architecture are you using (`go env`)?
amd64

### What did you do?
On my slow computer, using encoding/base64, I can decode data at ~100MB/s. 
It should be much faster as shown by https://github.com/aklomp/base64

I'm planning to work on this in my spare time. This issue tracks this effort.
Repository: TypeScript
Issue: raise a type error on attempt to strict-equal-compare a value of string | null to undefined
Labels: Suggestion,Awaiting More Feedback

the following examples are almost certainly bugs:

```typescript
declare var one: string | undefined;
// expected a type error: Operator '===' cannot be applied to types 'string | undefined' and 'null'
// actual no problem
if (one === null) { 
   // unreachable, because one can't ever be null, undefined was likely meant instead
}
```
```typescript
declare var another: string | null;
// expected a type error: Operator '===' cannot be applied to types 'string | null' and 'undefined'
// actual no problem
if (another === undefined) {
   // unreachable, because one can't ever be undefined, null was likely meant instead
}
```

consider raising a type error for the above situations
Repository: angular
Issue: There is no way to access inputs or outputs of Components created by NgComponentOutlet 
Labels: feature,area: common,feature: under consideration

**I'm submitting a ...**  (check one with "x")
```
[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
```

**Current behavior**
There is no way to set @Inputs or subscribe to @Output events of the Component created by `NgComponentOutlet`.

**Expected behavior**
I expect some to set values and to subscribe events.

**What is the motivation / use case for changing the behavior?**
At least, we should have the same level of functionality as `ViewContainerRef.createComponent()` which is roughly the programatic equivalent of `NgComponentOutlet`. That function returns a `ComponentRef<any>` which provides an instance property that allows direct access to the class instance of the Component. The original feature request for `NgComponentOutlet` defined an event on the directive that would fire and pass this `ComponentRef` object after creation. This did not make it into the current implementation and I see no other alternatives to access inputs/outputs.

Supporting only Components with no inputs or outputs severely limits the usefulness of `NgComponentOutlet`.

* **Angular version:** 4.0.0-rc.1
Repository: go
Issue: cmd/compile: use FP-based frame zeroing outside of package runtime on plan9
Labels: Performance,OS-Plan9,NeedsInvestigation,compiler/runtime

In 039d455f9d3d5d5109424f15d86b7f9b63768b42, we changed cmd/compile to avoid using DUFFZERO and other FP-based frame zeroing methods, because they're not permitted within note handlers.

I think this is overly conservative. It should still be safe to use DUFFZERO on plan9 when we're compiling non-runtime packages, because functions from those packages will never be called by sigtramp. This is probably as simple as changing

    var isPlan9 = obj.GOOS == "plan9"

to

    var isPlan9 = obj.GOOS == "plan9" && compiling_runtime

in cmd/compile/internal/amd64/ggen.go.

Just pointing out since I was looking at related code. Will let some of the plan9 folks decide if this is worth pursuing.

/cc @0intro
Repository: go
Issue: x/build/kubernetes/gke: use non-deprecated auth
Labels: Builders,NeedsFix

We're currently using `clusters.list` to get the certificate pair used to authenticate to the Kubernetes API. This is deprecated (and very confusing to set up in a new project). The docs say we should switch to just using OAuth directly with the API (which has the advantage that we don't need to also grant the coordinator permission to create new clusters).

/cc @bradfitz
Repository: rust
Issue: Type inference incorrectly selects specialized instance of type parameter
Labels: T-compiler,A-specialization,A-inference,C-bug,F-specialization

```rust
#![feature(specialization)]
use std::vec;

struct Foo<T>(T);

impl<T> Foo<T> {
    fn foo<I: IntoIterator<Item = T>>(it: I) -> Foo<T> {
        <Self as SpecExtend<_, _>>::from_iter(it.into_iter())
    }
}

trait SpecExtend<T, I> {
    fn from_iter(iter: I) -> Self;
}

impl<T, I> SpecExtend<T, I> for Foo<T>
    where I: Iterator<Item = T>
{
    default fn from_iter(iter: I) -> Self {
        panic!()
    }

}

impl<T> SpecExtend<T, vec::IntoIter<T>> for Foo<T> {
    fn from_iter(iter: vec::IntoIter<T>) -> Self {
        panic!()
    }
}

fn main() {}
```

```
rustc 1.17.0-nightly (134c4a0f0 2017-03-20)
error[E0308]: mismatched types
 --> <anon>:8:47
  |
8 |         <Self as SpecExtend<_, _>>::from_iter(it.into_iter())
  |                                               ^^^^^^^^^^^^^^ expected struct `std::vec::IntoIter`, found associated type
  |
  = note: expected type `std::vec::IntoIter<T>`
             found type `<I as std::iter::IntoIterator>::IntoIter`

error: aborting due to previous error
```

@aturon
Repository: opencv
Issue: Stitcher not working on the real Windows Phone (Lumia 950) but works fine on emulator
Labels: bug,category: stitching,platform: winrt/uwp

## System information (version)

- OpenCV => 3.0.0-dev (master)
- Operating System / Platform => Windows Phone 8.1
- Compiler => Visual Studio 2013

## Detailed description

Stitcher.stitch() function works pretty fine on Windows Phone emulators (x86 code, checked both WP8.1 and W10M) but fails on the real device (I used Microsoft Lumia 950 for development). From my code trace, I found that call of `matcher->knnMatch(features1.descriptors, features2.descriptors, pair_matches, 2);` in the **matchers.cpp** produces different **pair_matches** on emulator and real handset. Sorry, I can't trace this sophisticated code too deep.

I'm using [this picture set](https://www.dropbox.com/s/qwx5x8knyv6ob7x/test_images.zip?dl=0); for the test app, I've modified slightly (for simplicity) **opencv_perf_stitching** project by this way (added these lines at the beginning:
```
    Mat pano;
    vector<Mat> imgs;
    imgs.push_back( imread( "1.jpg" ) );
    imgs.push_back( imread( "2.jpg" ) );
    imgs.push_back( imread( "3.jpg" ) );

   Stitcher stitcher = Stitcher::createDefault();
   auto result = stitcher.stitch(imgs, pano);

```

**Could you please fix this issue as soon as you can (or suggest workaround)? It's a real showstopper for me now :(**

## Steps to reproduce

- download and unzip [this picture set](https://www.dropbox.com/s/qwx5x8knyv6ob7x/test_images.zip?dl=0)
- open solution **OpenCV.sln**
- set active project **opencv_perf_stitching**
- modify source file **perf_stitch.cpp** as described above
- add images 1.jpg, 2.jpg, 3.jpg as a Content to the project
- build project on **x86** platform  and run on emulator, **status** will be 0 (normal situation, panorama built)
- build project on **arm** platform and run on real phone, **status** will be 1, i.e. ERR_NEED_MORE_IMGS (matcher not found points)
Repository: TypeScript
Issue: Allow an interface in the JSX namespace to specify the element class type
Labels: Suggestion,In Discussion

We're writing a non-react library that uses TS's JSX support with custom interfaces defined in the JSX namespace. Unless we are very much mistaken (The documentation seems a little out-of-date in this area? Most of our current understanding comes from reading through issues on here, we may have missed something.) it seems that while ElementClass can be used to define the type of the _element instance type_ there is no interface to limit the members of the _element class type_.

We have a custom component base-class and an equivalent to React's createElement function. Our createElement function needs to be able to create instances of the component classes. To be able to do this  in a type-safe manner, we need to be able to specify an interface for the _element class type_ that can require a specific constructor signature. 

This feels like an oversight in the current implementation TBH. With React itself it's even possible to create components with incompatible constructors that would fail at runtime.
Repository: TypeScript
Issue: Improve feedback for abstract class instantiation error messages
Labels: Suggestion,Help Wanted,Effort: Moderate,Experience Enhancement

<!-- 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 -->
**SUGGESTION**

Recently, I was trying to use a library written in ES2015 in an Ionic 2 project, and kept getting a `Cannot instantiate abstract class 'Foo'`. `Foo` is a concrete class that extends abstract class `Bar`, which extends abstract class `Baz`. The problem turned out to be a typo in `Bar.d.ts` (see below), which (I believe) made Typescript think that `Foo` did not implement some abstract methods of `Bar` and/or `Baz` (I'm still not sure which), but it took me a day and half to figure out what was going on. This error message should have more information about why `Foo` is abstract: `Foo is declared as abstract` or `Foo does not implement abstract methods ...`

**TypeScript Version:**  2.0.9

**Code**

**`Baz.d.ts`**
```ts
export as namespace Baz;

declare abstract class Baz {
  abstract baz(): string;
}
```

**`Bar.d.ts`**
```ts
export as namespace BarTypo;

declare abstract class Bar extends Baz {
  abstract foo(): void;
  abstract bar(): string;
  baz(): string;
}

export { Bar };
```

**`Foo.d.ts`**
```ts
import { Bar } from './bar.d';

export as namespace Foo;

declare class Foo extends Bar {
  constructor(opts?);

  foo(): void;
  bar(a: string): string;
}

export { Foo };
```

**`otherProject.ts`**
```ts
import { Foo } from 'library';

export class Service {
  foo: Foo;

  constructor()  {
    this.foo = new Foo({ opt: true });
  }
}
```

**Expected behavior:**
`Error: Cannot instantiate abstract class 'Foo'. It does not implement abstract method(s): baz.`
OR
`Error: Cannot instantiate abstract class 'Foo'. It does not implement abstract method(s): foo, bar.`
OR
`Error: Cannot instantiate abstract class 'Foo'. It does not implement abstract method(s): baz (from Baz); foo, bar (from Bar).`

**Actual behavior:**
`Error: Cannot instantiate abstract class 'Foo'.`
Repository: go
Issue: x/build: make trybots refuse to test a commit that's too old
Labels: Builders

Make trybots refuse to test a commit with a git parent over N commits or days old.

Related to but different than #9858
Repository: go
Issue: x/tools/go/ssa: docs describe a non-existent DebugRef.Object method
Labels: Documentation,NeedsInvestigation,Tools

The documentation for the [DebugRef type](https://godoc.org/golang.org/x/tools/go/ssa#DebugRef) describes the possible values returned by the Object method. However, no such method exists.

As far as I can tell, the method has never existed; the comment, however, dates back to at least 2013. Should the method be added, or the comment removed?

/cc @alandonovan @griesemer
Repository: go
Issue: html/template: dynamic substrings in HTML tags or attributes can result in unsafe HTML output
Labels: help wanted,NeedsFix

The following template:
```html
<s{{.X}}>alert('pwned')</script>
```
produces the following HTML output when executed with `X = "cript"`:
```html
<script>alert('pwned')</script>
```
This happens because:
* **During HTML parsing/escaping time**, the parser interprets "s" as the tag name, since the rest of the tagname will only be evaluated at execution-time. This causes the escaper to transition into the plain-text state, rather than the JS state, inside the script element body.
* **During execution time**, the htmlNameFilter inserted into `{{.X}}` (i.e. `{{.X | _html_template_htmlnamefilter`) sees the text value `"cript"`, deems that it is a safe HTML tag/attribute name, and renders it as-is.

In general, allowing dynamic substrings in HTML tags or attributes may confuse the parser and escaper, since the static and dynamic parts of the name are handled in different phases.

**Suggested solution:** disallow dynamic substrings in HTML tags or attributes completely.
Repository: go
Issue: x/tools/go/ssa: make opaqueType less annoying to use
Labels: Tools

The ssa package defines an opaqueType, which is an "opaque and degenerate" type, currently used by the Range instruction. It truly is degenerate, embedding a nil types.Type, causing a call to types.Type.Underlying to panic. 

Code that wants to operate on the types of instructions needs to specifically check for the Range instruction and skip it. There doesn't seem to be a way to check for this degenerate type specifically, which would at least permit passing types around without having to keep track of the originating instruction.

The simplest solution that I can think of is to implement Underlying as the identity function. However I suspect that this hasn't been done for a good reason?

/cc @alandonovan
Repository: go
Issue: x/image/webp: issue with colors contrast when converting to jpeg/png
Labels: NeedsInvestigation

When i try to convert a webp image to a PNG image doing like that: https://play.golang.org/p/yAGNTfQrx2

The converted PNG dont keep the same "contrast" as the source webp image, while it's ok when converting the webp image with:
 `dwebp in.webp -o out.png`

The same thing occurs when i convert a WEBP to JPEG.

- webp image (in.webp) : https://files.fm/f/dygrmekf
- png image (converted with dwebp cmd) : https://files.fm/f/hx2thfdn 
- png image (converted with webp.Decode()->png.Encode()) : https://files.fm/f/2hws9psu

Im using  go1.8 darwin/amd64
Repository: vscode
Issue: Add dropdown for search input history
Labels: feature-request,search,editor-find

- VSCode Version: 1.10
- OS Version: Windows 10

Very closely related to https://github.com/Microsoft/vscode/issues/18735

This is a feature request.  The UX around `find` is the one place where VS Code is not quite perfect - which speaks volumes to how wonderful this editor is.  Wonderful job.

Basically, it would be great if, inside the `Find` box you could hit the down arrow and get a dropdown of prior searches which you could navigate between to re-search.
Repository: create-react-app
Issue: Show a transparent overlay with development warnings
Labels: issue: proposal

As proposed [here](https://github.com/facebookincubator/create-react-app/issues/1873#issuecomment-288726204), maybe we should have a transparent "warning overlay" which is dismiss-able.
Repository: vscode
Issue: Allow to configure editor auto reload behaviour
Labels: feature-request,workbench-editors,keep

**VSCode Version:** 1.10.2
**OS Version:** macOS 10.12.3

**Steps to Reproduce:**
1. Open editor
2. Modify a file in your git repository, but don't save it
3. Checkout a different branch that touches the same file
4. Go back to the editor and try to save
5. ERROR: "Failed to save 'file1': The content on disk is newer. Click on Compare to compare your version with the one on disk."

Personally I would like to see the files being reload from the disk every time without prompt. With git I don't have to worry about losing history. Similar to how SublimeText works. When the files change in disk (ex: change of branches), they get automatically reloaded, independently of their current state in the editor. I prefer this behaviour, rather than having to confirm reloads.

With that said however, **there must be options for all the use cases**. Many people prefer to be notified of changes in their files!
Suggestion to add an `editor.autoReload` parameter in order to control this behaviour. Possible values:
* `Always` - reload from disk without prompt
* `Confirm` - show a prompt confirmation to either accept or discard the changes
* `Backup` - show the file with the new changes automatically, but always backup the old state to 'filename.bak'
* `Never` - current behaviour?

Evolved the idea from @rmunn on [#23043](https://github.com/Microsoft/vscode/issues/23043#issuecomment-288601201) issue. Decided it was best to create a separate issue for this.

EDIT: Made it clear that it is mandatory to implement this feature with all the use cases in mind, and added new options.
Repository: go
Issue: cmd/compile: eliminate base.Pos and ir.CurFunc
Labels: help wanted,NeedsFix,compiler/runtime

This is an umbrella issue for eliminating the global `lineno` variable from package gc. Filing as a HelpWanted issue because I think it's a relatively low-barrier-to-entry issue that people can usefully contribute to the compiler with small incremental improvements.

Here's the general algorithm:

  1. Identify a function `Bar` that uses lineno.
  2. Split it into two functions `Bar` and `Barl`; `Barl` takes an additional `pos src.XPos` parameter, and `Bar` just calls `Barl` with `lineno`.
  3. Change callers of `Bar` to use `Barl`. Ideally, the caller can supply the position information directly (e.g., via `n.Pos` or something); but if necessary, just use `lineno` and later we'll recursively apply this procedure on the caller function.

An example of this is `yyerror` and `Warn` now have `yyerrorl` and `Warnl' functions that we're trying to use instead.

Note: sometimes uses of lineno should just go away entirely (e.g., CL 38393 / 80c4b53e1e5159cc440e52c906583edc1eb79abc). I suggest pinging here to discuss instances and/or express interest in working on this to avoid duplicating work (e.g., @josharian and I are looking at this in the backend for #15756).