sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: go/types: expose interface satisfaction constraints
Labels: Refactoring

<pre>The type checker goes to very great lengths to be robust and precise even for ill-typed
inputs, and it is very hard to match this level of robustness in other passes over the
(typed) AST.  As a result, the refactor/lexical and refactor/satisfy packages, both of
which recompute information computed but not exposed by go/types, are not safe to run on
programs with type errors.

refactor/lexical records, for every referring identifier, the structure of the lexical
environment at that point, information that is necessary for refactoring tools and
impossible to derive from the Scope information currently exposed by the type checker
(which is rarely useful).

refactor/satisfies records the set of type pairs (x, y) such that x is assignable to
interface y, and if it were not assignable, the program would not compile.  This also is
necessary for refactoring tools.

I think the 'lexical' pass could be very cheaply and elegantly implemented into the
existing type checker, and I think it should be since it is so useful; 'satisfies' is 
trickier.</pre>
Repository: go
Issue: cmd/gofmt: two dimensional slice/array formatting
Labels: Thinking

by **mrekucci**:

<pre>go version go1.3.1 darwin/amd64

Try to format next code snippet: <a href="http://play.golang.org/p/b0tIzdvp9i">http://play.golang.org/p/b0tIzdvp9i</a>
In my opinion the code should be formatted in a way how it looks like
before formatting i.e. columns aligned to comma.</pre>
Repository: go
Issue: cmd/compile: package type name collision with built-in types in compiler error messages
Labels: NeedsFix

by **sedevelopers01**:

<pre>v1.3.3

Thread on go-nuts:

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

Problem:

    When you define a package level &quot;error&quot; type (lower-case) it shadows the built-in error type and causes error messages like:

    &gt; Cannot use errors.New(&quot;something wrong&quot;) (type error) as type error in return argument

Solutions proposed:

    Maybe the type name could be shown as &quot;built in type error&quot; in error messages, and the same for &quot;built in type int&quot;.

    Or, on the other hand, maybe the locally defined type should be shown as &quot;type foo.error&quot; where foo is the package name in which it is defined.

    And then, why not both? That would make all error messages redundantly unambiguous.

    We've tried very hard to keep error messages concise. Perhaps we could just add the context where there is ambiguity.</pre>
Repository: go
Issue: crypto/sha512: Arm Optimizations not implemented
Labels: Performance

by **jeromyj**:

<pre>sha family hash functions on ARM architectures are quite slow, there is an
implementation of sha512 (and sha1) in libgcrypt that has assembly optimized code for
ARM Neon. It would be really nice to have something similar implemented into the Go
standard library.</pre>
Repository: go
Issue: x/tools/present: .play snippet don't handle inserted newlines when using the Enter key.
Labels: NeedsInvestigation

by **smyrman**:

<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 does 'go version' print?

go version go1.3.3 linux/amd64


What steps reproduce the problem?

Using the following configuration:
- OS: Arch Linux
- Web browser: Chrome Version 38.0.2125.104 (64-bit)
- Keyboard layout: US Internationl AltGr Unicode combining

1. Edit the code in a present &quot;.play&quot; snippet.
2. Add a new code line by using Enter (not shift enter).
3.  Click Run...

If possible, include a link to a program on play.golang.org.

What happened?

The compiler don't detect the newline added by Enter, and the snippet compilation fails.
E.g.:

    prog.go:10: syntax error: unexpected name, expecting semicolon or newline or }
    [process exited with non-zero status]
    Program exited.

What should have happened instead?

The newline should have been detected, and the program should have compiled.

Please provide any additional information below.

I tested to use Chrome Inspect elements, and I can see that using
&quot;shift+Enter&quot; and &quot;Enter&quot;, have slightly different effect on the
edited HTML.

Adding a line with Shift + Enter works, and the snippet runs. Adding a file with just
Enter, creates a new &quot;&lt;pre&gt;&quot;, element, and the snipet don't run (unless
semicolons are manually adde to the end of the line).</pre>


Attachments:
1. <a href="https://storage.googleapis.com/go-attachment/9011/0/original.png">original.png</a> (13618 bytes)
2. <a href="https://storage.googleapis.com/go-attachment/9011/0/added_line_with_shift_enter.png">added_line_with_shift_enter.png</a> (14761 bytes)
3. <a href="https://storage.googleapis.com/go-attachment/9011/0/added_line_with_just_enter.png">added_line_with_just_enter.png</a> (21574 bytes)
Repository: go
Issue: io: no easy way to fan out to multiple readers
Labels: NeedsInvestigation

