sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/compile: odd/inconsistent behavior with cyclic declarations
Labels: NeedsInvestigation

<pre>This applies to:

$ go version
go version go1.1.1 linux/amd64

The following program compiles w/o errors:

    package p

    import &quot;unsafe&quot;

    type A [unsafe.Sizeof(x)]T

    type T interface {
        m(A)
    }

    var x T

Adding one extra declaration leads to a cycle error:

    package p

    import &quot;unsafe&quot;

    const n = unsafe.Sizeof(x)  // &lt;&lt;&lt; EXTRA DECLARATION

    type A [unsafe.Sizeof(x)]T

    type T interface {
        m(A)
    }

    var x T

$ go tool 6g x.go
x.go:7: typechecking loop involving x
    x.go:7 unsafe.Sizeof(x)
    x.go:7 []unsafe.Sizeof(x)
    x.go:7 A
    x.go:10 &lt;T&gt;
    x.go:9 T
    x.go:13 x
    x.go:5 unsafe.Sizeof(x)
    x.go:5 n
    x.go:5 &lt;node DCLCONST&gt;
x.go:7: invalid expression unsafe.Sizeof(x)

even though the n is not even used (and thus cannot be part of a cycle). What is more
surprising even is that when moving that same declaration to the bottom of the file:

    package p

    import &quot;unsafe&quot;

    type A [unsafe.Sizeof(x)]T

    type T interface {
        m(A)
    }

    var x T

    const n = unsafe.Sizeof(x)  // &lt;&lt;&lt; EXTRA DECLARATION MOVED DOWN

the program again compiles w/o errors. But top-level declarations do not depend of
source order in Go, so this is clearly a bug somewhere.

Furthermore, using n now in the type of A:

    package p

    import &quot;unsafe&quot;

    type A [n]T  // &lt;&lt;&lt; USING n HERE

    type T interface {
        m(A)
    }

    var x T

    const n = unsafe.Sizeof(x)

appears to work fine (and changing this to a main package and printing out n produces
the correct value 16). Moving the const declaration up again, leads to the cycle error,
however with a less detailed error now:

    package p

    import &quot;unsafe&quot;

    const n = unsafe.Sizeof(x)  // &lt;&lt;&lt; MOVED DECL UP AGAIN

    type A [n]T

    type T interface {
        m(A)
    }

    var x T

$ go tool 6g x.go
x.go:5: constant definition loop
    x.go:5: n uses n
x.go:7: invalid array bound n

Summary:

1) This specific program is compilable w/o a cycle since unsafe.Sizeof(x) doesn't need
to look into the internals of the interface type of x. That said, the spec doesn't say
anything about it, and one might argue that it's ok for a compiler to not handle this
esoteric case. However, 6g is inconsistent in this respect here.

2) Package-level declarations do not depend on source order. The behavior of the
compiler (error or not) should not depend on it either.

(gccgo accepts all programs w/o errors).</pre>
Repository: go
Issue: misc/gdb: freezes and consumes CPU when using "info locals"
Labels: NeedsInvestigation

by **newton688**:

