sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: JSDoc function type within generic not parsed correctly
Labels: Bug,Domain: JSDoc,Domain: JavaScript

<!-- 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 -->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.7.0-dev.201xxxxx

**Code**

```ts
    /** @type {!Set<function()>} */
    this._listeners = new Set();
```

**Expected behavior:**
No error, strongly typed `this._listeners`

**Actual behavior:**
```
front_end/bindings/BlackboxManager.js(22,21): error TS1005: '>' expected.
```
(A parse error on `function` claiming a closing `>` is expected)
Repository: TypeScript
Issue: JSDoc function type not parsed correctly when nested
Labels: Bug,Domain: JSDoc,Domain: JavaScript

<!-- 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 -->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.7.0-dev.201xxxxx

**Code**

```ts
  /**
   * @param {!Runtime.Extension} extension
   * @param {?function(function(new:Object)):boolean} predicate
   * @return {boolean}
   */
  _checkExtensionApplicability(extension, predicate) {
    return false;
  }
```

**Expected behavior:**
Strong types for `extension` and `predicate`.

**Actual behavior:**
```
front_end/Runtime.js(398,24): error TS1138: Parameter declaration expected.
```
(An error on the inner `function`, rather than a correctly constructed type)
Repository: TypeScript
Issue: JSDoc allow missing parameter names
Labels: Bug,Domain: JSDoc,Domain: JavaScript

<!-- 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 -->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.7.0-dev.201xxxxx

**Code**

```ts
  /**
   * @override
   * @param {function(string)}
   */
  setNotify(notify) {
    this._notify = notify;
  }
```

**Expected behavior:**
strongly typed `notify`

**Actual behavior:**
```
front_end/audits2_worker/Audits2Service.js(33,31): error TS1003: Identifier expected.
```
(Error on the end of the `@param` line)

Found a few instances of this in the chrome devtools, which means this validates in the closure compiler. If the param names are missing, they should just be matched by position.
Repository: TypeScript
Issue: JSDoc Allow lone rest type
Labels: Bug,Domain: JavaScript

**Code**

```ts
  /**
   * @param {function(new:T, ...)} flavorType
   * @param {?T} flavorValue
   * @template T
   */
  setFlavor(flavorType, flavorValue) {
}
```

**Expected behavior:**
Strong types for both arguments, no errors

**Actual behavior:**
```
front_end/ui/Context.js(14,33): error TS1110: Type expected.
```
(An error on the `...` in the first parameter type)

We'd usually consider the "right" thing to do here as `...*`, but closure is apparently fine with just `...`, so we should also respect that. A few files in the chrome devtools codebase make use of this pattern.
Repository: TypeScript
Issue: JSDoc trying to parse tag names where tag names aren't possible
Labels: Suggestion,In Discussion,Domain: JSDoc,Domain: JavaScript

<!-- 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 -->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.7.0-dev.201xxxxx

**Code**

```ts
 /**
   * When concatenated with a string, this automatically concatenates the user's mention instead of the Member object.
   * @returns {string}
   * @example
   * // Logs: Hello from <@123456789>!
   * console.log(`Hello from ${member}!`);
   */
  toString() {
    return `<@${this.nickname ? '!' : ''}${this.user.id}>`;
  }
```

**Expected behavior:**
No error

**Actual behavior:**
```
node_modules/discord.js/src/structures/GuildMember.js(511,28): error TS1003: Identifier expected.
```
Error on `@123456789` - we probably shouldn't be looking for tags in the middle of a line.
Repository: opencv
Issue: OpenCV 3.1's SVD is 3600 times slower than OpenCV 2.2's SVD
Labels: feature,category: core

##### Detailed description

As it is already reported previously, SVD of version 2.3 and later is slower than SVD of version 2.2.
https://github.com/opencv/opencv/issues/4313
https://github.com/opencv/opencv/issues/7563
https://github.com/opencv/opencv/issues/7917

Below, I will report the benchmark result.

