sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: identifierCount may not be correct
Labels: Infrastructure

**TypeScript Version:**  3.2.0-dev.20181114

In `parser.ts`, there is an `identifierCount` variable that is incremented every time `createIdentifier` is called.
Unfortunately, not all `createIdentifier` calls will result in an identifier in the AST, since some may have happened during speculative parsing. It may be necessary to reset `identifierCount` after speculative parsing fails.
Repository: opencv
Issue: pass ENVIRONMENT to Emscripten
Labels: feature,priority: low,category: build/install,category: javascript (js)

See: https://github.com/kripken/emscripten/pull/6565

As it is right now, the build doesn't work out of the box with bundlers like webpack. I'd imagine that the "worker" target can come in handy too.
Repository: node
Issue: Run tests with OPENSSL_CONF set to embedded openssl.cnf
Labels: help wanted,test,openssl

* **Version**: <= 10.13.0
* **Platform**: Linux

when building with the `--shared-openssl` flag, it is highly probable that the `openssl.cnf` used by the shared library will be different than the one present in Node.js source code, resulting in several test failures.
Typically, on debian, openssl is configured with stricter options regarding key length and TLS versions.
It is very easy to avoid any test failure, though, by setting this environment variable when running tests:
`OPENSSL_CONF=./deps/openssl/openssl/apps/openssl.cnf`
Repository: opencv
Issue: Exception in knnMatch of cvflann::anyimpl::bad_any_cast when upgrading Podfile from 3.1.0.1 to latest
Labels: platform: ios/osx,incomplete,needs investigation

##### System information (version)
- OpenCV => latest Pod install
- Operating System / Platform => iOS
- Compiler => Xcode

##### Detailed description

I have an image matching program on iOS that identifies images from the phone's camera for the user.  It's been working fine for two years, starting with a much, much older opencv2 library.  I've updated it several times throughout the years with no issues, but when going from 3.1.0.1 to latest Pod using Podfiles, I suddenly get crashes.

Here is the feature extractor I use:

```
#define NUM_FEATURES_ORB (400)
m_descriptorExtractor = cv::ORB::create(NUM_FEATURES_ORB);
```

In debug mode, I only get a exception in `knnMatch(...)` of type 

```
cvflann::anyimpl::bad_any_cast
```

Which is usually thrown when you've setup your system incorrectly (as most posts about that exception are about dating back to 2012).  However, I know the system is setup correctly and untouched for two years.

In release mode, it just crashes in the constructor for the FlannMatcher

```
int const table_number = 6;// 12
int const key_size = 12;// 20
int const multi_probe_level = 1;// 2
cv::FlannBasedMatcher flannMatcher(cv::makePtr<cv::flann::LshIndexParams>(table_number, key_size, multi_probe_level));  
```

Reverting back to using 3.1.0.1 in the Podfile fixes the issue
Repository: TypeScript
Issue: Statically match namespace names using `new Function().name`
Labels: Suggestion,In Discussion

I have this bit of code:

```js
import * as express from 'express';
import {RequestHandler} from 'express';

const router = express.Router();

export const register = (v: any) => {
  router.get('/', makeGetFoo(v));
  router.put('/', makePutFoo(v));
};

namespace ApiDoc {
  
  export interface makeGetFoo  {  // <--- i want to share this interface with front-end codebase
    success: boolean
  }
  
  export interface makePutFoo  {  // <--- i want to share this interface with front-end codebase
    success: boolean
  }
}


const makeGetFoo = (v: any): RequestHandler => {
  
  return (req, res, next) => {
    
    res.json(<ApiDoc[makeGetFoo.name]>{success: true});
    
  };
  
};

const makePutFoo = (v: any): RequestHandler => {
  
  return (req, res, next) => {
    
    res.json(<ApiDoc[makePutFoo.name]>{success: true});
    
  };
  
};
```

my goal is to put the typings in a intermediary file, so that the types can be sourced by the front-end code. Hopefully you understand what I am trying to do.

The problem is I get this:

