sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/gofmt: gofmt -r should preserve attached comments through a rewrite
Labels: NeedsFix

<pre>$ cat test.go
package p

var x = (foo /* foo */ + bar /* bar */)

$ gofmt -r 'foo-&gt;bla' test.go 
package p

var x = (bla + bar /* bar */)

Instead it should print:

package p

var x = (bla /* foo */ + bar /* bar */)</pre>
Repository: go
Issue: proposal: spec: file and package scope interact in odd ways
Labels: LanguageChange,Proposal,LanguageChangeReview

<pre>This is just a reminder to revisit the interactions between file and package scope at
some point in the future.

At the moment we have the following rule:

&quot;... no identifier may be declared in both the file and package block.&quot; (
<a href="http://tip.golang.org/ref/spec#Declarations_and_scope">http://tip.golang.org/ref/spec#Declarations_and_scope</a> )

The reason for this rule is that we don't want to, say, import package math, and also
have a - in the same file - a package level variable math, and the import would then
hide the variable because the file block is inside the package block, and not have any
visible nesting (in fact the nesting is &quot;inside out&quot; in this case).

However, as a consequence, other odd behavior follows. Assume a package p consisting of
two files a.go, b.go, with a.go importing package math, and b.go not importing anything.

In b.go, the identifier math is not visible (it is in a.go's file scope), yet it is not
possible to declare a package-level variable math in b.go w/o an error because of the
above-cited rule. This is counter-intuitive.

One could imagine an alternative approach that satisfies the same intent, namely avoids
that both an import of an identifier x hides a package-level identifier x in the same
file:

- File blocks are nested inside the package block as before.
- Each import and also each top-level declaration in a file go into the file block.
- Additionally, each non-imported identifier also goes into the package block.

This way, all non-imported top-level identifiers are visible in all files. Imports
remain only visible in the file containing the import. Imports and file-level
declarations cannot conflict (this is the main purpose of the above rule).

Implementation-wise there may be different approaches to obtain the desired behavior. A
direct implementation of these new rules might lead to the (possibly undesired) property
that non-import file-level declarations end up both in a compiler's file and package
scope, that is, an object belongs to two scopes simultaneously.

The new rules would be a backward-compatible language change.</pre>
Repository: go
Issue: testing: add ratcheting variants
Labels: NeedsInvestigation,FeatureRequest

<pre>For some testing and benchmark purposes, a ratchet is better suited than an average.

<a href="https://golang.org/cl/67870053/">https://golang.org/cl/67870053/</a> bumps up the number of AllocsPerRun runs of an
http test to avoid flakiness. This test would be more reliable using a lower number of
runs if it could measure the best run rather than the average. In addition, it could set
an explicit (rather than comparative) goal for the number of allocs, which would allow
it to catch other regressions. With care, MinAllocsPerRun could even use heuristics to
avoid requiring the user to pass an explicit number of runs.

For benchmarking tightly CPU-bound code with minimal scheduler/OS interactions, a
ratcheting benchmark will often yield more stable, useful results than an averaging
benchmark.</pre>
Repository: go
Issue: x/tools/cmd/cover or cmd/yacc: go tool cover -html shows all lines in yacc generated code as "not tracked"
Labels: NeedsInvestigation

by **hwang.dev**:

<pre>What steps reproduce the problem?
1. run ./test.sh in the attachment:
    go tool yacc -p expr -o expr_auto.go expr.y
    go test -coverprofile profile.cov
    go tool cover -html profile.cov

2. In the opened browser, select &quot;parser.go&quot; in the drop-down list.

What happened?
All the code lines are grey (&quot;not tracked&quot;).

What should have happened instead?
Some lines are green (covered) or red (not covered).

Please provide any additional information below:
If I modified each comment from &quot;//line xxx&quot; to &quot;// line xxx&quot; (add
an extra space between &quot;//&quot; and &quot;line&quot;, then it can be tracked
correctly. So I guess that the comments like &quot;//line xxx&quot; somehow is a way to
tell the cover tool not to track, but why?</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/7483/0/expr.zip">expr.zip</a> (5480 bytes)
Repository: go
Issue: encoding/xml: Encoder duplicates namespace tags
Labels: NeedsFix,early-in-cycle

by **seanerussell**:

<pre>== What does 'go version' print?

go version go1.2.1 darwin/amd64

== What steps reproduce the problem?

<a href="http://play.golang.org/p/3_oUruPYhq">http://play.golang.org/p/3_oUruPYhq</a>

== What happened?

Encoder.EncodeToken duplicates namespace attributes.

== What should have happened instead?

The encoded document should have had a single namespace attribute.

== Please provide any additional information below.

Attribute names on an element must be unique; this is a well-formedness constraint per
the XML 1.0 specification (<a href="http://www.w3.org/TR/xml/#uniqattspec)">http://www.w3.org/TR/xml/#uniqattspec)</a>. Per the
specification, both validating and non-validating parsers must report well-formedness
violations (<a href="http://www.w3.org/TR/xml/#sec-conformance)">http://www.w3.org/TR/xml/#sec-conformance)</a>.

Encoding and decoding XML documents should be idempotent and produce equivalent
documents.  This issue means that not only that decoding and encoding the result
produces a non-equivalent document, but that the document it generates is
not-well-formed.

This issue only occurs with namespaces.  Normal attributes are handled correctly.</pre>
Repository: go
Issue: cmd/vet: warn of cyclic closures that cause Finalizers not to run
Labels: Analysis

<pre>What does 'go version' print?
go version devel +08dcdcdb757b Thu Mar 13 14:04:29 2014 -0700 linux/amd64

What steps reproduce the problem?
1. <a href="http://play.golang.org/p/QWn904819Y">http://play.golang.org/p/QWn904819Y</a>

What happened?
A tricky case with Finalizers and closures can be created where the Finalizer will not
run due to the cyclic structure created (not a bug). Go vet does not complain about suck
tricky cases which could be useful.

What should have happened instead?
Go vet should warn of such tricky cases.</pre>
Repository: go
Issue: unicode: decrease binary size
Labels: NeedsInvestigation,binary-size

<pre>Currently, the generated unicode tables.go sets up a separate slice for each R16/R32 in
each RangeTable, each with its own backing array.

Rearranging the code generated by maketables.go (in a way that is invisible to the
exported API) so that the RangeTable slices point into a big, shared R16/R32 array
reduces the contribution of the unicode tables to binary size by ~35k. If <a href="https://golang.org/issue/7599">issue #7599</a>
were fixed as well, the space savings would be ~45k to ~60k. Details on the savings
below.


Questions:

(1) Are these space savings significant enough to warrant possible inclusion in Go 1.3,
or should I wait to polish + mail the CL until Go 1.4?
(2) Is there a reason not to do this rearrangement?
(3) Is there a fix to the toolchain that achieves these reductions in a better / cleaner
/ deeper way? (For example, instead of creating a separate backing array symbol and
slice header symbol for staticly initialized slices, one could just create a single
slice symbol containing the slice header followed by the array. That would prove some
space savings.)


Details on the size changes:

$ cat radical.go
package main

import &quot;unicode&quot;

func main() {
    _ = unicode.Radical
}


Build with 6g.

Binary size before: 733664 bytes. Binary size after: 699296 bytes.


Largest symbols before:

$ go tool nm -size -sort size radical | head -n 50
   4e0c0     101365 R _esymtab
   4e0c0     101365 R _pclntab
   4e0c0     101365 R _etypelink
   4e0c0     101365 R _symtab
   87200      56984 B runtime.mheap
   3d340      49024 R _gcbss
   319f8      47372 R go.string.*
   265a0      46168 R _rodata
   265a0      46168 R type.*
   81fc0      21056 B _bufferList
   492c0      18192 R _gcdata
   492c0      18192 R _egcbss
   7e100      16064 B _semtable
   22920      15088 T unicode.init


Largest symbols after:

$ go tool nm -size -sort size radical | head -n 50
   4efa0     102141 R _pclntab
   878c0      56984 B runtime.mheap
   3e420      52360 R _gcbss
   33c18      42956 R go.string.*
   2a5c0      38488 R type.*
   2a5c0      38488 R _rodata
   22920      31504 T unicode.init
   82680      21056 B _bufferList
   6a740      20904 D unicode.allRange16
   7e7c0      16064 B _semtable
   4b0c0      14856 R _gcdata
   68020      10016 D unicode.allRange32
   7c7a0       8192 B _pdesc
   7a800       8096 B _hash


The main size savings here come from a reduction in the number of small symbols
generated to hold staticly initialized autotmp values, each with their own overhead
(name, padding, etc.).

The increase in the size of unicode.init is addressable via <a href="https://golang.org/issue/7599">issue #7599</a>.</pre>
Repository: go
Issue: cmd/cgo: cgo breaks multiple cgo packages linked with libgcc  
Labels: Suggested

by **jim.deng**:

<pre>What does 'go version' print?
go version devel +358e2b416518 Wed Mar 19 09:00:58 2014 -0700 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Create a source tree that can be downloaded below:

  src/main/main.go   <a href="http://play.golang.org/p/3y44TXNfEf">http://play.golang.org/p/3y44TXNfEf</a>
  src/hello/hello.go   <a href="http://play.golang.org/p/iJZL_tuvDm">http://play.golang.org/p/iJZL_tuvDm</a>
  src/world/world.go <a href="http://play.golang.org/p/V7m4penOiv">http://play.golang.org/p/V7m4penOiv</a>

2. Install android standalone ndk 49d following 4/ Invoking the compiler (the easy way):

  <a href="http://www.kandroid.org/ndk/docs/STANDALONE-TOOLCHAIN.html">http://www.kandroid.org/ndk/docs/STANDALONE-TOOLCHAIN.html</a>
  <a href="https://developer.android.com/tools/sdk/ndk/index.html">https://developer.android.com/tools/sdk/ndk/index.html</a>

3.  Run  the following command to build
export PATH=/path/to/android/toolchain-r9d/bin:$PATH

CGO_CFLAGS='-I /Users/jim_deng/workspace/android/toolchain-r9d/include -march=armv7-a
-mfloat-abi=softfp' \ 
CGO_LDFLAGS='-Wl,--fix-cortex-a8' \ 
CC=arm-linux-androideabi-gcc \ 
CXX=arm-linux-androideabi-g++ \ 
GOOS=linux \ 
GOARCH=arm \ 
CGO_ENABLED=1 \ 
go build -tags android -x

What happened?

Got multiple definition of '__aeabi_dcmpge' errors ...
<a href="http://hastebin.com/sodekeqibi.mel">http://hastebin.com/sodekeqibi.mel</a>

What should have happened instead?

go build should succeed

Please provide any additional information below.

* Background discussion: <a href="https://groups.google.com/forum/#">https://groups.google.com/forum/#</a>!topic/golang-nuts/73NvFzLZpSY
* android tool chain cannot be linked with -lpthread.  I have to patch cgo not to add
-lpthread in the linker.
--- a/src/pkg/runtime/cgo/cgo.go        Wed Mar 19 09:00:58 2014 -0700
+++ b/src/pkg/runtime/cgo/cgo.go        Thu Mar 20 17:31:16 2014 -0700
@@ -14,7 +14,7 @@
-#cgo linux LDFLAGS: -lpthread
+#cgo linux,!android LDFLAGS: -lpthread</pre>
Repository: go
Issue: sort: superior SymMerge-based algorithm available
Labels: help wanted

by **mike@bonzaiapps.com**:

<pre>Someone on the mailing list told me to file a bug for this, but the SymMerge-based sort
used in the sort.go file has since been surpassed by a new algorithm created by the same
authors (Pok-Son Kim and Arne Kutzner):
<a href="http://golang.org/src/pkg/sort/sort.go?m=text">http://golang.org/src/pkg/sort/sort.go?m=text</a>

I have a GitHub page up with working implementations available, but no Go version right
now.
<a href="https://github.com/BonzaiThePenguin/WikiSort">https://github.com/BonzaiThePenguin/WikiSort</a></pre>
Repository: go
Issue: gdb: cannot debug windows/386 binaries in wine/gdb due to internal gdb assert failure
Labels: OS-Windows

<pre>What does 'go version' print?
go version devel +26aa53304a48 Fri Mar 07 16:08:12 2014 -0500 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Build a Go program emdash any Go program emdash for windows/386.
2. wine --gdb program.exe
3. Alternatively, wine --gdb --no-start program.exe, then attach the resultant gdb
server to a debugging frontend; same effect.

What happened?
xe: gdbproxy.c:2494: gdb_init_context: Assertion `gdbctx-&gt;process == ((void *)0)
&amp;&amp; de.dwProcessId == dbg_curr_pid' failed.
winedbg: Internal crash at 0xf7746430
/tmp/winegdb.2uyltD:2: Error in sourced command file:
Remote communication error.  Target disconnected.: Connection reset by peer.

If attaching to a frontend, the &quot;Connection reset&quot; line will appear in the
frontend and the others in the terminal where winedbg is being run.

What should have happened instead?
(standard gdb prompt and session)

Please provide any additional information below.
Not sure if this affects windows/amd64 as well; that has its own problems working in
wine/winedbg.</pre>
Repository: go
Issue: x/net/websocket: messages not exposed in package API
Labels: NeedsInvestigation

by **lorresylvan@yahoo.com**:

<pre>WebSocket peers exchange messages. A message is composed of one or more frames.

The (*Conn).Read and (Codec).Receive methods return a single frame. There is no
mechanism to detect message boundaries or otherwise compose frames into a message.

To use this package, an application must provide its own framing or assume that the peer
sends single frame messages. My guess is that most applications assume that the peer
sends single frame messages because that's what browsers and the websocket package do.
This assumption is not true of all peers.</pre>
Repository: go
Issue: cmd/compile: combine slice header and backing array for static slices into a single symbol
Labels: binary-size

<pre>Static slices generate two symbols, one for the slice header and one for the backing
array. These could be combined into a single symbol, laid out with the slice header
followed by the backing array. This would reduce binary size, particularly for the
unicode tables.

This does not make sense to do unless <a href="https://golang.org/issue/7599">issue #7599</a> is also done, otherwise the backing
array will be needlessly loaded during init.

See <a href="https://golang.org/cl/78870047/">https://golang.org/cl/78870047/</a> for more discussion.

Something similar could probably profitably be done for strings and string headers,
although there is a different approach under discussion at <a href="https://golang.org/issue/7384">issue #7384</a>.</pre>
Repository: go
Issue: misc/gdb: gdb "l" command displays wrong source file/line
Labels: NeedsInvestigation

<pre>I'm no windows/386 tip.

C:\go\path\mine\src\a&gt;type main.go
package main

import &quot;fmt&quot;

func main() {
        fmt.Println(&quot;Hello&quot;)
}
C:\go\path\mine\src\a&gt;go build main.go

C:\go\path\mine\src\a&gt;gdb main.exe
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later &lt;<a href="http://gnu.org/licenses/gpl.html&gt">http://gnu.org/licenses/gpl.html&gt</a>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type &quot;show copying&quot;
and &quot;show warranty&quot; for details.
This GDB was configured as &quot;mingw32&quot;.
For bug reporting instructions, please see:
&lt;<a href="http://www.gnu.org/software/gdb/bugs/&gt">http://www.gnu.org/software/gdb/bugs/&gt</a>;...
Reading symbols from C:\go\path\mine\src\a/main.exe...done.
(gdb) br 'runtime.stdcall'
Breakpoint 1 at 0x40c730
(gdb) r
Starting program: C:\go\path\mine\src\a/main.exe
[New Thread 5524.0x81c]

Breakpoint 1, 0x0040c730 in runtime.stdcall ()
    at C:/go/root/src/pkg/runtime/compiler.go:1
1       // Copyright 2012 The Go Authors.  All rights reserved.
(gdb) l
1       // Copyright 2012 The Go Authors.  All rights reserved.
2       // Use of this source code is governed by a BSD-style
3       // license that can be found in the LICENSE file.
4
5       package runtime
6
7       // Compiler is the name of the compiler toolchain that built the
8       // running binary.  Known toolchains are:
9       //
10      //      gc      The 5g/6g/8g compiler suite at code.google.com/p/go.
(gdb)</pre>
Repository: go
Issue: cmd/compile: recognize x[:] of global array x as static data
Labels: NeedsInvestigation

<pre>If an array is defined in the global scope and concerted to a slice in an unused struct
literal, it will not get garbage collected by the linker.

See code below to reproduce the problem.

go version devel +0134c7020c40 Wed Mar 26 15:23:31 2014 -0700 darwin/amd64

===BEGIN===
package main

func main() {
}

type foo struct {
    arr []int
}

var f = foo{
    arr: a[:], // Remove this line and a will get collected.
}

var a = [1000111]int{3} // Removing the 3 will cause the array to be collected.

===END===</pre>
Repository: go
Issue: x/crypto/ssh: suggested add auth methods from server to error info
Labels: NeedsInvestigation

by **weyllor**:

<pre>What does 'go version' print?
go version go1.2.1 windows/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. config a Client only with password method
2. connect to a ssh server reject password method
3. auth fail, but no more info to find out what happened.

What happened?
not enough error info to known why ssh auth fail.

What should have happened instead?
show what methods supported by server in error info.

Please provide any additional information below.
I make a path for this issue, ref the attachment.</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/7670/0/patch.diff">patch.diff</a> (1379 bytes)
Repository: go
Issue: cmd/compile: don't use REP prefix for reverse-order copying on amd64, 386
Labels: NeedsInvestigation

<pre>REP prefixes have a high startup cost.  Most were eliminated with CL 81370046.  For
overlapping source/destinations when we have to copy in descending address order, they
are still used.  Fix that.</pre>
Repository: go
Issue: crypto/x509: add more detail to the error message arising from a missing hash function.
Labels: help wanted,NeedsFix

<pre>If a certificate is signed with a hash function that wasn't compiled in the error
message isn't bad, but could be better:

x509: certificate signed by unknown authority (possibly because of &quot;x509: cannot
verify signature: algorithm unimplemented&quot; while trying to verify candidate
authority certificate &quot;CA Cert Signing Authority&quot;)</pre>
Repository: go
Issue: runtime: gc can add clock tick latency when HPETs are not used
Labels: NeedsInvestigation

<pre>Garbage collector can add latency on the order of clock tick (usually
10ms, 2.5ms, or 1ms) to each run.

This is due to some runtime·usleep(1) and runtime·usleep(100) calls,
which get rounded up to clock period when HPETs are not used.

More details in this thread:
<a href="https://groups.google.com/d/topic/golang-codereviews/AxqxYnioBOQ/discussion">https://groups.google.com/d/topic/golang-codereviews/AxqxYnioBOQ/discussion</a>

Linux uses HPETs by default, but most ARM machines don't have HPETs.
Solaris doesn't use HPETs by default, so this issue affects arm
machines and solaris.

I'm not sure if we need to do anything (maybe we can just assume
&quot;fast&quot; machines), I'm logging it so we can refer to it later.</pre>
Repository: go
Issue: reflect: Call is slow
Labels: Performance,GarbageCollector,help wanted

<pre>reflect.Value.Call is pretty slow.

In addition to always allocating a slice for its []reflect.Value result parameters, it
also does a lot of prep work on each call.

It would be nice to both avoid that allocation and also do the setup checks just once.

Maybe a new method to return some sort of 'Caller' type that makes repeated Calls
faster, with less paranoia and no allocation.

Or just speed up the checks and make a new Call method that also accepts a slice for the
result values.</pre>
Repository: go
Issue: x/pkgsite: conditionally expose unexported types
Labels: NeedsInvestigation,pkgsite

<pre>Currently godoc only exposes the documentation of exported types, vars, etc.

However, there are a number of cases where it would be convenient to expose unexported
types: when there is a variable or constant of that type and when a function or method
takes or returns values of that type.

If the unexported type has exported methods, this allows them to be shown in godoc. It
is less important if it does not, but it would still allow godoc to render a link to
that type, showing its docs, consts, and vars.

The same effect, of course, can be generated by exporting the type, but leaving it
unexported, if nothing else, is a signal that users should not create arbitrary values
of this type, which has to be manually documented if you export the type.

This is related, conceptually and likely implementation-wise, to <a href="https://golang.org/issue/5860">issue #5860</a>, <a href="https://golang.org/issue/5397">issue #5397</a>
and its duplicate (that contains more information) <a href="https://golang.org/issue/7815">issue #7815</a></pre>
Repository: go
Issue: x/tools/cmd/eg: No way to rewrite expressions that include unexported identifiers
Labels: NeedsInvestigation

<pre>Because of the way that eg parses the template files, you can't refer to unexported
identifiers inside the before and after functions.

Possibility is to include the package files when parsing the template file, so that it
can refer to the unexported identifiers.</pre>
Repository: go
Issue: encoding/json: Encoder internally buffers full output
Labels: NeedsFix

<pre>What does 'go version' print?

go version devel +2f6b9f80be36 Fri Apr 25 09:46:07 2014 -0600 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Use json.NewEncoder(writer).Encode(value)

What happened?

Each call to json.Encoder.Encode uses an internal bytes.Buffer to buffer all encoded
output prior to writing any of that output.

What should have happened instead?

Output should use little or no internal buffering. Encoder should be able to efficiently
encode (and incrementally output) very large inputs.</pre>
Repository: go
Issue: database/sql: nested transaction or save point support
Labels: help wanted,Proposal,Proposal-Accepted,FeatureRequest

<pre>It might be useful to consider supporting nested transactions when a particular
driver/DB combo is able to support that.

#Go 1.4+</pre>
Repository: go
Issue: os: add a semaphore in front of the filesystem?
Labels: NeedsInvestigation

<pre>I'd like to investigate putting a semaphore in front of the pkg/os filesystem
operations, so massive numbers of goroutines attempting filesystem I/O don't create
threads each and make the operating system cry.

There are deadlock concerns, but perhaps we can do it per filesystem id, or learn the
limits, etc.</pre>
Repository: go
Issue: proposal: net/http/httputil/v2: remove ClientConn, ServerConn
Labels: v2,Proposal

<pre>These have been deprecated in Go1.3 ( <a href="https://golang.org/cl/92790043/">https://golang.org/cl/92790043/</a> ), but
cannot be removed because of the compatibility guarantee.  

This is a bug to track them to be removed from Go2.</pre>