sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: print shell commands safely
Labels: NeedsInvestigation

<pre>The printing of commands by the go tool is simple-minded, can be incorrect in the face
of empty strings and other issues, ignores system-dependent issues ($foo vs %foo;
quoting, etc.) and should be improved. The current setup just calls Printf or special
formatting routines that sometimes (not always) expand variables, and ignore local
quoting and other conventions (rm vs. del for example). It's not important but it is
worth doing right.

It's a big job.</pre>
Repository: go
Issue: spec: Clarify semantics of interface to interface assignment
Labels: Documentation,NeedsFix

<pre>When assigning an interface to an interface, the dynamic value of the LHS becomes the
dynamic value of the RHS, but this is not stated anywhere in the spec.

This came up in a discussion I had with a developer who was confused because he could
not use the reflect package to find the method set of an interface. He believed that the
interface{} parameter of reflect.TypeOf should have contained the static type of his
typed nil interface.</pre>
Repository: go
Issue: runtime: detect zombie goroutines
Labels: NeedsDecision,FeatureRequest

<pre>Runtime can detect goroutines blocked on unreachable chans/mutexes/etc and report such
cases.
This needs an interface in http/pprof to query zombie goroutines on running services.
And probably testing package integration to test for absence of zombie goroutines.</pre>
Repository: go
Issue: net: cgoLookupIPCNAME doesn't try again for temporary failures in getaddrinfo()
Labels: NeedsInvestigation

<pre>go version devel +55f0ec9b3c00 Mon Apr 22 22:09:11 2013 -0700 linux/amd64

Heavy usage of net.Dial via net/http.Get gives errors stringifying as &quot; Temporary
failure in name resolution&quot; which corresponds to EAI_AGAIN returned from
getaddrinfo().

I expect net.Dial to retry on this error code.

I'm using 6g on Linux.

No effort is made to set the IsTimeout member of DNSError at the callsite
<a href="http://code.google.com/p/go/source/browse/src/pkg/net/cgo_unix.go#98">http://code.google.com/p/go/source/browse/src/pkg/net/cgo_unix.go#98</a>, and an appropriate
IsTemporary variable is not available.</pre>
Repository: go
Issue: go/printer: think about format for chained calls
Labels: Thinking

by **tshaked@google.com**:

<pre>var ss = s.NewConfig().
    User(&quot;t&quot;).
    DataLayout(
    sssssss.NewDataLayout().
        BaseDir(&quot;/c&quot;).
        StartDate(&quot;2013-01-01&quot;).
        Sh(
        s.PN{
            P: 1,
            N: 10}).
        H(7).
        Hon(0.01))</pre>
Repository: go
Issue: runtime/race: instrument Sendmsg/Recvmsg and Flock
Labels: RaceDetector

<pre>What steps will reproduce the problem?

write a program that synchronizes due to calls to Sendmsg and Recvmsg

build and test with -race

What do you see instead?

a race is detected

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

linux

Which version are you using?  (run 'go version')

tip

Please provide any additional information below.

Dmitry helped me debug this. Recvmsg needs:

  if rsa.Addr.Family != AF_UNSPEC {
  from, err = anyToSockaddr(&amp;rsa)
  }
+ if raceenabled &amp;&amp; err == nil {
+ raceAcquire(unsafe.Pointer(&amp;ioSync))
+ }

Sendmsg needs:

  msg.Iov = &amp;iov
  msg.Iovlen = 1
+ if raceenabled {
+ raceReleaseMerge(unsafe.Pointer(&amp;ioSync))
+ }

Dmitry suggested that this is for after Go 1.1. Since it's a small fix, it would be nice
to do it before, but we can wait.</pre>
Repository: go
Issue: cmd/compile: avoid closure for captured dynamic constant
Labels: NeedsInvestigation

<pre>The compiler is not very smart about compiling away closures.  The following function
needlessly allocates a closure at runtime