<pre>Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run &quot;go version&quot; and compare against
<a href="http://golang.org/doc/devel/release.html">http://golang.org/doc/devel/release.html</a>  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. Compile a relatively large Go program (e.g. github.com/sirnewton01/godev) with the go
build/install -gcflags &quot;-N -l&quot; option recommended here:
<a href="http://golang.org/doc/gdb">http://golang.org/doc/gdb</a>
2. Launch gdb providing the path to the program binary
2. Set a breakpoint in a section where there are plenty of complex local variables (e.g.
file.go:173 in the godev project)
3. Run the program and make it hit the breakpoint (e.g. navigate to
<a href="http://127.0.0.1:2022/navigate/table.html#">http://127.0.0.1:2022/navigate/table.html#</a> and expand different folders)
4. After the breakpoint it hit issue an &quot;info locals&quot; command and try to page
through the full list of local variables

What is the expected output?
It is expected that uninitialized variables should show up albeit in an undefined state
(e.g. weird characters, 0x0, or just blank).

What do you see instead?
Instead, gdb freezes. Only Ctrl-C seems to bring it back. When using an application that
uses gdb/MI for a GUI interface gdb is totally unresponsive.

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

Which operating system are you using?
Ubuntu 12.04

Which version are you using?  (run 'go version')
go version devel +f4d1cb8d9a91 Thu Sep 19 22:34:33 2013 +1000 linux/amd64
-This is 1.2RC1 according to the godeb distribution

Please provide any additional information below.
I poked around in the runtime-gdb.py script and found that the to_string() of the
StringTypePrinter appears to the the culprit for the excessive CPU consumption. If I
change the implementation of this function the following the CPU problems disappear:

        def to_string(self):
                l = int(self.val['len'])
                if l &lt; 102400 and l &gt; -1:
                        return self.val['str'].string(&quot;utf-8&quot;, &quot;ignore&quot;, l)
                return self.val['len']</pre>
Repository: go
Issue: gdb: not showing Go strings values as initialized
Labels: NeedsInvestigation

by **newton688**:

<pre>Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run &quot;go version&quot; and compare against
<a href="http://golang.org/doc/devel/release.html">http://golang.org/doc/devel/release.html</a>  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. Apply the patch from <a href="https://golang.org/issue/6598">issue #6598</a> to avoid gdb freezes
2. Compile a relatively large Go program (e.g. github.com/sirnewton01/godev) with the go
build/install -gcflags &quot;-N -l&quot; option recommended here:
<a href="http://golang.org/doc/gdb">http://golang.org/doc/gdb</a>
3. Launch gdb providing the path to the program binary
4. Set a breakpoint in a section where there are plenty of complex local variables (e.g.
file.go:173 in the godev project)
5. Run the program and make it hit the breakpoint (e.g. navigate to
<a href="http://127.0.0.1:2022/navigate/table.html#">http://127.0.0.1:2022/navigate/table.html#</a> and expand different folders)
6. Step over a few lines that initialize some of the string variables
7. Issue an &quot;info locals&quot; command to look at the string variables that have
been initialized

What is the expected output?
It is expected that the string values should have a reasonable length (ie. less than
6MB) given that the strings are known to be small.

What do you see instead?
Instead, the runtime-gdb.py patch reveals that the strings have incredible length (ie.
larger than 6M) even though they have been initialized to a small string. Running
&quot;p $len(string)&quot; is showing a large size for the strings as well. Undoing the
runtime-gdb.py patch and using the standard version causes gdb to consume tremendous CPU
trying to xfer large chunks of memory from the target process.

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

Which operating system are you using?
Ubuntu 12.04 amd64

Which version are you using?  (run 'go version')
go version devel +f4d1cb8d9a91 Thu Sep 19 22:34:33 2013 +1000 linux/amd64
-The godeb distribution indicates that this is 1.2RC1

Please provide any additional information below.</pre>
Repository: go
Issue: x/pkgsite: show exported fields promoted from unexported anonymous fields
Labels: NeedsDecision

<pre>Within my code, I have the following structure.

type common struct {
    Option1 bool
}

func (c *common) Method1() {
}

type A struct {
    OptionA int
    common
}

type B struct {
    OptionB int
    common
}

I want godoc to show that type A and type B have field Option1 available, and Method1 in
their method sets.

However, godoc would not show Option1, because common is not exported. It however show
Method1 (the full method set).

The only current workaround is to export common (which really is an internal
implementation detail), or duplicate the functionality across all types that share it. 

TO fix, godoc should show these promoted fields got from unexported anonymous fields. 

For example, godoc output for A could look like:

type A struct {
    OptionA int
    // contains filtered or unexported fields
    // Available from unexported anonymous fields
    Option1 bool
}


Which version are you using?  (run 'go version')
go version devel +47b2b07a837f Fri Oct 11 16:39:40 2013 -0700 linux/amd64

Please provide any additional information below.</pre>
Repository: go
Issue: cmd/compile: spurious error for recursive anonymous interface type
Labels: NeedsInvestigation

<pre><a href="http://play.golang.org/p/SV4pqRxk2g">http://play.golang.org/p/SV4pqRxk2g</a>

This program can't be linked because the compiler generates a very long symbol for an
anonymous interface type with an infinite unrolling.</pre>
Repository: go
Issue: image/gif: encoder does not honor image bounds.
Labels: help wanted

by **dan.pupius**:

<pre>1. Open a image using gif.DecodeAll
2. Replace frame(s) with a `SubImage`, e.g. to make a square crop
3. Save image using gif.EncodeAll

What is the expected output?
Saved image should correctly show cropped region

What do you see instead?
Resultant image is incorrectly offset, see lucha.out.gif vs lucha.out.jpg

Which operating system are you using?
OSX

Which version are you using?  (run 'go version')
$ go version
go version devel +560ca6cc94b5 Sun Oct 20 18:29:15 2013 -0700 darwin/amd64

Please provide any additional information below.
I think the sImageDescriptor block in gif/writer.go needs to have the X/Y values
adjusted by the Min bounds of the first frame.</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/6635/0/gifs.go">gifs.go</a> (966 bytes)
2. <a href="https://storage.googleapis.com/go-attachment/6635/0/lucha.gif">lucha.gif</a> (7598 bytes)
3. <a href="https://storage.googleapis.com/go-attachment/6635/0/lucha.out.jpg">lucha.out.jpg</a> (17750 bytes)
4. <a href="https://storage.googleapis.com/go-attachment/6635/0/lucha.out.gif">lucha.out.gif</a> (6843 bytes)
Repository: go
Issue: cmd/compile: internal compiler error with self-referential method in interface
Labels: NeedsInvestigation

<pre>$ cat x.go
package p

import &quot;unsafe&quot;

type T interface {
    m() [unsafe.Sizeof(T(nil).m())]int
}


$ go tool 6g x.go
x.go:6: internal compiler error: getinarg: not a func E-36 &lt;&lt;S&gt;&gt; &lt;T&gt;</pre>
Repository: go
Issue: cmd/compile: use less memory for large []byte literal
Labels: help wanted,ToolSpeed,NeedsFix

<pre>[]byte literals take up a lot of memory inside the compiler, because each byte in the
literal is a separate syntax Node and, worse, each byte is represented by a
multiprecision integer constant.

Probably a trick is required during parsing to turn []byte{...} into an actual byte
array holding the constant values + a list of index and value for the non-constant data.</pre>
Repository: go
Issue: x/pkgsite: display type kind of each named type
Labels: NeedsInvestigation

<pre>Currently godoc does not list the base type of type, for example:

<a href="http://golang.org/pkg/encoding/json/#Decoder">http://golang.org/pkg/encoding/json/#Decoder</a>

type Decoder
    func NewDecoder(r io.Reader) *Decoder
    func (dec *Decoder) Buffered() io.Reader
type Marshaler
type MarshalerError
    func (e *MarshalerError) Error() string


It would be really nice if this were listed as:

type Decoder struct
    func NewDecoder(r io.Reader) *Decoder
    func (dec *Decoder) Buffered() io.Reader
type Marshaler interface
type MarshalerError struct
    func (e *MarshalerError) Error() string

It's often hard to tell if a name represents an interface or a methodless non-interface
(for example, here Decoder has the -er suffix typical of interfaces). Additionally, many
times the use of a type is much clearer if it is easily seen that it has an int as the
underlying representation (or whatever).</pre>
Repository: go
Issue: cmd/cgo: more mkall.sh behaviour changes at tip
Labels: NeedsInvestigation

<pre>What steps will reproduce the problem?

Fedora 19 x86_64
gcc-4.8.1-1.fc19.x86_64

GOARCH=amd64 GOOS=linux ./mkall.sh 

What do you see instead?

some constants like VDISCARD are showing up in zerrors_linux_amd64.go although they are
defined in types_linux.go, which leads to a compile error

the Rusage struct loses its field names:

 type Rusage struct {
-       Utime    Timeval
-       Stime    Timeval
-       Maxrss   int64
-       Ixrss    int64
-       Idrss    int64
-       Isrss    int64
-       Minflt   int64
-       Majflt   int64
-       Nswap    int64
-       Inblock  int64
-       Oublock  int64
-       Msgsnd   int64
-       Msgrcv   int64
-       Nsignals int64
-       Nvcsw    int64
-       Nivcsw   int64
+       Utime  Timeval
+       Stime  Timeval
+       Anon0  [8]byte
+       Anon1  [8]byte
+       Anon2  [8]byte
+       Anon3  [8]byte
+       Anon4  [8]byte
+       Anon5  [8]byte
+       Anon6  [8]byte
+       Anon7  [8]byte
+       Anon8  [8]byte
+       Anon9  [8]byte
+       Anon10 [8]byte
+       Anon11 [8]byte
+       Anon12 [8]byte
+       Anon13 [8]byte
 }

the CSTATUS constant gets a strange value instead of 0x14 which doesn't compile:

CSTATUS = '\0'

the error is: non-octal character in escape sequence: '

the name field in InotifyEvent also changes type, which might break some code:

-   Name   [0]uint8
+   Name   [0]int8

Which operating system are you using?

linux

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

tip</pre>
Repository: go
Issue: runtime/race: say where the memory block was allocated
Labels: RaceDetector

<pre>C++ ThreadSanitizer describes where the memory involved in report was allocated:
<a href="http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/lit_tests/malloc_stack.cc?revision=187875&amp">http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/lit_tests/malloc_stack.cc?revision=187875&amp</a>;view=markup

It would be useful to do the same for Go.

C++ ThreadSanitizer can also pronounce the name of the global (if the race in on
global). Look if it's possible in Go.</pre>
Repository: go
Issue: testing: add test helpers for measuring goroutine leaks
Labels: NeedsInvestigation,FeatureRequest

<pre>It's common for tests to check for goroutine leaks, but the testing package or standard
library doesn't make this easy.

These tests end up verbose and often frail.

We should provide something.</pre>
Repository: go
Issue: cmd/compile: skip slicebytetostring when argument doesn't escape
Labels: Performance,GarbageCollector

<pre>In this function,

func hi() string {
        b := make([]byte, 0, 100) // 1st alloc
        b = append(b, &quot;Hello, &quot;...)
        b = append(b, &quot;world.\n&quot;...)
        return string(b) // 2nd alloc, but could be removed.
}

The final line currently generates a call to runtime.slicebytetostring, causing a copy
of b to be allocated.

But the compiler already knows that b doesn't escape.  It could instead return a string
header re-using the []byte memory.</pre>
Repository: go
Issue: crypto/tls: needs a convenience function for reading encrypted keys
Labels: NeedsInvestigation

by **jeff.allen**:

<pre>crypto/tls.X509KeyPair can't deal with encrypted key files. This wouldn't be much of a
big deal except that the quantity of code needed to work around it is really big and
repeats lots of code from the std library.

See this message: <a href="https://groups.google.com/d/msg/golang-nuts/ht_gQ2ET0c0/efaGZdIxCmAJ">https://groups.google.com/d/msg/golang-nuts/ht_gQ2ET0c0/efaGZdIxCmAJ</a>

It would be nicer to have crypto/tls.X509EncryptedKeyPair(certPEMBlock, keyPEMBlock,
password []byte) (cert Certificate, err error) that would use password to decrypt
keyPEMBlock.</pre>
Repository: go
Issue: cmd/compile: support for explicit alignment annotations
Labels: Thinking

by **rayneolivetti**:

<pre>Data alignment other than 8 bytes (ex: 128-bits, 256-bits, 512-bits) is necessary for
various instructions (belonging to SSE/AVX/AVX2 and the upcoming AVX-512). Instruction
and label alignment contributes to speed for some instructions.

It would hugely be helpful to be able to specify the alignment of data, text and
ordinary labels.

On the user mailing list, Ian mentioned the possibility of enabling similar
functionality via a magic comment.</pre>
Repository: go
Issue: runtime: sockets closed by remote peer may remain undetected by poller
Labels: NeedsInvestigation

<pre>I have observed a network TCP server blocked on a Write although the client (Go program
located on a remote machine) has closed the connection.

So far I have been unable to produce a minimal reproducer.

My hypothesis is that the poller is not handling EPOLLRDHUP correctly. map epoll_ctl(2)
says that it means: &quot;Stream socket peer closed connection, or shut down writing
half of  connection.&quot;
But when obtaining EPOLLRDHUP from the socket the poller wakes up WaitRead() but not
WaitWrite(), so if the EPOLLRDHUP was generated by a remote close, waiting writers will
never wake up (one would expect something like &quot;connection reset by peer&quot;).

Using linux/amd64.</pre>
Repository: go
Issue: go/types: make go/types more tolerant in case of 'import "C"'
Labels: NeedsInvestigation

<pre>gotype $GOROOT/src/pkg/net

leads to several error messages due to unresolvable 'import &quot;C&quot;'.

go/types could be more tolerant with invalid operands and types to avoid follow-up
errors.

(For instance, conversions of the form T(x) could always succeed even if x is invalid.
Other operations should not report an error if an operand is already invalid.)</pre>
Repository: go
Issue: proposal: strings: AppendSplitN to reuse destination slice buffer
Labels: Performance,GarbageCollector

<pre>I recently found myself forking strings.SplitN to take a destination buffer, to avoid
the slice allocation.

I called it AppendSplitN, with append semantics.  (like the Append funcs in
<a href="http://golang.org/pkg/strconv/)">http://golang.org/pkg/strconv/)</a>

Maybe worth putting in the strings package, although I expect the usual reservations.</pre>
Repository: go
Issue: cmd/compile: improve compiler error message when accessing type instead of instance of type
Labels: NeedsInvestigation

<pre><a href="http://play.golang.org/p/54n3Rs7JHT">http://play.golang.org/p/54n3Rs7JHT</a>

If you have a function that has f which is a Foo, and try to reference Foo.Bar instead
of f.Bar, you get the following error message:

prog.go:10: Foo.Bar undefined (type Foo has no method Bar)
 [process exited with non-zero status]

I can see where this is coming from, because it's valid syntax if you're trying to get a
method, but I wonder if there could be a different error message when Foo has the field
Bar as in this case Foo is trying to be used as a value.</pre>
Repository: go
Issue: os: "async" file IO
Labels: Performance,NeedsInvestigation

<pre>Read/Write file operations must not consume threads, and use the polling similar to net
package.

This was raised several times before.

Here is a particular example with godoc:
<a href="https://groups.google.com/d/msg/golang-nuts/TeNvQqf4tO4/dskZuFH5QVYJ">https://groups.google.com/d/msg/golang-nuts/TeNvQqf4tO4/dskZuFH5QVYJ</a></pre>
Repository: go
Issue: encoding/xml: Allow ",any" elements to be unmarshalled as raw xml
Labels: NeedsInvestigation

<pre>It would be nice if the encoding/xml package would allow to unmarshal unknown / not
explicitly mapped XML elements as raw XML.

This could be achieved by either allowing to combine the &quot;,innerxml&quot; and
&quot;,any&quot; tags for struct fields or by introducing a new tag &quot;,anyxml&quot;
or something similar.

Example:

type MyStruct struct {
    Name string   `xml:&quot;name&quot;`
    Rest []string `xml:&quot;,any,innerxml&quot;`
}</pre>
Repository: go
Issue: x/tools/present: support sub-section headings
Labels: help wanted

by **sathishvj**:

<pre>go version 1.2rc5

Multiple issues with sub sections in go.talks/present.  Please see attached partial
screenshot.

* A subsection has a title numbering system that a section does not have
* Size and formatting of sub section is much larger than section
* Content under subsection is not showing
* 2 subsections overwrite one another

priority: low, but still would be nice to get done sometime.</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/6846/0/go.talks-present%20subsection%20issues.png">go.talks-present subsection issues.png</a> (110139 bytes)
Repository: go
Issue: gccgo tests: running a 'runoutput' test can hang the testsuite
Labels: NeedsInvestigation

<pre>I'm not sure if this is the right place to report this, but anyway:

Some of the gccgo tests are use a &quot;runoutput&quot; model where the test code is
compiled and run, generating more go code which is then run to be the 'real' test.  If
the code generating code hangs, though, the whole testsuite hangs -- the timeout that
protects the overall test suite execution from most hanging tests does not kick in.</pre>
Repository: go
Issue: proposal: net/v2: add SetDeadline to Listener interface
Labels: v2,Proposal

<pre>Probably it has been overlooked. It would be nice if we can avoid unnecessary type
assertion in the loop of accepting incoming connections. Both TCPListener and
UnixListener already implemented this method.</pre>
Repository: go
Issue: x/pkgsite: specifying a file's language
Labels: Thinking,pkgsite

<pre>Go source files are UTF-8 so there is, in principle, no need to specify its encoding or
language. However, I think there is one case when it would be very convenient to specify
in which language are the comments written.

When using CJK (Chinese, Japanese and Korean), there are different variations of some
ideograms that are written with different glyphs (sometimes differences are minor,
sometimes not so minor). However, in Unicode, some of these varied glyphs share the same
codepoint, so it is not possible to choose the right glyph if the language is unknown.
This is called the Han Unification: <a href="https://en.wikipedia.org/wiki/Han_unification">https://en.wikipedia.org/wiki/Han_unification</a>

HTML code can include the &lt;lang&gt; label to inform the browser which font should it
use to render a text. If it is not included, the browser usually will use a default
font. For example, Google Chrome on a non-CJK system will usually choose a Chinese font,
and Japanese ideograms will be rendered with Chinese glyphs.

So my suggestion would be to include some kind of label for godoc to include the right
&lt;lang&gt; label in the HTML generated, so it will be rendered correctly in most
systems. 

Ideally, it should be possible to modify it inside a file, so you could write Chinese
and Japanese in the same file.

What do you think?</pre>
Repository: go
Issue: x/pkgsite: comments in [][]T are omitted in doc rendering
Labels: NeedsInvestigation,pkgsite

<pre>What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. mkdir foo &amp;&amp; cd foo
2. curl <a href="http://play.golang.org/p/MdnYIPw4Ee.go">http://play.golang.org/p/MdnYIPw4Ee.go</a> &gt; foo.go
3. godoc .

What is the expected output?

PACKAGE DOCUMENTATION

package foo
    import &quot;.&quot;



VARIABLES

var NUC_4 = [][]int{
    /*       - A C G T */
    /* - */ {0, 0, 0, 0, 0},
    /* A */ {0, 5, -4, -4, -4},
    /* C */ {0, -4, 5, -4, -4},
    /* G */ {0, -4, -4, 5, -4},
    /* T */ {0, -4, -4, -4, 5},
}


What do you see instead?

PACKAGE DOCUMENTATION

package foo
    import &quot;.&quot;



VARIABLES

var NUC_4 = [][]int{

    {0, 0, 0, 0, 0},
    {0, 5, -4, -4, -4},
    {0, -4, 5, -4, -4},
    {0, -4, -4, 5, -4},
    {0, -4, -4, -4, 5},
}


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')
go1.2
go.tools 25a7477727f3

Please provide any additional information below.</pre>