sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Lint for types where cleanup before drop is desirable
Labels: T-lang,T-compiler,C-feature-request

`BufWriter.drop` is broken.

`BufWriter` flushes data on `drop` and ignores the result. It is incorrect for two reasons:
- you must not ignore write errors. For example, when filesystem is full, write fails. Currently last write error is quietly ignored. This code demonstrates the problem: http://is.gd/ZdgbF9
- `drop` may indefinitly hang, for example, if `BufWrtiter` underlying stream is socket, and nobody reads on the other side

Generally, I think any `drop` must only release resources, do not do anything blocking or failing.

The similar issue was only partially fixed in #30888.

We (together with @cfallin) propose a solution:
## Proposed solution

Add another function to `BufWriter` (and probably to `Write` trait): `cancel`. User of `BufWriter` _must_ explicitly call either `flush` or `cancel` prior to drop.

`struct BufWriter` gets `unfinished` flag instead of `panicked`.

`BufWriter.write` unconditionally sets `unfinished = true`.

`BufWriter.flush` or `BufWriter.cancel` unconditionally set `unfinished = false`.

And finally, `BufWriter.drop` becomes an assertion:

```
impl Drop for BufWriter {
    fn drop(&mut self) {
        // check `flush` or `cancel` is explicitly called
        // but it is OK to discard buffer on panic
        assert!(!self.unfinished || std::thread::panicking());
    }
}
```

That change is backward incompatible, however, it is not _that_ bad: developer will likely get panic on first program run, and can quickly fix the code.

Change could be transitional: no-op `cancel` function could be added in rust version current+1 and assertion added in rust version current+2.
Repository: rust
Issue: Intern strings in metadata
Labels: C-enhancement,A-metadata,T-compiler

The lack of string interning causes the metadata for rlibs to massively bloat. `libwinapi.rlib` for example takes up 54MB, which is mostly due to strings being repeated needlessly, and exacerbated by the sheer length of many of the identifiers. Simple greps of the file indicate basically all identifiers being repeated multiple times. Even something as simple as a constant that is never referenced has its name repeated at least 3 times. Interning strings would have massive space savings.

cc @eddyb who helped in figuring this out.
Repository: go
Issue: x/exp/shiny/driver/x11driver: runtime error on centos-7
Labels: help wanted,NeedsFix

Please answer these questions before submitting your issue. Thanks!
1. What version of Go are you using (`go version`)?

``` sh
$> go version
go version go1.6 linux/amd64
```
1. What operating system and processor architecture are you using (`go env`)?

``` sh
$> go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
```
1. What did you do?

``` sh
$> go get -t -u golang.org/x/exp/shiny/...
$> cd $GOPATH/src/golang/x/exp/shiny/example/basic
$> go build main.go
$> ./main
```
1. What did you expect to see?
   a window with 3 rounded squares.
2. What did you see instead?

an empty window (with whatever was displayed behind that window, captured into that window but not refreshed) and the following error:

``` sh
$> ./main
2016/04/04 13:47:06 x11driver: xproto.WaitForEvent: BadAccess {NiceName: Access, Sequence: 17, BadValue: 92274692, MinorOpcode: 1, MajorOpcode: 130}
2016/04/04 13:47:06 x11driver: xproto.WaitForEvent: BadBadSeg {NiceName: BadSeg, Sequence: 21, BadValue: 92274691, MinorOpcode: 3, MajorOpcode: 130}
```