OpenCV 2.2 use LAPACK, so its SVD was fast, but OpenCV 2.3 use own implementation, and so its SVD is slow. OpenCV's SVD is implemented in `lapack.cpp`'s `JacobiSVDImpl_`. I looked at this code, but I could not understand. I just guess that the speed of this function becomes slow when there are zero singular values. In order to check my hypothesis, two benchmark tests are done below: One with the matrix filled with the value "one," and the other with the matrix filled with random numbers.

##### System information (version)
- OpenCV => 3.1 or 2.2
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015

##### Steps to reproduce
```cpp
const int ROW = 2000;
const int COL = 2000;
Mat mat = Mat::ones(ROW, COL, CV_64F);
int64 start = getTickCount();
cout << "start = " << start << endl;
SVD svd(mat);
int64 end = getTickCount();
cout << "end = " << end << endl;
int calctime = (int)((end - start) * 1000 / getTickFrequency());
cout << "duration = " << calctime << " [msec]" << endl << endl;
cout << "W = " << endl << svd.w.rowRange(Range(0, 9)) << endl;
```

For random matrix, following code is used for `mat`.
```cpp
RNG gen(getTickCount());
Mat mat(ROW, COL, CV_64F);
gen.fill(mat, RNG::UNIFORM, 0.0, 1.0);
```

##### Benchmark result: random
Library | Millisecond
--- | ---
MATLAB | 3737
Python numpy | 3878
C/C++ OpenCV 2.2 | 27523
Python OpenCV 3.3 | 147870
C/C++ OpenCV 3.1 | 187424
C/C++ NRC 3rd edit. | 437539
C/C++ Eigen | 940722

##### Benchmark result: ones
Library | Millisecond
--- | ---
C/C++ Eigen | 170
C/C++ OpenCV 2.2 | 2501
MATLAB | 18784
Python numpy | 21017
C/C++ NRC 3rd edit. | 542057
Python OpenCV 3.3 | 9003935
C/C++ OpenCV 3.1 | 9004074
Repository: go
Issue: x/build: add a CGO_ENABLED=0 Windows Builder?
Labels: OS-Windows,Builders,new-builder

In https://github.com/golang/go/issues/22680#issuecomment-344122132 , @alexbrainman notes we don't have a CGO_ENABLED=0 Windows builder.

We probably should add one.

CLs welcome.
Repository: go
Issue: cmd/cgo: pointer-passing rules may not be strong enough
Labels: Documentation,NeedsFix,compiler/runtime

In #12416, we (mostly @ianlancetaylor, I think) defined some restrictions on what C functions can do with Go pointers.

The current restrictions say, “The C code … must not store any Go pointers in Go memory, even temporarily.”

They do not prohibit the C code from storing non-Go pointers in Go memory, but I've been thinking about the pointer check a lot lately, and https://github.com/golang/go/issues/20427#issuecomment-343255844 reminded me that C compilers can generate some pretty gnarly code.

In particular, C11 has a proper threading model, and a C11 compiler is allowed to assume that non-atomic writes do not race. It can rewrite them as, say, a store followed by an add, or a store of a spilled temporary followed by a load of that temporary and a store of the actual pointer. (Fortunately, I do not yet have an example of a C compiler actually generating such code.)

So now I'm not sure that the cgo pointer check is really strong enough after all: writes of non-Go pointers to Go pointer slots from C can, at least theoretically, race with the garbage collector tracing those slots, and cause it to observe invalid pointers.

To address that problem, I think we need to do one of:
* Strengthen the existing sentence: “The C code … must not store **any pointers** in Go memory, even temporarily,” or
* Add another clause: “The C code may store non-Go pointers in Go memory, but must ensure that each such store occurs atomically.”

(CC @dr2chase, @aclements, @RLH)
Repository: TypeScript
Issue: Function should be assignable to (...args: any[]) => any
Labels: Suggestion,In Discussion

Obviously all functions have type `Function`. And likewise all functions can be given the type

```ts
type AnyFunc = (...args: any[]) => any;
```

AFAIK, there is nothing one can do with something of type `Function` that cannot be done with something of type `AnyFunc` and vice versa. However they are not equivalently assignable:

```ts
(f: AnyFunc): Function => f;
(f: Function): AnyFunc => f;
//                        ^
// Type 'Function' is not assignable to type 'AnyFunc'.
//   Type 'Function' provides no match for the signature '(...args: any[]): any'.
```