![screenshot from 2018-11-14 17-08-22](https://user-images.githubusercontent.com/11139560/48523103-eb161500-e82f-11e8-8cf4-268846a4fba0.png)

> Cannot use namespace ApiDoc as a type

What I want to do is create a system where the interface name matches the function name so that I don't have to guess, etc.
Repository: TypeScript
Issue: "2 definitions" when using  module.exports to export a function wrapped in {}
Labels: Bug,Domain: JavaScript

- VSCode Version: 1.28.2
- OS Version: macOS 10.14

I noticed there are several issues opened against "2 definitions", noticeably https://github.com/Microsoft/vscode/issues/51459 & https://github.com/Microsoft/TypeScript/issues/24861 

But I don't think my issue is the same (I don't use ts or react, just nodejs code). It happens when I export like this

```
function downloadVoice() {
...
}

module.exports = {
    downloadVoice
}
// If I export like this it will not happen
// module.exports = downloadVoice
```

But when I hover over to the place when the function is called, vscode can show the definition correctly,

<img width="894" alt="2 inspection" src="https://user-images.githubusercontent.com/516243/48044533-5d9b4b00-e1c7-11e8-8902-cdddaf3ae2c2.png">


The 2 definitions warning:

<img width="948" alt="ks3test_js_ _inspection" src="https://user-images.githubusercontent.com/516243/48044566-86bbdb80-e1c7-11e8-9551-74f2b0fcaec8.png">



<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes
Repository: vscode
Issue: [scss] selector specificity works wrong with nested selectors
Labels: bug,css-less-scss

Issue Type: <b>Bug</b>

Css specifity calculator doesn't respect nested selectors or selectors with `&`.

```css
#id {} /* (1, 0, 0) */

#id div {} /* (1, 0, 1) */
```
```sass
#id {
  div { /* (0, 0, 1) */
  }
}

.block{ /* (0, 1, 0) */
  &__element { /* (0, 0, 0) */
  }
}
```

Reproduced without any extensions

VS Code version: Code 1.29.0 (5f24c93878bd4bc645a4a17c620e2487b11005f9, 2018-11-12T07:47:15.448Z)
OS version: Windows_NT x64 10.0.17134


<!-- generated by issue reporter -->
Repository: vue
Issue: match (getTypeIndex) is called lot of time when props changed and consume lot of memory
Labels: improvement

### Version
2.5.17