The "interesting" thing is that the [pointer-painting](https://github.com/BurntSushi/xgbutil/blob/master/_examples/pointer-painting/main.go) example from `xgbutil` works correctly.
So it presumably is some configuration issue on the `x11driver` end.
(I tried replacing `xgb.NewConn()` with `xgbutil.NewConn()` and adapt a bit, to no avail)
Repository: go
Issue: os/exec: don't use a thread to wait on processes
Labels: Performance

See https://github.com/docker/docker/issues/11529

There's no reasons why Docker should have to work around the standard library to reduce their thread count with large numbers of processes.

We could make `os/exec.Cmd.Wait` efficient instead.

/cc @ianlancetaylor
Repository: go
Issue: cmd/compile: combine AND 0xff and MOVQload into MOVBQZXload
Labels: Performance,compiler/runtime

I noticed that for uint&0xFF go tip on amd64 generates e.g.:

0x001d 00029 (main.go:10)   MOVQ    "".u+8(FP), DX
0x0022 00034 (main.go:10)   ANDQ    $255, DX

http://play.golang.org/p/CKhi_nt615

It might be possible to make these a zero latency MOV that does not require an ALU by using MOVZX for the applicable AND values or it might be possible to change the previous load to be MOVZX.

0x0022 00034 (main.go:10)   MOVBQZX DL, DX

See "Intel 64 and IA-32 Architectures Optimization Reference Manual" Section: "3.5.1.13     Zero-Latency MOV Instructions"
Repository: go
Issue: cmd/compile: make available as a library
Labels: NeedsDecision

It would be nice if there was an interface to the gc. I had extreme difficulty reading through the source code (maybe due to the fact it was transpiled from C), but I've come to the conclusion that it is pretty unrealistic to use the gc for anything, barring use of the go tool. How difficult would it be to give it an API and/or add it to the stdlib?
Repository: go
Issue: runtime: 40us pause in file-backed serve loops
Labels: Performance,compiler/runtime

Summary: An idiomatic serve loop that reads from a file (as opposed to a socket) pauses for 40us before the request goroutine starts. We isolated this from a FUSE filesystem into a small benchmark.

The idiomatic serve loop (Cf. [src/net/http/server.go Serve](https://golang.org/src/net/http/server.go#L2116) and [bazil.org/fuse/fs/serve.go Serve](https://github.com/bazil/fuse/blob/master/fs/serve.go#L383)) processes a request on a new goroutine:

```
for {
  req := accept()
  go process(req)
}
```

We compared it against a no-concurrency serial server:

```
for { 
  req := accept()
  process(req)
}
```

We measured the overhead (from the end of accept() to beginning of process()). Median of 100k runs for each strategy:
Serial: 441ns
Goroutine: 38us

For context, we've found the rest of our logic can run in ~10us, so the go scheduling overhead would be 400%

We tried a channel:

```
go func() {
  for {
    process(<-ch)
  }
}
for {
  req := accept()
  ch <- req
}
```

Which is comparable to a Goroutine:
Serial: 441ns
Goroutine: 38us
Channel: 40us

Most servers read/accept from a socket, which the Go runtime implements using polling via the netpoller. FUSE reads from a file, which uses a blocking syscall. AIUI, the Go runtime will let the thread make the syscall, and then another thread of the runtime will notice it's blocked after ~20 us, and then reschedule work. These numbers seem similar which makes me think they're related.

Our workaround: service one process (both accept and process) on one goroutine and hand off the next request to a new goroutine. Strategy "handoff" looks like:

```
func serve() {
  req := accept()
  go serve()
  process(req)
}
```

Serial: 441ns
Goroutine: 38us
Channel: 40us
Handoff: 671ns

I'm seeing this on Go version 1.6 darwin/amd64

Is this a known issue? Does it affect other platforms? Is our rewriting of the serve loop a known workaround?

Our full benchmark: http://play.golang.org/p/wc6hPnN778

Build it into a binary fileping. To run:
rm a b; mkfifo a; mkfifo b; ./bin/fileping -print -strategy handoff < b > a&  ./bin/fileping -strategy serial < a > b&  echo 000000000000000 > a

(Modify the -strategy argument in the first command to try different strategies)
Repository: go
Issue: cmd/compile: possible inlining bug with variable renaming?
Labels: compiler/runtime

A reminder for myself to investigate variable renaming for inlining. See #4326 for a test case where variable numbering is used to prevent name collisions when inlining.

Specifically, is it not possible that two different functions, when inlined, collide when variables and numbers are equal? Try to create test case.
Repository: neovim
Issue: show better error message if we don't have permissions to swap/, undo/, etc.
Labels: ux

- Neovim version: 0.1.3-dev
- Operating system: Ubuntu 15.10
- Terminal emulator: zsh
### Actual behaviour

On a fresh new install the message `Unable to open swap file for "filename", recovery impossible` always show when opening any file. 
### Expected behaviour

This shouldn't be the standard behavior on a fresh new install. 
### Steps to reproduce

On a fresh new Ubuntu:
- install neovim
- open file
- observe
Repository: opencv
Issue: ORB_GPU generates random features on each run
Labels: bug,affected: 2.4,category: gpu/cuda (contrib)

Apologies if the following is insufficient, hopefully it describes the problem adequately.
- OpenCV version: 2.4.11
- Host OS: Windows 7
### In which part of the OpenCV library you got the issue?

Examples:
- cuda, features2d
- object tracking
### Expected behaviour

feature detecting should generate the same features on each run
### Actual behaviour

random features are detected, when you run the CPU implementation it generates the same features on each run
### Additional description

I've observed that when running the ORB_GPU to detect features that it will generate random features on each run on the same image, this doesn't happen when you run the CPU implementation version. I don't see any changes to the OpenCV 3 source code for orb.cpp so it doesn't look like this has been resolved.
### Code example to reproduce the issue / Steps to reproduce the issue

```
#include "opencv2/core.hpp"
#include "opencv2/features2d/features2d.hpp"
#include "opencv2/imgproc/imgproc.hpp"
#include "opencv2/calib3d/calib3d.hpp"
#include "opencv2/gpu/gpu.hpp"

using namespace std;
using namespace cv;

int main( int argc, char** argv )
{
  if( argc != 3 )
  { readme(); return -1; }

  Mat img_1 = imread( argv[1], CV_LOAD_IMAGE_GRAYSCALE );
  GpuMat gpuImg, mask;
  gpuImg.upload(img_1);

  if( !img_1.data || !img_2.data )
  { std::cout<< " --(!) Error reading images " << std::endl; return -1; }

  //-- Step 1: Detect the keypoints using ORB_GPU Detector
  cv::gpu ORB_GPU detector;

  std::vector<KeyPoint> keypoints_1, keypoints_2;

  detector( gpuImg, mask, keypoints_1 );
  detector( gpuImg, mask, keypoints_2 );

  Mat img_keypoints_1; Mat img_keypoints_2;

  drawKeypoints( img_1, keypoints_1, img_keypoints_1, Scalar::all(-1), DrawMatchesFlags::DEFAULT );
  drawKeypoints( img_1, keypoints_2, img_keypoints_2, Scalar::all(-1), DrawMatchesFlags::DEFAULT );

  //-- Show detected (drawn) keypoints
  imshow("Keypoints 1", img_keypoints_1 );
  imshow("Keypoints 2", img_keypoints_2 );

  waitKey(0);

  return 0;
}

/**
 * @function readme
 */
void readme()
{ std::cout << " Usage: ./SURF_detector <img1> <img2>" << std::endl; }
```
Repository: kubernetes
Issue: Support port ranges or whole IPs in services
Labels: priority/backlog,sig/network,area/kube-proxy,kind/feature,lifecycle/rotten

There are several applications like SIP apps or RTP which needs a lot of ports to run multiple calls or media streams. Currently there is no way to allow a range in ports in spec. So essentially I have to do this:

```
          - name: sip-udp5060
            containerPort: 5060
            protocol: UDP
          - name: sip-udp5061
            containerPort: 5061
            protocol: UDP
```

Doing above for 500 ports is not pretty. Can we have a way to allow port ranges like 5060-5160?
Repository: go
Issue: git-codereview: allow git change <hash>
Labels: NeedsInvestigation

git mail <hash> allows one to specify which of a set of CLs to mail, but git change has no such ability. When one stacks CLs in a single branch, as I do often, it's nice to be able to manage them individually.

git rebase-work provides this functionality but it seems like there's an asymmetry between mail and change that could be fixed.
Repository: vscode
Issue: [rtl] Add Right-to-Left editing
Labels: feature-request,editor-core,editor-RTL

Please add a feature to change writing direction.
For example, I want to edit markdown documents, and my language is Persian/Farsi, a Right-to-Left language. Now, when I edit documents, always it is left aligned and direction is left-to-right, and it is not comfortable to edit documents that have both Persian text and English text. 

Thanks.
Repository: nvm
Issue: Prevent of patching `$PROFILE`
Labels: feature requests,installing nvm: profile detection

Let's use unix way with `$HOME/.profile.d` directory for requiring shell scripts without dirty hacks with `~/.profile`. I've realised basic patcher [profile_patcher](https://github.com/rumkin/profile_patcher) to do so.
Repository: opencv
Issue: Camera is not being released. camera.release() not working
Labels: bug,affected: 2.4,category: videoio(camera)

### Please state the information for your system
- OpenCV version: 2.4.10
- Host OS: Linux (Ubuntu 14.04)  
### In which part of the OpenCV library you got the issue?
- Camera capture and releasing
### Expected behaviour

I have a program that have two "programs" inside, in each one of them the camera will be open, but from a different class. When the first class close it supposed to release the camera. I have an camera.release() there, but it's not working.
### Actual behaviour

The camera keep on, the light, and it's not being released, when i try to access it from the other "program" it gives

> HIGHGUI ERROR: V4L2: Pixel format of incoming image is unsupported by OpenCV
> VIDIOC_STREAMON: Bad file descriptor
> OpenCV Error: Assertion failed (size.width>0 && size.height>0) in imshow, file /home/schirrel/Github/opencv/opencv-2.4.10/modules/highgui/src/window.cpp, line 261
> terminate called after throwing an instance of 'cv::Exception'
>   what():  /home/schirrel/Github/opencv/opencv-2.4.10/modules/highgui/src/window.cpp:261: error: (-215) size.width>0 && size.height>0 in function imshow
### Code

```
while (!janela->FINALIZADA || !FIM) {
            camera >> frame;
....
....
...
if (key == 99) {
                 cv::destroyAllWindows();
                camera.release();
                break;
            }
}
```
Repository: nvm
Issue: install nightly?
Labels: installing node,feature requests

Would it be possible to install nightly versions via nvm?
Different folder.  Good news is that they have a file listing that seems to be sorted newest on top:
https://nodejs.org/download/nightly/index.tab
Repository: TypeScript
Issue: Is there a MSBuild parameter that tells VS which `tsconfig.json` to use?
Labels: Bug,Visual Studio

I have 2 tsconfig.json files:
- tsconfig.full.json
- tsconfig.quick.json

I want to be able to point the VS2015 to either one of them accorting to the configuration parameters in `*.targets` files. How can I do it?
Repository: go
Issue: cmd/compile: suboptimal compilation of struct-valued switch statements
Labels: Performance,compiler/runtime

For [CL 21627](https://golang.org/cl/21627), I evaluated replacing the switch statement in cmd/link/internal/ld.relSize with:

```
type ft struct {
    af sys.ArchFamily
    et byte
}

switch (ft{SysArch.Family, byte(elftype)}) {
    ...
    case ft{sys.S390X, R_390_8}:
        ...
}
```

But this ends up compiling into much less efficient code than the existing idiom of combining into integer constants:
1. The integer constant cases are implemented as a binary search; the struct cases are implemented as linear search.
2. The struct temporary variables are constructed on the stack using _three_ MOVB instructions (even though they're only two bytes large; one of the MOVBs is a useless 0-initialization).
3. Both the switch and case statement's temporary struct variable needs to be loaded from memory each time, even though the switch variable ends up staying register-resident the entire time.
4. Each case statement's temporary variable is independently allocated stack memory, even though their lifetimes don't overlap.
Repository: go
Issue: runtime: current heapdump format is undocumented
Labels: Documentation,NeedsFix,compiler/runtime

runtime/debug.WriteHeapDump's godocs link to https://golang.org/s/go15heapdump, but that describes a file format that starts with "go1.5 heap dump\n".

Currently, runtime.dumphdr is "go1.7 heap dump\n".  Before 30f93f09, it was "go1.6 heap dump\n".  So that's at least two revisions to the heap dump file format that are undocumented.

Relevant because https://go-review.googlesource.com/#/c/21647/1 might change the heap dump format again.

/cc @crawshaw
Repository: react
Issue: Support Passive Event Listeners
Labels: Type: Feature Request,Component: DOM,Type: Big Picture,React Core Team

https://github.com/WICG/EventListenerOptions/blob/gh-pages/explainer.md

It would be good to have everything be passive by default and only opt-in to active when needed. E.g. you could listen to text input events but only preventDefault or used controlled behavior when you have active listeners.

Similarly, we could unify this with React Native's threading model. E.g. one thing we could do there is synchronously block the UI thread when there are active listeners such as handling keystrokes.

cc @vjeux @ide
Repository: go
Issue: x/exp/shiny/driver/x11driver: implement back buffer
Labels: help wanted,NeedsFix

Please answer these questions before submitting your issue. Thanks!
1. What version of Go are you using (`go version`)?

1.6
1. What operating system and processor architecture are you using (`go env`)?

```
$ go env 
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/eaburns"
GORACE=""
GOROOT="/home/eaburns/src/go.googlesource.com/go"
GOTOOLDIR="/home/eaburns/src/go.googlesource.com/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"
```
1. What did you do?

Use shiny x11driver
1. What did you expect to see?

Double buffering.
1. What did you see instead?

No double buffering.
Repository: electron
Issue: Working with GIFs in the clipboard / NativeImage
Labels: enhancement :sparkles:,component/clipboard

I'm trying to read a GIF from the clipboard and write it to a file. However only the first frame of the GIF is actually used. I assume this is because NativeImage only supports PNG/JPG so far.
Is there currently any way to work around this issue with GIFs?
Repository: rust
Issue: Add an "inherits" key or similar to JSON target specs
Labels: C-feature-request,A-target-specs

Looking at #32818, most of the target spec used there  is just copying the existing `i686-pc-windows-msvc` target settings. This seems a little unnecessary, especially if we add to the options in the spec. A key in the JSON that indicates an existing target to use as a base seems like it would be useful.

Potential names:
- "inherits"
- "extends"
- "base"
Repository: go
Issue: crypto/x509: support DirectoryName name constraints
Labels: NeedsDecision,FeatureRequest

I would like to request for the adoption of change [3230 ](https://go-review.googlesource.com/#/c/3230/)which is in code review for a long time.

> This change extents the Name Constraint properties by adding the Excluded property for DNSDomains and both the permitted and excluded properties for EmailDomains, IPAddresses and DirectoryNames as specified for the GeneralName property in RFC5280.
> 
> The selected properties are required to create or validate a fully constrained certificate.
> 
> The change also improves the validation of Name Constraints in general and allows the parsing of certificates that have Name Constraints marked as cirtial.

https://go-review.googlesource.com/#/c/3230/ 

Change-Id: Idaa7abafec372d5eb444cad7ee2ea5794aee3424

To be able to validate all certificates issued according to the CA / Browser Forum Baseline Requirements the full set of name constraints need to be available in GO.

A recent version of the CA / Browser Forum Baseline Requirements states that Technical Constraints in Subordinate CA Certificates MUST be applied via Name Constraints. To support strong and strict certificate path validation and to allow users to see the actual constraints it's important that GO supports the required Name Constraints.

Section 9.7 of the baseline requirements states:

> "If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on dNSName, iPAddress and DirectoryName as follows:-"

The full requirements can be found on: https://cabforum.org/baseline-requirements-documents/

The DirectoryName is also needed in some Microsoft environments. Forbidding all directory names would enforce domain validated certificates even if all certificates under a specific root are used and issued by the same organisation. Or could enforce all certificates to be issued with the same OV certificate details. Email addresses are not specifically handled by the CABForum because they don't cover client auth or s/mime certificates currently but likely to have the same requirements and make the set of constraints supported complete.
Repository: go
Issue: x/crypto/ssh: TestClientUnsupportedKex : use of close network connection on FreeBSD. 
Labels: NeedsInvestigation

I noticed these failing ssh tests on a freebsd-amd64 trybot:

https://storage.googleapis.com/go-build-log/01360a64/freebsd-amd64-gce101_5e66e373.log

```
--- FAIL: TestClientAuthPublicKey (0.00s)
    client_auth_test.go:97: unable to dial remote side: ssh: handshake failed: ssh: unexpected message type 21 (expected 6)
--- FAIL: TestClientUnsupportedKex (0.00s)
    client_auth_test.go:256: got ssh: handshake failed: write tcp 127.0.0.1:30006->127.0.0.1:63686: use of closed network connection, expected 'common algorithm'
FAIL
FAIL    golang.org/x/crypto/ssh 1.024s
```
Repository: TypeScript
Issue: Flag for strict default function `this` types for call-site and assignability checking (`--strictThis`)
Labels: Suggestion,Awaiting More Feedback,Add a Flag

#6018 was originally going to add a `--strictThis` flag that made function `this` types default to `void` or the enclosing class (instead of `any`) for purposes of call-site and assignability checking, but that functionality was dropped ([details](https://github.com/Microsoft/TypeScript/issues/6018#issuecomment-207479337)).  This is a follow-up suggestion for the dropped functionality, whatever the flag ends up being named.
Repository: neovim
Issue: Empty undo file after system crash
Labels: robustness,bug-vim,io,system

- Neovim version: v0.1.3-361-g5730ad9
- Vim behaves differently? No
- Operating system/version: Arch Linux

I've had my machine lock up hard while using Neovim (mouse could not be moved, SSHing did not work etc), and after restarting, an undo file for a rather important file was empty?!

> E823: Not an undo file: /home/user/.local/share/vim/undo/...

The file itself is empty (0 bytes).

The file system is ext4.

I could imagine that the behavior here could be improved by not re-writing the undofile, but `mv`ing it instead?  (similar to `backupcopy`?!)

Relevant options I have set: `fsync` (default), `backup` (default), `backupcopy=yes` (default).
Repository: rust
Issue: Pluggable panic implementations (tracking issue for RFC 1513)
Labels: P-low,T-lang,T-libs-api,B-unstable,B-RFC-implemented,C-tracking-issue,A-error-handling,Libs-Tracked,S-tracking-perma-unstable

Tracking issue for rust-lang/rfcs#1513.

`-C panic=abort` is now stable, but the ability to create customized panic implementations is still unstable.