If I edit `lib.d.ts` to add a callable signature to `Function`:

```ts
interface Function {
  (...argArray: any[]): any;
  //...
}
```

it seems to "fix" this issue; is there any reason not to make this change for real?
Repository: youtube-dl
Issue: Export failed URL in a batch file
Labels: request

- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.11.06**

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [x] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

--- 

I frequently download multiple files within a batch-file. If some URL fail, I have no idea which of them worked and which did not.

I'd appreciate the option to export the failed URL in a new file for staying organized.

Any plans to do so?
Repository: pytorch
Issue: Deprecate inplace argument in torch.nn.functional
Labels: module: bc-breaking,feature,module: nn,triaged,module: deprecation

https://github.com/pytorch/pytorch/pull/3683 splits off in-place functions to use the underscore suffix, like the functions on the `Tensor`.

We should consider deprecating the inplace argument completely and require people to either call, e.g.:

```
F.relu(input)  # never in-place
F.relu_(input)  # always in-place
```

cc @albanD @mruberry @ezyang @SsnL @gchanan
Repository: go
Issue: x/net/http2: support memory re-use for MetaHeadersFrames
Labels: Performance,NeedsInvestigation

As pointed out in https://github.com/grpc/grpc-go/issues/1587#issuecomment-340015543 (and in https://github.com/cockroachdb/cockroach/issues/17370), re-using `MetaHeadersFrame` memory similarly to `DataFrame`s has the potential to increase performance significantly (~50% throughput increase), even where the header frame data is quite small (10s of bytes).  The http2 library should ideally support this.
Repository: kubernetes
Issue: Use `cmp.Equal` instead of DeepEqual?
Labels: kind/cleanup,sig/api-machinery,help wanted,lifecycle/frozen

https://github.com/google/go-cmp/

I wonder if this can replace our semantic DeepEqual?

@lavalamp 
@kubernetes/sig-api-machinery-bugs
Repository: kubernetes
Issue: fluentd-gcp crashing because of `JournalError: Bad message`
Labels: kind/bug,sig/instrumentation,lifecycle/frozen

This happened in a 1.6 test: https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-e2e-gci-gke-serial-release-1-6/929

fluentd crashed/restarted ~40 times during the test because it could not handle the bad message in journal.
```
2017-11-14 15:40:52 +0000 [error]: unexpected error error_class=Systemd::JournalError error=#<Systemd::JournalError: Bad message>
  2017-11-14 15:40:52 +0000 [error]: /var/lib/gems/2.1.0/gems/systemd-journal-1.2.3/lib/systemd/journal.rb:284:in `enumerate_helper'
  2017-11-14 15:40:52 +0000 [error]: /var/lib/gems/2.1.0/gems/systemd-journal-1.2.3/lib/systemd/journal.rb:106:in `current_entry'
  2017-11-14 15:40:52 +0000 [error]: /var/lib/gems/2.1.0/gems/fluent-plugin-systemd-0.0.8/lib/fluent/plugin/in_systemd.rb:88:in `watch'
  2017-11-14 15:40:52 +0000 [error]: /var/lib/gems/2.1.0/gems/fluent-plugin-systemd-0.0.8/lib/fluent/plugin/in_systemd.rb:70:in `run'
2017-11-14 15:40:52 +0000 [info]: shutting down fluentd
```

This issue fixed in fluentd-0.14.x according to https://github.com/reevoo/fluent-plugin-systemd/issues/16
Not sure if the latest fluentd-gcp image contains the fix or not.

/cc @crassirostris
Repository: vscode
Issue: Autoclosing pairs should be configurable
Labels: feature-request,editor-autoclosing

I've mentioned this in #15899, but this should really be a new issue. Just like Atom, Code should have an option to configure autocomplete characters. Currently, only brackets are auto-completed (and wrapped around selections), but it would be really useful if this also worked with quotes and backticks (especially in Markdown documents).

