sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: encoding/gob: encoder should ignore embedded structs with no exported fields
Labels: NeedsInvestigation

by **alan.strohm**:

<pre>What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. <a href="http://play.golang.org/p/ayZMy_HFKE">http://play.golang.org/p/ayZMy_HFKE</a>

What is the expected output?

&quot;worked&quot;

I don't see why hidden1 (an unexported field in an embedded struct) should be handled
differently than hidden2 (a top level unexported field). Making the embedded struct type
itself unexported (&quot;inner&quot; vs &quot;Inner&quot;) works but seems unecessary.

What do you see instead?

gob: type main.Inner has no exported fields</pre>
Repository: go
Issue: x/pkgsite: show interface methods more prominently
Labels: NeedsDecision,pkgsite

by **szopa@google.com**:

<pre>Right now, the whole interface has one link, and its code is included in its entirety.
This is not very clear, as many interfaces are the main public entry point for many
libraries. What I would like to see:

1. The index should contain links to interface methods.

2. Interface methods doccomments should be displayed in a way similar to normal
method/function doccomments.</pre>
Repository: go
Issue: encoding/json: allow per-Encoder/per-Decoder registration of marshal/unmarshal functions
Labels: Proposal,Proposal-Accepted,early-in-cycle

<pre>For example, if a user wants to marshal net.IP with custom code, we should provide a way
to do that, probably a method on *Encoder. Similarly for *Decoder.

Same for encoding/xml.</pre>
Repository: go
Issue: cmd/link: move symtab out of mapped memory
Labels: NeedsInvestigation

<pre>Nothing in package runtime looks at the Go 'symtab' symbol anymore. Move it into
unmapped memory, so that it is still in the file for debuggers but not mapped while the
program runs.

Low priority, since the size of the file will not be changing, and since the data is
never paged in, the total memory cost is under two pages of memory partially used by
fragmentation, so less than 8 kB.</pre>
Repository: go
Issue: cmd/compile: missed escape analysis opportunity
Labels: NeedsInvestigation

<pre>Escape analysis says that s escapes in this function even though it doesn't:

func f(s *string) {
    *s = *s
}

If f is called as f(&amp;s), the compiler will (with inlining disabled) allocate s on
the heap even though it could be allocated on the stack. For types that don't contain
pointers, this doesn't happen. For example, if I change string to int, the parameter
isn't considered to escape.

A real-world example of when this might happen is when a function takes a pointer to a
string or slice and then re-slices it:

*s = (*s)[n:]</pre>
Repository: go
Issue: cmd/cgo: atexit handlers not run
Labels: NeedsInvestigation

by **davidgreymackay**:

<pre>What steps will reproduce the problem?
Save the attached files into a directory and run make,
then run ./stmain

What is the expected output?
&quot;This is a test.&quot; should display on the console.

What do you see instead?
Nothing.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6c, 6g, 6l
swig 2.0.10

Which operating system are you using?
Fedora 19 linux

Which version are you using?  (run 'go version')
1.1.1-1

Please provide any additional information below.
Per Ian Taylor iant@golang.org, changing pinput to cout&lt;&lt;pstring&lt;&lt;std::endl;
does display.</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/5948/0/st.i">st.i</a> (166 bytes)
2. <a href="https://storage.googleapis.com/go-attachment/5948/0/st.cxx">st.cxx</a> (164 bytes)
3. <a href="https://storage.googleapis.com/go-attachment/5948/0/stmain.go">stmain.go</a> (87 bytes)
4. <a href="https://storage.googleapis.com/go-attachment/5948/0/Makefile">Makefile</a> (615 bytes)
Repository: go
Issue: text/tabwriter: elide trailing padding when last cell is empty
Labels: NeedsInvestigation

<pre>I would like to suggest a new switch for tabwriter that makes it discard trailing
padding bytes when all subsequent cells on that line are empty.

See example below. The third column is only filled in the first line. It's not possible
to align that cell right of the second column without having extra padding on the second
line.

<a href="http://play.golang.org/p/lW5-7CFrNC">http://play.golang.org/p/lW5-7CFrNC</a>

package main

import (
    &quot;fmt&quot;
    &quot;os&quot;
    &quot;text/tabwriter&quot;
)

