sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Reverse the stack traces
Labels: C-feature-request

A big improvement to the speed at which I can find the origin of a panic would be to reverse the order of the stack trace. At the moment the last line of the stack trace is always `main`. This means the stack trace is written deep->shallow, or in reverse(!) chronological order:

```
1:        0x10977219c - function_that_caused_the_panic
2:        0x1097738ee - foo
3:        0x109773590 - bar
4:        0x109773cf6 - baz
5:        0x109773b94 - badger
6:        0x109757669 - main
```

What you are generally looking for is the place that caused the panic (e.g. the line with an `assert!` or `panic!` on it), and so I think it would make sense to have that line *last* so that it is easy to find. This is particularly important when the call stack is deep and it fills your terminal. [Here is a more in-depth argument for this](http://yellerapp.com/posts/2015-01-22-upside-down-stacktraces.html). 

So my suggestion is: reverse the stack trace to print the stack frames in chronological order, shallow->deep, with `main` on the top and the stack frame with the panic at the end:

 ```
6:        0x109757669 - main
5:        0x109773b94 - badger
4:        0x109773cf6 - baz
3:        0x109773590 - bar
2:        0x1097738ee - foo
1:        0x10977219c - function_that_caused_the_panic
```

I realize this can become quite the bikeshedding religious war, and maybe this has been discussed before – if so, I apologize. Still, until the blog post above brought it up I didn't realize that most languages – including Rust – was doing it wrong, and that there was a better way. In C++ I switched the order I print stack traces about a year ago, and since then it has saved me a lot of scrolling.

*EDIT*: I've created a forum thread about this here: https://users.rust-lang.org/t/reverse-stack-trace-order/8786
Repository: go
Issue: doc/articles/wiki: misleading error handling in Writing Web Applications tutorial
Labels: Suggested,Documentation,NeedsFix

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?

1.7

### What operating system and processor architecture are you using (`go env`)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/nick/golang"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/c9/n428syrn3xl63_wf458yzw9w0000gq
/T/go-build862609477=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

### What did you do?

On line 66 of this example:
https://golang.org/doc/articles/wiki/final.go
If ExecuteTemplate begins to write to the http.ResponseWriter before an error is thrown, http.Error will not properly return an error to the user.

New Gophers will see this (as I did) and assume ExecuteTemplate will never write to the buffer if an error is thrown.  This is not correct.

Example case:
https://play.golang.org/p/E_-jtdCLjk

### What did you expect to see?

Write to a temporary buffer first, if no error is caught then write that to the http.ResponseWriter.

### What did you see instead?

http.Error(w, err.Error(), http.StatusInternalServerError)
Repository: vscode
Issue: Allow to cycle through previous typed values in quick input picker
Labels: feature-request,quick-pick

- VSCode Version: Code 1.8.1 (ee428b0eead68bf0fb99ab5fdc4439be227b6281, 2016-12-19T14:49:23.350Z)
- OS Version: Windows_NT ia32 6.1.7601
- Extensions:

|Extension|Author|Version|
|---|---|---|
|read-only-indicator|alefragnani|0.4.0|
|alignment|annsk|0.3.0|
|bettertab|arenl|1.0.1|
|Doxygen|bbenoist|1.0.0|
|python|donjayamanne|0.5.5|
|EditorConfig|EditorConfig|0.3.4|
|vscode-great-icons|emmanuelbeziat|1.1.36|
|matlab|Gimly81|0.4.0|
|status-bar-tasks|GuardRex|0.1.2|
|vscode-dimmer|hoovercj|2.1.0|
|docthis|joelday|0.3.6|
|cpptools|ms-vscode|0.9.3|
|vscode-clearcase|OpenNingia|1.4.1|
|vscode-icons|robertohuertasm|4.3.0|
|theme-cyanicpastels|SamuelLampa|0.0.9|
|indenticator|SirTori|0.2.1|
|vscode-hexdump|slevesque|1.1.4|
|code-spell-checker|streetsidesoftware|0.13.3|
|comment-snippets|Tobiah|0.2.0|
|dark-plus-material|vangware|0.1.4|
|change-case|wmaurer|1.0.0|
|highlight-trailing-white-spaces|ybaumes|0.0.2|

---

Steps to Reproduce:

1. Press Ctrl-G.
2. Press Alt-Up. Nothing happens. When doing this in search it shows the last value enterred.

Please implement history for goto command similarly to search & replace.
Repository: rust
Issue: Deriving Debug on an enum with uninhabited type triggers warning
Labels: C-enhancement,A-lints,T-compiler

```rust
// no warning
#[derive(Debug)]
enum Void {}

// warns about unreachable pattern
#[derive(Debug)]
enum Foo {
    Bar(u8),
    Void(Void),
}
```

Caused by https://github.com/rust-lang/rust/pull/38069

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: go
Issue: doc: contribute.html doesn't mention GOROOT_BOOTSTRAP
Labels: Documentation,help wanted,NeedsInvestigation

Users should be able to find everything they need to know to contribute to Go by reading contribute.html.

There's no path from that page to learning about GOROOT_BOOTSTRAP, since GOROOT_BOOTSTRAP is only mentioned from the unlinked https://golang.org/doc/install/source

Fix.
Repository: vscode
Issue: Multiselect via ctrl+d case insensitivity makes it useless
Labels: feature-request,editor-multicursor

- VSCode Version: Code 1.8.1 (ee428b0eead68bf0fb99ab5fdc4439be227b6281, 2016-12-19T14:41:20.664Z)
- OS Version: Linux x64 4.4.38-1-MANJARO
- Extensions:

|Extension|Author|Version|
|---|---|---|
|Go|lukehoban|0.6.51|

---

Steps to Reproduce:

consider this block of code:
```
	accountQryConn   *grpc.ClientConn
	accountQryClient proto.AccountQueryClient
```

when I select 'account' and hit alt+d a few times it will select it like this.

![2017-01-06-150041_626x115_scrot](https://cloud.githubusercontent.com/assets/1015732/21731141/eb1079a8-d420-11e6-89a9-280b0f8d463b.png)

this is fine, but when I do this, I am doing it to replace it with something else. So I'll start typing:

![2017-01-06-150136_731x106_scrot](https://cloud.githubusercontent.com/assets/1015732/21731163/09140b68-d421-11e6-913e-a0bf92e9ed67.png)

but now my case is broken for my second string.

This is fine in a small example, but very annoying. 

Currently the case matches whatever is highlighted in the search widget. Behold what happens if I turn off case sensitivity: 

![2017-01-06-150329_1605x153_scrot](https://cloud.githubusercontent.com/assets/1015732/21731213/4eb44f16-d421-11e6-8fba-8f90ed207420.png)

This is incredibly annoying. I can't think of a time when you would want to multiselect case-insensitively with ctrl+d. It simply selects the wrong stuff, because in code it's always case sensitive. So depending on whatever I did last with ctrl+f, my ctrl+d either works or is annoying.

I think ctrl+d should always be case sensitive, or have a button that's not search-tied that does a case sensitive string selection match across the file

My two cents.
Repository: go
Issue: x/build: make a bot review CLs for common mistakes (like Tricorder)
Labels: Builders,NeedsFix,FeatureRequest

Tracking bug to write a bot to review CLs for common mistakes:

* properly-formatted references to CLs and bugs
* conventional subject ("pkg/name: lowercase verb, not period at end")
* gofmt
* missing copyright headers

And whatever else we add in the future.

(forked from email thread https://groups.google.com/forum/#!topic/golang-dev/KpHMoePhg6c)

/cc @kevinburke @rsc
Repository: go
Issue: x/website: revise download page (system requirements for stable/archived versions)
Labels: help wanted,NeedsFix

"the official 1.4 download doesn't work on Macs. You need to use the special 1.4 download link on the build-from-source page. It would be nice if either the official 1.4 download were updated, or if another one were added with an annotation on the downloads page." - @robpike https://github.com/golang/go/issues/18545#issuecomment-271014385

related issue: https://github.com/golang/go/issues/16352
Repository: nvm
Issue: exec: nvm: not found
Labels: needs followup,installing nvm

OS: Archlinux 

I tried run nvm through tsocks.
got this:
```
rapiz@sig:~/ > tsocks nvm install node
/usr/bin/tsocks: line 84: exec: nvm: not found
```
Repository: neovim
Issue: Add `:command -herearg`
Labels: enhancement,vimscript,provider

This would be essential for developers willing to add language support similar to `:py` without altering the C code. `command -herearg Foo` should, at minimum

1. Imply `-nargs=1`.
2. Make `Foo bar  baz\ b` set `<q-args>` to `"bar\x20\x20baz\\ b"` (not literally, but result of evaluation should be the same).
3. Make

        Foo << EOF
          bar \  baz
        b
       EOF

    set `<q-args>` to `"\x20\x20bar \\ baz\n b\n"`.

(basically minimal implementation should just employ code similar to `script_host_execute`, thus `-nargs=1`).
Repository: TypeScript
Issue: Interface with readonly property is assignable to interface with mutable property
Labels: Suggestion,Awaiting More Feedback

**TypeScript Version:**  2.1.4

**Code**

```ts
interface MutableValue<T> {
    value: T;
}

interface ImmutableValue<T> {
    readonly value: T;
}

let i: ImmutableValue<string> = { value: "hi" };
i.value = "Excellent, I can't change it"; // compile-time error

let m: MutableValue<string> = i;
m.value = "Oh dear, I can change it";
```

**Expected behavior:**
The assignment of `i` to `m` would fail, to stop us accidentally allowing `value` to be modified.

**Actual behavior:**
The assignment is allowed.

[The current behaviour was a deliberate choice](https://github.com/Microsoft/TypeScript/pull/6532#issuecomment-174356151) so this is a breaking change (or strict flag) feature request rather than a bug report!

The Handbook [has this snippet](https://www.typescriptlang.org/docs/handbook/interfaces.html):

```ts
let a: number[] = [1, 2, 3, 4];
let ro: ReadonlyArray<number> = a;
ro[0] = 12; // error!
ro.push(5); // error!
ro.length = 100; // error!
a = ro; // error!
```

It notes that `a = ro` being an error is helpful. But this happens because `ReadonlyArray` has no `push` method, making it incompatible with `Array`.

My example above seems "morally equivalent" to modelling the input/output flow of values with separate methods:

```ts
interface MutableValue<T> {
    getValue(): T;
    setValue(v: T): void;
}

interface ImmutableValue<T> {
    getValue(): T;
}

declare let i: ImmutableValue<string>;
i.setValue("Excellent, I can't change it"); // compile-time error

let m: MutableValue<string> = i;
m.setValue("Oh dear, I can change it");
```

And sure enough, this stops the assignment of `i` to `m`.

Would be great if mutable and readonly properties had the same relationship as if they were modelled by separate get/set methods (which of course they might actually be, via property getter/setters).
Repository: go
Issue: x/exp/shiny: key repeats reported as release + press
Labels: NeedsFix

### What did you do?

This program opens an x/exp/shiny window and reports key presses:

```
package main

import (
    "log"
    "golang.org/x/exp/shiny/driver"
    "golang.org/x/exp/shiny/screen"
    "golang.org/x/mobile/event/key"
)

func main() {
    log.SetFlags(log.Lmicroseconds)
    driver.Main(func(s screen.Screen) {
        w, _ := s.NewWindow(nil)
        for {
            e := w.NextEvent()
            if e, ok := e.(key.Event); ok {
                log.Println(e.Direction)
            }
        }
    })
}
```

### What did you expect to see?
According to https://github.com/golang/mobile/blob/master/event/key/key.go#L50, key repeats should report key.DirNone. So when pressing and holding down a key for a while, I expect to see:
```
11:59:49.544507 Press
11:59:50.045002 None
11:59:50.076717 None
11:59:50.107537 None
11:59:50.137585 Release
```

### What did you see instead?
Holding down a key results in repeated Release/Press events:

```
11:59:49.544507 Press
11:59:50.045002 Release
11:59:50.045110 Press
11:59:50.076717 Release
11:59:50.076807 Press
11:59:50.107537 Release
11:59:50.107578 Press
11:59:50.137585 Release
```

### What version of Go are you using (`go version`)?
`go version go1.7.1 linux/amd64`

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/arne"
GORACE=""
GOROOT="/home/arne/bin/go"
GOTOOLDIR="/home/arne/bin/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build871086202=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
```
Repository: youtube-dl
Issue: RFE: support retrieving credentials from a keyring
Labels: request

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2017.01.05*. If it's not read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.01.05**

### Before submitting an *issue* make sure you have:
- [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

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [x] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---

### Storing credentials in a keyring is safer than ~/.netrc

Would you consider adding support for getting credentials from keyring?  
There's a keyring-agnostic [library](https://people.gnome.org/~stefw/libsecret-docs/py-lookup-example.html) with Python bindings.
Repository: rust
Issue: Missed optimization: references from pointers aren't treated as noalias
Labels: A-LLVM,I-slow,C-enhancement,A-codegen,P-medium,T-compiler,WG-llvm,C-optimization

The following code results in `a` being dereferenced again for the return value: (https://godbolt.org/z/YnrzMa3oj)

```rust
pub unsafe fn g(a: *mut i32, b: *mut i32) -> i32 {
  *a = 0;
  *b = 1;
  return *a;
}
```

That is to be expected. In contrast, the same function with references avoids the load: (https://godbolt.org/z/YnrzMa3oj)

```rust
pub fn g_ref(a: &mut i32, b: &mut i32) -> i32 {
  *a = 0;
  *b = 1;
  return *a;
}
```

However, if we change the code to the following: (https://godbolt.org/z/YnrzMa3oj)

```rust
pub fn g(a: *mut i32, b: *mut i32, x: *const i32) {
  let a = &mut *a;
  let b = &mut *b;
  *a = 10;
  *b = 11;
  return *a;
}
```

then the extra dereference is *not* optimized out as it should be, because do not emit anything like `noalias` inside functions.
Repository: go
Issue: doc: document installation from package managers
Labels: Proposal-Accepted

The officially documented ways to install Go are to download the release archives from golang.org/dl, install it via msi or pkg installater or installing Go from the source. Even though we only support these options, a large portion of Go users are already depending on package managers to install Go and even more to desire that they can depend on package manager installations [[*](http://go-talks.appspot.com/github.com/freeformz/talks/20160712_gophercon/talk.slide#6)].

Currently, we have community-drive approach to maintain and release Go packages and this model seems to be working for some and widely used to install Go (32% of the installers already use brew and Linux package managers already).

To improve this experience, I propose the following:
* Keep package maintainers in sync during the releases and make sure that they are unblocked.
* Document these packages and instructions to use them on the golang.org website.
* Reevaluate the material on the wiki, such as https://github.com/golang/go/wiki/Ubuntu, to make it consistent with the official documentation.

/cc @bradfitz @mwhudson @rsc
Repository: go
Issue: doc: fix where we forgot to target Windows users
Labels: Documentation,help wanted,OS-Windows,NeedsFix

A significant amount of Go users are Windows users even though the official Go documentation is lacking references targeting the Windows users. This is frustrating the Windows and end up them relying on third party sources which are often not up to date or not documenting the best practices.

This is a tracking issue to improve Windows-specific instructions in docs.

* Go through all docs to evaluate if the docs are Windows friendly.
* Document instructions to set PATH a la what we have done for GOPATH, https://golang.org/wiki/SettingGOPATH. Refer to this doc where possible.
* Use https://golang.org/wiki/SettingGOPATH consistently everywhere.
* Produce a screencast similar to https://www.youtube.com/watch?v=XCsL89YtqCs for Windows users.

/cc @bradfitz @cbro @rsc
Repository: opencv
Issue: DShow: Crossbar implementation prevents multiple capture channels of same type
Labels: feature,category: videoio

Regarding this file: https://github.com/opencv/opencv/blob/master/modules/videoio/src/cap_dshow.cpp

In capture cards that feature an analogue crossbar for multiple video inputs, this driver expects each muxed input to have a different input type. Unfortunately, this prevents capture cards that have multiple inputs of the same type from working on more than one channel.

Specifically: I have a capture card with two composite inputs, and am unable to use this driver to change the crossbar setting.
Repository: go
Issue: proposal: encoding/binary/v2: Read (or a new call) should return number of bytes read
Labels: v2,Proposal

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
1.7.4

### What operating system and processor architecture are you using (`go env`)?
linux/amd64
linux/arm
darwin/amd64

### What did you do?
I want to use `binary.Read()` to marshall data to/from network byte-order.
I must keep track of my offset from the beginning of the stream (I'm decoding DNS records, which sometimes refer to strings found at offsets-from-0 farther back as a form of compression).
I would prefer not to require the use of an `io.ReadSeeker` just for the sake of discovering my current offset.

### What did you expect to see?
I expected `binary.Read()` to return the number of bytes read, as all of the `io.Read` implementations do.

### What did you see instead?
It doesn't! This seems like a silly oversight, but also not a big or difficult change.

I created [a trivial library](https://github.com/sayotte/binary) to replace the function. In retrospect, it would be better to have a differently-named function in the upstream Golang `binary` package so that Go-1.x compatibility isn't broken. `binary.Read` could be a wrapper which just drops the bytesRead return value.
Repository: TypeScript
Issue: async/await: nowait keyword?
Labels: Suggestion,Awaiting More Feedback

I have a large project that has now been migrated over from javascript to typescript and we're very pleased with the results.  Bugs have fallen dramatically with the improved compiler support in combination with rigorously written code.

Ours is a server-side product that runs under node (ts-node, actually).  By its nature, it is highly asynchronous, so the move to Typescript had the major benefit of providing us access to async/await.  It has been working really well, and dramatically reduced our code size and complexity.

The one problem it has introduced is that we occasionally miss putting an "await" keyword in front of calls to methods returning promises (i.e., other async functions) when inside an async function.  This "send and forget" is something that one occasionally might want to use, but for the most part, this creates a lot of chaos in our design pattern, as in most cases, the call is to something that will complete asynchronously, but most of the time we need to wait for that to complete.  (That method cannot be synchronous because it depends on external services that are asynchronous.)  It is not uncommon in our case to have 5 or 10 await statements in a single method.

A missing "await" keyword can be hard to find -- especially when the method being called doesn't return anything that is needed by the caller.  (If it returns something, type-checking will usually catch the mismatch between the type of the Promise<type> returned from the call.)

Ideally, we could have a "nowait" keyword that would go where one would otherwise put an "await" to indicate to the Typescript compiler that the design intent is to explicitly NOT WAIT for the called method to be completing.  The tsc compiler could have a new flag that controls whether to create a warning if a method call returns a Promise that is missing either "await" or "nowait".  The "nowait" keyword would have no effect whatsoever on the compiled code.