Here's the relevant settings page in Atom:
![screen shot 2017-11-14 at 22 26 26](https://user-images.githubusercontent.com/4377312/32806059-9fd20298-c98b-11e7-9cca-ce5010288eda.png)
Repository: react-native
Issue: KeyboardAvoidingView has no effect on multiline TextInput
Labels: Platform: iOS,Ran Commands,Component: TextInput,Bug

KeyboardAvoidingView only works with single-line TextInputs.  When the `multiline` prop is set, KeyboardAvoidingView does not shift the TextInput at all.

### Is this a bug report?
Yes

### Have you read the [Contributing Guidelines](https://facebook.github.io/react-native/docs/contributing.html)?
Yes

### Environment
  Environment:
    OS:  macOS Sierra 10.12.6
    Node:  7.0.0
    npm:  3.10.8
    Watchman:  4.7.0
    Xcode:  9.1

  Packages: (wanted => installed)
    react-native: 0.49.3
    react: 16.0.0-beta.5

  Target Platform: iOS (10.3)

### Steps to Reproduce

1. Use a `<TextInput>` component with `multiline` prop set.
2. Wrap this in a ScrollView
3. Wrap that in a KeyboardAvoidingView.

### Expected Behavior

Multiline TextInput should scroll above the soft keyboard.

### Actual Behavior

Soft keyboard covers multiline TextInput.

### Reproducible Demo

```
import React, { Component } from 'react';
import { Text, TextInput, View, ScrollView, KeyboardAvoidingView, Keyboard} from 'react-native';

...

	render() {
		return (
			<KeyboardAvoidingView style={{flex:1}} behavior="padding" keyboardVerticalOffset={64}>
				<ScrollView keyboardShouldPersistTaps={'handled'}>
					<View style={{padding: 12}}>
						// various content to fill the page
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 1</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 2</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 3</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 4</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 5</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 6</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 7</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 8</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 9</Text>
						<Text style={{fontSize: 20, padding: 40}}>MESSAGE 10</Text>
					</View>
					<TextInput
						style={{padding: 4}}
						multiline={true}
						placeholder={'Type something here...'}
						onChangeText={this.updateMessage}
						value={this.state.message}
					/>
				</ScrollView>
			</KeyboardAvoidingView>
		);
	}

```
Repository: rust
Issue: [impl Trait] Should we allow `impl Trait` after `->` in `fn` types or parentheses sugar?
Labels: C-enhancement,T-lang,A-impl-trait

[RFC 1951] disallowed uses of impl Trait within Fn trait sugar or higher-ranked bounds. For example, the following is disallowed:

[RFC 1951]: https://github.com/rust-lang/rfcs/blob/master/text/1951-expand-impl-trait.md#expansion-to-arguments

```
fn foo(f: impl Fn(impl SomeTrait) -> impl OtherTrait)
fn bar() -> (impl Fn(impl SomeTrait) -> impl OtherTrait)
```

This tracking issue exists to discuss -- if we were to allow them -- what semantics they ought to have. Some known concerns around the syntax are:

- Should the `()` switch from existential to universal quantification and back?
    - I think the general feeling here is now "no", basically because "too complex".
- If HRTB were introduced, where would we (e.g.) want `impl OtherTrait` to be bound?

For consistency, we are disallow `fn(impl SomeTrait) -> impl OtherTrait` and `dyn Fn(impl SomeTrait) -> impl OtherTrait` as well. When considering the questions, one should also consider what the meaning would be in those contexts.
Repository: TypeScript
Issue: Allow type annotation on catch clause variable
Labels: Suggestion,Awaiting More Feedback,Add a Flag

**TypeScript Version:**  2.6.1

```ts
const rejected = Promise.reject(new Error());

async function tryCatch() {
  try {
    await rejected;
  } catch (err: Error) { // TS1196: Catch clause variable cannot have a type annotation
    // Typo, but `err` is `any`, so it results in runtime error
    console.log(err.mesage.length);
  }
}

function promiseCatch() {
  rejected.catch((err: Error) => { // OK
    // Compiler error; Yay!
    console.log(err.mesage.length);
  });
}
```

This was discussed in #8677 and #10000. It was closed as "fixed" in #9999, but as far as I can tell neither of the issues was actually resolved. In either event, I'd like to make a case for allowing type annotations in catch clauses.

Especially with the introduction of downlevel async functions, I'd suggest that disallowing catch clause type annotations leads to less safe code. In the example, the two methods of handling the promise are functionally equivalent, but one allows you to type the error, and the other doesn't. Without writing _extra_ code for the `try`/`catch` version (`if (err instanceof Error) {` or `const e: Error = err` or something), you'll get a runtime error that you wouldn't get with the pure `Promise` version.

The primary rationale for not allowing this is that any object can be thrown, so it's not guaranteed to be correct. However, most of the benefit of TypeScript comes from making assertions about your and other people's code that can't be strictly guaranteed (especially when importing JavaScript). And unless one would argue that the `Promise` catch function _also_ shouldn't allow a type annotation on the error parameter, this argument seems to make very little practical sense.

I believe one of the other arguments against is that it might be confusing, as it looks like the typed exception handling you might see in other languages (e.g., Java), and folks may think the catch will **only** catch errors of the annotated type. I don't personally believe that's a legitimate issue, but if it really is I'd propose at least allowing a `catch (err as Error) {` syntax or similar as a way of emphasizing that it's a type _assertion_.

If nothing else at all, it seems that there should be a way to trigger a warning (similar to an implicit any warning) when using an untyped `err` directly within a catch block.
Repository: opencv
Issue: OpenCV build failed on android with -isystem /usr/include defined
Labels: category: build/install,incomplete

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)