### Reproduction link
[https://codepen.io/anon/pen/MzpZoz?editors=1011](https://codepen.io/anon/pen/MzpZoz?editors=1011)





### Steps to reproduce
Open google chrome dev console  
Go in 'Memory' tab  
Select 'Allocation instrumentation timeline' and check 'Record allocation stacks'  
Launch for 30 seconds  
On your snapshot select 'Allocation' on the top left drop-down  
Order by 'Count'  
You will see high number of match called (a lot more than the actual var change)

### What is expected?
Expected to have match number closer to the number of var change.

### What is actually happening?
Match is executed lot of time and consume lot of memory.

---
I think it's the way i deal with the object that it's not the right way but i search in the doc and couldn't find something related to that behavior and how to manage it (perhaps use store ?).

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: godot
Issue: Errors when trying to import and open EXR files with multiple layers
Labels: bug,topic:thirdparty,topic:import

**Godot version:**
3.1 66c6dfb

**OS/device including version:**
Windows 10

**Issue description:**
When I copy exr file(created in Krita 4 without merging layers) to godot project, and later open this project and file, then this error is shown:
```
ERROR: load_image: TinyEXR: R channel not found.
   At: modules/tinyexr/image_loader_tinyexr.cpp:111
ERROR: _reimport_file: Error importing: res://Places/Flag/flaga.exr
   At: editor/editor_file_system.cpp:1540
ERROR: Failed loading resource: res://Places/Flag/flaga.exr
   At: core/io/resource_loader.cpp:192
ERROR: load_resource: Condition ' !res.is_valid() ' is true. returned: ERR_CANT_OPEN
   At: editor/editor_node.cpp:583
```

Example file(need change extension to .exr)
[flaga.zip](https://github.com/godotengine/godot/files/2585085/flaga.zip)
Repository: flutter
Issue: Support debugging `flutter drive` integration tests from the editors
Labels: tool,t: flutter driver,P2,team-tool,triaged-tool

Hi,

I can't find any way debugging integration tests run with flutter drive.
in flutter site it's only say to use Observatory for debug, but not explain how to do this.
https://flutter.io/docs/testing/debugging
 
i also tried to connect to link of listening to Observatory like show in screenshot i attache
![run test](https://user-images.githubusercontent.com/43311627/48550340-23266200-e8db-11e8-92f9-e353fe5ff628.JPG)

, but i couldn't see my code and debut it.

please help me.
thanks
Repository: pytorch
Issue: Cannot import caffe2_pybind11_state_gpu
Labels: caffe2

## 🐛 Bug

Hello, THe problem is that import caffe2_pybind11_state_gpu doesn't work it says:
ImportError: DLL load failed: The specified module could not be found.

On the other hand, import caffe2_pybind11_state (without gpu) works fine. What could be missing ? How can I find which DLL is he looking for ?

## To Reproduce

Steps to reproduce the behavior:

1. Download master branch and build from sources, Window 10, Cuda 9.2, Python 3.6
Repository: go
Issue: cmd/go: should help users understand when a new GOOS or GOARCH breaks their build
Labels: NeedsDecision

We ran to an interesting issue today in the Go newbies channel on the Slack workspace, specifically around a user's build breaking in between Go v1.10.x and v1.11.x. I'm not sure if there's really a tenable solution here, but I thought it was worth starting a discussion with the Go authors.

This user upgraded from Go v1.10.x to Go v1.11.2 with no other changes to their code, and they were then met with build failures:

```
./swaguidist.go:15:38: undefined: swaggerUiBundleJs
./swaguidist.go:17:38: undefined: swaggerUiStandalonePresetJs
```

When the user tried to figure out what was wrong, they incorrectly asserted that because some of the files in the package were large the compiler was ignoring them. They reached out to the Slack workspace to see whether anyone was aware of such a limitation, but thankfully we happened to spot the files ending in `*_js.go`.

While I think it's ideal to expect everyone to read the release notes in their entirety, I don't think we'll ever get to that place. It makes me wonder if there're are any options available to us that would make these things a little more approachable and actionable (especially to newbies), versus something like a variable not defined error.
Repository: go
Issue: testing: Benchmark reporting incorrect stats when running in parallel
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11 linux/amd64
</pre>

Applies to earlier versions as well

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build896591388=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Using the following test file:

```
package bechmarkperf

import (
	"strconv"
	"testing"
	"time"
)

func BenchmarkSleepSerial(b *testing.B) {
	for i := 0; i < b.N; i++ {
		sleepFunc()
	}
}

func BenchmarkSleepParallel(b *testing.B) {
	for i := 1; i <= 8; i *= 2 {
		b.Run(strconv.Itoa(i), func(b *testing.B) {
			b.SetParallelism(i)
			b.RunParallel(func(pb *testing.PB) {
				for pb.Next() {
					sleepFunc()
				}
			})
		})
	}
}

func sleepFunc() {
	time.Sleep(1 * time.Millisecond)
}
```

Running in parallel, results were ~1ms / <parallelism> for `ns/op`.  This mean that doubling threadcount would halve ns/op.



### What did you expect to see?

ns/op hold the same and not go below 1ms.

### What did you see instead?

When running with 128 goroutines, go the following output:

```
BenchmarkSleepParallel/8-16  	  100000	     12024 ns/op	       0 B/op	       0 allocs/op
```

This is reporting that the benchmark process is taking well under 1ms (which is the sleep duration above).
Repository: three.js
Issue: skinning vertex shader possible optimization
Labels: Suggestion

##### Description of the problem

https://github.com/KhronosGroup/glTF/issues/1397#issuecomment-408232715

offers an alternative implementation for the skinning vertex shader at

https://github.com/mrdoob/three.js/blob/dev/src/renderers/shaders/ShaderChunk/skinning_vertex.glsl :

```js
        vec4 skinVertex = bindMatrix * vec4( transformed, 1.0 );

	vec4 skinned = vec4( 0.0 );
	skinned += boneMatX * skinVertex * skinWeight.x;
	skinned += boneMatY * skinVertex * skinWeight.y;
	skinned += boneMatZ * skinVertex * skinWeight.z;
	skinned += boneMatW * skinVertex * skinWeight.w;

	transformed = ( bindMatrixInverse * skinned ).xyz;
```
alternative:
```js
        vec4 skinVertex = bindMatrix * vec4( transformed, 1.0 );

        mat4 skinMatrix = mat4( 0.0 );
	skinMatrix += skinWeight.x * boneMatX;
	skinMatrix += skinWeight.y * boneMatY;
	skinMatrix += skinWeight.z * boneMatZ;
	skinMatrix += skinWeight.w * boneMatW;

        skinned = vec4(skinMatrix * skinVertex);
	transformed = ( bindMatrixInverse * skinned ).xyz;
```

The alternative applies the weights to the matrices and then uses a single mat4 vec4 mult. to calculate the result of the skinning. It uses less GPU operations (9 vs. 12) but in terms of resolved scalar scalar multiplications and additions would not offer advantages over the existing shader. But mat4 and vec4 operations are likely highly optimized on the GPU.

An additional advantage of the alternative is that the final skinMatrix could likely be reused by the skin normal shader fragment (or vice versa) (https://github.com/mrdoob/three.js/blob/dev/src/renderers/shaders/ShaderChunk/skinnormal_vertex.glsl).

While the alternative shader code is tested successfully with all available Three skinning examples and glTF examples, I am, unfortunately, not in a position to do performance testing, across GPUs.

##### Three.js version

- [x] Dev

##### Browser

- [x] All of them

##### OS

- [x] All of them
Repository: go
Issue: cmd/vet: add compilebench to track 'go vet std'
Labels: ToolSpeed,NeedsInvestigation,Analysis

We should update compilebench to measure the cost of cmd/vet analysis.

```
  go install cmd/vet
  for i in 1 2 3 4 5
  do
    go clean -cache
    time go vet std >/dev/null 2>&1 # clean build
    time go vet std >/dev/null 2>&1 # noop incremental build
  done
```
Repository: godot
Issue: Viewports do not inherit project default rendering settings
Labels: enhancement,topic:core,topic:rendering,documentation

**Godot version:**
Godot 3.1 Alpha 2

**OS/device including version:**
Windows 10 64 Bit
NVIDIA GTX 960M
Driver v416.16

**Issue description:**
Viewports do not inherit project default settings, requiring the user to manually set MSAA, Shadow Atlas, etc

**Minimal reproduction project:**
[GLES3.zip](https://github.com/godotengine/godot/files/2587236/GLES3.zip)
Repository: pytorch
Issue: Make torch.multiprocessing.SpawnContext usable
Labels: module: multiprocessing,feature,triaged

See https://github.com/pytorch/pytorch/pull/14039#issuecomment-439219408
Repository: flutter
Issue: Second slow tap on the same spot brings up selection controls
Labels: a: text input,c: new feature,platform-ios,framework,P2,team-ios,triaged-ios

As described in the title. Right now the controls only appear on long press.
Repository: TypeScript
Issue: map through enum
Labels: Suggestion,Needs Proposal

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.1.6

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** enum

**Code**

```ts
enum ABC {
  A = 'A',
  B = 'B',
  C = 'C',
}
// No Error
for (const key in ABC) {
  console.log(ABC[key]);
}
// Error: Element implicitly has an 'any' type because index expression is not of type 'number'
Object.keys(ABC).map(key => console.log(ABC[key]));
```

**Expected behavior:**
`Object.keys, values, entries` on `enum ABC` infer type of `ABC`'s key and value.
**Actual behavior:**
Cannot get inferred type.

Shouldn't type of key from enum be 'A' | 'B' | 'C'?
Repository: TypeScript
Issue: Compiler warning for always true/false strict inequality expression
Labels: Suggestion,In Discussion

## Search Terms

type guard warning if always true false non-identity inequality

## Suggestion

The compiler should emit a warning if it can determine that an expression using a strict inequality check (`!==`) always returns true or false. It already does this for strict equality checks (`===`).

## Use Cases

Like the warnings for the strict equality check, it helps identifying unreachable code blocks or unnecessary if blocks which can get introduced during refactoring of existing code or during carefree creation of new code.

## Examples

The following function definition emits an error ("This condition will always return 'false' since the types '"abc"' and '"xyz"' have no overlap."):
```ts
function fn(p: "abc") {
  if (p === "xyz") {
    
  }
}
```

But this function definition compiles just fine (a possible error message could be "This condition will always return 'true' since the types '"abc"' and '"abc"' overlap completely":
```ts
function fn2(p: "abc") {
  if (p !== "abc") {
    
  }
}
```

It even correctly type-guards the type of `p` inside the if block (it becomes `never`).

Two other scenarios which trigger this non-warning, but could be harder to detect:

```ts
// typeof checks
function fn3(p: string) {
  if (typeof p !== "string") {

  }
}

// the length of a tuple
function fn4(p: []) {
  if (p.length !== 0) {

  }
}
```

The last example doesn't type-guard the value of p correctly to `never` even though `p.length` is correctly of type `0`, maybe this is a separate feature request.

## Problems / Discussion Points

* I'm not sure whether this qualifies as a breaking change, since it introduces a warning for code constructs which compile totally fine at the moment.
* This could be extended for other checks as well (e.g. for the `<`/`<=` and `>`/`>=` operators) even though this would be pretty edge-casey.

## Checklist

My suggestion meets these guidelines:

* [ ] (Unsure) This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: javascript-algorithms
Issue: Knapsack has error
Labels: bug


```
var uu = [
      new KnapsackItem({ value: 3, weight: 2 }),
      new KnapsackItem({ value: 4, weight: 3 }),
      new KnapsackItem({ value: 5, weight: 4 }),
      new KnapsackItem({ value: 7, weight: 5 }),
    ];
var b  = new Knapsack(uu, 7);
b.solveZeroOneKnapsackProblem()
```
Repository: rust
Issue: issue-44056.rs was incorrectly moved to compile pass and should not if hardware does not support AVX
Labels: A-testsuite,T-compiler,E-help-wanted

See https://github.com/rust-lang/rust/pull/55667.

There are two problems:

* the issue-44056.rs test was incorrectly moved from run-pass (https://github.com/rust-lang/rust/issues/44056) to compile-pass: this test must be executed

* the issue-44056.rs test should not run on non-AVX hardware, and this cannot be checked in the test itself. That is, the test runner has to detect whether the host supports AVX, and then and only then, attempt to run the test.

cc @infinity0 @RalfJung @nikic @alexcrichton
Repository: rust
Issue: Cycle detected when processing existential type
Labels: A-diagnostics,T-compiler,A-impl-trait,F-type_alias_impl_trait,requires-nightly

[playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=c35f11c83bb2e0fdbde12749f8a4927c)

```rust
#![feature(existential_type)]

use std::rc::Rc;

existential type Foo: Fn() -> usize;

fn foo() -> Foo {
    let rc = Rc::new(5);
    move || { *rc.as_ref() }
}

fn assert_send<T: Send>(_: &T) {
}

fn main() {
    let f = foo();
    assert_send(&f);
    println!("{}", f());
}
```

```
error[E0391]: cycle detected when processing `Foo`
 --> src/main.rs:5:1
  |
5 | existential type Foo: Fn() -> usize;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: ...which requires processing `main`...
 --> src/main.rs:15:1
  |
15| fn main() {
  | ^^^^^^^^^
note: ...which requires evaluating trait selection obligation `Foo: std::marker::Send`...
  = note: ...which again requires processing `Foo`, completing the cycle
```

Commenting out the `assert_send(&f);` line compiles and runs fine ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=ae3e28eec9d7b8c81fea970152a0e466)), moving `Foo` and `foo` into a sub-module correctly identifies that `Foo: !Send` ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=e6cb72c4424ba8b9b1477301701a5c50)).
Repository: create-react-app
Issue: Application crashes on IE11 and lower, Syntax error
Labels: issue: bug

### Is this a bug report?

 Yes

### Did you try recovering your dependencies?

Yes

### Environment
node version: 8.11.1,
npm version: 5.6.0

This problem is specific for IE11 running on Windows 10

### Steps to Reproduce

1. npx create-react-app my-app
2. cd my-app
3. npm start
4. Open application in IE11 browser

### Expected Behavior

I expected my app to load, like it does in Chrome, Firefox and Safari.

### Actual Behavior

Got console error - "Syntax error" after running npm start command. Debugger points to ansi-regex dependecy in node-modules, the problem is ES6 arrow function syntax. Any ideas how can I fix this? I tried using react-app-polyfill package but with no results.

![image](https://user-images.githubusercontent.com/37124609/48615563-8a9ee900-e991-11e8-8cae-37020af871e5.png)

It seems related to this old topic: https://github.com/facebook/create-react-app/issues/2691

ansi-regex in version 3.00 or higher exports arrow functions instead of regular functions and it causes error in IE11. Previously package version was downgraded, but now it seems to be bumped to 3.00 again