by **recv@awesam.de**:

<pre>There is currently no good way to fan out from an io.Reader to multiple readers. A
use-case we commonly encounter is piping data from one reader to another, and doing some
calculation over the piped data on the side in a goroutine.

io.TeeReader gets you only half the way, and we found a nice solution based on that and
io.Pipe.

See <a href="http://play.golang.org/p/xBBeaBdVJf">http://play.golang.org/p/xBBeaBdVJf</a> for an example, piping a .tar.gz from stdin to
stdout, printing the tar headers to stderr along the way.

Would you be open to introduce a similar StreamReader implementation to io/ioutils?</pre>
Repository: go
Issue: x/text/unicode/norm: LastBoundary is inconsistent
Labels: NeedsInvestigation

<pre>The LastBoundary methods seems inconsistent as to
where it reports a boundary. When called with a string
containing a single (non-combining) character, the boundary
is sometimes reported at the start of the string
and sometimes at the end:

This code:

    fmt.Printf(&quot;%d\n&quot;, norm.NFD.LastBoundary([]byte(&quot;a&quot;)))
    fmt.Printf(&quot;%d\n&quot;, norm.NFD.LastBoundary([]byte(&quot;♔&quot;)))

print 0 and 3. I would expect it to print 0 and 0 or 1 and 3.

Perhaps it would be better if neither FirstBoundary (LastBoundary)
never reported a boundary at the start (end) of a string.
That way it becomes easier to use FirstBoundary and LastBoundary
to iterate through strings when use of Iter is not convenient.</pre>
Repository: go
Issue: go/build: Import(".", ".", 0) fails to resolve the full package path relative to GOPATH while build.Import(".", <cwd>, 0) works
Labels: NeedsInvestigation

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

What steps reproduce the problem?
1. mkdir $HOME/src2
2. mkdir $HOME/src2/golang
3. export GOPATH=$HOME/src2/golang
4. mkdir -p $GOPATH/src/foo
5. Put the content of <a href="http://play.golang.org/p/gzOX-Obb75">http://play.golang.org/p/gzOX-Obb75</a> into $GOPATH/src/foo/a.go
6. go run a.go

What happened?
build.ImportDir() and build.Import() fail to correctly resolve Package.ImportPath to
&quot;foo&quot;. I think it used (?) to work recently.

I reproduce the problem via <a href="https://github.com/kisielk/errcheck">https://github.com/kisielk/errcheck</a> but it can be easily
reproduced with the code I provided above. The problem is actually surfacing in
<a href="https://github.com/kisielk/gotool">https://github.com/kisielk/gotool</a> which does the build.ImportDir(&quot;.&quot;, 0) call,
which fails to return the correct ImportPath.


What should have happened instead?
build.ImportDir() and build.Import() with &quot;.&quot; should have the same behavior
than when provided os.Getwd(), e.g.:

Do the same code path as would 
dir, _ := os.Getwd()
pkg, err := build.Import(&quot;.&quot;, dir, 0)

should have the same result than:

pkg, err := build.Import(&quot;.&quot;, &quot;.&quot;, 0)</pre>
Repository: go
Issue: cmd/link: include $a and $t symbols in arm final link
Labels: NeedsInvestigation

<pre>The host objdump -d doesn't work correctly on 5l-linked binaries.  5l does not add $a
(arm) and $t (thumb) symbols to the output, and thus objdump doesn't know how to
disassemble the code.  It ends up disassembling as .word directives instead of actual
disassembly.

objdump can be forced to disassemble correctly using -D, but then you get data sections
disassembled into junk.  Or you can use go tool objdump, which works but can't
disassemble thumb.</pre>
Repository: go
Issue: runtime: remove implementation restriction on channel element size
Labels: NeedsInvestigation

<pre>It appears that gc and the runtime currently disable channel elements to be over 64kB:

    <a href="http://play.golang.org/p/_aVWt-qiud">http://play.golang.org/p/_aVWt-qiud</a>

But I see nothing about this (allowed?) implementation restriction in the spec, despite
the spec calling out a number of other implementation-allowed restrictions.</pre>
Repository: go
Issue: net/http: DialTLS is not used w/ proxy (by design)
Labels: NeedsInvestigation

