sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/compile: Opportunity for de-pessimization in provably const range loops
Labels: Suggested

<pre>What does 'go version' print?

go version go1.3 linux/amd64

What steps reproduce the problem?

Using the 2-return 'range' over a slice of structs will copy each struct, even if the
struct is provably not modified in the loop.  This is a premature pessimization that the
compiler could and should eliminate.  Ideally the spec would guarantee this optimization
(a la RVO in C++) so people could count on it and maybe even warn when it is not true.

The for-each construct is much nicer to read and write, but this behavior sort of makes
it a non-starter for large data.  This is discussed in many places on the web, with the
general recommendation of &quot;just iterate on index&quot;.  This is unfortunate for
the language.

Alternatively: some syntax to say explicitly &quot;iterate by reference&quot; or by
pointer.

Ian asked me to file this issue.</pre>
Repository: go
Issue: go/types: confusing behaviour of Selection.Indirect() for Kind()==MethodVal
Labels: NeedsInvestigation

<pre>In go/types/selection.go, the intended significance of the Indirect flag (for MethodVal)
is hard to tell from the example.  I was assuming that is means whether there are any
pointer indirections between the type of the receiver and the declared type of the
method, but that doesn't seem to explain it:

I instrumented recordSelection:

% cat sel.go 

package main

type T struct {}

func (T)f() {}
func (*T)g() {}

func main() {
        var x T
        x.f()
        x.g()

        var p *T
        p.f()
        p.g()
}

% ./ssadump sel.go
sel.go:11:2: SEL method (main.T) f() indirect=false
sel.go:12:2: SEL method (main.T) g() indirect=false
sel.go:15:2: SEL method (*main.T) f() indirect=true
sel.go:16:2: SEL method (*main.T) g() indirect=true

In the last selection, there is no actual indirection between the receiver type *T and
the method type *T, yet the indirect flag is reported as true.  (The indirect flag seems
to record only the pointerness of the receiver, which is redundant information.)

I think, by analogy with field selections, the indirect bit should be set iff there was
an implicit pointer indirection between the actual receiver type and the formal receiver
type, e.g a (T) method was called with an expression of type (*T), or in this example:

   type A struct {}
   func (*A) f() {}
   type B struct {*A}

   ... B{}.f()   // indirect, since method (*A).f 

An (A) method is called with an expression of type B.</pre>
Repository: go
Issue: cmd/compile: Debug information missing : no stack info , no variables info using gdb
Labels: NeedsInvestigation

by **guybrandw**:

<pre>Since version 1.3 , I cant get debugging information .
using both linux64 , windows64/32 :
1. the variables displays values with no correlation to the real value (fmt.Print()
displays the right values) .
2. the call stack displays only the last step of the stack , other steps are displayed
as ???? .

I have uninstalled Go 1.3 , installed 1.21 and both problems were &quot;solved&quot; .
reinstalled 1.3 , the problem returned .

attached prinshots of simple code , the variables displayed in LiteIde , the stack , and
print function of the gdb .

to make sure , I have tried the same installing the Zues IDE , same problems reproduced .</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/8357/0/debugIssue.png">debugIssue.png</a> (37441 bytes)
Repository: go
Issue: go/doc: incorrect href link for dot import
Labels: NeedsInvestigation

by **fgmarand**:

<pre>What does 'go version' print?
  go version go1.3 linux/amd64

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

1. unpack the archive in src/
2. start godoc -http=:6060
3. go to <a href="http://localhost:6060/pkg/outer/inner">http://localhost:6060/pkg/outer/inner</a>
4. examine the link to OuterA within InnerA

What happened?

  The link points to <a href="http://localhost:6060/pkg/outer/inner/#OuterA">http://localhost:6060/pkg/outer/inner/#OuterA</a>

What should have happened instead?

  The link should have pointed to <a href="http://localhost:6060/pkg/outer/#OuterA">http://localhost:6060/pkg/outer/#OuterA</a>