func main() {
    w := tabwriter.NewWriter(os.Stdout, 0, 0, 1, '*', 0)
    fmt.Fprintln(w, &quot;x\tx\tx&quot;)
    fmt.Fprintln(w, &quot;aaaa\tbbb&quot;)
    w.Flush()
    fmt.Fprintln(w, &quot;x\tx\tx&quot;)
    fmt.Fprintln(w, &quot;aaaa\tbbb\t&quot;)
    w.Flush()
}


x****x*x
aaaa*bbb
x****x***x
aaaa*bbb*

(Obviously, this is much more useful for trailing whitespace.)</pre>
Repository: go
Issue: cmd/vet: diagnose set and not used
Labels: Analysis

<pre>If you have:

x := 1
_ = x
x = 2

the spec allows this program and therefore the compilers accept it without comment.

However, it would be nice if vet could tell you about 'set and not used' on the final
line.
Maybe this falls out of some code Alan already has lying around. Maybe not.</pre>
Repository: go
Issue: encoding/xml: more tests
Labels: Suggested,Testing

<pre>encoding/xml is under-tested. Now that we have go tool cover, it might be nice to write
some more tests, especially of things like name spaces, custom marshalers, custom
unmarshalers, and the interaction between all those.</pre>
Repository: go
Issue: runtime: threadcreate profile is broken
Labels: compiler/runtime

<pre>With the new scheduler threadcreate profile is broken. Most of the threads are created
by sysmon thread, which stack is not very informative.
We need to either remove the profile, or capture stack of the blocking cgo/syscall that
caused new thread creation.</pre>
Repository: go
Issue: x/pkgsite: show embedded methods
Labels: NeedsDecision,Tools

<pre>Fix the cmd/godoc side of issue 

<a href="https://code.google.com/p/go/source/detail?r=f5b37c93e4c5bb2962c">https://code.google.com/p/go/source/detail?r=f5b37c93e4c5bb2962c</a> added some methods to
go1.txt that were always there, but neither cmd/godoc nor cmd/api (both with their own
bad embedding rules) detected.

Robert's rewrite of cmd/api to use go/types fixed cmd/api, but cmd/godoc is still broken.

This bug is about making those methods (like <a href="https://golang.org/issue/6125">issue #6125</a> -- xml.Encoder.Reset / Available
/ etc) show up, if they're actually there.  (But <a href="https://golang.org/issue/6125">issue #6125</a> should remove them)</pre>
Repository: go
Issue: sync/atomic: 64-bit primitives are not supported on ARMv5
Labels: NeedsInvestigation

<pre>The following change introduced the armSwapUint64

<a href="https://code.google.com/p/go/source/detail?r=41d393af9bb8">https://code.google.com/p/go/source/detail?r=41d393af9bb8</a>

This function, written in assembly, uses newer ARM instructions to perform a double
width LL/SC.  I believe this code is correct.

For older ARM processors, which are supported by Go, these instructions do not exist. 
On Linux, there is a primitive provided by the kernel that cooperates with the scheduler
to provide a the same primitive. However, non-Linux targets do not have similar
functionality.

Since non-Linux ARM targets are not generally well supported, a viable option might be
to discontinue support for ARMv5 CPUs on those systems and require a CPU that supports
at least the ARMv6K instructions.</pre>
Repository: go
Issue: sync: detect copying of Mutex
Labels: NeedsInvestigation

<pre>Discussion on golang-dev:
<a href="https://groups.google.com/forum/#">https://groups.google.com/forum/#</a>!searchin/golang-dev/copying$20sync.mutex/golang-dev/3jCp3vd4BQ8/dqjjePtV8iwJ

sync.Mutex can use the same technique as sync.Cond to detect copying.

Package docs says &quot;Values containing the types defined in this package should not
be copied&quot;.

It will also help to simplify runtime code and make Mutexes faster.

Brad raised the concern that it will increase size of Mutex.</pre>
Repository: go
Issue: proposal: encoding/json: add "inline" struct tag
Labels: Proposal,Proposal-Hold

by **bjruth**:

<pre>Discussion was conceived on golang-nuts:
<a href="https://groups.google.com/forum/#!topic/golang-nuts/bAgNll-EMkI">https://groups.google.com/forum/#!topic/golang-nuts/bAgNll-EMkI</a> to add support for a
flag that supports unmarshaling arbitary JSON into structs. A tag was announced for the
mgo/bson package here:
<a href="https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/ZeP7PaXVDQo">https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/ZeP7PaXVDQo</a> that
transparently stores data into a separate struct field denoted by &quot;inline&quot;
during an unmarshal and then merges that data back into the output during marshaling.

