sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: API: Do not translate errors; add more error "types"
Labels: api,needs:design

Currently there are only two types of errors: Exception and Validation and translated exception text, but many languages like Python are supposed to translate them into something own: e.g. when indexing buffer it is expected that invalid index is IndexError, invalid buffer is something like ValueError and “Line index is too high” is TypeError. But with the current code it is clearly not possible to do such translation because one does not know what text will be received. Thus I suggest that

1. Variant 1

   1. Error messages are part of the API. Any change (including typo fixes) to the text is considered to be incompatible.
   2. Messages which my potentially be truncated (e.g. like “Key "%s" doesn't exist”) must be written in a form `{identifier}: {data}`, e.g. `Key doesn't exist: %s`. `api_set_error` should contain an assert which checks that either `vim_snprintf()` was able to fit text into the message field or text ends with `%s` and there are no other `%…` atoms except `%%`. (Currently used `snprintf()` is not guaranteed to return sane length on some systems.)
   3. No errors are translated.

2. Variant 2

   1. Exception messages are replaced or start with an identifier which are unique per function: e.g. `locked`, `lengthy`, `missing` for dict_set_value. Make it categorized to avoid confusion with other functions: `dict/locked`, `dict/lengthy`, … Identifiers must not be translated, must be a separate argument to `api_set_error` even if messages are kept and it would be logical if CI checked that no identifier is repeated twice. Identifiers are considered to be a part of the API.
   2. If messages are chosen to be kept then they may be translated and are not a part of the API (except for the fact of their presence in reply).

Additionally error types are retired: I have no idea what these two types may be useful for in the current state and there is no documentation where I would expect it to live (i.e. api/private/defs.h should have at least some pointer or ag should be able to find documentation for `\bk?ErrorType`, but neither is the case), so I assume that enough developers had already put some semi-random exception types to the code. Even if they are not retired there must be easily accessible documentation explaining WTF is the difference between Exception and Validation and all occurrences of api_set_error must be revisited to check conformance.

I think that it is better to agree on this soon but this is not too urgent to be included in the `0.2`, so I selected `0.3` milestone. Note that current python client is not compatible with Vim in case scripts are written using EAFP principle: e.g.

```Python
try:
    cached_value = vim.vars['cached_value']
except KeyError:
    vim.vars['cached_value'] = cached_value = compute_value()
```

is not going to work because it emits NvimError.
Repository: rust
Issue: A new compiler flag: "link everything statically or die, dammit!"
Labels: A-frontend,A-linkage,T-compiler,C-feature-request

My adventures with static linking and native dependencies have been frustrating – because of the multitude of different `build.rs` scripts each configured in a different way, the build environment is fragile. Lately I made some changes to my environment, and since then, I've been trying to get all the native deps linking statically again – and some of them quite stubbornly refuse to do so.

The general problem with `build.rs` is hard to fix, but I think at least the process of troubleshooting the build could be made less frustrating. I'm thinking something like passing a flag to `cargo` or` rustc`, signalling that "I'm expecting the build to be fully statically linked, so if some of the libraries passes dynamic linking flags, stop building and tell me the name of that traitor".

At the moment, the build just silently accepts dynamic flags, resulting, after a long compilation, in a binary that I'm expecting to be able to run in an empty Linux userspace, but which fails. This is because `rustc` doesn't know my intent. Should we not be allowed to signal that intent?
Repository: opencv
Issue: Distance between multi-contour shapes
Labels: feature,category: shape

<!--
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.0+
- Operating System / Platform => ALL
- Compiler => ALL

##### Detailed description
Not all the shapes consist of a single contour, and `fillPoly` have taken that into consideration. It would be great if similar behavior is adapted for the `computeDistance` function as well.

##### Current signature:
```.cpp
float ShapeDistanceExtractor::computeDistance(InputArray contour1, InputArray contour2);
```

##### Desired signature:
```.cpp
float ShapeDistanceExtractor::computeDistance(InputArrayOfArrays pts1, InputArrayOfArrays pts2);
```
Repository: TypeScript
Issue: Suggestion: tsc should display a one line summary
Labels: Suggestion,Help Wanted

Suggestion:
tsc currently list the errors. Sometimes you want to see if the number of errors increases or decreases.

Proposition:
```
$ tsc
FooBar.tsx(66,59): error TS2339: Property 'query' does not exist on type 'Location'.
Hello.tsx(42,60): error TS2339: Property 'query' does not exist on type 'Location'.
dispatcher.ts(1,13): error TS6133: '_' is declared but never used.
World.test.ts(3,35): error TS7006: Parameter 'reason' implicitly has an 'any' type.
World.test.ts(3,43): error TS7006: Parameter 'promise' implicitly has an 'any' type.
World.test.ts(18,13): error TS6133: 'hello' is declared but never used.
mock.ts(194,23): error TS6133: 'ruleId' is declared but never used.
mock.ts(221,8): error TS2339: Property 'fetch' does not exist on type 'Window'.

Compilation done in 2.6s - 8 errors
```

```
$ tsc
[...]
Compilation aborted [...]
```

Could be the opportunity to display other informations (compilation time for example) given that it fits in a single line (72 columns).

(I'm not talking about `--diagnostics`)
Repository: go
Issue: net/smtp: TestTLSClient failures with "connection reset by peer" on freebsd
Labels: ExpertNeeded,Testing,OS-FreeBSD

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
1.8+ (development)

### What operating system and processor architecture are you using (`go env`)?
freebsd-amd64-gce101

### What did you do?
Tried to run Trybots for an unrelated change: 
https://go-review.googlesource.com/c/37333/#message-ae31a67c5f6927959d8d507bc5ae951e01fbc4e7

Observed failure, followed instructions to check https://build.golang.org

In the first column for freebsd-x64 (the left-hand one), I clicked through some of the failures in that column, and noticed the repeated occurrence of 
```
--- FAIL: TestTLSClient (0.00s)
	smtp_test.go:610: client error: close tcp 127.0.0.1:46828->127.0.0.1:46827: connection reset by peer
FAIL
FAIL	net/smtp	0.016s
```
which is also what besmirched my otherwise-clean TryBot run.
Repository: vscode
Issue: When using Run to Cursor, then there is no inline instruction pointer decoration
Labels: feature-request,debug

Testing #20793 

I would have expected to see an inline instruction pointer decoration when I use the 'Run to Cursor' command.

![run-to-cursor](https://cloud.githubusercontent.com/assets/172399/23210926/e1e8dbbe-f8ff-11e6-9fd4-f3f684424baf.gif)
Repository: youtube-dl
Issue: Multi-Threaded postproc for playlists
Labels: request,postprocessors

Would be nice if postproc was done in separate thread(s) (up to N threads, N being the number of CPU cores). As soon as a download is finished, the postproc job should be dispatched and the next download should start immediately. But if all N cores are doing postproc, wait for one to finish before downloading another playlist item. If the machine has only 1 core then the the behavior is exactly the same as it currently is.
Repository: rust
Issue: Need a way to close standard output
Labels: T-libs-api,C-feature-accepted

It is sometimes appropriate for a program to close its standard output stream long before it's done running.  For instance, I have a [C program](https://github.com/zackw/tbbscraper/blob/master/collector/scripts/tunnel-ns.c) that sets up some system-wide state, waits for its parent to be done using that setup, and then tears it down again.  (It's a separate program from the parent because it has to be setuid.)  It notifies the parent that it's done setting up by closing its stdout, which is expected to be a pipe.

You _can_ do this in Rust, but only by going behind the stdlib's back and calling `libc::close(1)`.  I would like there to be an official way to do this, without going behind the stdlib's back.  A concrete proposal: `Stdout` (and `Stderr`) add a `close` method.  These flush buffered output, close the underlying OS-level file descriptor, and then immediately reopen it on `/dev/null`, taking care to ensure that the well-known fd number is retained.  It remains OK to use `io::stdout()` after calling `close` on it.

(Reopening the OS-level file descriptor on `/dev/null` is to accommodate third-party libraries that may assume it is always safe to write to file descriptors 1 and/or 2, and/or that the `open()` primitive will never return descriptors numbered 0, 1, or 2.)

(Windows doesn't exactly have "file descriptors" but it _does_ have the concept of "standard handles" and there is a 1:1 mapping from the Unixy terms I used above to Windows equivalents.)

(For consistency, the internal method for "replacing `Stdout` and `Stderr` with an arbitrary instance of `Write`" (mentioned in #40007) should also perform this `close` operation.)
Repository: flutter
Issue: 'flutter daemon' reports an inconsistent device 'platform' field when starting up versus shutting down
Labels: tool,P3,team-tool,triaged-tool

The problem seems to be that 'flutter daemon' reports an inconsistent 'platform' field when starting up versus shutting down.

In the debugger, when a device is added, I see:
```
id: emulator-5554
name: Android SDK built for x86 64
platform: android-x64
```

On shutdown, the "id" and "name" fields are the same, but platform is incorrectly reported as:
```
platform:  android-arm
```

See https://github.com/flutter/flutter-intellij/issues/754 for more context.
Repository: react
Issue: Disabling or destroying event's target stops further event propagation.
Labels: Component: DOM,Type: Discussion

Disabling a submit button within a form on `onClick`, stops the event propagation to the forms `onSubmit` handler.

The fiddle:
 ```
import React from "react";

class SomeForm extends React.Component {
    constructor(props){
       super(props)
       this.state = {
          disabled:false
       }
    }
    handleClick() {
        this.setState({
          disabled:true
        });
        console.log("Clicked button");
    }
    handleSubmit(e){
      alert("Submitted the form")
    }
    render() {
        let opts = {};
        opts.disabled = this.state.disabled; // disabling the button stops the event propagation
        
        return (<form onSubmit={this.handleSubmit.bind(this)}>
              <button {...opts} 
                type="submit" 
                onClick={this.handleClick.bind(this)}>
                Continue
              </button>
         </form>)
    }
}

ReactDOM.render(<SomeForm />, document.getElementById('a'));
```
[JsBin with the live example](http://jsbin.com/kidabifono/1/edit?js,output)

Expected behavior: The event gets propagated unless explicitly swallowed via `e.preventDefault() && e.stopPropagation()`

**React version:** 15.4.2
**Browser:** Chrome 56.0.2924.87 x64

Unfortunately I cannot tell if this happens with older versions.
Repository: TypeScript
Issue: [Salsa] Support jsdoc `@namespace` 
Labels: Suggestion,Committed,Domain: JSDoc,Domain: JavaScript

Support treating variable declarations with [`@namespace`](http://usejsdoc.org/tags-namespace.html) JSDoc tag as TS namespaces.

```ts
/** @namespace */
var Documents = {
    /**
     * An ordinary newspaper.
     */
    Newspaper: 1,
    /**
     * My diary.
     * @private
     */
    Diary: 2
};
```
Repository: go
Issue: strings: Split1 slowdown
Labels: Performance

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
1.8

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"


### What did you do?

Run strings/BenchmarkSplit1 benchmark


### What did you expect to see?
Same performance as 1.7 

### What did you see instead?
3x slowdown
Split1-4                                    12.0ms ± 0%     52.7ms ± 2%   +337.56%          (p=0.002 n=6+6)


I've also reproduced this on tip. https://github.com/golang/go/commit/894650277670eed065566f803c642a8f80437456 renamed Split1 to SplitEmptySeparator, but kept benchmark the same. 
This performance regression was caused by https://github.com/golang/go/commit/b92d39ef6924fd5174449f95505d782f3f75db16 
Investigation shows that extra time is spent in  mostly GC,runtime.procyield and runtime.writebarrierptr_prewrite1. This is  due to missing stack check prologue in  utf8.DecodeRuneInString (disabling this optimization for DecodeRuneInString removes regression), which is called in a loop inside a benchmark.
Because of missing stack size check goroutine cannot be preempted, preventing concurent GC and resulting in worse performance.
If https://github.com/golang/go/issues/10958 is fixed, this particular regression should disappear.
I'm not sure whether having more preemption points is more important than having lower call overhead.
Repository: flutter
Issue: Hard to test exceptions during layout
Labels: a: tests,team,framework,P3,team-framework,triaged-framework

Exceptions during layout tend to cause a cascade of other exceptions, which makes it hard to test.  See https://github.com/flutter/flutter/pull/8321 for an example of a layout exception we'd like to test.
Repository: TypeScript
Issue: JSDoc - generate @type for a variable
Labels: Suggestion,Awaiting More Feedback,Domain: JSDoc,Domain: JavaScript

_From @egamma on February 22, 2017 11:21_

Generating a JSDoc comment for a variable/constant should generate an @type annotation
```js
/** |
var p;
```

Inserts

```js
/**
 * @type {any}
 */
var p;
```

_Copied from original issue: Microsoft/vscode#21110_
Repository: angular
Issue: feature: support multiple case matching in `ngSwitch`/`@switch`
Labels: feature,area: common,feature: under consideration

Like what anuglar 1 provide 
https://docs.angularjs.org/api/ng/directive/ngSwitch

Also mentioned in here:
https://github.com/angular/angular/issues/12174

Angular version: 2.4.7
Repository: react-native
Issue: [Android] position: absolute shouldn't be cut off within a container with border
Labels: Ran Commands,Platform: Android,Bug,Never gets stale

### Description

If you have an element `position: absolute` with negative offset within a container with a border, it's going to be cut off, it's like `overflow: hidden` of the container is suddenly enabled by the border. But if you remove the border of the container, it works well. This issue only happens on Android.

#3198 is a similar issue, and was reported with lots of discussions. However, I believe they are not exactly the same.

### Reproduction

I've made [an example on rnplay](https://rnplay.org/apps/CouTuQ) to reproduce the issue.

### Solution

TBD

### Additional Information

* React Native version: 0.33 (rnplay), 0.39 (the version I currently use)
* Platform: Android
* Operating System: MacOS
Repository: vue
Issue: <textarea> and <input type=text> cursor issue in IE 11.0
Labels: improvement

To reproduce:
- open https://vuejs.org/v2/guide/forms.html#Multiline-text with IE 11.0 (Edge) on Windows 7
- type some text in the textarea
- move the cursor at the beginning of the text (press the Home key)
- quickly type random chars
=> the cursor jumps to the end

same issue with input type=text (https://vuejs.org/v2/guide/forms.html#Text)
Repository: javascript
Issue: missing function expression name : naming / semantics
Labels: question

Assuming a function expression that toggles the visibility of `<tr>`s depending on some criteria,

```
const filterRows = function () {
...
}
```

`  39:23  warning  Missing function expression name  func-names`

I'm running into difficulty finding a name for that function expression as the rule suggests. More often it would be pure duplication of the variable in which the function is saved.

Any ideas on how to properly redact a meaningful name that isn't a duplicate of the variable name?
Repository: rust
Issue: "Stability" of the `-C passes` and `-C llvm-args` flags
Labels: I-needs-decision,A-stability,T-compiler,T-dev-tools,C-bug,A-cranelift,A-gcc

These flags are part of the stable `rustc` CLI but they let you tap into LLVM internals that we can't guarantee the stability of. Known usages of these flags include:

- Generating code coverage files. [Works on stable](https://github.com/rust-lang/rust/pull/38608#issuecomment-280797934)

- Fuzzing ([`cargo fuzz`](https://github.com/rust-fuzz/cargo-fuzz)). This additionally requires using a sanitizer so it requires nightly.

Concerns:

- An LLVM upgrade may break the functionality exposed by these flags. An LLVM pass may be removed or renamed, the code coverage format may change, etc.

- These flags may pose an obstacle for the adoption of non-LLVM backends (like Cranelift). For example, `-C llvm-args` has no meaning for the Cranelift backend.

We discussed this a bit towards the end of the last tools meeting. Some ways to communicate the unstability of these flags were brought up:

- Discourage their use. Something along these lines:
  - Stable: remove them from `-C help`, and print a warning if they are used
  - Beta/nightly: show a warning if these flags are used without the `-Z unstable-options` flag.

- Document what are the real stability guarantees of the functionality exposed by `-C` flags.

- Provide more targeted *unstable* `-Z` flags for the LLVM functionality that can be accessed through these flags and encourage users to use those instead the `-C` ones. For example, `-Z fuzz`, `-Z code-coverage`, etc.

cc @rust-lang/tools
Repository: rust
Issue: Error on bad pub(path) depends on module ordering
Labels: A-diagnostics,A-resolve,E-mentor,T-compiler,C-bug,WG-diagnostics

Which error message you get with a non-ancestral `pub(path)` visibility restriction depends on the ordering of module declarations.

These two struct declarations produce different errors;

```rust
mod foo {
    pub(in ::bar) struct Foo;
}

mod bar {
    pub(in ::foo) struct Bar;
}
```

The second produces the correct error:

```
error: visibilities can only be restricted to ancestor modules
```

The first produces this, incorrect error:

```
error[E0578]: cannot find module `bar` in the crate root
```

Presumably the pub(path) code is operating on the assumption the path, if real, has already been walked (because any correct path would have been walked), but this is not the case.
Repository: TypeScript
Issue: Support JSDoc `@function` 
Labels: Suggestion,Committed,VS Code Tracked,Domain: JSDoc

<!-- 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/21321

**TypeScript Version:**  2.2.1 / nightly (2.2.0-dev.201xxxxx)

**Code**

```ts
// test-module.d.ts
declare module 'test-module' {
    declare function func<T>(c: T): (y: any) => any;
}
```

```js
// example.js
import { func } from 'test-module';

/** 
 * @function
 * @param {number} c first number
 * @returns {number} result
 */
const thisDoesNot = func(1);
```

**Expected behavior:**
The JSDoc specifications give `thisDoesNot` a type of `(c: number) => number`

**Actual behavior:**
The type from the `*.d.ts` file is preferred instead, giving `thisDoesNot` a type of `(c: any) => any`
Repository: TypeScript
Issue: Relax visibility rules for type-aliases when 'declaration' compiler option is set.
Labels: Suggestion,Awaiting More Feedback

One common thing I use type-aliases for is to give shorter, more expressive names to commonly used types throughout a file.

This is especially useful for callback signatures that see common use throughout a module, as well as string-literal types used in a union type, like `type HttpMethods = 'get' | 'post' | 'put' | 'delete'`.

Let's look at the following simplified example:
```ts
type CharCallback = (c: string, i: number) => string;

export function mapOnChar(str: string, fn: CharCallback): string {
  const newStr = [];
  for (let i = 0, lim = str.length; i < lim; i++)
    newStr.push(fn(str.charAt(i), i));
  return newStr.join('');
}
```

When using the `declaration` compiler option, this example fails to compile with the following error:
`error TS4078: Parameter 'fn' of exported function has or is using private name 'CharCallback'.`

This initially makes sense; the type-alias is not being exported so it **is** private.  However, if you look at the type-alias, the only thing "private" about it is the name it was given, and an alias' name is not really important to or needed for a definition file.

There is no reason that the un-exported type-alias in the example cannot be automatically de-aliased back into `(c: string, i: number) => string` and that used in its place when the definition file is emitted.

However, if the alias in the example were to be exported, then it should not be de-aliased in the definition file.

I should point out that this suggestion is considering type-aliases only.  If the `CharCallback` type was re-written as `interface CharCallback { (c: string, i: number): string }`, then that would be a good case to raise an error.  An `interface` is  generally considered more "concrete" than a simple type-alias, and so its name should be preserved and used in the definition file.