Additional information

  This appears to be because of the default import alias: when using a normal import, even aliased (like: import o &quot;outer&quot;), the link is built correctly.</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/8394/0/outer.tgz">outer.tgz</a> (10240 bytes)
Repository: go
Issue: cmd/vet: check for useless assignments to struct fields
Labels: Analysis

<pre>Implement this TODO from the assignment checker:

// TODO: should also check for assignments to struct fields inside methods
// that are on T instead of *T. 

Discussion at <a href="https://groups.google.com/forum/#">https://groups.google.com/forum/#</a>!topic/golang-nuts/rSTE4G75QQU/discussion.

This might also be extended to range loops -- see <a href="http://play.golang.org/p/FMsMT0dnhf">http://play.golang.org/p/FMsMT0dnhf</a>,
linked from <a href="https://golang.org/issue/8356">issue #8356</a>.</pre>
Repository: go
Issue: cmd/compile: Wrong type reported for constant in type mismatch report
Labels: NeedsInvestigation

<pre>In the following code:

func Foo() []float64 {
    return 0
}

gc reports &quot;cannot use 0 (type int) as type []float64 in return argument&quot;.
However, 0 is not an integer, 0 is a constant.

<a href="http://play.golang.org/p/hyUix7H8aX">http://play.golang.org/p/hyUix7H8aX</a></pre>
Repository: go
Issue: cmd/cgo: build failed when any code have CFLAGS: -Werror=unused-vairable
Labels: help wanted,NeedsInvestigation

by **Snyh1010**:

<pre>1. What is a short input program that triggers the error?
package main

//#cgo CFLAGS: -Werror=unused-variable
//void test(){}
import &quot;C&quot;

func main() {
        C.test()
}


2. What is the full compiler output?
snyh:shm$go build
# _/run/shm
./a.go: In function ‘_cgo_043ca501ac1f_Cfunc_test’:
./a.go:32:49: error: unused variable ‘a’ [-Werror=unused-variable]
cc1: some warnings being treated as errors

------------------------------------------
I have fixed this by  a CL <a href="https://golang.org/cl/118890044/">https://golang.org/cl/118890044/</a>  

