sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/gofmt: inconsistent spacing on slice indices
Labels: NeedsInvestigation

**What version of Go are you using (go version)?** `go version go1.4.2 linux/amd64`
**What operating system and processor architecture are you using?** Ubuntu 14.04
**What did you do?** Run `gofmt` on below code examples
**What did you expect to see?** Consistent spacing of slice indices

These are two lines within the same function. They vary slightly, but the interesting part is the `[1:len(key-1]` which has inconsistent spacing. Adding spaces to the first one will result in them being removed when `gofmt` is run, and removing the spaces from the second will only have them added back.

If this is not a bug, please let me know what difference here is causing the spacing to change.

``` Go
return "?" + key[1:len(key)-1]
```

``` Go
key = key[1 : len(key)-1]
```
Repository: rust
Issue: Can't infer the type of index
Labels: A-closures,A-inference,C-bug,T-types

This doesn't type-check

```rs
fn main() {
    let m = [[0.; 2]; 2];
    println!("{}", (|i, j| m[i][j])(0, 1));
}
```

failing with

```
error[E0282]: type annotations needed
 --> inf.rs:3:28
  |
3 |     println!("{}", (|i, j| m[i][j])(0, 1));
  |                            ^^^^ cannot infer type
```

Annotating as `usize` fixes it, but I would expect the compiler to be able to infer the type. Is there a reason why it can't?
Repository: go
Issue: cmd/trace: view large trace all at once
Labels: FeatureRequest,compiler/runtime

Here's an example.

x_test.go:

``` go
package p

import (
    "sync"
    "testing"
)

func BenchmarkBlocking(b *testing.B) {
    var mu sync.Mutex
    b.RunParallel(func(pb *testing.PB) {
        var x int
        for pb.Next() {
            for i := 0; i < 10000; i++ {
                x *= 2
                x /= 2
            }
            mu.Lock()
            for i := 0; i < 1000; i++ {
                x *= 2
                x /= 2
            }
            mu.Unlock()
        }
    })
}
```

Do this:

``` bash
$ go test -bench=. -trace=trace.out
BenchmarkBlocking-8   500000          3401 ns/op
$ go tool trace p.test trace.out
```

Then click on View trace.

Result: Browser tab crashes.

@egonelbre did an initial analysis on a related trace that came from real code (thanks, Egon!):

> Preliminary analysis seems to indicate that the trace-viewer is blowing some sort of internal memory limit in Chrome. i.e. the trace json file is 133MB and chrome dies after allocating 800MB of RAM.
> Found somewhat related issue https://github.com/google/trace-viewer/issues/298
> 
> I did some experimenting and was able to load 1.07 million events, but not 1.08M. It seems that trace-viewer can load around ~1M events. The whole dataset is ~1.5M events.
> From DOM/JavaScript perspective it is quite impressive that it can handle that much and the tool stays quite responsive.
> I think it might be better to do this at the go trace tool level, enforce the limit that you cannot look over 1M events. And then from the selection part you can select the range you wish to see.
> 
> Note that there is also a possibility of removing some particular counters from the trace.json they make up over half of the events.
> Alternatively we can reduce counters using some similarity: https://play.golang.org/p/GnJIyzmsA5

Given how easy it is to create giant (and thus unusable) traces, I think we should handle them gracefully, since the trace-viewer can't.

One option (perhaps not great): 'go tool trace' could allow you to specify a time window to display, and refuse to send windows that are too large to the trace viewer.

/cc @dvyukov @egonelbre
Repository: TypeScript
Issue: Down-level destructuring in `for..in` statement
Labels: Bug,ES6

We report an error for the following code, :

``` ts
for (var {toString} in { a: 1 }) { // error TS2491: The left-hand side of a 'for...in' statement cannot be a destructuring pattern.
   console.log(toString);
}
```

We also emit the following incorrect javascript:

``` ts
for (var toString = (void 0).toString in { a: 1 }) {
    console.log(toString);
}
```

We should instead emit:

``` ts
for (var _a in { a: 1 }) {
    var toString = _a.toString;
    console.log(toString);
}
```