func main() {
  s := &quot;&quot;
  f := func () { println(s) }
  g(f)
}

This example should succumb to closure analysis.  The closure should be eliminated at
compile time and replaced by an ordinary function.</pre>
Repository: go
Issue: proposal: spec: byte view: type that can represent a []byte or string
Labels: LanguageChange,Proposal,LanguageChangeReview

<pre>Go has no built-in type which can represent a read-only view of possibly-changing bytes.

We have two current types which internally are a byte pointer and a length:  (the first
also has a capacity, irrelevant to this issue) 


[]byte

   Allowance: &quot;you can mess with this memory&quot;
   Restriction: &quot;this memory isn't necessarily forever; anybody else might be changing it now (race) or later (iterator becoming invalidated after this call, etc)&quot;

string

   Allowance: &quot;if you have a reference to this, it's good forever, and nobody will ever mess with it&quot;.
   Restriction: &quot;you can NOT change&quot;


And because of their conflicting allowances and restrictions, any conversion from
string-&gt;[]byte or []byte-&gt;string necessarily has to make a copy and often
generates garbage. 

Both are great, but there's a missing piece:

Many places in Go's API want a type with *neither* of those allowances, and are happy
with both of those restrictions:

-- much of pkg strings
-- much of pkg bytes
-- all the strconv.Parse* functions (<a href="https://golang.org/issue/2632">issue #2632</a>)
-- most of the string arguments to system calls
-- the io.Writer interface's argument (no need then for io.WriteString)
-- leveldb's Key/Value accessors.

Look at leveldb's Iterator:

<a href="http://godoc.org/code.google.com/p/leveldb-go/leveldb/db#Iterator">http://godoc.org/code.google.com/p/leveldb-go/leveldb/db#Iterator</a>

It has to go out of its way to say &quot;please do not corrupt my memory&quot;.  If
somebody uses memdb directly
(<a href="http://godoc.org/code.google.com/p/leveldb-go/leveldb/memdb)">http://godoc.org/code.google.com/p/leveldb-go/leveldb/memdb)</a> and misuses the Iterator
type, all the sudden the memory corruption and stack traces implicate the memdb package,
even though it's a caller of memdb who violated the db.Iterator contract.

All leveldb really wants is to give callers a view of the bytes.

That is, in addition to &quot;string&quot; with its promise A (handle for life) and
&quot;[]byte&quot; with its promise B (you can mutate), we need a a common type to both
of those with neither promise, what is constant-time assignable from a string or a
[]byte.

s := &quot;string&quot;
b := []byte(s)
var v byteview = s // constant time assignment
var v byteview = b // constant time assignment

A byteview would be represented in memory just like a string (*byte, int), but the
compiler would prevent mutations or addressing (like string), and callers would always
treat its backing data as ephemeral, like a []byte, unless negotiated otherwise.

Obviously this isn't a Go 1.n item, considering the impact it would have on the standard
library.

A good name for byteview would be &quot;bytes&quot;, but we have a package
&quot;bytes&quot; already. Maybe we can get rid of that package.</pre>
Repository: go
Issue: path/filepath: Glob is case-sensitive on Windows
Labels: OS-Windows,NeedsDecision

by **me@conradz.com**:

<pre>What steps will reproduce the problem?

Copy the program at <a href="http://play.golang.org/p/9G14FfcKES">http://play.golang.org/p/9G14FfcKES</a> into a .go file and run in a
directory that has write permissions (it will create the test.txt file).

What is the expected output?

Files found with *.txt: [test.txt]
Files found with *.TXT: [test.txt]

What do you see instead?

Files found with *.txt: [test.txt]
Files found with *.TXT: []

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g

Which operating system are you using?
Windows 8 64-bit

Which version are you using?  (run 'go version')
go version go1.1rc3 windows/386


File paths on Windows are normally case-insensitive, but the filepath.Glob is currently
case-sensitive on Windows. I would expect it to be case-sensitive if the OS has
case-sensitive paths, and be case-insensitive if the OS has case-insensitive paths.</pre>
Repository: go
Issue: proposal: net/http/v2: thoughts for Go 2.0
Labels: v2

<pre>Wishlist bug for what net/http would look like if we could make backwards-incompatible
changes.

Anything goes.

I'll start:

* Handler (<a href="http://golang.org/pkg/net/http/#Handler)">http://golang.org/pkg/net/http/#Handler)</a> currently takes a pointer to a 208
byte Request struct.  

* The Request struct (<a href="http://golang.org/pkg/net/http/#Request)">http://golang.org/pkg/net/http/#Request)</a> has all its fields
publicly exposed, most of which require memory allocation:

  -- Method
  -- URL (itself 104 bytes, with a bunch of strings requiring allocation)
  -- Header map + slices + strings (even if never accessed)
  -- TransferEncoding slice (even if not accessed)
  -- Host string (even if not accessed)
  -- RemoteAddr string (even if not accessed)
  -- RequestURI (even if not accessed)
  -- TLS state struct (even if not accessed)

For a lightweight handler that doesn't touch anything (say, serves some static content
from memory), this means we can't do any better than generating ~1KB of garbage per
request.

I'd prefer to make a ServerRequest interface with accessor methods which can generate
needed data on demand.

This would also simplify our docs on our doubly-abused-in-different-ways *Request, which
contains documentation gems like:

    // PostForm contains the parsed form data from POST or PUT
    // body parameters.
    // This field is only available after ParseForm is called.
    // The HTTP client ignores PostForm and uses Body instead.
    PostForm url.Values

If we had byte views (<a href="https://golang.org/issue/5376">issue #5376</a>), I would also say that most fields in the
ServerRequest, URL, Header, and FormValues are all byte views with validity scoped to
the duration of the http.Handler call, instead of strings.</pre>
Repository: go
Issue: cmd/link: external linker generates larger binaries than 6l/8l
Labels: NeedsInvestigation

by **unclejacksons**:

<pre>What steps will reproduce the problem?

Using 6l from Go 1.1:
go build -ldflags '-s -linkmode internal' -tags release
github.com/valyala/ybc/apps/go/memcached
wc -c memcached 
  1562016 memcached

Using Go 1.1 the patch which passes '-s' to ld:
go build -ldflags '-s' -tags release github.com/valyala/ybc/apps/go/memcached
wc -c memcached 
  2096920 memcached

Using Go 1.1 release:
wc -c memcached
  3194317 memcached

What is the expected output?
The resulting binary linked with the external linker should be smaller, its size should
be closer to that of the binary linked with 6l.
Since Go 1.1 defaults to using the external linker because it's more mature, it should
generate smaller binaries.


Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Ubuntu 13.04 amd64

Which version are you using?  (run 'go version')
go version go1.1 linux/amd64 from
<a href="https://go.googlecode.com/files/go1.1.linux-amd64.tar.gz">https://go.googlecode.com/files/go1.1.linux-amd64.tar.gz</a>


What can be done to make the resulting binaries smaller?</pre>
Repository: go
Issue: go/types: named types defined within a function print as if defined at package scope
Labels: NeedsInvestigation

<pre>package main
type T int
func f() {
        type T int
}

Both of these types are printed as &quot;main.T&quot;.  This is ambiguous and confusing;
the f-local type should have a different name.  Not sure what 6g does.</pre>
Repository: go
Issue: gdb: nothing works (windows amd64)
Labels: ExpertNeeded,OS-Windows

by **SmileKZS**:

<pre>## What steps will reproduce the problem?

1. <a href="https://gist.github.com/smilekzs/5640921">https://gist.github.com/smilekzs/5640921</a>
2. go build test.go
3. gdb test.exe
4. run the following

```
(gdb) break main.main
(gdb) r
(gdb) n
(gdb) n
(gdb) n
(gdb) p s
(gdb) p S
(gdb) p I
(gdb) info goroutines
```


## What is the expected output?

Print value of `s`, `S`, and `I`
List goroutines.


## What do you see instead?

```
(gdb) p s
No symbol &quot;s&quot; in current context.
(gdb) p S
No symbol &quot;S&quot; in current context.
(gdb) info goroutine
```

Then it crashes.


## Which compiler are you using (5g, 6g, 8g, gccgo)?

go build test.go
(6g I suppose?)


##Which operating system are you using?

Windows 8 amd64.
Same results on two windows 8 boxes.


## Which version are you using?  (run 'go version')

go version go1.1 windows/amd64


## Please provide any additional information below.

* Go 1.1, official windows amd64 msi installer.
* Python 2.6, official installer.
* GDB 7.4 amd64 with python26 support, from
<a href="https://code.google.com/p/go-w64/downloads/list">https://code.google.com/p/go-w64/downloads/list</a>
* Environment properly set.

Workaround batch script for <a href="https://golang.org/issue/5458">https://golang.org/issue/5458</a> :
<a href="https://gist.github.com/smilekzs/5640649">https://gist.github.com/smilekzs/5640649</a>

BTW: It's really hard to find a working GDB amd64 binary with Python support. Before I
even hit this bug, there's the necessity of a workaround (otherwise GDB can't even find
the runtime sources -- see issue #5458 for details). How can we have no first-class
debug tool that Just Works?</pre>
Repository: go
Issue: x/net/ipv4: an address as a result of routing table lookup for source-routing, source address selection
Labels: NeedsInvestigation

<pre>In addition to Dst and IfIndex, ControlMessage should contain a member corresponding to
ipi_spec_dst, from struct in_pktinfo. This is available when IP_PKTINFO is set.

It's necessary when the IP address that a packet is received on is required, rather than
the header destination address (which is what Dst represents).</pre>
Repository: go
Issue: net/http/cgi: allow chunked body in request
Labels: Suggested,help wanted,NeedsInvestigation

by **cgmurray**:

<pre>What steps will reproduce the problem?
Why are requests with chunked transfer encoding not permitted in http/cgi? Is this
according to the cgi specification? Git sends data (push) with chunked transfer encoding
and I believe that it's supported in Apache.

Side-note: By disabling the error-check in ServeHTTP chunked requests seems work in
general but when sending large data, &gt;= 1MB,  in combination with writing the
&quot;Content-Type&quot; header the request data seems to be corrupted. Any other
header, e.g. &quot;_Content-Type&quot; works however.

Which version are you using?  (run 'go version')
go version go1.1 darwin/amd64</pre>
Repository: go
Issue: cmd/link: add eabi tag to arm binary
Labels: NeedsInvestigation

by **namsgorf**:

<pre>What steps will reproduce the problem?

1. Run &quot;readelf -A -- /path/to/go/binary&quot;

What is the expected output?

Something like the following, which is the result of running the same command on
/bin/bash instead:

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: &quot;7-A&quot;
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3-D16
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

What do you see instead?

No output; zero exit status.

Which compiler are you using (5g, 6g, 8g, gccgo)?

N/A

Which operating system are you using?

Ubuntu Saucy

Which version are you using?  (run 'go version')

go version go1.1 linux/arm

Please provide any additional information below.

See <a href="https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1187722">https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1187722</a> for a golang build
problem this caused.

The ARM Architecture ABI r2.09 Addenda specifies the &quot;eabi&quot; attribute tags. In
this case, a Tag_ABI_VFP_args setting of VFP would allow tools to detect the binary as
armhf. I think this could be achieved with:

    .eabi_attribute 28, 1

But note that this bug is a request to add all useful attributes in general, rather than
the specific issue that prompted this report.

I'm trying to find out if is a requirement that ARM executables specify this information
if they want to link with system libraries that do. Nevertheless, it would be useful as
a wishlist item for the go binaries to provide this information so that distribution
tooling can make use of it.</pre>
Repository: go
Issue: regexp: no way to replace submatches with a function
Labels: NeedsInvestigation

by **denys.seguret**:

<pre>ReplaceAllStringFunc is useful when you need to process the match to compute the
replacement, but sometimes you need to match a bigger string than the one you want to
replace. A similar function able to replace submatch(es) seems necessary.

Let's say you have strings like

    input := `bla b:foo=&quot;hop&quot; blabla b:bar=&quot;hu?&quot;`

and you want to replace the part between quotes in b:foo=&quot;hop&quot; and
b:bar=&quot;hu?&quot; using a function.

It's easy to build a regular expression to get the match and submatch, for example

    r := regexp.MustCompile(`\bb:\w+=&quot;([^&quot;]+)&quot;`)

but when you use ReplaceAllStringFunc, the callback is only provided the whole match,
not the submatch, and must return the whole string. Practically this means you need to
execute the regexp (or another one) in the callback, for example like this :

        input := `bla bla b:foo=&quot;hop&quot; blablabla b:bar=&quot;hu?&quot;`
        r := regexp.MustCompile(`(\bb:\w+=&quot;)([^&quot;]+)`)
        fmt.Println(r.ReplaceAllStringFunc(input, func(m string) string {
                parts := r.FindStringSubmatch(m)
                return parts[1] + complexFunc(parts[2])
        }))

I think a function ReplaceAllStringSubmatchFunc would be useful and would avoid the
second pass. The callback would receive the submatch and return the replacement of the
submatch. The last example would be rewritten as

        input := `bla bla b:foo=&quot;hop&quot; blablabla b:bar=&quot;hu?&quot;`
        r := regexp.MustCompile(`\bb:\w+=&quot;([^&quot;]+)&quot;`)
        fmt.Println(r.ReplaceAllStringSubmatchFunc(input, complexFunc))
        
A similar function (ReplaceAllStringSubmatchSliceFunc ?) could be designed to give the
callback an array of strings that the callback would change. In fact it could be decided
that only this last function is really necessary.

Links :

 - &quot;How-to&quot; question on Stack-Overflow : <a href="http://stackoverflow.com/q/17065465/263525">http://stackoverflow.com/q/17065465/263525</a>
 - Playground link : <a href="http://play.golang.org/p/I6Pg8OUeTj">http://play.golang.org/p/I6Pg8OUeTj</a></pre>
Repository: go
Issue: reflect: field lookup ignores methods that cancel fields (ambiguity is ignored)
Labels: NeedsInvestigation

<pre>1) $ cat x.go
package main

import &quot;reflect&quot;

type S1 struct {
    m int
}

type S2 struct{}

func (S2) m() int { return 0 }

type S struct {
    S1
    S2
}

func main() {
    var s S
    t := reflect.TypeOf(s)
    if f, ok := t.FieldByName(&quot;m&quot;); ok {
        println(&quot;field found:&quot;, f.Name)
    } else {
        println(&quot;field not found&quot;)
    }
}


2) $ go run x.go
field found: m


But in truth, the field m and the method m are at the same level and thus &quot;cancel
each other out&quot;. In the same program, accessing s.m leads to a compile-time error (
ambiguous selector s.m ).

The bug is in <a href="http://golang.org/src/pkg/reflect/type.go?#L856">http://golang.org/src/pkg/reflect/type.go?#L856</a>
(structType.FieldByNameFunc) which ignores methods.</pre>
Repository: go
Issue: all: test fails on IPv4- or IPv6-only kernels
Labels: Testing

<pre><a href="http://www.freebsd.org/ipv6/ipv6only.html">http://www.freebsd.org/ipv6/ipv6only.html</a>

Sure, it fails, of course.</pre>
Repository: go
Issue: x/net/ipv4: test fails on IPv6-only kernels
Labels: NeedsInvestigation

<pre><a href="http://www.freebsd.org/ipv6/ipv6only.html">http://www.freebsd.org/ipv6/ipv6only.html</a>

Sure, it fails.</pre>
Repository: go
Issue: cmd/compile: emits unnecessary deferreturn
Labels: Performance

<pre>parent: 17086:2879112bff3d tip, linux/amd64

The program is:

package main

import &quot;sync&quot;

func main() {
    println(foo(0))
}

func foo(x int) int {
    // fast path
    if x != 42 {
        return x
    }
    // slow path
    mu.Lock()
    defer mu.Unlock()
    seq++
    return seq
}

var (
    mu  sync.Mutex
    seq int
)

The generated code for fast path is:

func foo(x int) int {
  400c40:       64 48 8b 0c 25 f0 ff    mov    %fs:0xfffffffffffffff0,%rcx
  400c47:       ff ff 
  400c49:       48 3b 21                cmp    (%rcx),%rsp
  400c4c:       77 05                   ja     400c53 &lt;main.foo+0x13&gt;
  400c4e:       e8 bd 81 01 00          callq  418e10 &lt;runtime.morestack16&gt;
  400c53:       48 83 ec 08             sub    $0x8,%rsp
  400c57:       48 8b 44 24 10          mov    0x10(%rsp),%rax
  400c5c:       48 c7 44 24 18 00 00    movq   $0x0,0x18(%rsp)
  400c63:       00 00 
        if x != 42 {
  400c65:       48 83 f8 2a             cmp    $0x2a,%rax
  400c69:       74 0f                   je     400c7a &lt;main.foo+0x3a&gt;
                return x
  400c6b:       48 89 44 24 18          mov    %rax,0x18(%rsp)
        }
        mu.Lock()
        defer mu.Unlock()
        seq++
        return seq
}
  400c70:       e8 eb b7 00 00          callq  40c460 &lt;runtime.deferreturn&gt;
  400c75:       48 83 c4 08             add    $0x8,%rsp
  400c79:       c3                      retq   


If the compiler performs some CFG analysis, it can figure out that 'callq
runtime.deferreturn' is unnecessary in this case.</pre>
Repository: go
Issue: sync/atomic: support int/uint types
Labels: Thinking

<pre>Add operations on int/uint types to sync/atomic package.

int is used as indices/len/cap by slices/maps/chans, widely used in
std lib interfaces and seems to be the &quot;default&quot; integer type
otherwise.
Current atomic interface forces to use casts to work with int type.
Casts are ugly.
There is another unpleasant implication -- the casts make code less
portable because force you to say explicitly how many bits you expect
int is.
If int64 is used instead of int for the sake of atomic operations, it incurs performance
penalty on 32-bit platforms, and raises alignment issues.</pre>
Repository: go
Issue: x/pkgsite: option to show "exported" declarations of main packages
Labels: NeedsInvestigation

<pre>What steps will reproduce the problem?
1. Run godoc -http=:8080
2. Go to <a href="http://localhost:8080/pkg/">http://localhost:8080/pkg/</a>
3. Click on a package that is main

What is the expected output?

Documentation for exported components.

What do you see instead?

A blank page.

Which operating system are you using?

Mac OS X, Linux

Which version are you using?  (run 'go version')

Go1.1 (it worked in Go1.0)

Please provide any additional information below.

Our company uses Go as our primary language, and we have been successfully for a year
now. All we really want is a command-line option in godoc to export main like it used to
do in Go1.

This is for internal reasons. We use it to distinguish finalized verses experimental
functionality in our binaries, much like you would export something in a package to make
it available for use. This was extremely helpful in our company Hackathon - we would
communicate RPC calls to our iPhone developer without verbal communication. We got a lot
done. We've used this day to day, and it has helped a lot. Now we can't do this in Go
1.1.</pre>