by **joshua.boelter**:

<pre>What does 'go version' print?

go version go1.4rc1 [windows/amd64 | linux/amd64]

What steps reproduce the problem?

transport.DialTLS not used when an HTTPS connection is proxied.
<a href="http://play.golang.org/p/hSZy5-Sg0I">http://play.golang.org/p/hSZy5-Sg0I</a>

Equally concerned developers will introduce unintended security bugs if/when an app is
executed in an environment with a proxy.

What happened?

DialTLS not used (by design) when a proxy is present.

What should have happened instead?

Need support to reject connections based on factors outside hostname when a proxy is
present.  e.g. a Verify(...) callback on tls.Config executed after the handshake and
other verification steps have executed.

Please provide any additional information below.

The issue that added DialTLS:
<a href="https://golang.org/issue/8522">https://golang.org/issue/8522</a>

Patch set #3 (or similar) would address the need.
<a href="https://golang.org/cl/137940043/#ps40001">https://golang.org/cl/137940043/#ps40001</a></pre>
Repository: go
Issue: runtime: support parallel cache-oblivious algorithms
Labels: Performance

<pre>Cache-oblivious algorithms automatically take advantage of all levels of caches present
in the system (register set, L1/L2/L2, disk) by recursively sub-dividing the problem
into smaller parts:
<a href="http://en.wikipedia.org/wiki/Cache-oblivious_algorithm">http://en.wikipedia.org/wiki/Cache-oblivious_algorithm</a>

Recursive divide-and-conquer is the working horse of lots of parallel algorithms.

Here is a sample program that does simple O(N^2) computation using 4 methods:
1. sequential naive (iterative)
2. sequential cache-oblivious
3. parallel naive (iterative)
4. parallel cache-oblivious

<a href="http://play.golang.org/p/P4vh-GxnRz">http://play.golang.org/p/P4vh-GxnRz</a>

Results are:

serial sum... 3m0.149312702s (sum=480293945344)
cache oblivious sum... 1m59.191344136s (sum=480293945344)
parallel sum(1)... 2m45.547188918s (sum=480293945344)
parallel sum(2)... 1m29.9953968s (sum=480293945344)
parallel sum(4)... 46.828645173s (sum=480293945344)
parallel sum(8)... 27.005117917s (sum=480293945344)
parallel sum(16)... 13.942930282s (sum=480293945344)
parallel sum(32)... 10.920164632s (sum=480293945344)
cache oblivious parallel sum(1)... 2m32.863516062s (sum=480293945344)
cache oblivious parallel sum(2)... 1m13.964254945s (sum=480293945344)
cache oblivious parallel sum(4)... 43.00664982s (sum=480293945344)
cache oblivious parallel sum(8)... 21.625423811s (sum=480293945344)
cache oblivious parallel sum(16)... 13.566854603s (sum=480293945344)
cache oblivious parallel sum(32)... 9.740402766s (sum=480293945344)

Sequential cache-oblivious algorithm is 33% faster even on this small data set. However,
parallel cache-oblivious version does not show this speedup. The problem is that
parallel cache-oblivious algorithms require LIFO scheduling (or at least as close to
LIFO as possible), but current goroutine scheduler does FIFO. As the result the
algorithm does BFS instead of DFS, this not only breaks cache locality, but also
increases memory consumption from N to 2^N (where N is the depth of the
divide-and-conquer tree).

Currently a user has to make a choice between efficient cache usage or parallelization,
but not both. One way or another we need to support such algorithms.</pre>
Repository: go
Issue: math/big: print and parse in different bases
Labels: NeedsInvestigation

<pre>Feature request.

The math/big types Int and Rat do not provide facilities analogous to strconv that allow
printing and parsing numbers in arbitrary bases. This would be nice to have.</pre>
Repository: go
Issue: x/pkgsite: "const" declarations with type on right are not grouped with the type
Labels: NeedsInvestigation

<pre>Run the godoc tool on a file such as <a href="http://play.golang.org/p/fnp9JT3Ki_">http://play.golang.org/p/fnp9JT3Ki_</a>.

The constants with types on the left of &quot;=&quot; are grouped with the type.  The
equivalent constants with types on the right are not.

Since the two styles of declaration produce equivalent constants, they should arguably
also produce equivalent documentation.</pre>
Repository: go
Issue: x/tools/cmd/goimports: Handle ambiguous import properly
Labels: NeedsInvestigation

