sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/cgo: permits reference to non-existent struct
Labels: NeedsFix,compiler/runtime

This code compiles and runs:

    package main

    import "C"

    import "fmt"

    var V C.struct_X

    func main() {
            fmt.Println(V)
    }

It prints `{}`.  That makes no sense.  There is no type `X` here.  It should give an error somewhere.
Repository: vscode
Issue: Feature request: highlight problem indicator with color when problems exist
Labels: feature-request,ux,themes,error-list

<!-- Do you have a question? Please ask it on http://stackoverflow.com/questions/tagged/vscode -->

- VSCode Version: 1.10.2
- OS Version: Windows 7 SP 1 & Windows 10

For a better callout (those icons aren't very noticeable normally), it would be nice if when there are errors or warnings detected, it highlighted the respective icon (yellow for warning, red for error).
Repository: opencv
Issue: Feature Request: Set normal and up vector for WText3D
Labels: feature,category: viz

##### System information (version)
- OpenCV => latest
- Operating System / Platform => Ubuntu 16.04
- Compiler => GCC 5.4

##### Detailed description

Currently when using [WText3D](http://docs.opencv.org/3.1.0/d6/d3d/classcv_1_1viz_1_1WText3D.html) only the position and text_scale can be set, I want to control the normal and upvector just like [WPlane](http://docs.opencv.org/3.1.0/d8/d01/classcv_1_1viz_1_1WPlane.html), but I can't do it so I am unable to orient the text in the right direction I like. Can we have this function added? Isn't WText3D just kinda like WPlane with a built in alpha channel?
Repository: go
Issue: x/net/xsrftoken: move away from SHA-1
Labels: NeedsFix

SHA-1 is not considered secure any more.
Repository: go
Issue: cmd/vet: -shadow false positive
Labels: NeedsFix,Analysis

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
```
go version go1.7.1 darwin/amd64
```

A sample code:
```go
package main

import (
	"fmt"

	"github.com/pkg/errors"
)

func main() {
	var err error

	defer func() {
		// Rear the mistake here is just a local error in processing logic, does not belong to the end to unified handling errors
		if err := errors.New(""); err != nil {
			fmt.Println(err)
		}

		// Business logic mistakes need to deal with here
		fmt.Println(err)
	}()

	if err = errors.New(""); err != nil {
		return
	}

	if err = errors.New(""); err != nil {
		return
	}

}
```

Run the command `go tool vet -shadow *.go` to get :
```
sample.go:14: declaration of "err" shadows declaration at sample.go:10
``` 

I think there is no question of such code, in the main function in the defer if caused by using the local err statement.
Repository: vscode
Issue: Alt + Numpad keybindings insert characters into editor
Labels: feature-request,keybindings,windows

- VSCode Version: Code 1.10.2 (8076a19fdcab7e1fc1707952d652f0bb6c6db331, 2017-03-08T14:02:52.799Z)
- OS Version: Windows_NT ia32 10.0.14393
- Extensions: 

|Extension|Author|Version|
|---|---|---|
|plantuml|jebbs|1.2.5|
|cpptools|ms-vscode|0.10.2|
|debugger-for-chrome|msjsdiag|2.6.0|
|language-vscode-javascript-angular2|nwallace|0.0.11|
|language-plantuml|qhoekman|0.0.3|
|nativescript|Telerik|0.6.1|;

---

Old schoold people like me, still want the numlock key disabled. This means that "ALT + arrows" (and using the arrows on the numpad of a desktop keyboard) results in inserting an ascii code instead in addition to the keyboard shortcut defined in VSCode.


Steps to Reproduce:

1. Open the editor with some text separated by newlines
2. ALT + Up arrow and ALT + Down arrow move the lines up and down
3. Now turn off the numlock on the keyboard
4. repeat the step at point (2):
   ALT + Up Arrow (on the numpad) lead to inserting the character ◘
   ALT + Down Arrow (on the numpad) lead to inserting the character ☻

I expect the behavior is consistent with Visual Studio where ascii characted are never injected on these keyboard combinations.

Thanks
Repository: opencv
Issue: CvVideoCamera : repeatedly stop cause app crash
Labels: bug,priority: low,category: videoio(camera),platform: ios/osx

**System information (version)**

OpenCV => 3.2.0
Operating System / Platform => macOS 10.12.12
Compiler => Xcode Version 8.2.1 (8C1002)

**Detailed description**

iOS 10 using CvVideoCamera, when repeatedly start/stop it crashes

**Steps to reproduce**

```objc
- (void) initializeCamera {
  self->videoCamera = [[CvVideoCamera alloc] initWithParentView:cameraView];
  self->videoCamera.delegate = self;
  self->videoCamera.defaultAVCaptureDevicePosition = AVCaptureDevicePositionBack;
  self->videoCamera.defaultAVCaptureSessionPreset = AVCaptureSessionPresetHigh;
  videoCamera.useAVCaptureVideoPreviewLayer = true;
  videoCamera.defaultAVCaptureVideoOrientation = AVCaptureVideoOrientationPortrait;
  videoCamera.videoCaptureConnection.videoOrientation = AVCaptureVideoOrientationPortrait;
  videoCamera.captureVideoPreviewLayer.connection.videoOrientation = AVCaptureVideoOrientationPortrait;
  self->videoCamera.defaultFPS = 24;
}

- (void)startCamera {
  [self initializeCamera];
  [self->videoCamera start];
  self->stillImageOutput = [AVCaptureStillImageOutput new];
  [self->videoCamera.captureSession addOutput:stillImageOutput];
}

- (void)stopCamera {
  [self->videoCamera stop];
  videoCamera = nil;
  stillImageOutput = nil;
}
```

**Logs**

```
*** -[AVCaptureSession addInput:] Can't add a nil AVCaptureInput{
0   CoreFoundation        __exceptionPreprocess + 124
1   libobjc.A.dylib       objc_exception_throw + 56
2   AVFoundation          -[AVCaptureSession addInput:] + 964
3   Tessa α               (null)
4   Tessa α               (null)
5   Tessa α               (null)
6   Tessa α               (null)
7   Tessa α               (null)
8   Tessa α               (null)
9   Tessa α               (null)
10  Tessa α               (null)
11  UIKit                 -[UIViewController _setViewAppearState:isAnimating:] + 624
12  UIKit                 -[UIViewController __viewWillAppear:] + 156
13  UIKit                 __56-[UIPresentationController runTransitionForCurrentState]_block_invoke + 1096
14  UIKit                 _runAfterCACommitDeferredBlocks + 292
15  UIKit                 _cleanUpAfterCAFlushAndRunDeferredBlocks + 560
16  UIKit                 _afterCACommitHandler + 168
17  CoreFoundation        __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
18  CoreFoundation        __CFRunLoopDoObservers + 372
19  CoreFoundation        __CFRunLoopRun + 1024
20  CoreFoundation        CFRunLoopRunSpecific + 444
21  GraphicsServices      GSEventRunModal + 180
22  UIKit                 -[UIApplication _run] + 684
23  UIKit                 UIApplicationMain + 208
24  Tessa α               (null)
25  libdyld.dylib         start + 4
}
```
Repository: TypeScript
Issue: JSDoc comment nodes are not traversed and their parents are sent even if they should not
Labels: Bug,Help Wanted,API

<!-- BUGS: Please use this template. -->
<!-- QUESTIONS: This is not a general support forum! Ask Qs at http://stackoverflow.com/questions/tagged/typescript -->
<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

**TypeScript Version:**  2.2.1

**Code**

```ts
const ts = require('typescript');

const source = `
/**
 * Some fancy comment
 * 
 * @function sum
 * @param {number} a
 * @param {number} b
 * @returns {number} 
 */
function sum(a: number, b: number): number {
  return a + b;
}
`;

let sourceFile = ts.createSourceFile(
  'input.ts',
  source,
  ts.ScriptTarget.ESNext,
  false // <-- don't set parents
);

ts.forEachChild(sourceFile, function (node) {
  if (node.kind === ts.SyntaxKind.FunctionDeclaration) {
    console.assert(!!node.jsDoc);
    console.assert(node.jsDoc.length === 1);
    console.assert(node.jsDoc[0].parent === undefined);
  } else if (node.kind === ts.SyntaxKind.JSDocComment) {
    console.assert(false);
  }
});
```

**Expected behavior:**

* Expected `JSDocComment` nodes parents not to be set.
* Expected `JSDocComment` nodes to be traversed using `forEachChild`.

**Actual behavior:**

When explicitly passing `false` to `createSourceFile` for not setting parents in nodes, they are set anyway in all `JSDocComment` nodes. Also, `JSDocComments` (and therefore all their children) are not traversed when calling `forEachChild`. I don't know if that last part is expected behavior, but it is definitely weird that they are not traversed.
Repository: electron
Issue: Subclass of native classes (re-consider or update docs)
Labels: discussion,component/BrowserWindow

I've just discovered that `BrowserWindow` and other native classes of Electron shouldn't be sub-classed, @zcbenz has provided an explanation for this choice in 2013 here: https://github.com/electron/electron/issues/23.

I am wondering if this can be reconsidered since it has been decided when ES2015 wasn't around, and that V8 has changed a lot since (I don't know if it's now possible). Today, it's very natural to write:
```javascript
class MyBrowserWindow extends BrowserWindow {
  constructor (options){
    super(options)
    // Do stuff
  }
}
const myBrowserWindowInstance = new MyBrowserWindow({ height:600; width: 800 })
```

In my case, I am currently sub-classing `BrowserWindow` with no found caveats since Electron 1.4.x, except when using methods that check the equality of `myBrowserWindowInstance.constructor` with `BrowserWindow` (for example in `Menu` and `dialog` methods, see here https://github.com/electron/electron/issues/8895).

**If this is definitely a won't fix, the documentation should specify that native classes of Electron shouldn't be sub-classed.**
Repository: go
Issue: misc/trace: events disappear at high zoom
Labels: help wanted,NeedsFix

### What version of Go are you using (`go version`)?
go version go1.8 linux/amd64

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/austin/r/go"
GORACE=""
GOROOT="/home/austin/.cache/gover/1.8"
GOTOOLDIR="/home/austin/.cache/gover/1.8/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build085760083=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
```

### What did you do?
Use `go tool trace` on the trace from https://github.com/golang/go/issues/19378#issuecomment-284020538. Zoom in around timestamp 208,125 ms.


### What did you expect to see?

All of the events in the visible time window, regardless of zoom.


### What did you see instead?

When the zoom gets close enough to show a few milliseconds on the screen (it happens around 8 ms for me), the sweep events on proc 0 start to flicker, shift around, and disappear. If you keep zooming in, several of them will disappear entirely. You can tell that they should be there by clicking on one of the events that's still visible, pressing left or right a few times to navigate to a neighboring event, and then pressing 'm' to mark the duration of the selected event. If you're on one of the invisible events, it will highlight a range that appears to have nothing in it.

Zoomed close but not too close:
![screenshot from 2017-03-10 12 15 57](https://cloud.githubusercontent.com/assets/2688315/23805312/615f32e8-058b-11e7-9682-5c17aaa81d5f.png)

Zoomed very slightly closer:
![screenshot from 2017-03-10 12 16 43](https://cloud.githubusercontent.com/assets/2688315/23805331/75fb07a4-058b-11e7-833f-bab7c2008dbd.png)

/cc @dvyukov
Repository: go
Issue: runtime: measure actual CPU time of GC
Labels: compiler/runtime

Currently, the CPU time we report for GC in the gctrace is based on the assumption that each GC worker actually gets the CPU for the full wall-clock duration it runs for. This is a bad assumption on over-subscribed systems. We've seen this internally when users set GOMAXPROCS too high or have other processes in the same cgroup that consume too much CPU and the cgroup throttles execution. This may also be relevant to #19378.

We should consider asking the OS for actual CPU consumed by GC and reporting that. Comparing this with wall-clock time in the gctrace will give both us and users a better sense of any environmental problems causing long GC phases.

We should also consider how GC pacing would be affected by measuring actual CPU time versus wall-clock CPU time.

/cc @RLH
Repository: kubernetes
Issue: Pod cgroup sandbox should be cleaned up in the pod worker
Labels: priority/important-soon,kind/cleanup,sig/node,lifecycle/frozen

Cleaning up the pod cgroup in the pod worker is more efficient than relying on the periodic cleanup routine (`HandlePodCleanup`). 
This would also allow removing the extra condition (see https://github.com/kubernetes/kubernetes/pull/42585/files#r105076567) that may cause even more races . 

Ref: #42893

/cc @derekwaynecarr @dashpole @Random-Liu @dchen1107
Repository: three.js
Issue: Memory pool for RenderTargets to help with complex EffectComposer pipelines
Labels: Enhancement,Post-processing

##### Description of the problem 

I have a lot of effects on my ThreeJS scenes.  Right now with the way ThreeJS's effects are designed, they each allocate their own render targets, even their intermediate/temporary render targets.  This leads to somewhere around 50 render targets allocated for my specific use case.  But really only a couple are ever used at the same time, the rest are just setting there wasting memory and causing out of memory errors are various devices, especially high resolution (QHD/4K) + low memory mobile devices.

I am thinking that if we create a memory pool ( https://en.wikipedia.org/wiki/Memory_pool ) for RenderTargets we could decrease the maximum amount of memory required for complex EffectComposer pipelines without sacrificing speed or quality.

The design would be something like:

RenderTargetPool:
  allocate( width, height, options ) -> renderTarget;
  free( renderTarget )
  nextFrame() - increase current frame.
  disposeOld( oldness ) - to dispose all targets not recently used (could be all)
  disposeAll() -- to be called once done or in the case of a resize (see below.)

This memory pool would track which render targets are currently in use (which haven't been returned) and allocate new ones if needed.  But it would try to recycle as much as possible.  I'd keep it simple and track the current frame and allow explicit disposal of those render targets that haven't been used in a recent frame (specified by the user - but I think a value of 10 is pretty reasonable for most use cases) or all current render targets (if ending the rendering.)

This will automatically minimally allocate render targets.

I guess the only issue is how to handle resizes.  Right now ThreeJS will resize render targets when the render region changes shape.  I wonder if we adopt the RenderTargetPool we could just dispose all in that case and recreate render targets of the new size -- I think that is how it works underneath anyhow.

Only intermediate render targets can be used via the pool.  Those that persist such those that back up textures attached to objects need to have explicitly controlled lifetimes.

Thoughts welcome.... this is just an idea on how to solve our issue while making Three.JS easier and more efficient.

##### Three.js version

- [x] Dev
- [x] r84

##### Browser

- [x] All of them

##### OS

- [x] All of them
Repository: kubernetes
Issue: Proposal: versioned DaemonSet
Labels: kind/feature,sig/apps,area/workload-api/daemonset,lifecycle/frozen

Pod running as a Daemon Set is usually responsible for some operations on the node. With new releases of node components the environment for those operations can happen. Since usually DS is updated together with the master node and we are committed to support a few past versions of nodes due to backward compatibility it would be great to have a support to run different versions of the agent for different versions of the node.

For example I'd like to run fluentd in the following way:
- version 1.25 on nodes in version 1.4.x
- version 1.28 on nodes in version 1.5.x
- version 2.0 on nodes in version 1.6.x

Currently this can be done by creating 3 Daemon Sets separately which targets different node versions (though it's not obvious how do it, see #42840). This also generates additional maintenance overhead and general confusion (why do I need a DS for version 1.5.x while I don't have any nodes in this version).

The issue could be addressed by introducing an abstraction on top of DaemonSet which will manage daemon sets underneath in a similar manner that currently Deployment manages a set of ReplicaSets.

@bgrant0607 @erictune @janetkuo @kubernetes/sig-apps-feature-requests 
cc @fgrzadkowski @crassirostris
Repository: TypeScript
Issue: Way to Go From Method Implementation to Interface Method Declaration
Labels: Suggestion,Awaiting More Feedback,VS Code Tracked,Domain: Symbol Navigation

<!-- BUGS: Please use this template. -->
<!-- QUESTIONS: This is not a general support forum! Ask Qs at http://stackoverflow.com/questions/tagged/typescript -->
<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

From https://github.com/Microsoft/vscode/issues/22385

**TypeScript Version:**  2.2.1

**Code**

```ts
interface ITest {
    test(): void;
}

class Test implements ITest {
    test() {
        return null;
    }
}
```


**Request**
Running `go to definition` on `test` in class `Test` currently does not return `ITest::test`. Neither does `go to type definition`.

In VSCode, we would like some way to jump from a class's interface method implementation  or abstract method implementation to the interface method declaration or abstract method declaration  itself. I'm not sure which command makes sense to do this, either `go to definition` or `go to type definition`, but we are open to any suggestions
Repository: go
Issue: x/term: cross-platform key codes
Labels: NeedsInvestigation

Add cross-platform key identifiers that can be used to detect keypresses for user shortcuts regardless of keyboard layouts.

More info:

- https://stackoverflow.com/questions/8737566/rolling-ones-own-keyboard-input-system-in-c-c
- https://hg.libsdl.org/SDL/file/default/include/SDL_scancode.h
- http://www.usb.org/developers/hidpage/Hut1_12v2.pdf

About names - let's keep them consistent with SDL:

- KeyUp
- KeyPageUp
Repository: go
Issue: x/net/proxy: add HTTP CONNECT support
Labels: NeedsInvestigation,FeatureRequest

This is a proposal to add HTTP CONNECT support to x/net/proxy package.

### Implement HTTP CONNECT dialer
As what’s done for socks5, we can add an implementation for HTTP CONNECT dialer, it dials to the proxy, and then does a HTTP CONNECT handshake.

Also, we can register this dialer to proxySchemes with key “http” and key “https” as default dialers. This should be done in an init() function, so that users can overwrite those with their custom dialers if they want.

### Add function `FromEnvironmentForScheme(scheme)`
Like `FromEnvironment()`, this function returns a dialer.

The existing function `FromEnvironment()` checks the environment variable “all_proxy”, while in the case of HTTP CONNECT, we would want to use “http_proxy” and “https_proxy”.

The new function `FromEnvironmentForScheme()` checks https_proxy, http_proxy and all_proxy based on the scheme.

 - If scheme is "https", it checks https_proxy, http_proxy and all_proxy.
 - If scheme is "http", it checks http_proxy and all_proxy.
 - In other cases, it checks all_proxy.

### Add `DialContext()` function
As requested in https://github.com/golang/go/issues/17759.
Adding `DialContext()` to `Dialer` interface will be a breaking change though. What's proposed in #17759 seems like a good solution.
Repository: opencv
Issue: VideoCapture::read() returns "true" erroneously
Labels: bug,priority: low,category: videoio(camera),platform: win32

I am using opencv 3.2 with VS2017 on Windows 10 and noticed that there is a problem with VideoCapture and webcams.  If I open my USB webcam from some other application so that it is displaying video and then do something this:

```
m_webCam = cv::VideoCapture(0);
bool ok = false;
ok = m_webCam.read(m_frame);

```
`ok` is true after this.  I was using opencv 3.1 and Visual Studio 2015 and I can confirm it returned false.  Either moving to opencv 3.2 or Visual Studio 2017 broke the functionality.  Because this returns true, m_frame ends up having uninitialized data and causes my program to hang somewhere within the system code.  If I break my application during the hang it is off in never never land.  Regardless, the read() function should definitely be returning false in this situation.

I also checked and `m_webCam.isOpen` also returns true.
Repository: rust
Issue: Undetected unconditional recursion in Clone impl using to_owned()
Labels: C-enhancement,A-lints,T-compiler

```rust
fn main() {
    struct Foo;
    impl Clone for Foo {
        fn clone(&self) -> Self {
            self.to_owned()
        }
    }
    Foo.clone();
}

```

Rustc gives no warning, but this overflows the stack.

Slightly more realistic example:
```rust
fn main() {
    use std::borrow::{Borrow, ToOwned};
    use std::ops::Deref;
    struct Foo;
    struct Borrowed;
    impl Deref for Foo {
        type Target = Borrowed;
        fn deref(&self) -> &Borrowed {
            unimplemented!()
        }
    }
    impl Borrow<Borrowed> for Foo {
        fn borrow(&self) -> &Borrowed {
            &*self
        }
    }
    impl ToOwned for Borrowed {
        type Owned = Foo;
        fn to_owned(&self) -> Foo {
            unimplemented!()
        }
    }
    impl Clone for Foo {
        fn clone(&self) -> Self {
            (*self).to_owned() // Oops, should have dereferenced twice
        }
    }
    Foo.clone();
}

```
([Real life use case for implementing `Clone` through `deref -> to_owned`](https://github.com/jeremyletang/rust-sfml/blob/941a53008d3385ec4e578deabc398a8851eecd69/src/audio/sound_buffer.rs#L219-L236))

Is it feasible for rustc to detect this kind of cross-trait unconditional recursion?
Repository: go
Issue: runtime: better support for 64bit div/mod operations on 32bit platforms
Labels: Performance,compiler/runtime

encountered in https://go-review.googlesource.com/c/38071/:

assuming x and y are uint64:
```
q = x/y 
r = x%y
```

only uses a single DIV instruction on amd64 however on 386 this makes a runtime call to 
uint64div and one to uint64mod.

1) Both could be handled calculated together in a combined uint64divmod runtime call
2) In case y is constant the compiler could optimize the calculation to not require a div and not need a runtime call