The  CL(<a href="https://golang.org/cl/109640045)">https://golang.org/cl/109640045)</a>  had fix this problem under gcc. 
The first time I hasn't notice clang, so when the CL has been submitted, it broken
freebsd because clang.  And the CL has been undo.

The broken problem is not caused by my code, it's appeared upon the submission because
the CL contains the test code let the problem appeared. 

I have fixed the problem  both clang and gcc.  But it seems no one have confidence to
submit it this time, I have send the CL request. 
 
Anyway I want the problem be fixed, with or without my CL.</pre>
Repository: go
Issue: x/net/ether: create package that supports raw ethernet sockets
Labels: help wanted

by **nathan@nathan.io**:

<pre>It would be useful if Go supported raw ethernet sockets. It is indicated that this was
planned in a TODO on net.go: 
// TODO(rsc):
//  support for raw ethernet sockets

Is this still planned? 

Thanks!</pre>
Repository: go
Issue: runtime: TestStackMem needs to be run in isolation to be accurate
Labels: NeedsInvestigation

<pre>See CL 119330044

TestStackMem measures the amount of stack used, which can change due to other tests
running simultaneously.

We see instances of the amount of stack used going negative.  This bug requests a way of
running this test in isolation so it isn't degraded by other nearby tests.</pre>
Repository: go
Issue: testing/quick: generate NaN and +/-Inf for float and complex parameters
Labels: NeedsInvestigation

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

quick's default generator never produces NaN or +/-Inf. These are commonly-missed edge
cases.</pre>
Repository: go
Issue: cmd/compile: Manually calling init should provide a better error message, currently says "undefined: init"
Labels: NeedsFix

<pre>Attempting to manually call an init() function fails with the somewhat cryptic compiler
error &quot;undefined: init&quot;.

It should indicate that init is a special symbol (automatically run) and cannot be
manually called.

<a href="http://play.golang.org/p/d2A2m56Fvp">http://play.golang.org/p/d2A2m56Fvp</a></pre>
Repository: go
Issue: runtime: fatal error: cannot map pages in arena address space on Windows
Labels: OS-Windows

by **kaixinlaoshu2008**:

<pre>What does 'go version' print?
go 1.3 windows/386
What steps reproduce the problem?

file, handler, err := r.FormFile(&quot;file&quot;)
...
defer file.Close()

Use FormFile to receive documents.
When i upload a flie(100M) 4 or 5 times will get errors.

What happened?

fatal error: runtime: cannot map pages in arena address space

What should have happened instead?

go free memory after the FormFile receive a document.</pre>
Repository: go
Issue: reflect: Add UnderlyingType(reflect.Type)
Labels: NeedsDecision,FeatureRequest

<pre>The go spec refers to the underlying type of a given type T:

Each type T has an underlying type: If T is one of the predeclared boolean, numeric, or
string types, or a type literal, the corresponding underlying type is T itself.
Otherwise, T's underlying type is the underlying type of the type to which T refers in
its type declaration.

Discussion: <a href="https://groups.google.com/d/msg/golang-nuts/BJEuegjQtEA/q2S3b6JxY1MJ">https://groups.google.com/d/msg/golang-nuts/BJEuegjQtEA/q2S3b6JxY1MJ</a></pre>
Repository: go
Issue: gdb: Gdb doesn't show strings values
Labels: NeedsInvestigation

by **ignatovs**:

<pre>Mac OS X 10.9.4

What does 'go version' print?
go version go1.3.1 darwin/amd64 (via brew)

GNU gdb (GDB) 7.7.1 (via brew)
Copyright (C) 2014 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;x86_64-apple-darwin13.3.0&quot;.
Type &quot;show configuration&quot; for configuration details.
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>;.
Find the GDB manual and other documentation resources online at:
&lt;<a href="http://www.gnu.org/software/gdb/documentation/&gt">http://www.gnu.org/software/gdb/documentation/&gt</a>;.
For help, type &quot;help&quot;.
Type &quot;apropos word&quot; to search for commands related to &quot;word&quot;.
(gdb) show configuration
This GDB was configured as follows:
   configure --host=x86_64-apple-darwin13.3.0 --target=x86_64-apple-darwin13.3.0
             --with-auto-load-dir=:${prefix}/share/auto-load
             --with-auto-load-safe-path=:${prefix}/share/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/Cellar/gdb/7.7.1/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/Cellar/gdb/7.7.1/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --with-python=/System/Library/Frameworks/Python.framework/Versions/2.7
             --with-separate-debug-dir=/usr/local/Cellar/gdb/7.7.1/lib/debug (relocatable)
             --with-zlib
             --without-babeltrace

(&quot;Relocatable&quot; means the directory can be moved with the GDB installation
tree, and GDB will still find it.)


1. Build a sample <a href="http://play.golang.org/p/n2L68VzRen">http://play.golang.org/p/n2L68VzRen</a> as a binary m (via go build m.go)
2. Run gdb m
3. Setup a new breakpoint at line 9
4. Run the executable
5. Try to view local variables via info locals

What happened?
(gdb) info locals 
x = map[string]string&lt;error reading variable: Cannot access memory at address 0x10&gt;
z =  []string = {&lt;error reading variable: Cannot access memory at address 0x0&gt;, 
  &lt;error reading variable: Cannot access memory at address 0x15fb60&gt;, &quot;&quot;, &quot;&quot;, &quot;&quot;, &quot;&quot;}
y =  []int

What should have happened instead?
I'd like to see something more readable :)

Please provide any additional information below.</pre>
Repository: go
Issue: x/pkgsite: support company-specific doc annotations
Labels: NeedsInvestigation

<pre>Google internally runs a godoc server serving docs for the standard library + all of
Google $GOPATH (all internal Google Go code).

In many cases, we'd like to mention the Google-specific libraries or ways of doing
things from the standard library docs.

It would be nice if there were a file we could maintain that appended company-specific
doc annotations to the standard library on at least:

-- packages
-- funcs
-- types
-- specific fields on struct types</pre>
Repository: go
Issue: runtime: don't allocate for non-escaping conversions to interface{}
Labels: Performance

<pre>fmt.Fprintf(&quot;%d&quot;, 8)

Since all interface data fields are now pointers, an int must be allocated and
initialized to 8 so that it can be put in an interface{} to pass to Fprintf.

Since we know the 8 doesn't escape, we could instead allocate that 8 on the stack and
have the interface data word point to that stack slot.  To be safe, we can only do this
when the resulting interface{} doesn't escape.  We probably also need to be sure the
conversion happens at most once so the stack slot is not reused.

We could have a special convT2Enoescape call for the compiler to use when it knows the
result doesn't escape.  Maybe also convT2I, assertT2E, ...</pre>
Repository: go
Issue: runtime: make GC runtime stats test run on GCE
Labels: NeedsInvestigation

<pre>In <a href="https://code.google.com/p/go/source/detail?r=ec6629ef3dae19">https://code.google.com/p/go/source/detail?r=ec6629ef3dae19</a> I removed part of a test
that Dmitry liked because it doesn't run on GCE (which only has ~1ms timers apparently).

This bug is about restoring the test somehow. We could make it a -short test (so it's
skipped on builders, but runs on our machiens). Or try the test first and if we get a
0ns pause, then generate a lot of garbage and try for a &gt;= 1 ms GC pause, which is
measurable on Windows (physical hardware) and GCE (any OS).</pre>
Repository: go
Issue: x/tools/imports: Removes comments if it doesn't see "package"
Labels: NeedsInvestigation

<pre>$ printf '// i am precious\n' &gt;i.go &amp;&amp; goimports -d i.go
diff i.go gofmt/i.go
--- /home/tv/tmp/gofmt524290255 2014-09-03 11:33:53.118042810 -0700
+++ /home/tv/tmp/gofmt219767778 2014-09-03 11:33:53.118042810 -0700
@@ -1 +1 @@
-// i am precious
+
$ gofmt -d i.go 
i.go:1:18: expected 'package', found 'EOF'

$ printf '// i am precious\nfunc f() {}' &gt;i.go &amp;&amp; goimports -d i.go
diff i.go gofmt/i.go
--- /home/tv/tmp/gofmt433476709 2014-09-03 11:36:09.002716626 -0700
+++ /home/tv/tmp/gofmt636561536 2014-09-03 11:36:09.002716626 -0700
@@ -1,2 +1 @@
-// i am precious
 func f() {}
\ No newline at end of file

I'm ok with getting an error about invalid Go, or having a still-invalid file that
preserves the comments. I am not ok with losing my input.

This is extra annoying when goimports is hooked into editor save, and I move a
documented function into a new file.</pre>
Repository: go
Issue: cmd/compile: In struct literals, type check outside in rather than inside out.
Labels: NeedsInvestigation

<pre>When constructing a struct literal, the types appear to be checked from the &quot;inside
out&quot;, that is, it appears that the last thing checked is that the variable type
matches the struct field. This leads to <a href="http://play.golang.org/p/vwvF9uNyhU">http://play.golang.org/p/vwvF9uNyhU</a>, where the
error is really that the outer literal should be [][]float64, not that the inner
literals are the wrong type.</pre>
Repository: go
Issue: cmd/compile: random performance fluctuations after unrelated changes
Labels: Performance,NeedsFix

<pre>We see constant performance fluctuations after unrelated changes on the perf dashboard.
For example:
<a href="http://build.golang.org/perfdetail?commit=96c713ab6c6f2a4b2a8a0bb2e8d674637b6ce596&amp">http://build.golang.org/perfdetail?commit=96c713ab6c6f2a4b2a8a0bb2e8d674637b6ce596&amp</a>;commit0=fee5fcd5f87e75235d93fb297123feb15a59ae38&amp;builder=linux-amd64-perf&amp;benchmark=json
<a href="http://build.golang.org/perfdetail?commit=455042166f1366b147e1249b8d5639be7d67bfce&amp">http://build.golang.org/perfdetail?commit=455042166f1366b147e1249b8d5639be7d67bfce&amp</a>;commit0=0a5fafdd2343b083457d0baf6487dfce0f01e25f&amp;builder=windows-amd64-perf&amp;benchmark=json
<a href="http://build.golang.org/perfdetail?commit=ad5d9f8f9be743e72f89d85d8bd6348807bdac90&amp">http://build.golang.org/perfdetail?commit=ad5d9f8f9be743e72f89d85d8bd6348807bdac90&amp</a>;commit0=fc588981a45afa430a2d2cd29d234403cb86e1bd&amp;builder=windows-amd64-perf&amp;benchmark=json

I can reproduce it locally as well. I've took 2 consecutive commits:
changeset:   21142:91110f70916a
summary:     runtime: allow crash from gsignal stack
changeset:   21141:0768bb1fd027
summary:     net: fix inconsistent behavior across platforms in SetKeepAlivePeriod

and run go.benchmarks binary as:
./bench -bench=json -benchtime=3s -benchnum=100
alternating old and new binaries.

The results are:
GOPERF-METRIC:time=91998310
GOPERF-METRIC:time=91863644
GOPERF-METRIC:time=91491272
GOPERF-METRIC:time=91988322

new:
GOPERF-METRIC:time=93191495
GOPERF-METRIC:time=93222905
GOPERF-METRIC:time=93224972
GOPERF-METRIC:time=93140395

The difference is now that big (probably because my processors panilizes less what is
being penalized), but clearly observable.

It looks like code alignment issue. Probably loops are not 16-byte aligned or something
like this.

I guess this also penalizes user binaries in the same random and unpredictable way.</pre>
Repository: go
Issue: go/types: constant values should reported as machine values for concrete types
Labels: NeedsInvestigation

<pre>Feature request: The reported values of constants should be the respective machine
values (perhaps in addition to the precise values) if the constant type is not an
untyped type.</pre>
Repository: go
Issue: runtime,sync/atomic: unify API for runtime/internal/atomic and sync/atomic
Labels: Performance

<pre>We need to unify interface of atomic operations between runtime package and sync/atomic
package. And then teach gc to replace functions in both packages with intrinsics where
possible.

This is followup to <a href="https://golang.org/issue/4947">https://golang.org/issue/4947</a> which was about
atomic intrinsics for runtime C code.</pre>
Repository: go
Issue: cmd/compile: merge temporaries more aggressively
Labels: Performance,NeedsFix

<pre>CL 12829043 added a compiler pass that merges temporary variables with equal types and
non-overlapping lifetimes.

I believe that &quot;equal types&quot; is sufficient but not necessary and that
&quot;equivalent w.r.t. GC&quot; is both necessary and sufficient. (Please correct me if
I am wrong!) This should allow more temporaries to be merged, further reducing stack
usage.</pre>
Repository: go
Issue: testing: measure coverage inside boolean expressions
Labels: help wanted

<pre>Test coverage works on basic blocks. It could be extended to short-circuiting boolean
expressions like f() &amp;&amp; g().

Approach:

func GoCoverBool(ret bool, n int) bool {
  GoCover.Count[n] = 1
  return ret
}

Rewrite f() &amp;&amp; g() to f() &amp;&amp; GoCoverBool(true, 5) &amp;&amp; g() and f()
|| g() to f() || GoCoverBool(false, 5) || g().

I don't know what adjustments to the downstream tools this might require.</pre>
Repository: go
Issue: x/sys/unix: Sysctl doesn't supporting writing values
Labels: NeedsInvestigation

<pre>Hello,

This is not really reporting defects but more like a feature request.

In syscall package, or go.sys package, Sysctl is defined as: 

func Sysctl(name string) (value string, err error)

It provides a way to read values through sysctl, but makes it impossible to write/update
values. Internally, it uses &quot;sysctl&quot; defined in each particular OS / ARCH. For
example, (from zsyscall_freebsd_amd64.go):

func sysctl(mib []_C_int, old *byte, oldlen *uintptr, new *byte, newlen uintptr) (err
error)

It would be nice if it can be exported in some way because this is essentially the same
interface as defined in BSD systems. e.g. <a href="https://www.freebsd.org/cgi/man.cgi?sysctl(3)">https://www.freebsd.org/cgi/man.cgi?sysctl(3)</a>

int sysctl(const int *name, u_int namelen, void *oldp, size_t *oldlenp, const void
*newp, size_t newlen);
int sysctlbyname(const char *name, void *oldp, size_t *oldlenp, const void *newp, size_t
newlen);

Can we provide a similar set of functions in go.sys that provides full sysctl support
(both read / write)? If go.sys is not frozen yet, maybe it's a good idea to use the
function names used in most BSD systems, in which case current Sysctl will need to be
renamed to, e.g., SysctlRead.</pre>
Repository: go
Issue: runtime: shrink stacks more aggressively on explicit GC
Labels: NeedsInvestigation

<pre>If the user calls runtime.GC or debug.FreeOSMemory, shrink stacks even if they are &gt;
1/4 full.  That way we can reclaim more space (at the expense of incurring runtime cost
when those goroutines start back up).

Maybe also if gp.blockedsince shows the goroutine has been blocked for a long time.</pre>
Repository: go
Issue: html/template: provide a way to specify the initial escaping context (JS or CSS) when parsing
Labels: NeedsInvestigation

<pre>There is currently no way (that I am aware of) to specify the initial escaping context
(JS or CSS, or other?) when parsing a template using html/template.

The use case where this would be useful is when treating JS or CSS files as templates. 
In these cases, it would seem to make sense to be able to call Template.Parse() with an
initial escaping context, telling it to treat this as a JS (or other) file.  Some
example use cases for treating JS or CSS files as templates are to inject translated
text into them (JS), or dynamically inlining images as data urls (CSS).

To work around this using the current system, you get something like this:
<a href="http://play.golang.org/p/J-21ux0gLE">http://play.golang.org/p/J-21ux0gLE</a>

As you can see, having this as a template:

 //&lt;script&gt;
 (function(){console.log(&quot;hello&quot;)})()
 {{jsraw &quot;//&quot;}}&lt;/script&gt;

is rather crufty.

It would make much more sense to lose the script tag trickery and instead when we parse,
do something like this:

 t, err := t.Parse(jsInput, template.TypeJS)</pre>
Repository: go
Issue: go/types: need way to get from function type to function decl
Labels: Thinking

<pre>From a mail conversation:

On Fri, Sep 12, 2014 at 12:09 PM, Peter Collingbourne &lt;pcc@google.com&gt; wrote:
This information is significant for name mangling and is therefore needed. If there were
a convenient way to ask a named type for its enclosing function, I think it would be
possible to get rid of this traversal. Robert might have opinions on this.

On Fri, Sep 12, 2014 at 5:05 PM, Robert Griesemer &lt;gri@google.com&gt; wrote:
 You should be able to get the scope for each variable (Object) via Parent(). Furthermore, Info.Scopes should give you a mapping of nodes to scopes, which should make this simpler. But perhaps I am missing something.

Peter Collingbourne:
I looked at Info.Scopes. I imagine that I could potentially make that work if I built my
own scope-to-function map from that mapping.

According to the documentation, I might expect to find (among other things) ast.FuncType
keys in the map. Is this what I should expect functions to be represented as? I looked
up ast.FuncType and could not see any way to get the function's name. It seems like it
would be more useful for me if that map stored FuncDecl keys. (If that wouldn't work for
whatever reason, it seems better to me for go/types to maintain the mapping from scopes
to objects, maybe just by adding an Object field to Scope).

--------------------

Need to rethink connection between function types/decls and scopes.</pre>