by **cnyegle**:

<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 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.

Run goimports over this code <a href="http://play.golang.org/p/u_HSZ6xDLX">http://play.golang.org/p/u_HSZ6xDLX</a>

What happened?
goimports suggest me to import &quot;html/template&quot;


What should have happened instead?

goimports should suggest &quot;text/template&quot; as well, or add that in a comment
with FIXME: tag.

Please provide any additional information below.

goimports worked very well in the past, so when I find there's some strange escaped
character in my template.Execute result it took me a long time to figure out the reason.

text/template and html/template have same signature for most if not all functions, so
the compiler didn't complain anything.

I'd suggest when modifying/suggesting the imports, the tool put all possible candidates
in comment with FIXME: tag.</pre>
Repository: go
Issue: html/template: add support for template strings (backticks)
Labels: NeedsDecision,FeatureRequest

by **opennota**:

<pre>ES6 specifies a new language feature called &quot;Template Strings&quot; (often also
referred to as &quot;Quasi Literals&quot; alongside multi-line strings and others). This
allows to execute arbitrary JavaScript code without using parenthesis but
back-ticks instead. Inside back-tick delimited strings, placeholders such as
${} can wrap executable code.

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

If you open the output of the above program in a modern browser (e.g., recently released
Mozilla Firefox 34 supports template strings), it will happily execute alert(1).

References:

<a href="https://people.mozilla.org/~jorendorff/es6-draft.html">https://people.mozilla.org/~jorendorff/es6-draft.html</a>
<a href="https://html5sec.org/#140">https://html5sec.org/#140</a>
<a href="https://html5sec.org/#141">https://html5sec.org/#141</a></pre>
Repository: go
Issue: proposal: sync/v2: prohibit unlocking mutex in a different goroutine
Labels: v2,Proposal

sync.Mutex allows lock/unlock in different goroutines:

<a href="http://golang.org/pkg/sync/#Mutex.Unlock">http://golang.org/pkg/sync/#Mutex.Unlock</a>
&quot;A locked Mutex is not associated with a particular goroutine. It is allowed for
one goroutine to lock a Mutex and then arrange for another goroutine to unlock it.&quot;

And the same for RWMutex:
<a href="http://golang.org/pkg/sync/#RWMutex.Unlock">http://golang.org/pkg/sync/#RWMutex.Unlock</a>

The possibility to unlock the mutex in a different goroutine is very rarely used in real
code. And if you really need something more complex than lock/unlock in a single
goroutine, you can always use channels.

But it creates several problems:
1. Deadlock detection becomes impossible, as there is no notion of &quot;critical
sections&quot;.
2. Similarly static lock annotations becomes impossible for the same reason.
3. Optimizations like hardware lock elision (see e.g. Intel HLE) become impossible.
4. Another potential optimization that becomes impossible is priority boosting inside of critical sections. Namely, if a goroutine is preempted inside of a critical sections, scheduler may give it another tiny time slot to finish the critical section (or perhaps it can then voluntarily switch in Unlock). Solaris did this for a long time.

We should prohibit possibility to unlock in a different goroutine in Go2.
Repository: go
Issue: runtime: reduce StackGuard
Labels: NeedsFix

<pre>We raised it to 512 in the run up to Go 1.4 and I'm raising it to 640 now for
Windows/amd64 + write barriers. I'd like to get it back down to something like 256.</pre>
Repository: go
Issue: x/sys/unix: Seteuid/Setegid for linux
Labels: NeedsInvestigation

by **dustin@criticalstack.com**:

<pre>Missing syscall.Seteuid/Setegid for linux_amd64 and linux_386 syscall packages.</pre>
Repository: rust
Issue: fat-ptr-transmutes lint doesn't work
Labels: A-lints,T-compiler,C-bug

``` rust
#![deny(fat_ptr_transmutes)]

use std::mem;

fn main() {
    let x: [u8, ..8] = [0, ..8];
    let y: [u8, ..16] = unsafe {
        mem::transmute(x.as_slice())
    };
    println!("{}", y.as_slice());
}
```

