sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Quick fix for variable of wrong type results in ugly formatting
Labels: Bug,Domain: Quick Fixes

**TypeScript Version:**  nightly (2.5.0-dev.20170613)

**Code**

```js
/**
 * @param {boolean} b
 * @returns {string | number}
 */
function f(b) { return b ? "" : 0; }

/** @type {number} */
const x = f(false);
```

Click on `x` and use the quick for "Ignore this error message."

**Expected behavior:**

```js
// @ts-ignore
const x = f(false);
```

**Actual behavior:**

```js
const
    // @ts-ignore
    x = f(false);
```
Repository: vscode
Issue: On highlight/select text - cannot unhighlight/deselect text on click - need to do ESC
Labels: under-discussion,editor-drag-and-drop

- VSCode Version: Code 1.13.0 (376c52b955428d205459bea6619fc161fc8faacf, 2017-06-08T16:43:13.058Z)
- OS Version: Windows_NT ia32 6.1.7601
- Extensions: 

|Extension|Author|Version|
|---|---|---|
|git-easy|bibhasdn|1.9.1|
|file-icons|file-icons|1.0.3|
|auto-close-tag|formulahendry|0.4.2|
|auto-rename-tag|formulahendry|0.0.12|
|minify|HookyQR|0.3.0|
|Angular2|johnpapa|2.3.2|
|vscode-github|KnisterPeter|0.16.2|
|vs-deploy|mkloubert|9.25.0|
|prettify-json|mohsen1|0.0.3|
|debugger-for-chrome|msjsdiag|3.1.3|
|vscode-run-git-difftool|narekmal|0.0.4|
|gitblame|waderyan|1.11.2|
|bootstrap-3-snippets|wcwhitehead|0.0.9|;


---

Steps to Reproduce:

1. Open a file
2. Click Ctrl+A 
3. Click anywhere - highlight still stays and can't do anything else
Repository: youtube-dl
Issue: [eitb] Add support for eitb.eus
Labels: site-support-request

- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.06.12**
- [x] At least skimmed through [README](https://github.com/rg3/youtube-dl/blob/master/README.md) and **most notably** [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
- [x] Bug report (encountered problems with youtube-dl)

- Single video: http://www.eitb.eus/eu/kirolak/txirrindularitza/bideoak/osoa/4895232/bideoa-rohan-dennisek-irabazi-du-suitzako-tourreko-lehenengo-etapa/

**description**
URLs of the type eitb.eus/eu/ are not working.
URLs of the type eitb.tv/es/video/ from the same site are working fine.

**log**
```
youtube-dl.exe -v http://www.eitb.eus/eu/kirolak/txirrindularitza/bideoak/osoa/4895232/bideoa-rohan-dennisek-irabazi-du-suitzako-tourreko-lehenengo-etapa/
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'http://www.eitb.eus/eu/kirolak/txirrindularitza/bideoak/osoa/4895232/bideoa-rohan-dennisek-irabazi-du-suitzako-tourreko-lehenengo-etapa/']
[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2017.06.12
[debug] Python version 3.4.4
[debug] exe versions: ffmpeg N-67100-g6dc99fd, ffprobe N-67100-g6dc99fd, rtmpdump 2.4
[debug] Proxy map: {}
[generic] bideoa-rohan-dennisek-irabazi-du-suitzako-tourreko-lehenengo-etapa: Requesting header
WARNING: Falling back on generic information extractor.
[generic] bideoa-rohan-dennisek-irabazi-du-suitzako-tourreko-lehenengo-etapa: Downloading webpage
[generic] bideoa-rohan-dennisek-irabazi-du-suitzako-tourreko-lehenengo-etapa: Extracting information
ERROR: Unsupported URL: http://www.eitb.eus/eu/kirolak/txirrindularitza/bideoak/osoa/4895232/bideoa-rohan-dennisek-irabazi-du-suitzako-tourreko-lehenengo-etapa/
Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpkyaecyzu\build\youtube_dl\YoutubeDL.py", line 762, in extract_info
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpkyaecyzu\build\youtube_dl\extractor\common.py", line 433, in extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpkyaecyzu\build\youtube_dl\extractor\generic.py", line 2796, in _real_extract
youtube_dl.utils.UnsupportedError: Unsupported URL: http://www.eitb.eus/eu/kirolak/txirrindularitza/bideoak/osoa/4895232/bideoa-rohan-dennisek-irabazi-du-suitzako-tourreko-lehenengo-etapa/
<end of log>
```
Repository: go
Issue: proposal: spec: disallow NaN keys in maps
Labels: LanguageChange,Proposal,LanguageChangeReview

**Motivation**

Go currently supports NaN keys in maps through some [clever tricks](https://research.swtch.com/randhash).

The current spec is ambiguous on this behavior.  It says:
> [I]f the map contains an entry with key `x`, `a[x]` is the map value with key `x` and the type of `a[x]` is the value […]

but "with key `x`" could plausibly mean "with key represented by `x`". (In practice, today it means "with key equal to `x`".)

That leads to surprising and subtle bugs (such as https://github.com/golang/go/issues/14427) and adds complexity even in correct code (https://github.com/golang/go/issues/20138#issuecomment-302242472).

For example, the following two functions appear to be equivalent, but the latter version silently copies zeroes instead of the intended values for NaN keys:

```go
func copy(m map[float64]int) map[float64]int {
  c := make(map[float64]int, len(m))
  for k, v := range m {
    c[k] = v
  }
}
```

```go
func copy(m map[float64]int) map[float64]int {
  c := make(map[float64]int, len(m))
  for k := range m {
    c[k] = m[k]
  }
}
```

----
**Proposal**

We already reject incomparable values as map keys:
> If the key type is an interface type, these comparison operators must be defined for the dynamic key values; failure will cause a run-time panic.

I propose that we should apply that standard to NaNs as well. Specifically, I propose that we add the following sentence to https://golang.org/ref/spec#Index_expressions:
**Assigning to an element of a map with a key that is not equal to itself causes a run-time panic.**

This proposal is along the lines of https://github.com/golang/go/issues/19624, in that it produces panics for arithmetic operations which are otherwise likely to result in silent corruption in typical user code.

----

**Workarounds**

Users can easily avoid the proposed panics by <strike>calling `math.IsNaN(k)`</strike> checking whether the key is equal to itself before inserting a map entry.

Users who expect NaNs with _the same representation_ to map to the same element can transform the keys using `math.Float64bits` or `math.Float32bits`:

```go
  if k == 0 { // -0.0 or +0.0
    m[math.Float64bits(0)] = v
  } else {
    m[math.Float64bits(k)] = v
  }
```

Users who really do intend to store all of the entries for NaN keys separately can explicitly pair the map with a slice:

```go
  type nanElem struct {
    k float64
    v V
  }
  var (
    m map[float64]V
    nans []nanElem
  )
  if k != k {
    nans = append(nans, nanElem{k, v})
  } else {
    m[k] = v
  }
```
Repository: pytorch
Issue: Feature request: reverse_padded_sequence
Labels: module: rnn,triaged,enhancement,actionable

Hi,

There's existing discussion around a more extendable RNN API, which as of yet hasn't moved forward. Given that, and that `PackedSequence`s exist, would a `reverse_padded_sequence` function be useful, or do you just see it as being unnecessary clutter?

In particular it'd take in a Variable of padded sequences along with sequence lengths (and a `batch_first` option) and produce a Variable of padded sequences that are reversed according to their lengths, mimicking `reverse_sequence` in TensorFlow.

My thought is that this option would be a useful alternative to `PackedSequence`s in the case of bidirectional RNNs. (`PackedSequence`s seem to be primarily motivated by cuDNN, whereas in a research setting they might introduce more bookkeeping than they're worth.)

cc @ezyang @gchanan @zou3519
Repository: rust
Issue: Enable some android host builder
Labels: T-infra,C-feature-request

There are some interest in running rust in android devices, see for example: termux/termux-packages#261, https://www.reddit.com/r/rust/comments/631bl2/exciting_rust_coming_to_android_and_chromebooks/

We have [disabled](https://github.com/rust-lang/rust/pull/41864) android builders, it would be great if we  enabled some of these builders, so users of android devices (including chromebooks) would be able to run rustc.

As discussed [here](https://github.com/rust-lang/rust/pull/41149#issuecomment-293768516), we are running at the limit of our travis capacity, so it must be discussed.
Repository: rust
Issue: Avoid shipping duplicate artifacts in the host and target sysroot
Labels: C-enhancement,E-help-wanted,C-optimization

All released compilers have identical dynamic libraries in two locations. The locations on Linux are:

* `$sysroot/lib/*.dylib`
* `$sysroot/lib/rustlib/$target/lib/*.dylib`

All of these artifacts are byte-for-byte equivalent (they're just copies of one another). These duplicate artifacts inflate our installed size, inflate downloads, and cause weird bugs like https://github.com/rust-lang/rust/issues/39870. Although https://github.com/rust-lang/rust/issues/39870 is itself fixed it's [just a hack fix for now](https://github.com/rust-lang/rust/issues/39870#issuecomment-308141470) that would be ideally solved by fixing this issue!

Some possible thoughts I personally have on this are:

* Symlinks won't work because they don't work on Windows
* Hard links may work here, but I'm not sure. This'd require a lot of updates to lots of tools (rust-installer, rustup, etc)
* Simply not shipping one of these is going to be very difficult. `$sysroot/lib` is required for `rustc` itself to run correctly (that dir is typically in `LD_LIBRARY_PATH` or the equivalent) and `$sysroot/lib/rustlib/$target/lib` is where the compiler looks for target libraries. The compiler can't look in `$sysroot/lib` for libs as that's typically got a ton of libs on Unix systems.
* The most plausible solution in my mind is to create our own pseudo-symlink file format. When assembling a sysroot this is what rustbuild itself would emit (instead of copying files) but it'd basically be a file with the literal contents `rustc-look-in-your-libdir`. That way something like `$sysroot/lib/rustlib/$target/lib/libstd.dylib` would exist but essentially be an empty file (not a valid dynamic library). Instead rustc would look at `$sysroot/lib/libstd.dylib` for that file instead.

Unsure if I'm on the right track there, but hopefully can get discussion around this moving!
Repository: go
Issue: net/http: Transport does not handle 302 redirects with link-local server address correctly
Labels: help wanted,NeedsFix

Please answer these questions before submitting your issue. Thanks!

### 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="/usr/local/go"
GORACE=""
GOROOT="/opt/go"
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
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?
I need to get some data from link-local neighbor:
```
package main

import (
	"fmt"
	"net/http"
)

func main() {
	if resp, err := http.Get("http://[fe80::1%25eth0]:8002/info.json"); err == nil {
		defer resp.Body.Close()
		fmt.Println(resp)
	} else {
		fmt.Println(err)
	}
}
```

### What did you expect to see?
Something like this:
```
&{200 OK 200 HTTP/1.1 1 1 map[Connection:[keep-alive] Set-Cookie:[uid=AAAAAVlBPd2KJ2cFAwMUAg==; path=/] Server:[nginx] Date:[Wed, 14 Jun 2017 13:45:01 GMT] Content-Type:[application/json]] 0xc42007a600 -1 [chunked] false false map[] 0xc4200e8300 <nil>}
```

### What did you see instead?
`Get http://[fe80::1]:8002/info.sh: dial tcp [fe80::1]:8002: connect: invalid argument`

It happened, because `http://[fe80::1%eth0]:8002/info.json` returned 302-redirect to /info.sh and http-library lost zone-prefix somewhere while following redirect.
Proof:
```
curl -v "http://\[fe80::1%25eth0\]:8002/info.json"
*   Trying fe80::1...
* Connected to fe80::1 (fe80::1) port 8002 (#0)
> GET /info.json HTTP/1.1
> Host: [fe80::1]:8002
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
< Server: nginx
< Date: Wed, 14 Jun 2017 13:49:17 GMT
< Content-Type: text/html
< Content-Length: 154
< Location: http://[fe80::1]:8002/info.sh
< Connection: keep-alive
< Set-Cookie: uid=AAAAAVlBPt2KJ2cFAwMVAg==; path=/
<
<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host fe80::1 left intact
```
Repository: go
Issue: time: unchecked overflow in Add and AddDays
Labels: help wanted,NeedsFix

I'm trying to define a mapping between `time.Time` and a C++ time library.

The library that I'm trying to map to supports distinct "infinite past" and "infinite future" times, which need to be mapped to distinct `time.Time` values. The logical choices would seem to be the maximum and minimum representable `time.Time` values.

One way to try to obtain those is to call `(time.Time).AddDate` with absurdly positive or absurdly negative values. `AddDate` does not return an error, and it cannot reasonably panic on overflow (because the package does not define a way for users to check for such an overflow ahead of time). That leaves one "obvious" behavior: saturation.

Sadly, the current implementation fails to provide that behavior, and instead silently overflows to nonsensical values (https://play.golang.org/p/UUC2JG7Xcj).

(Further evidence for https://github.com/golang/go/issues/19624?)
Repository: flutter
Issue: Hot restart while keyboard is up leaves the keyboard up
Labels: a: text input,platform-android,platform-ios,tool,framework,engine,t: hot reload,has reproducible steps,P3,team-engine,triaged-engine,found in release: 3.16,found in release: 3.19,fyi-text-input
Repository: vscode
Issue: Editor: scroll jumps randomly (related to Chrome, Electron, xinput)
Labels: bug,upstream,linux,electron,upstream-issue-linked

- VSCode Version: starting at 1.13.0, up to current
- OS Version: Fedora 24-27

Looks like VS Code is listening to mouse scroll events, even while it is not active in the window.
Related: 
https://bugs.chromium.org/p/chromium/issues/detail?id=608246
https://bugs.chromium.org/p/chromium/issues/detail?id=807187


**Steps to Reproduce**
requirements: Browser (Chromium / Firefox / Google Chrome), VSCode Editor (Any file type. Ideally a long file to ensure the scroll is visible.)

VSCode: Leave cursor at top of file.
Browser: Scroll, excessively, (For a few seconds) down the page. Even if it's a blank tab with no content.
VSCode: Scroll, ever so slightly, in any direction.
You'll find the editor will jump suddenly further down the active file.

It seems VSCode is receiving the scroll events, for whatever reason; which are all suddenly evaluated upon any form of scroll input in the editor.

**Updates based on comments**

GUESS: Appears to be an issue with Electron and some input libraries?
Is not isolated to VScode
Fix: Does not yet exist.

Linux Workarounds (Not to be confused with a fix)

imwheel - not suitable for all users
wayland - not suitable for all users
Note: Ubuntu 19.04 (Desktop) appears to be using Wayland.

I'm not sure we will see further updates in here, which is a bit disappointing from the developers, given the amount of comments from affected people. I would like to have some official guidance, even if it's pointing us to other resources.
Repository: You-Dont-Know-JS
Issue: ES6 & Beyond: Early Completion
Labels: for second edition

Hi! In the [Early Completion](https://github.com/getify/You-Dont-Know-JS/blob/master/es6%20%26%20beyond/ch3.md#early-completion) section there is a sentence: 
`In addition to return(..) being callable manually, it's also called automatically at the end of iteration by any of the ES6 constructs that consume iterators, such as the for..of loop and the ... spread operator.`

So to check it out I created a custom iterable object with the next() and return() methods in it. I put console.log inside the every method and was expected that at the end of the for..of statement, the _return_ method of my object was called automatically. But it wasn't called!
You can check out what I mean by [this jsfiddle](https://jsfiddle.net/ovkadurin/7L21ze4y/).

So if I understand it correctly, the automatic call happens only when there is _break_ inside the for..of or we manually call _return()_. Maybe I got the phrase _at the end of iteration_ incorrectly for some reason. Does it really mean like "the very last step of for..of"?
Thanks!
Repository: rust
Issue: Add Vec::contains_ref which is worse for inference but less restrictive than Vec::contains
Labels: A-collections,T-libs-api,C-feature-request

Using Vec::contains currently only works if the contains parameter is of the same &Type as the Vector elements. This means the parameter must be converted to the vec-item-type even though it is comparable with the type in the first place.

e.g. following code does not work, even though `impl<'a, 'b> PartialEq<str> for String` exists:
```
fn main() {
    let mut v: Vec<String> = Vec::new();
    v.contains("mystring");
}
```
The Error:
```
error[E0308]: mismatched types
 --> <anon>:3:16
  |
3 |     v.contains("mystring");
  |                ^^^^^^^^^^ expected struct `std::string::String`, found str
  |
  = note: expected type `&std::string::String`
             found type `&'static str`
```

I'd be better if Vec::contains had definition like:
`fn contains<U>(&self, value: &U) where T: PartialEq<U>, U: ?Sized`
Repository: TypeScript
Issue: [bug] TemplateStringsArray is incompatible with literal array type
Labels: Suggestion,In Discussion

**TypeScript Version:**  2.4.0

**Code**

```ts
// A *self-contained* demonstration of the problem follows...
interface SQLQuery<TResult> {
  __result: TResult;
} 
declare function sql(
  literals: ['SELECT id FROM users'],
  ...placeholders: any[]
): SQLQuery<{id: number}>;

declare function querySync<TResult>(q: SQLQuery<TResult>): Array<TResult>;

const values: Array<{id: number}> = querySync(sql`SELECT id FROM users`);
```

**Expected behavior:**

Typescript should see that the input string 'SELECT id FROM users' matches the expected literals of `['SELECT id FROM users']` and use the declared function, allowing me to generate an overloaded version of the `sql` function for each query.

**Actual behavior:**

I get the error:

> src/index.ts(23,50): error TS2345: Argument of type 'TemplateStringsArray' is not assignable to parameter of type '["SELECT id FROM users"]'.
>  Property '0' is missing in type 'TemplateStringsArray'.
Repository: rust
Issue: rustdoc still doesn't handle renames in reexports correctly 
Labels: T-rustdoc,C-bug

Test case:

```rust
mod internal {
    pub struct BadName;
    impl BadName {
        pub fn f(&self) {}
    }
}
pub use internal::BadName as GoodName;
```

Running `rustdoc a.rs`, it produces this page:

> ![screenshot_2017-06-15 21 11 37_38miri](https://user-images.githubusercontent.com/103023/27182946-844014d2-520f-11e7-9b5f-0e984efe29a3.png)

Note that the `impl` still refers to the struct as `BadName`. The fix for #34473 is not enough.

Real world example:

* https://docs.rs/handlebars/5.1.0/handlebars/struct.Handlebars.html — the struct is exported as `Handlebars` but the content says `impl Registry`. The method `new()` also returns `Registry`.
* https://docs.rs/handlebars/5.1.0/handlebars/trait.HelperDef.html — the parameter involving `&'reg` refers to `Registry`, although it correctly links to `struct.Handlebars.html`.
Repository: rust
Issue: Reconsider using SVH for loading transitive crate dependencies
Labels: A-linkage,A-metadata,T-compiler,A-incr-comp

When you write `extern crate bar` in your crate then the compiler will search for and load all crates that are transitive dependencies of `bar`. Let's say, for example, that `bar` depended on crate `foo`. The compiler will look for `libfoo.rlib` after loading `libbar.rlib`. Because `bar` is already compiled the compiler wants to find the precise same `libfoo.rlib` as before. Each crate has a "strict version hash" historically (SVH) which is used for this. The metadata of `bar` says that it needs crate `foo` at a precise SVH. The intention here is to prune duplicates or other crates that look like they could satifsy the request.

Over time, though, the SVH's definition has changed over time and it may no longer be the correct tool for the job here. @nikomatsakis may have more information.
Repository: go
Issue: sync: unchecked overflow in (*WaitGroup).Add
Labels: help wanted,NeedsFix,compiler/runtime

Thinking about https://github.com/golang/go/issues/20678 (and #19624) made me wonder what other unchecked overflows are lurking in the standard library. I've found another one, but I don't have real-world code that triggers it. (I'm filing this issue just for reference.)

`(*sync.WaitGroup).Add` accepts an `int` parameter, so it is reasonable for users to expect that they cannot make `Add` calls summing to more than the maximum possible `int`. However, in practice `WaitGroup` only supports `Add` calls that sum to within `math.MaxInt32`.

`Add` currently detects (and panics on) overflows that happen to land in the negative half of the `int32` space, but fails to detect other overflows entirely.

`Add` should be fixed to reliably panic on all overflows. It should ideally support the full positive `int` range, but if that isn't feasible the supported range should be made clear in the documentation.

```
$ go version
go version devel +0a0e45d5c6 Thu May 25 17:57:21 2017 -0400 linux/amd64
```

wgover/wgover.go:
```go
package main

import (
	"fmt"
	"math"
	"sync"
	"sync/atomic"
)

func main() {
	var wg sync.WaitGroup
	var n int64

	const maxInt = int(^uint(0) >> 1)
	iters := 0x40000000
	if int64(maxInt) > math.MaxInt32 {
		iters <<= 2
	}

	fmt.Printf("looping for %d iterations\n", iters)
	wg.Add(iters)
	atomic.AddInt64(&n, int64(iters))
	go func() {
		for {
			wg.Done()
			if atomic.AddInt64(&n, -1) == 0 {
				break
			}
		}
	}()
	wg.Wait()

	fmt.Printf("done with %d iterations remaining\n", atomic.LoadInt64(&n))
}
```

expected (with very long running time):
```
$ go run wgover/wgover.go
looping for 4294967296 iterations
done with 0 iterations remaining
```

actual:
```
$ go run wgover/wgover.go
looping for 4294967296 iterations
done with 4294967296 iterations remaining
```