While it is unlikely this will be very useful, this is another of the [ES6 compatibility tests](http://kangax.github.io/compat-table/es6/#destructuring_in_for-in_loop_heads) on the kangax compatibility table that we could consider addressing as it seems a small enough change.
Repository: kubernetes
Issue: Remove non-mergeable fields from .kubeconfig (such as preferences)
Labels: priority/important-soon,area/kubectl,sig/cli,lifecycle/frozen

As per #9298, there are two fields (Preferences and CurrentContext) in kubeconfig which are destructive when kubeconfigs are merged and prevent clean and transparent merging of kubeconfig files. We should pull out these fields to support the use case of more merging of kubeconfig files (#9298).

.kubeconfig currently holds two kinds of data:
- Maps of data that are _fully mergable_ (save for conflicts across files, which can be considered an error):
  - Clusters - a map of referencable names to cluster configs
  - AuthInfos - a map of referencable names to user configs
  - Contexts - a map of referencable names to context configs
- Unmergeble data that would overwrite each other if merged:
  - Preferences - holds general information to be use for cli interactions
  - CurrentContext - the name of the context that you would like to use by default

By pulling out Preferences and CurrentContext, we can arbitrarily merge in .kubeconfigs in any order without worrying about overwriting or confusion/anger (like that described in #4428).

The proposed design:
- For all non-kubectl programs (kubelet, controller manager, etc.), CurrentContext is either inferred when there is only one context, or something passed in as a command line parameter. It is treated just like any other config param for the program. 
- For kubectl, CurrentContext can be merged into the Preferences struct (since it's really just another kubectl preference), and the Preferences struct can be moved to a new file, ~/.kubectl. It can also be set at the command line or as an env var, given how important a Preference it is.
- For backwards compatibility, if the CurrentContext field is specified in kubeconfig it can continue to be respected (I don't think Preferences is even used anywhere yet), but all our examples/docs/auto-generated kubeconfig files would be updated to not contain it.

I believe this should be in 1.0, if we can resource it.
Repository: javascript
Issue: jQuery: $(this) vs $(event.currentTarget)
Labels: enhancement,pull request wanted,editorial

When working with jQuery in ES6 you have to pay particular attention to `$(this)` in event handlers. Using `$(this)` in ES5 is quite popular to access the DOM element of the event handler. In ES6 the code breaks if you switch from function to arrow function syntax:

``` js
// works:
$selector.on('click', function() {
   $(this).hide();
});

// doesn't work:
$selector.on('click', () => $(this).hide());
```

Instead you have to access the DOM element via `event.currentTarget`:

``` js
// works:
$selector.on('click', ev => $(ev.currentTarget).hide());
```

IMO the main problem is that you can accidentally break code by just switching from `function` syntax to arrow functions. I'm aware that this problem is not exclusive to jQuery but since `$(this)` is so widely used in jQuery code, imo it wouldn't be the badest idea idea to add this to the list of bad styles.

What do you think?
Repository: three.js
Issue: "Fit all" (show all) feature
Labels: Enhancement

Dear ThreeJS developers!

Please implement "fit all" ("show all") feature to the camera and/or OrbitControl and other controls.
This feature is very missing thing. 

To provide some help, here is implementation of same feature in X3dom:
https://github.com/x3dom/x3dom/blob/master/src/Viewarea.js#L1077

Also, there is "fit object" (e.g. show object) feature:
https://github.com/x3dom/x3dom/blob/master/src/Runtime.js#L631

Many thanks in advance.

Please do not refer me to other feature requests like https://github.com/mrdoob/three.js/issues/1095

If you deny to do this, please at least point me, where is it better to code it, e.g. in camera, or in OrbitControl/etc, to get them (camera and control) synchronized?
Repository: You-Dont-Know-JS
Issue: "async & performance": ch4, Delegating Recursion
Labels: for second edition

I've been trying to wrap my brain around the recursive `yield`-delegation example in [ch4](https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch4.md#delegating-recursion), but I can't quite seem to fully grok it, so I'm hoping you could clearify a couple of things:

In step 8, it says 

> When the promise resolves, its fulfillment message is sent [...] to the normal `yield` that's waiting in the `*foo(3)` generator instance.

But this is how I understand what's going on:
(I set up a working example over at jsbin: https://stebru.jsbin.com/noheco/2/edit?js,console, and according to the console output it seems to make sense the way I have (mis?-)understood this.)

When the first promise resolves, the response value (let's say its the number `1`) is sent (via `it.next(value)`in the `run()`method) to `*bar()`, which delegates to `*foo(3)`, which delegates to `*foo(2)`, which delegates to `*foo(1)`, where the waiting `return yield request(...);` is "replaced" with `return 1;`.

So the value is `return`ed (from `foo(1)`) to the waiting `val = yield *foo(1);` (in `foo(2)`), and so the yield expression and var assignment is replaced with `val = 1;`.

If my understanding is correct (which it probably isn't), step 8 should read:

> When the promise resolves, its fulfillment message is sent [...] to the normal `yield` that's waiting in the **`*foo(1)`** generator instance.

And in step 9 where it states:

> That first call's Ajax response is now immediately `return`ed from the `*foo(3)`generator instance [...]

it should rather read:

> That first call's Ajax response is now immediately `return`ed from the **`*foo(1)`** generator instance [...]

And lastly, in step 10 it states:

> [...] the second Ajax response propagates all the way back into the `*foo(2)`generator instance, and is assigned to its local `val` variable.

But as I understand it, the response is not assigned to the local `val` in `*foo(2)`, but rather replaced with the waiting `return yield request(...);`, e.g. `return 2`, and `return`èd from `*foo(2)` into the waiting `val = yield *foo(2);` in `*foo(3)` (which is replaced with `val = 2`).

I'm sure I'm just missing something here, but as my brain has now stopped working from thinking about all of this for too long, I hope you can help me out! :)
Repository: rust
Issue: Rust .msi installer ignores current install
Labels: O-windows,P-low,T-infra,T-dev-tools,C-bug

One of the convenient features of the defunct .exe installer is it would remove old library archives before installing new ones, so that one could update Rust just by running over the current install. The .msi installer does not do this, it just naively installs the new libraries next to the old ones, and Rust can't figure out which to use: 

```
rustbook\src\main.rs:1:1: 1:1 error: multiple matching crates for `std`
rustbook\src\main.rs:1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
                       ^
note: candidates:
note: path: \\?\C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\std-d855c359.dll
note: path: \\?\C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\libstd-d855c359.rlib
note: crate name: std
note: path: \\?\C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\std-74fa456f.dll
note: path: \\?\C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\libstd-74fa456f.rlib
note: crate name: std
rustbook\src\main.rs:1:1: 1:1 error: found staticlib `std` instead of rlib or dylib
rustbook\src\main.rs:1 // Copyright 2014 The Rust Project Developers. See the COPYRIGHT
                       ^
rustbook\src\main.rs:1:1: 1:1 help: please recompile this crate using --crate-type lib
rustbook\src\main.rs:1:1: 1:1 note: crate `std` path #1: C:\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib\libstdc++.a
error: aborting due to 2 previous errors
Could not compile `rustbook`.

To learn more, run the command again with --verbose.
```

I can't simply update my Rust install anymore. I have to remove the old libraries either manually or by running the Rust uninstaller. This is a _major_ convenience discrepancy compared to using Rust on the Unix-based platforms.
Repository: nvm
Issue: Support `node v4+`/`io.js` release candidates
Labels: installing node,feature requests,io.js

This issue is to track adding support for `io.js` release candidates. The same process will work for `node` post-merge.
Repository: go
Issue: test: add per-test timeout to run.go
Labels: NeedsFix,FeatureRequest

On the SSA branch, after fixing some other issues, the compiler hangs while compiling ken/label.go. This causes run.go to run forever. Let's add a per-test time limit, even if it is high, so we don't ever spin forever.
Repository: rust
Issue: Confusing error messages when invariant type is involved
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler

#### Reproducer

```rs
use std::{cell::RefCell, fmt::Debug};

#[derive(Default)]
struct S<'a> {
    c: RefCell<Option<Box<dyn Debug + 'a>>>,
}

impl<'a> S<'a> {
    fn r(&'a self) -> &'a () {
        panic!()
    }
}

fn main() {
    let s = S::default();
    let _ = s.r();
}

```

<details><summary>Original now malfunctioning reproducer from 2015</summary>

Playpen: http://is.gd/f1SPdn

``` rust
#[derive(Default)]
struct S<'a> {
    c: RefCell<Option<Box<Sized + 'a>>>,    // Doesn't work
    //c: RefCell<Option<Box<&'a Sized>>>,   // Works
    //c: Option<Box<Sized + 'a>>,           // Also works
}

impl <'a> S<'a> {
    fn r(&'a self) -> &'a () {
        panic!();
    }
}

fn main() {
    let s = S::default();
    let r = s.r(); //~ ERROR `s` does not live long enough [E0597]
}
```

</details>

#### Compiler Output

```
error[E0597]: `s` does not live long enough
  --> src/main.rs:16:13
   |
15 |     let s = S::default();
   |         - binding `s` declared here
16 |     let _ = s.r();
   |             ^ borrowed value does not live long enough
17 | }
   | -
   | |
   | `s` dropped here while still borrowed
   | borrow might be used here, when `s` is dropped and runs the destructor for type `S<'_>`
```

<details><summary>Original compiler output from 2015</summary>

```
<anon>:19:13: 19:14 error: `s` does not live long enough
<anon>:19     let r = s.r();
                      ^
<anon>:17:11: 20:2 note: reference must be valid for the block at 17:10...
<anon>:17 fn main() {
<anon>:18     let s = S::default();
<anon>:19     let r = s.r();
<anon>:20 }
<anon>:18:26: 20:2 note: ...but borrowed value is only valid for the block suffix following statement 0 at 18:25
<anon>:18     let s = S::default();
<anon>:19     let r = s.r();
<anon>:20 }
```

</details>

This is confusing, since the compiler seems to demand that `s` is valid in the line before it is declared (the only difference between the regions is that the first one includes the `fn main() {`). It is never mentioned that this is caused by `S` being invariant on `'a`, which disallows rustc to enlarge the lifetime to include the whole block.

I think rustc should give a better error is this case (maybe something like `` note: cannot extend lifetime of `s` since its type `S` is invariant with respect to `'a` ``).
Repository: rust
Issue: Weird inference failure with unary minus
Labels: A-type-system,T-compiler,C-bug,T-types

``` rust
fn f<T>() -> T { panic!() }
fn main() {
    let a = f();
    let b = -a;
    let c : &i32 = &a;
}
```

```
<anon>:4:14: 4:15 error: the type of this value must be known in this context
<anon>:4     let b = -a;
                      ^
error: aborting due to previous error
```

As far as I can tell, there's enough information here for inference to succeed.
Repository: javascript
Issue: ECMAScript 6 and Block Scope
Labels: pull request wanted,editorial

Add block scope to let & const bullet under ECMAScript 6 Styles section or give it its own overview and link.
Repository: rust
Issue: Inference failure with int inference variable
Labels: A-type-system,T-compiler,A-inference,C-bug,T-types

``` rust
fn f<T>() -> T { panic!(); }
fn main() {
    let mut a = f();
    let b : u8 = a+a;
    a = 1;
}
```

```
<anon>:4:18: 4:21 error: type mismatch resolving `<i32 as core::ops::Add>::Output == u8`:
 expected i32,
    found u8 [E0271]
<anon>:4     let b : u8 = a+a;
                          ^~~
```

Given that the type of `b` is `u8`, the type of `a` is a builtin integer type, and the result of `a+a` is assigned to `b`, the type of `a` must be `u8`.  Currently, this rule only applies "forwards": it only works if `a` is known to be a builtin integer type when the addition is being checked.  However, type inference could be extended to apply it backwards as well.

I'm not sure if this is relevant in practical usage of Rust.
Repository: go
Issue: x/build: support searching across build logs
Labels: Builders

For issues like #11617, it would be handy to be able to search across all build logs server-side rather than needing to download them locally.
Repository: go
Issue: x/mobile/event: lifecycle APIs are overly complicated
Labels: mobile

The new lifecycle events and having to deal with crosses to determine basic states are both overly complicated for an average user. Majority of the time, users don't want to have a good understanding of the lifecycle's itself but want to perform actions such as freeing resources or stopping the playback at certain states. Currently, Go mobile has a novel (invented here™) event model that requires user to have good understanding of its novel terminology and application lifecycle details. The new event model is a big barrier for new and existing users.

I'd, at least, prefer `LifecycleStageInvisible` and `LifecycleStageDestroyed` to be pushed to the user, it's very unlikely the users will be comfortable with determining these fundamental states themselves.
Repository: go
Issue: runtime: display fully-qualified types when strings are equal in unequal type panic
Labels: NeedsInvestigation,compiler/runtime

> What version of Go are you using (go version)?

go version devel +bd45bce Wed Jul 8 01:20:02 2015 +0000 linux/amd64

> What operating system and processor architecture are you using?

Ubuntu 15.04, amd64

> What did you do?

Created a test case to see what would happen when vendoring the same package twice in two different repositories.

go15vendortest has a copy of vendortedthing under the vendor directory
it also pulls in go15vendortest2 which has its own copy of vendoredthing under the vendor directory

```
export GO15VENDOREXPERIMENT=1
go get github.com/frumious/go15vendortest
go15vendortest
```

> What did you expect to see?

A type exception with a way to tell which type came from which package.

> What did you see instead?

panic: interface conversion: interface is vendoredthing.Data, not vendoredthing.Data

I know why this is happening because I created it on purpose, but there seems to be no way to display where these types came from.
Repository: TypeScript
Issue: Cannot 'export default' abstract, ambient class or interface
Labels: Suggestion,Help Wanted

```
export default abstract class B {

}
```

By the way, the same with

```
export default declare class B {

}
```

Seems to be a parser bug
Repository: angular
Issue: Add validators to Forms verifying basic data types
Labels: feature,effort2: days,area: forms,feature: under consideration

Data types: email, url, number, date, time, week, month.
Repository: youtube-dl
Issue: Recording flv into mp4, but not recoding mkv
Labels: request

I want to be able to record flv files into mp4.

So far, I have used this script:

```
#!/bin/bash
# Usage: youtube-480 url
youtube-dl -f "bestvideo[height<=480][ext=mp4]+bestaudio/[height <=? 480]" --write-sub --recode-video mp4 "$@"
```

But I discovered recently that if it is fetching a .mkv file (I think it was from vimeo), then it spends forever in ffmpeg trying to convert it.

I'd like to say "Convert a .flv file to .mp4".
I have no problem working with a .mkv instead.

How would I do that?
Repository: rust
Issue: `#[derive]` sometimes uses incorrect bounds (aka lack of "perfect derive")
Labels: A-trait-system,P-low,T-lang,C-bug,A-proc-macros

In the following code:

```rs
#[derive(Copy, Clone)]
struct Y<T>(&'static fn(T));
```

both derives expand to impls that require the corresponding trait to be implemented on the type parameter, e.g.:

```rs
#[automatically_derived]
impl<T: ::std::marker::Copy> ::std::marker::Copy for Y<T>
where
     T: ::std::marker::Copy
{}
```

However, this isn't actually necessary, as `Y<T>` will still be eligible for `Copy` regardless of whether `T` is.

This may be hard to fix, given the compilation phase at which `#[derive]` works...
Repository: go
Issue: regexp: port RE2's DFA matcher to the regexp package
Labels: Performance,Proposal,Proposal-Accepted,NeedsFix

The regexp package currently chooses between the standard NFA matcher, onepass, or the backtracker. This proposal is for porting over RE2's DFA matcher to be used as an option by exec.
Repository: go
Issue: runtime: refactor into separate subpackages
Labels: NeedsFix,compiler/runtime

Now that the runtime is Go code, we should be able to break it apart into multiple packages.

Among other things we should consider putting locking, the gc, and special symbols in separate packages.
Repository: go
Issue: x/tools/cmd: add tool to convert between functions and methods
Labels: FeatureRequest,Tools

Discussed with @alandonovan yesterday, recording here.

It would be useful to have a refactoring tool that could convert between:

`func (t T) f(x int)`

and

`func f(t T, x int)`

 and clean up all the callers. This could be do with `eg`, but for common refactorings, it might be nicer to have a tool that can just do it, without having to write a template (or write a template generator), so that it can be invoked easily by IDEs. This probably just means new frontends to eg.
Repository: rust
Issue: Abort on some large allocation requests, Panic on other
Labels: E-hard,P-low,A-allocators,T-libs-api,C-bug

Compare these two:

```
let v = vec![0u8; !0];
let u = vec![0u16; !0];
```

We request a vector with 18446744073709551615 elements. 
- For `u8` we receive out of memory (null) from the allocator, and call `alloc::oom`, which aborts the program: `application terminated abnormally with signal 4 (Illegal instruction)`
- For `u16`, we get an assertion: `thread '<main>' panicked at 'capacity overflow', ../src/libcore/option.rs:330`

This is inconsistent. Why don't we abort on both of these cases? We abort on too large allocation requests, so those that are even larger could abort too?