- OpenCV => 3.3.1
- Operating System Host => Linux 
- Operating System Target => Android
- Compiler => Clang 5.0 
- CMake => 3.9

##### Detailed description

I am building opencv using the last version of CMake with clang. When I build I have a lot of error because of the path /usr/include is defined during the build. I was able to find other repository with this issue and the last CMake version should fix the trouble but the build keep failing.

The issue I am facing is this one : https://github.com/android-ndk/ndk/issues/467

May be someone has some suggestion because I try many stuff and none of them fix the trouble.
BTW the same configuration is building fine on Android when the host machine is Darwin.
Repository: go
Issue: proposal: spec: add kind-specific nil predeclared identifier constants
Labels: LanguageChange,Proposal,LanguageChangeReview

A common error for people new to Go is misunderstanding that a interface that is not `nil` can contain a `nil` pointer.  This is one of the most commonly cited entries in the Go FAQ: https://golang.org/doc/faq#nil_error.  A quick search shows at least 24 threads on golang-nuts discussing this, even though it is already in the FAQ.

It is not new to observe that one of the causes of this common mistake is that `nil` is overloaded.  Since changing that would not be backwards compatible, I propose the following changes.

1) We add six new predefined identifiers: `nilptr`, `nilinterface`, `nilslice`, `nilchan`, `nilfunc`, `nilmap`.  These new identifiers are untyped constants that only resolve to a certain kind, much as `1.1` is an untyped constant that only resolves to a `float` or `complex` type.  `nilptr` may be used as the zero value for any pointer type, `nilinterface` may be used as the zero value for any interface type, and so forth.  An attempt to use, for example, `nilptr` in an assignment or comparison with a variable or value that is not a pointer type is invalid.

2) We add a vet check that warns about any comparison of a value of any type with plain `nil`.  We encourage people to change `x == nil` to `x == nilinterface` or `x == nilptr` or whatever is appropriate.  Since initially this vet check will trigger all the time, we can not turn it on when running `go test`.  It could be on by default when running `go vet`.

3) At this point people who run `go vet` will no longer make the common mistake.  If `v` is a value of interface type, then writing `v == nilptr` will be a compilation error.  Writing `v == nilinterface` will not cause people to erroneously think that this is testing whether `v` contains a `nil` pointer.

4) In some later release, we turn on the vet check when running `go test`.

5) If we are ever willing to make a backward incompatible change, we can make `v == nil` a compilation error rather than simply being a vet error.

Something to consider is that one could imagine permitting `v == nilptr` when v has an interface type, and having this be `true` if `v` is not `nilinterface`, if `v` holds a value of pointer type, and if the pointer value is `nilptr`.  I don't know that this is a good idea, and I'm not proposing it.  I'm only proposing the above.