I believe this would be a very useful feature to add into the encoding/json package and
does not introduce any breaking changes in the Go 1.x series.</pre>

Edited by @dsnet on 2020-11-10 to fix formatting.
Repository: go
Issue: runtime: win32 should support more than 64 processors
Labels: OS-Windows

<pre>Windows 7 and Windows Server 2008 support up to 256 processors.  It seems that, by
default, a process is constrained to running in a single processor group which can be as
large as 64 processors.  To support more than 64 processors the scheduler needs to
become aware of &quot;processor groups&quot; and allocate threads explicitly to
different processor groups.

Processor groups are explained on the following page

<a href="http://msdn.microsoft.com/en-us/library/windows/desktop/dd405503(v=vs.85).aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/dd405503(v=vs.85).aspx</a>

Microsoft also publishes a document generally describing how to support systems with
&gt;64 processors

<a href="http://msdn.microsoft.com/en-us/windows/hardware/gg463349.aspx">http://msdn.microsoft.com/en-us/windows/hardware/gg463349.aspx</a></pre>
Repository: go
Issue: cmd/link: linker cannot discard unused but runtime-initialized global variables
Labels: NeedsInvestigation

<pre>The code.google.com/p/go.text/encoding/charmap package contains variable pairs like:

var CodePage437 encoding.Encoding = &amp;codePage437
var codePage437 = charmap{ /* a data table */ }

encoding.Encoding is an interface, so that the CodePage437 variable currently requires a
convT2I call, in a package init function. (<a href="https://golang.org/issue/6289">issue #6289</a> is possibly related, but even if
that was fixed, suppose for argument's sake that CodePage437 was initialized by a
constructed-at-runtime composite literal.)

Because CodePage437 is implicitly referenced by a package init function, the linker
considers it used by any program that imports that package, even if it otherwise doesn't
refer to CodePage437. The linker thus can't drop the unused data table (and maybe other
related metadata like pclntab??), and likewise for the N other encoding.Encoding
implementations in that package.</pre>
Repository: go
Issue: gdb: 'next' command confused by cgo calls
Labels: NeedsInvestigation

by **kaoshi.juan82**:

<pre>What steps will reproduce the problem?
write these code:
package main

//#include &lt;stdio.h&gt;
/*
void Print(int i){
        printf(&quot;result:%d\n&quot;,i);
}
*/
import &quot;C&quot;


func A() {
        a := 1
        b := 2
        c := 4
        C.Print((C.int)(a+b+c))
}

func main() {
        a := 1
        b := 2
        c := 3
        A()   //gdb n command will step into this function
        C.Print((C.int)(a+b+c))
}

What is the expected output?
if you press n at the line function call of A() while debugging, you should step over
the function call

What do you see instead?
instead, you step into the function.

Which compiler are you using (5g, 6g, 8g, gccgo)?
compiler is gcc (cgo) + 6g, 


Which operating system are you using?
under centos x86_64, gdb 7.4, and gcc 4.1.2

Which version are you using?  (run 'go version')
go 1.1.2</pre>
Repository: go
Issue: crypto/tls: add PSK support
Labels: NeedsDecision,FeatureRequest,Proposal-Crypto

by **tiebingzhang**:

<pre>RFC 4279 (<a href="http://tools.ietf.org/html/rfc4279#page-10)">http://tools.ietf.org/html/rfc4279#page-10)</a> added PSK to TLS.
OpenSSL and GnuTLS already have support for it.

The RFC defines three additional key exchange algorithms:
PSK
RSA-PSK
DHE-PSK

It would be nice to add at least PSK and DHE-PSK to GO's crypto/tls package. The work
seems to be reasonable size.

According to Wikipedia
(<a href="http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_Exchange_Algorithms_.28Alternative_key-exchanges.29)">http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations#Key_Exchange_Algorithms_.28Alternative_key-exchanges.29)</a>,
RSA-PSK has not been implemented by any of the listed implementations, so it is maybe
okay to push that one off for later.</pre>
Repository: go
Issue: proposal: spec: allow constants of arbitrary data structure type
Labels: LanguageChange,Proposal,LanguageChangeReview

by **RickySeltzer**:

<pre>var each1 = []byte{'e', 'a', 'c', 'h'}
    const each2 = []byte{'e', 'a', 'c', 'h'}

The 'var' is accepted, the 'const' is not. This is a defect in the language spec and
design.

1. What is a short input program that triggers the error?
<a href="http://play.golang.org/p/Jbo9waCn_h">http://play.golang.org/p/Jbo9waCn_h</a>

2. What is the full compiler output?
prog.go:7: const initializer []byte literal is not a constant
 [process exited with non-zero status]</pre>
Repository: go
Issue: spec: clarify intended behaviour of method values using promoted methods
Labels: Documentation,NeedsInvestigation

<pre>What steps will reproduce the problem?

Run this program:
<a href="http://play.golang.org/p/pQb9VlrLkv">http://play.golang.org/p/pQb9VlrLkv</a>

What is the expected output?

Based on the spec, it's not clear if this should print &quot;1 1&quot; or &quot;1
2&quot;.

What do you see instead?

Running the program in the go playground prints &quot;1 1&quot;.

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

Which operating system are you using?
n/a

Which version are you using?  (run 'go version')
go1.1.2

Please provide any additional information below.

The spec mentions auto-referencing/dereferencing the x in method value expression x.M as
necessary so that it matches the kind of receiver M has, which is why the call to tFn is
expected to print 1. It doesn't mention resolving x to the value that will ultimately
used to initialize the receiver-parameter visible in the body of the method M. Instead,
it says that x is evaluated and saved to be used as the receiver. Note that receiver has
multiple meanings used in the spec, depending on whether you're talking about the
receiver-argument or the receiver-parameter.

Depending on the intended behaviour, this may also be a compiler bug.</pre>
Repository: go
Issue: proposal: os/v2: Chown expects int, but os/user uses strings
Labels: v2,Proposal

<pre>[Noting down confusion from IRC]

Chown takes ints, os/user Lookup returns strings. If someone wants to &quot;chown jdoe
file&quot;, they're supposed to have platform-specific code to strconv from os/lookup
strings to ints?

I know backwards-compatibility means changes are hard, but this API does not seem ideal.

func Chown(name string, uid, gid int) error
<a href="http://golang.org/pkg/os/#Chown">http://golang.org/pkg/os/#Chown</a>

type User struct { Uid string; ... }
<a href="http://golang.org/pkg/os/user/#User">http://golang.org/pkg/os/user/#User</a>

I understand different platforms do different things -- but surely, if a platform has
Chown that operates on ints, surely it should have an API that produces ints too. Or a
cross-platform User abstraction that can be passed to Chown (where Chown exists).</pre>
Repository: go
Issue: runtime/race: eliminate dependency on cmd/cgo
Labels: RaceDetector,FeatureRequest

<pre>There is a circular dependency between runtime/race and cmd/cgo in -race build.
Everything depends on runtime/race, but runtime/race is a cgo package.
Currently it's resolved by a hack in go tool:

    // If we are not doing a cross-build, then record the binary we'll
    // generate for cgo as a dependency of the build of any package
    // using cgo, to make sure we do not overwrite the binary while
    // a package is using it.  If this is a cross-build, then the cgo we
    // are writing is not the cgo we need to use.
    if goos == runtime.GOOS &amp;&amp; goarch == runtime.GOARCH &amp;&amp; !buildRace {

We pretend that packages do not depend on cmd/cgo. But as the result we can overwrite
cmd/cgo binary while it is used.

A better solution is to make runtime/race to be not dependent on cmd/cgo.</pre>
Repository: go
Issue: misc/swig: long long not working with gcc 4.7 on Windows
Labels: OS-Windows

<pre>What steps will reproduce the problem?
1. grab the file at <a href="https://gist.github.com/steeve/6872454">https://gist.github.com/steeve/6872454</a>
2. on windows/386: go run test-int64.go


What is the expected output?
1

What do you see instead?
4603183328

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g, cgo on mingw32 + msys

Which operating system are you using?
windows 7

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

Please provide any additional information below.
Running this on darwin/amd64 and windows/amd64 works perfectly.</pre>
Repository: go
Issue: go/printer: printed output cannot be parsed if comments are retained
Labels: Thinking

<pre>This program:
  <a href="http://play.golang.org/p/f3VrIs2Z70">http://play.golang.org/p/f3VrIs2Z70</a>
parses a syntactically well-formed Go program, inserts an additional statement, then
prints it out again.  The result cannot be parsed because a newline was inserted in an
inappropriate place to accommodate a comment.  Here's the output:

package P

func f() {
    print(&quot;12&quot;
    /*hi*/)
    g(0, 1)
}

Note that the length of the literal &quot;12&quot; is critical: if a shorter expression
is used, the /*hi*/ comment, which is retains its association with its original byte
offset, will not be inserted at that point.</pre>
Repository: go
Issue: reflect: clarify that behaviour of Value returned from Value.Method is different from method value
Labels: Documentation,NeedsInvestigation

<pre>What steps will reproduce the problem?

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

What is the expected output?

Some users might expect the receiver of a function value returned by Value.Method to be
evaluated the same way it is for a method value once they've removed in from reflection
land by calling Value.Interface on it.

What do you see instead?

The reflect.Value, rather than the value it represents, is still used to derive the
receiver on each call even after you remove the value from reflection land. This could
be seen as being in keeping with

&quot;The arguments to a Call on the returned function should not include a receiver;
the returned function will always use v as the receiver.&quot;

The potentially surprising implications of this could be clarified though, since the
focus of this statement appears to be on the fact that you don't need to provide your
own receiver on each call, rather than on a deviation of the behaviour of the method
from the language feature it approximates.</pre>
Repository: go
Issue: cmd/compile: 8MB error message for one char error
Labels: NeedsInvestigation

<pre>$ cat x.go
package p

type A interface {
    a() interface{AB}
}

type B interface {
    a() interface{AB}
}

type AB interface {
    a() interface{A;B}
    b() interface{A;B}
}

var x AB
var y interface{A;B}
var _ = x == y


$ go tool 6g x.go
x.go:12: duplicate method a
x.go:13: duplicate method a
x.go:17: duplicate method a
x.go:18: invalid operation: x == y (mismatched types AB and interface { a() interface {
a() interface { a() interface { a() interface { a() interface { a() interface { a()
interface { a() interface { a() interface { a() interface { a&lt;...&gt;; a() interface
{ a&lt;...&gt;; b() interface { a&lt;...&gt;; a() interface { a&lt;...&gt;; b()
interface { a&lt;...&gt;; a() interface { a&lt;...&gt;; b() interface { a&lt;...&gt;;
a() interface { a&lt;...&gt;; b() interface { a&lt;...&gt;; a() interface {
a&lt;...&gt;; b() interface { a&lt;...&gt;; a&lt;...&gt; } } } } } } } } } } }; b()
interface { a&lt;...&gt;; a() interface { a() interface { a&lt;...&gt;; a() interface {
a&lt;...&gt;; b() interface { a&lt;...&gt;; a() interface { a&lt;...&gt;; b() interface
{ a&lt;...&gt;; a() interface { a&lt;...&gt;; b() interface { a&lt;...&gt;; a()
interface { a&lt;...&gt;; b() interface { a&lt;...&gt;; a&lt;...&gt; } } } } } } } } };
b() interface { a&lt;...&gt;; a() interface { a() interface { a&lt;...&gt;; a()
interface { a&lt;...&gt;; b() interface { a&lt;...&gt;; a() interface { a&lt;...&gt;;
b() interface { a&lt;...&gt;; a() interface { a&lt;...&gt;; b() interface {
a&lt;...&gt;; a&lt;...&gt; } } } } } } }; b() interface { a&lt;...&gt;; a() interface {
a() interface { a&lt;...&gt;; a() interface { a&lt;...&gt;; b() interface {
a&lt;...&gt;; a() interface { a&lt;...&gt;; b() interface { a&lt;...&gt;; a&lt;...&gt; }
} } } }; b() interface { a&lt;...&gt;; a() interface { a() interface { a&lt;...&gt;; a()
interface { a&lt;...&gt;; b() interface { a&lt;...&gt;; a&lt;...&gt; } } };...


$ go tool 6g x.go | wc
       4 1586257 8248570


When the program is fixed (rename method a in interface B to b), the compiler runs
extremely long:

$ time go tool 6g x.go

real    0m19.170s
user    0m17.352s
sys 0m1.037s


For comparison, for the incorrect program, gccgo reports:

$ gccgo x.go
x.go:12:20: error: inherited method 'a' is ambiguous
      a() interface{A;B}
                    ^
x.go:13:20: error: inherited method 'a' is ambiguous
      b() interface{A;B}
                    ^
x.go:17:17: error: inherited method 'a' is ambiguous
 var y interface{A;B}
                 ^
x.go:18:11: error: incompatible types in binary expression
 var _ = x == y
           ^


For the correct program, gcc does not appear slower than usual.</pre>