compiles and runs with no warnings.  The problem is that `trans::intrinsic::check_intrinsics` [calls `Session::add_lint`](https://github.com/rust-lang/rust/blob/master/src/librustc_trans/trans/intrinsic.rs#L125-L132) but the pass that emits these lints has already run.  See [this comment in `rustc::lint`](https://github.com/rust-lang/rust/blob/master/src/librustc/lint/mod.rs#L24-L29).

Please add a test case when fixing this! :)
Repository: nvm
Issue: Modifying a file when .bashrc and .zshrc are present
Labels: shell: zsh,installing nvm: profile detection,pull request wanted

I just switched to zsh so still there's .bashrc and .zshrc present in my ~ . However, it's choosing .bashrc over the one I'm actually using, so I copied it by hand. I know it's a particular problem, but maybe the script could check the current shell and modify whatever file suits it?
Repository: go
Issue: math/big: improve assembly cores: alignment and unrolling
Labels: NeedsInvestigation

Suggestions from Torbjörn Granlund (personal e-mail):

"Aligning:

  Consider aligning loops to at least a 0 mod 16 address.
  Same for function start.

Tail code after unrolling:

  Setting up a loop which runs 0-3 iterations is quite expensive.
  It should be better to follow the pattern:

```
    test $2, Rcount
    je       skip2
    restore CF
    [do two "iterations"]
    save CF
  skip2:
    test $2, Rcount
    je       skip1
    restore CF
    [do one "iteration"]
  skip1:
    [footer]
```

"
Repository: go
Issue: math/big: better multiply primitives
Labels: Performance,NeedsFix

Suggestions from Torbjörn Granlund (personal e-mail):

"
The multiply primitives, in particular addMulVVW surely deserves more
attention:

  Offset the pointers so that you can index with a counter register
  which goes from -n to 0, saving the CMPQ.

  Unroll.  You can save most of the ADCQ $0, R that way.  Basically,
  do one run with just MULQ where you sum the old highpart (DX) with
  the new lowpart (AX).  You will need some MOVQ to move DX
  out-of-the-way too.  Then do a new run over these sums where you
  bring in the memory addend.  This should double the speed on some
  newer CPUs.

  A good addMulVVW is probably really the first thing to write in
  assembly; addition and subtraction is much less important, usually.
"
Repository: go
Issue: x/review/git-codereview: add change -d
Labels: NeedsInvestigation,FeatureRequest

We should have a change -d command that you run at the same time you click Abandon in the web UI. Or maybe it even does the Abandon for you too. It's too hard to back everything out by hand.

@griesemer ran into this with the peano change. @adg
Repository: go
Issue: x/mobile/app: support all-Go app development on windows
Labels: OS-Windows,mobile

The http://golang.org/x/mobile/app package lets you run all-Go apps on desktop darwin and linux with nothing more than the stock Go build. Just `go get` and you're programming. This is done via cgo: we ask for a window, get an OpenGL context, and map mouse events to touch events.

We should do the same for Windows. There are a few complications.

The first is by default there is C compiler for cgo on windows. On both linux and OS X we can rely on the user to install gcc/xcode because the platform makes it easy. By comparison MinGW is an extra, non-obvious step for windows users and VC++ isn't supported (and not necessarily any more obvious).

The second is there is no OpenGL. Well, there is kinda, as provided by graphics card makers, but support in particular for OpenGL ES 2 and EGL is spotty. Luckily, Chrome has this problem too and maintain an open source project implementing ES 2 and EGL for Windows on top of DirectX: https://code.google.com/p/angleproject/

I want to avoid importing angleproject directly into the mobile repository as it has several licenses and I want to keep the notices story for the Go repository simple. So we will need another repository that contains a package that links against angleproject and creates the window.

Is there any way about needing windows users to install a C compiler? Can we ship a binary .dll in a repository that is downloaded with go get? If we do, what about the cgo parts of `mobile/app` and `mobile/gl`? Can they be provided by the .dll even if we fetch it as part of a different repository? For `mobile/app` probably, but `mobile/gl` is harder.
Repository: go
Issue: x/mobile/gl/gles3: OpenGL ES 3 bindings
Labels: mobile

OpenGL ES 3 is a large extension to ES 2, offering a large number of new features. Eventually we should have support for it.

I propose we do so by having a new package that contains the extra enum values and functions, which can be used in conjunction with the existing gl package.

This is a very low priority item as ES 3 is not currently usable on Android. 72% of devices only support ES 2, so all software today must first target ES 2 and only use ES 3 as an optional extension.

http://developer.android.com/about/dashboards/index.html#OpenGL