sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: net/v2: Listen is unfriendly to multiple address families, endpoints and subflows
Labels: v2,Proposal

The following example program:

``` go
package main

import (
        "net"
)

func main() {
        net.Listen("tcp", "localhost:8080")
        select{}
}
```

Currently yields this result:

```
$ netstat -nl | grep 8080
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN
```

While the following result would be optimal:

```
$ netstat -nl | grep 8080
tcp6       0      0 127.0.0.1:8080          :::*                    LISTEN
tcp6       0      0 ::1:8080                :::*                    LISTEN
```

(Note that the first socket is actually dualstack, and bound to ::ffff:127.0.0.1, but that's less critical than adding the second socket bound to ::1.)

More generally, when you call `net.Listen()` on a hostname which resolves to multiple IPv4/IPv6 addresses, only the first IPv4 address is selected.  An analogous problem occurs if you `Listen("tcp", ":8080")` on an operating system that doesn't support dualstack sockets: instead of returning a pair of sockets bound to `[::]:8080` and `0.0.0.0:80`, you only get IPv4.

The fundamental flaw is that `Listen()` assumes a single socket, which is a leaky abstraction that's inappropriate for high-level things like example servers, e.g.:
http://golang.org/pkg/net/#pkg-overview

Go should either adapt the `Listen()` API to support multiple sockets, or if that's not feasible, a new multi-socket API should be introduced, which deprecates `Listen()` for all cases except simple non-wildcard addresses.
Repository: TypeScript
Issue: Find references for shorthand properties
Labels: Bug

``` ts
interface A {
    foo();
}

function foo() { }
var a: A = { foo };
a.foo(); // find references on call to foo
```

If you find references on the call to foo, it should also turn up the actual function definition. But the function definition seems to be excluded.
Repository: rust
Issue: Unboxed closure types look weird in error messages
Labels: C-enhancement,A-diagnostics,T-compiler,WG-diagnostics

``` rust
fn main() {
    let x: () = |:| {}; // error: mismatched types: expected `()`, found `closure[<anon>:2:17: 2:23]` (expected (), found closure)
}
```

It looks like d258d68 might have changed this for debugging purposes, but forgot to change it back.
Repository: neovim
Issue: License for docs
Labels: documentation,runtime,project-management

Migrated from https://github.com/neovim/docs/issues/29 (which was deleted).

---

@ZyX-I suggested CC license for docs. We should implement that so we can have a clear license going forward. https://github.com/neovim/neovim/issues/878#issuecomment-46810685

Existing Vim docs are licensed under http://www.opencontent.org/openpub/ . Relevant line:
 https://github.com/neovim/neovim/blob/a62fe49d3caa40b8a6efb6528cce725f4dffa78a/runtime/doc/usr_01.txt#L159

Existing Vim docs specify the Vim license: https://github.com/neovim/neovim/blob/08c99dcff0d9397a1d464eee159b1d56217fc5e0/runtime/doc/uganda.txt#L24

We need to add the Neovim license to that.
Repository: go
Issue: proposal: net: should provide an interface for dialing
Labels: Proposal,NeedsInvestigation

net.Dialer sounds like it's close to making transports pluggable the way e.g. http.Client / http.Transport behave, but reading further one realizes that net.Dialer is hardcoded to basically be net.Dial with timeouts. This makes e.g. crypto/tls DialWithDialer less useful; I can't just easily replace the whole transport layer with something that e.g. doesn't touch the host TCP stack (think unit tests, Tor, stream protocols constructed on top of UDP, and such).

Note that tls.DialWithDialer doesn't just dialer.Dial, it also accesses the Timeout field. By the time Go2 comes around, maybe /x/net/context will have grown into something that can unify this sort of behavior.

Of course, the workaround is to dial manually and use tls.Client, but then one is responsible for all the little details that are inside tls.DialWithDialer.

Naturally, I don't expect Go1 to change existing APIs, though something new might be workable. Sorry for the ramble, just felt like writing down my hopes of reusability being crushed.
Repository: go
Issue: x/mobile/event: keyboard support
Labels: mobile

Both android and iOS provide OS software onscreen keyboards. The event package needs a common API for activating both, and needs to adjust the reported screen space appropriately.

There are some curious complications for those of us used to traditional keyboards, but nothing impossible:
- there are various ways to suggest different key layouts (for example, just a numeric pad)
- word suggestion can translate in a large number of single key presses all at once
Repository: go
Issue: x/review/git-codereview: doesn't set upstream to origin/master
Labels: NeedsInvestigation

We need to set upstream to master like below.

```
$ git checkout -b fix-windows-readlink
$ vim foo.go
$ git change
git rev-parse --abbrev-ref fix-windows-readlink@{u}
error: No upstream branch found for 'fix-windows-readlink'
error: No upstream branch found for 'fix-windows-readlink'
fatal: ambiguous argument 'fix-windows-readlink@{u}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fix-windows-readlink@{u}
```

```
git branch --set-upstream fix-windows-readlink origin/master
```
Repository: kubernetes
Issue: REST api - 'kind' property not always exists on entities
Labels: priority/backlog,area/api,area/usability,sig/api-machinery,lifecycle/frozen,triage/accepted

'kind' property exists only on the outer entity in REST api hence providing not aligned behavior for REST api consumers.
Example: when querying for all services (/api/v1beta1/services) there's an attribute 
"kind": "ServiceList" on the collection, but in the "items" section with the actual services - none of the services has the "kind" attribute.
But when querying for a specific service, for example:
http://localhost:8080/api/v1beta1/services/kubernetes-ro
There is a "kind": "Service" on the entity.

I don't see the necessity to have the "kind" property in the first place since the user knows which resource was called by the api specific url, but even if it has a reason and is by design, the entities attributes should be identical whether retrieved as a single entity or as a collection. Otherwise the client should be adding/deleting attributes when retrieved as a collection by their collection type - which is doable, but definitely not elegant.
In other words, either "kind" should be present in each entity when retrieved in bulk AND when retrieved as a single entity, or not present at all for all cases.
Repository: go
Issue: x/review/git-codereview: commit-msg hook doesn't play well with Signed-off-by lines
Labels: NeedsInvestigation

For example, git commit -s will generate this log message:

```
    test: test commit

    Signed-off-by: Shenghou Ma <minux@golang.org>

    Change-Id: I3545610fc076ab9da46bb5ed571a49730a5075dc
```

However, it should look this instead, which is generated by the official gerrit commit-msg hook:

```
    test: test commit

    Change-Id: I3545610fc076ab9da46bb5ed571a49730a5075dc    
    Signed-off-by: Shenghou Ma <minux@golang.org>
```
Repository: go
Issue: net: LookupSRV and search domains when name is empty
Labels: NeedsInvestigation

Using Go 1.4 on Linux x86_64 (Ubuntu).

I called the lookupSRV function in the "net" package, with
`lookupSRV("service", "tcp", "")` (empty name). 

I expected this to lookup using my search domains ("_service._tcp.my.search.domain"), but it potentially seems to have queried it with an extra "." ("_service._tcp..my.search.domain").

Is this intended? Or am I just using the function in a strange way? The workaround I'm using right now is to call `lookupSRV("", "", "_service._tcp")` instead.
Repository: TypeScript
Issue: Add "sealed" key word to mark some public/protected methods not be overriden
Labels: Suggestion,Needs Proposal

From https://github.com/Microsoft/TypeScript/issues/1524, I see that the default method are all "virtual", but sometimes I don't wanna some public method to be overidden. Would you invent a mechasim to force the users that they cannot override a public method (with the key word, something like "sealed")?

Thanks!
Repository: rust
Issue: Spurious test out-of-stack test failure on Android
Labels: A-codegen,O-android,T-compiler,C-bug,I-flaky-test

See https://gist.github.com/aturon/6c03914f968084548cd6 for an example. @alexcrichton dug into this and found strange behavior but wasn't able to make sense of it.

The test is going to be marked ignore on android for the time being.
Repository: rust
Issue: Permit impl methods whose bounds cannot be satisfied to have no body
Labels: A-trait-system,T-lang,E-medium,C-feature-request

There is a curious case with where clauses where sometimes we can show that a method in an impl could not possibly be called. This is because the impl has more precise information than the trait. Here is an example:

``` rust
    trait MyTrait<T> {
        fn method(&self, t: &T) where T : Eq;
    }

    struct Foo;
    struct Bar; // note that `Bar` does not derive `Eq`

    impl MyTrait<Bar> for Foo {
        fn method(&self, t: &T) where Bar : Eq { // <-- `Bar : Eq` cannot be satisfied!
        }
    }
```

We should permit the method body to be omitted in such a case. As a workaround, once #20020 is fixed, I imagine it would be possible to write an impl like this:

```
impl MyTrait<Bar> for Foo {
    fn method(&self, t: &T) { // no where clause at all
        panic!("Bar : Eq could not be satisfied");
    }
}
```

However, it is unfortunate to require that of the user. For one thing, perhaps it happens later that an impl of `Eq` is added for `Bar` -- now we have this method hanging around that will panic. It'd be nice to detect that statically. 

The plan then would be to permit:

```
impl MyTrait<Bar> for Foo {
    fn method(&self, t: &T); // <-- no body or where clauses needed
}
```

This serves as a declaration that you believe this method could never be called. At trans time, we will generate a body that simply does the equivalent of `panic!("unsatisfiable method`method`invoked")`.

I plan to open an amendment to the where clause RFC describing this particular case.
Repository: youtube-dl
Issue: youtube-dl -U exit status
Labels: request

I disable networking and run
simon@falcon:~$ youtube-dl --version
2014.12.17.2
simon@falcon:~$ youtube-dl -U
ERROR: can't find the current version. Please try again later.
simon@falcon:~$ echo $?
0
Why not set an non-zero exit status and print the message to STDERR?
best regards
Repository: rust
Issue: Parse and accept type equality constraints in where clauses
Labels: A-type-system,T-lang,C-tracking-issue,A-lazy-normalization,S-tracking-unimplemented,S-tracking-design-concerns,T-types

Implement the missing type equality constraint specified in [RFC 135](https://github.com/rust-lang/rfcs/pull/135).

### Examples

```rs
fn sum<I: Iterator>(_: I) -> i32
where
    I::Item == i32 // or `I::Item = i32`
{
    // ...    
}
```
Repository: neovim
Issue: remove 'imcmdline', 'imdisable', 'imsearch'
Labels: compatibility

These options were effectively disabled in https://github.com/neovim/neovim/pull/1568. Need to investigate if they should be removed.

Related:

- vscode Nvim GUI: https://github.com/vscode-neovim/vscode-neovim/issues/1370
Repository: rust
Issue: Fully generalize cmp instances
Labels: T-libs-api,C-feature-request

With [cmp/ops reform](https://github.com/rust-lang/rfcs/pull/439), all of the comparison traits allow the types of the two sides to differ. However, the traits provide a _default_ type for the right-hand size that is the same as the left-hand side. Thus, an impl like:

``` rust
impl<T: PartialEq> PartialEq for Rc<T> { ... }
```

is more limited than it needs to be; it could instead be

``` rust
impl<U, T: PartialEq<U>> PartialEq<Rc<U>> for Rc<T> { ... }
```

(Of course, you could imagine being even more general than that, allowing Rc values to be compared to other values.)

The various impls in the standard library should probably be generalized along these lines; currently a few are but most aren't.
Repository: go
Issue: x/review/git-codereview: can't run git change
Labels: NeedsInvestigation

git-codereview is confused and thinks I'm on some other branch:

```
ba12:oauth2 bradfitz$ go get -u -v golang.org/x/review/git-codereview
Fetching https://golang.org/x/review/git-codereview?go-get=1
Parsing meta tags from https://golang.org/x/review/git-codereview?go-get=1 (status code 200)
get "golang.org/x/review/git-codereview": found meta tag main.metaImport{Prefix:"golang.org/x/review", VCS:"git", RepoRoot:"https://go.googlesource.com/review"} at https://golang.org/x/review/git-codereview?go-get=1
get "golang.org/x/review/git-codereview": verifying non-authoritative meta tag
Fetching https://golang.org/x/review?go-get=1
Parsing meta tags from https://golang.org/x/review?go-get=1 (status code 200)
golang.org/x/review (download)

ba12:oauth2 bradfitz$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 12 commits.
#   (use "git push" to publish your local commits)
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   transport.go
#

ba12:oauth2 bradfitz$ git branch
* master

ba12:oauth2 bradfitz$ git diff --cached
diff --git a/transport.go b/transport.go
index 9e7b106..10339a0 100644
--- a/transport.go
+++ b/transport.go
@@ -62,7 +62,7 @@ func (t *Transport) CancelRequest(req *http.Request) {
        type canceler interface {
                CancelRequest(*http.Request)
        }
-       if cr, ok := t.Base.(canceler); ok {
+       if cr, ok := t.base().(canceler); ok {
                t.mu.Lock()
                modReq := t.modReq[req]
                delete(t.modReq, req)

ba12:oauth2 bradfitz$ git codereview change nilbase
git-codereview: cannot branch from work branch; change back to master first.

ba12:oauth2 bradfitz$ git branch
* master
```

/cc @adg @rsc
Repository: go
Issue: x/mobile: allow api users to decide when to SwapBuffers.
Labels: mobile

While fixing app on x11/egl and porting it to x11/glx I found some need for a redesign.
See https://go-review.googlesource.com/#/c/1851 for some discussion.

Right now the idea is to always vsync on back buffer swap.
This will make any app run at the display devices (probably) fixed refresh rate.
An app that takes 1.1 frames to render will wait 0.9 frames for the next vblank causing your app to run at half of the display's refresh rate when you could be running much faster.
Refresh rates are not required to be 60hz, so you would have to measure your framerate every frame to figure out if you are running slower or faster.

I recommend letting the user trigger a draw and swap and the user running their own timer.
The triggers for draw and swap should be separate so people have the choice to use single buffered contexts (which may be making a comeback oddly).  
For running your own timer I recommend timer.NewTicker().  
I found it works perfectly as a frame timer with desktop gl.

For controlling whether SwapBuffers() vsync's
This simple function is available with nearly the same definition for egl/glx/wgl.
https://www.khronos.org/registry/egl/sdk/docs/man/html/eglSwapInterval.xhtml
It just takes an integer >= 0 that is the number of vblanks SwapBuffers should wait for.
Something similar exists for darwin but ios looks a bit ugly.
Repository: youtube-dl
Issue: [site request] CollegeRama
Labels: site-support-request

Some big universities in Holland are running a presentation site for their lectures. Technical University Delft (TUD) offer great content to many thousands of regular visitors on:  http://collegeramacolleges.tudelft.nl/online/faculties/all-faculties/public-lectures/

Basically, a video of the professor/lecturer speaking (or videoclips in their presentation) and a timelapsed sequence of slides (images) is what comprises an online lecture. It would be great if youtube-dl could support this site to:
1) download the lecture video
2) download the presentation (slide images) with a time-code in their name (or perhaps as a second video, or side-by-side/picture-in-picture single video)

An example of a lecture:
https://collegerama.tudelft.nl/Mediasite/Play/585a43626e544bdd97aeb71a0ec907a01d?catalog=fd32fd35-6c99-466c-89d4-cd3c431bc8a4

I very much hope this can be supported in a future version of Youtube-DL.
Repository: go
Issue: cmd/vet: flag unkeyed struct literals when a struct has two fields of the same type
Labels: Analysis

Suggested in #9409.

Note that vet already flags all unkeyed composite struct literals when the type comes from a different package. This would extend checks to same-package types, but with more stringent criteria.

@bradfitz @alandonovan @shurcooL
Repository: go
Issue: net/http: document errors more (*Transport, Client's wrapper errors, etc), how to check canceled, ...
Labels: Documentation,help wanted,Proposal,Proposal-Accepted,NeedsFix

I've been doing some experimenting with Go HTTP clients and servers under load.
One of the curious things I've discovered is that calls to (*http.Client).Get occasionally return unusual errors.

The documentation at http://golang.org/pkg/net/http/#Client says:
"An error is returned if the Client's CheckRedirect function fails or if there was an HTTP protocol error."

I've been leaving CheckRedirect nil and testing against a local server that never serves redirects.  From the comment, that would imply that I should only receive HTTP protocol errors - which would correspond to the type *http.ProtocolError.

For typical socket errors, the clients in fact return a *url.Error - but the only place in the net/http documentation where url.Error is even mentioned is for the client.CheckRedirect field, which is completely unrelated to the errors I'm testing.

But that's not all!

The *url.Error usually wraps a net.OpError, which seems reasonable enough.  In fact, net.Error is what I would have expected in the first place, since I didn't know about url.Error at all before I started these experiments.

But instead, the *url.Error occasionally wraps io.EOF.  I'm guessing that happens when the socket happens to close at exactly the wrong moment, and because of the poor documentation it's not at all clear to me whether that's the intended behavior of the Client methods or an outright bug in the library.

But that's not all either!

The error wrapped by the OpError, one would expect, is a net.Error describing the underlying network error for the op.  But that's not the case either - it's often a syscall.Errno instead, and syscall.Errno does not implement net.Error.  So for temporary conditions, such as EPIPE or ECONNRESET, the net package's preferred mechanism for indicating that the condition _is_ temporary does not work as expected.

So I end up needing a big pile of user code to sort through the whole stack of errors, find the root error, and check for particular syscall.Errno values, and that whole big pile of code is now relying on undocumented error spaces that could theoretically change completely with the next Go release.

To summarize: error handling in the http package is a mess.  Someone familiar with the intended behavior of the package should clarify the documentation at least to the point where it's sensible to say whether the more subtle behaviors (e.g. io.EOF in a url.Error) are bugs or not.
Repository: go
Issue: go/doc: confusing types displayed for mixed exported/unexported consts
Labels: NeedsInvestigation

Given:

``` go
const (
    a, _, c = T, iota, int
    D, E, f

    J, k = iota, T
    L, M
)
```

godoc outputs:

```
const (
    _ = T, iota, int
    D, E

    J = iota, T
    L, M
)
```

It is not clear from the output what the type of `D`, `E`, `L`, or `M` is.

I came across this while working on a follow-up to #5397. This is an edge case, and I've not seen it in the real world. It is not clear what the correct thing to do here is; probably we should just ignore it.
Repository: go
Issue: x/mobile/gl: Mismatch in Uniform and Attrib Value types
Labels: mobile

Hi,

I noticed that the `Value` field of the `Attrib` and `Uniform` types is of different type - `uint` and `int32` respectively.
[http://godoc.org/golang.org/x/mobile/gl#Attrib](http://godoc.org/golang.org/x/mobile/gl#Attrib)
[http://godoc.org/golang.org/x/mobile/gl#Uniform](http://godoc.org/golang.org/x/mobile/gl#Uniform)

According to the documentation, they both should be `uint`.
[https://www.khronos.org/opengles/sdk/docs/man3/html/glGetAttribLocation.xhtml](https://www.khronos.org/opengles/sdk/docs/man3/html/glGetAttribLocation.xhtml)
[https://www.khronos.org/opengles/sdk/docs/man3/html/glGetUniformLocation.xhtml](https://www.khronos.org/opengles/sdk/docs/man3/html/glGetUniformLocation.xhtml)

So I see no sense in them being of different type.

Furthermore, shouldn't the type of `Attrib` be a bit more strictly specified - for example `uint32` - similar to other ID types in the `mobile/gl` API?

Regards,
Momchil Atanasov
Repository: go
Issue: cmd/vet: "could not import" warning message not visible without -v.
Labels: Analysis

Using Go 1.4 and latest tools subrepo:

```
~ $ go version
go version go1.4 darwin/amd64
~ $ gostatus -v ...cmd/vet
     golang.org/x/tools/...
```

By default, `vet` is supposed to detect "Suspicious calls to functions in the Printf family." I've noticed that it sometimes did not do that reliably (it would detect some cases but not others). I wrote the following .go file that reproduces the issue for me:

``` Go
package main

import (
    "log"
    "net/url"

    "golang.org/x/oauth2"
)

func main() {
    thirdParty := oauth2.Config{
        ClientID: "some-string", // A string.
    }
    stdLib := url.URL{
        Path: "some-string", // A string.
    }

    log.Printf("Hello, %d.\n", thirdParty.ClientID) // go vet does _not_ catch this.
    log.Printf("Hello, %d.\n", stdLib.Path)         // But it catches this.
}
```
#### What did you expect to see?

Both printf verb usage issues should be reported, not just one.

```
main.go:18: arg thirdParty.ClientID for printf verb %d of wrong type: string
main.go:19: arg stdLib.Path for printf verb %d of wrong type: string
```
#### What did you see instead?

Here is my output of `vet` on that file/package:

```
main.go:19: arg stdLib.Path for printf verb %d of wrong type: string
```

It detects the bad printf verb usage for a string type from standard library, but not external library.

It would be great if `vet` were more reliable, so I could _depend on it_ to catch all printf verb misuse when possible (and it's certainly possible here).
Repository: go
Issue: proposal: spec: add support for int128 and uint128
Labels: LanguageChange,Proposal,LanguageChangeReview
Repository: go
Issue: cmd/gofmt: moves comment in for
Labels: NeedsInvestigation

On playground (and elsewhere), [this code](http://play.golang.org/p/0kv0J7re1b)

``` go
package main

func main() {
        for i := 0; i < 1 /* 9000 */ ; i++ {
                _ = i
        }
}
```

is transformed by gofmt into [this code](http://play.golang.org/p/0kv0J7re1b):

``` go
package main

func main() {
    for i := 0; i < 1; /* 9000 */ i++ {
        _ = i
    }
}
```

It has swapped the comment and the nearby semi-colon.

This code arises when temporarily changing the limit of a loop.

I think this swap changes the context of the comment, possibly changing its meaning.

It also means that I'll have to swap 9000 (in this example) and the semi-colon back when restoring the original loop limit.