sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react
Issue: Switch to using createFactory in compiler steps
Labels: Component: Optimizing Compiler,React Core Team

```js
var Foo = require('Foo');
function Bar() {
  return <Foo x={1}>Hi</Foo>;
}
```

Originally we intended to compile JSX to this format:

```js
var Foo = require('Foo');
var Foo_ = React.createFactory(Foo);
function Bar() {
  return Foo_({ x: 1, children: "Hi" });
}
```

That allows us to generate a factory that can be more optimized and resolves `defaultProps`.

There are some problems with generating an optimized factory in many cases because it can slow down start up. However, if you have an optimizing compiler that can resolve that, we can turn that on in those cases.

Another thing we can do is that if the function is a simple functional component then we can just return the functional component itself. So that it becomes just a straight through function call. At least if the element doesn't have a key. (Slight change in semantics but mostly not.)

An optimizing compiler or VM (that is aware of the type of "Foo" which not known to the Babel transform) can then infer that this function is just a function call and can then proceed to actually inline it.

For heavy functions it would be bad to do this though since it can expand the time a render is executed and work against the time slicing mechanism of Fiber.

Therefore, we might want to use a heuristic to determine if a functional component gets to be "inlined" or not. E.g. function length or something.

A good data point to use in a heuristic is whether the component is part of a loop or a closure (such as being part of a map);

```js
var Foo = require('Foo');
function Bar({ data }) {
  var children = [];
  for (var i = 0; i < data.length; i++) {
    children.push(<Baz>{data[i]}</Baz>);
  }
  return <Foo x={1}>{children}</Foo>;
}
```

or

```js
var Foo = require('Foo');
function Bar({ data }) {
  return <Foo x={1}>{data.map(d => <Baz>{d}</Baz>)}</Foo>;
}
```

We could change the transform to treat these special and flag them as part of a hot path by calling a special createFactory:

```js
var Foo = require('Foo');
var Baz = require('Baz');
var Foo_ = React.createFactory(Foo);
var Baz_ = React.createFactoryHot(Baz);
function Bar({ data }) {
  return Foo_({ x: 1, children: data.map(d => Baz_({ children: d })) });
}
```

The neat part of this model is that the transform can be pretty simple and readable.

The optimization itself is in createFactory and createFactoryHot.

It also doesn't have to reason about cross-module transforms. That's all taken care of by the optimizing compiler or VM.
Repository: rust
Issue: vtable accesses optimization in a tight loop.
Labels: I-slow,C-enhancement,C-optimization

This is a followup of #39992 .

This [playrust]( https://is.gd/foJgye):

```
#![crate_type="lib"]

use std::sync::Arc;

pub struct Wrapper {
    x: usize,
    y: usize,
    t: Arc<Foo>,
}

pub trait Foo {
    fn foo(&self);
}

pub fn test(foo: Wrapper) {
    for _ in 0..200 {
        foo.t.foo();
    }
}
```

Generates the tight loop:

```
.LBB1_1:
	incl	%ebp
	cmpl	$200, %ebp
	jge	.LBB1_2
	movq	16(%rbx), %rdi
	movq	24(%rbx), %rax
	leaq	15(%rdi), %rcx
	negq	%rdi
	andq	%rcx, %rdi
	addq	%r12, %rdi
.Ltmp12:
	callq	*%rax
.Ltmp13:
	jmp	.LBB1_1
```

while it seems to me the vtable access should be out of the loop, and it shouldn't be hard.
Repository: opencv
Issue: Move enums from cvflann to cv::flann
Labels: category: python bindings,category: flann,future

Now python bindings can't be generated for these enums. This causes usage of magic numbers like in #8245.
Repository: rust
Issue: std::io functions should document which ErrorKinds they can return
Labels: C-enhancement,P-medium,T-libs-api,E-medium,A-docs

See [this reddit post](https://www.reddit.com/r/rust/comments/5xrlys/hey_rustaceans_got_an_easy_question_ask_here/dekujpe/) where the question was "How can `File::open` fail?" and the information is sort of there in the docs, but I was reduced to guessing `io::ErrorKind` variants from the text description of errors. Similar to how Unix man pages list _exactly_ which `errno` values are possible, the `std::io` functions should list the exact variants they might return.
Repository: angular
Issue: ValueAccessor.writeValue is being called twice, first time with a phantom null value
Labels: type: bug/fix,freq2: medium,area: forms,state: confirmed,forms: ControlValueAccessor,P3

<!--
IF YOU DON'T FILL OUT THE FOLLOWING INFORMATION WE MIGHT CLOSE YOUR ISSUE WITHOUT INVESTIGATING
-->

**I'm submitting a ...**  (check one with "x")
```
[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
```

**Current behavior**
The ValueAccessor.writeValue method is called twice on a custom value accessor during component initialization, when a control is bound using [(ngModel)], first time with a phantom null value.

Note that this is not an issue in form builder scenarios when control is bound using [formControlName].

**Expected behavior**
ValueAccessor.writeValue should be called only once, with an actual value of the property bound to [(ngModel)].

**Minimal reproduction of the problem with instructions**
Run the following plunker:
[http://plnkr.co/edit/g5kjqQ9bQ9DF2cs4DbEH?p=preview](http://plnkr.co/edit/g5kjqQ9bQ9DF2cs4DbEH?p=preview)

MyValueAccessor is applied to the MyCmp component, the latter is bound using [(ngModel)] to the property initialized to 'Hello'. MyValueAccessor.writeValue writes the passed value to the console, the output looks as follows:
```
MyValueAccessor.writeValue: null
MyValueAccessor.writeValue: Hello
```

**What is the motivation / use case for changing the behavior?**
<!-- Describe the motivation or the concrete use case -->

**Please tell us about your environment:**
<!-- Operating system, IDE, package manager, HTTP server, ... -->

* **Angular version:** RC.4 - 2.4.9
<!-- Check whether this is still an issue in the most recent Angular version -->

* **Browser:** Chrome, IE11 
<!-- All browsers where this could be reproduced -->
 
* **Language:** TypeScript

* **Node (for AoT issues):** `node --version` =
Repository: TypeScript
Issue: Unicode Character Causing all Lines to Be shifted by one
Labels: Bug,VS Code Tracked

<!-- 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/22144
**TypeScript Version:**  2.1.1 / nightly (2.2.0-dev.201xxxxx)

**Code**

```ts
/**
 * 清除字节数组的内容，并将 length 和 position 属性重置为 0。 
 */
class Bla {
    foo(){}    
        bar(){}    

}
```

Note that there's an end byte sequence of `\xe2\x80\xa8` on the line of the comment (line separator perhaps)

**Bug**
This causes all lines returned by the TSServer to be off by one. It seems like the line is not being treated as a newline.

This in turn causes a number of issues, such incorrect symbol locations and incorrect formatting such as:

<img width="496" alt="screen shot 2017-03-07 at 10 17 09 am" src="https://cloud.githubusercontent.com/assets/12821956/23671223/4d660708-031f-11e7-81a4-e3f85f1a54ce.png">
Repository: TypeScript
Issue: Parameter type narrowing should consider function overload signatures
Labels: Suggestion,Needs Proposal

**TypeScript Version:**  2.2.1

**Code**

```ts
interface A { x: number; }
interface B { y: number; }

function foo(b: B): void;
function foo(a: A, b: B): void;
function foo(a: A|B, b?: B): void {
  if(b !== void 0) {
    console.log(a.y); // Error: Property 'y' does not exist on type 'A | B'
  }
}
```

The third (unified) function signature is hidden from the call site, and therefore any arguments should be able to be narrowed based on inspection of the provided arguments. In the case above, the second argument is only defined if the first argument is of type `A`, and so I would expect narrowing of the argument type to occur accordingly. One could make the argument that in the compiled output, it's possible for JavaScript to still pass subsequent arguments, but then why narrow types at all, seeing as JavaScript can always violate every type constraint that TypeScript makes inferences from?
Repository: TypeScript
Issue: Enable type parameter lower-bound syntax
Labels: Suggestion,In Discussion

<!-- 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.1.1

**Code**

```ts
class Animal {}
class Cat extends Animal {}
class Kitten extends Cat{}

function foo<A super Kitten>(a: A) { /* */ }
```

**Expected behavior:**
The type parameter `A` has the type `Kitten` as lower-bound. 

**Actual behavior:**
Compilation failure. The syntax is unsupported.

**Discussion:**
The upper-bound counterpart of the failed code works fine:

```ts
class Animal {}
class Cat extends Animal {}
class Kitten extends Cat{}

function foo<A extends Animal>(a: A) { /* */ }
```

People in issue [#13337](https://github.com/Microsoft/TypeScript/issues/13337) have suggested to use 

```ts
function foo <X extends Y, Y>(y: Y) { /* */ }
```

to lower-bound `Y` with `X`. But this does not cover the case where `X` is an actual type (instead of a type parameter).
Repository: neovim
Issue: :terminal range - ":%term foo" should read the output of `foo`
Labels: enhancement,terminal

- `nvim --version`: NVIM 0.2.0-dev
- Vim (version: 7.4.712-2ubuntu4) behaves differently? yes
- Operating system/version: Ubuntu 15.10
- Terminal name/version: GNOME Terminal 3.18.2
- `$TERM`: screen-256color

### Actual behaviour
I know `:%!cmd` runs in a non-interactive shell and I'm supposed to use `:te` but I can't find any way to pass lines from the current buffer to an interactive command for processing and read the output back to the buffer.

### Expected behaviour
Way to send some or all lines to `:te` in a similar way `%!cmd` works in Vim.

### Steps to reproduce using `nvim -u NORC`

Very practical usecase is to edit encrypted files - saving to hard drive (as well as swap) is undesired for security reasons. Creating such file would be:

```
nvim -u NORC
i foobar escape
:%!gpg -c
(normally here you type in and repeat the passphrase and then can save encrypted buffer)
(in NVIM the buffer doesn't get encrypted and process freezes)
```

For the time being I use Vim to do it but it would be nice to fully switch to NVIM.
Repository: go
Issue: context: TestLayersCancel flake
Labels: Testing,help wanted,NeedsFix

From trybot run https://storage.googleapis.com/go-build-log/dbcdd62f/openbsd-amd64-60_97787251.log 
```
--- FAIL: TestLayersCancel (0.46s)
	context_test.go:520: seed=1488986705610226342: ctx should not be canceled yet
	context_test.go:565: context.Background.WithCancel.WithDeadline(2017-03-08 07:25:05.810276628 -0800 PST m=+1.147363981 [-255.077111ms]).WithCancel.WithCancel.WithCancel.WithCancel.WithCancel.WithValue((*context.value)(0xc4200155b0), (*context.value)(0xc4200155b0)).WithCancel.WithCancel.WithCancel.WithValue((*context.value)(0xc4200155b8), (*context.value)(0xc4200155b8)).WithCancel.WithCancel.WithCancel.WithCancel.WithCancel.WithCancel.WithValue((*context.value)(0xc420015660), (*context.value)(0xc420015660)).WithCancel.WithCancel.WithCancel.WithCancel.WithCancel.WithCancel.WithValue((*context.value)(0xc420015668), (*context.value)(0xc420015668)).WithValue((*context.value)(0xc4200156d0), (*context.value)(0xc4200156d0)).WithCancel.WithCancel.WithCancel
FAIL
FAIL	context	1.745s
```
Repository: rust
Issue: Common well-known traits make "Trait Implementations" too verbose
Labels: T-rustdoc,P-low,C-feature-request

I find the "Trait Implementations" section of Rustdoc very hard to follow. It has low signal to noise ratio:

* Very common traits are displayed in full detail. For traits like `Copy`, `Clone`, `Default`, `Display`, `Debug`, `Hash`, etc. I don't need to see all the methods *inline* with their description. Just links to these traits would be enough. Generally I only need to know whether the type implements them or not.

* Similarly, traits used via operators are also displayed in full detail. `Eq`, `PartialEq`, `Add`, `Sub`, `Ord`, `PartialOrd`, etc. flood the documentation page with documentation *of* the traits, and the specific methods are even less relevant. The long verbose list makes it hard to see *which* traits are supported.

* If the type implements the same trait multiple times for slightly different types, the whole trait documentation is repeated multiple times. It is useful to know which type combinations are supported, but repeated function descriptions only lower signal to noise ratio. It's worst for [primitive types](https://doc.rust-lang.org/std/primitive.i32.html) where the list appears to be dominated by countless the variants of `Shr` and `Shl`, drowning out all other information.

The current layout does work well for less common/more specific traits, e.g. having entire trait documentation inlined is perfect for `*Ext` traits and makes sense in some cases like `impl Read for File`.

So I'm suggesting:

* Implement collapsing widget for trait implementations, which collapses documentation of methods, leaving only `[+] impl Trait for Foo` line.

* Collapse basic traits by default (`Copy`, `Clone`, `Debug`, `std::ops::*`, etc.). Not all traits in `std` are obvious, so the list of traits to display in a terse form would probably be manually curated.

* Group implementations of the same trait together, and collapse all implementations except one. For example [`File`](https://doc.rust-lang.org/std/fs/struct.File.html) displays all of `Read` docs twice, in two separate places. It makes the list longer and makes it harder to notice that there are two implementations. It would be clearer to display it as:

    > `[+] impl Read for File`
    > `[-] impl<'a> Read for &'a File`
    >  ` fn read(&mut self) …`
Repository: nvm
Issue: I have lost all node packages after installing nvm ?
Labels: installing node,needs followup

After installing nvm on   **PRODCUTION SERVER** everything is down since it have changed the default node folder I can no more have any installed packages. How to undo this effect and get the default node folder with all packages before installing nvm ?
Repository: rust
Issue: duplicate definition error depends on macro declaration order
Labels: C-enhancement,A-diagnostics,A-resolve,A-macros,T-compiler

Consider this code:

```rust
macro_rules! m { () => { mod Foo {} } }
struct Foo {}
m!();
```

The error is, "a module named `Foo` has already been defined in this module", pointing at line 2, the struct definition. Note that from, I would say, a user's perspective, the module is actually declared _after_ the struct (by calling the macro).

Furthermore, switching lines 1 and 2 (_not_ lines 2 and 3) switches the blame to the mod as being a duplicate.
Repository: godot
Issue: Sub-inherited scene is not updated properly in the editor
Labels: bug,topic:editor,confirmed

**Operating system or device - Godot version:**
Godot 2.1 and 3.0 probably too, after applying #7978 or #7979, respectively (without them the issues are much more serious)


**Issue description:**
If a scene indirectly inherits another, it doesn't get properly updated in the editor. The editor won't trigger the reload of the most derived scene, but will apply partially the changes made to the base scene.


**Steps to reproduce:**
1. Create a scene hierarchy (inheritance) like this: __C__ inherits __B__ which inherits __A__.
2. Open __A__ and __C__ in the editor.
3. Add some node to __A__.
4. Switch to __C__. Notice it isn't reloaded.
5. Reload manually with _Revert Scene_.
6. Switch back to __A__.
7. Remove the node you created.
8. Switch again to __C__. Notice how the node you created now appears as owned.
9.a. If you reload __C__ again, everything will be in place (with the phantom node gone).
9.b. If instead you save __C__, the node will be commited to the scene as if it had been created there initially.


**Link to minimal example project:**
Maybe one day.
Repository: rust
Issue: Misleading suggestion for missing trait bounds
Labels: C-enhancement,A-diagnostics,T-compiler,D-confusing,D-papercut

This is a simplified version of https://users.rust-lang.org/t/solved-iterator-filter-and-zip-in-place/9809/4

```rust
trait Foo {
    fn foo(self) -> Self;
}

impl<I, T, U> Foo for I
    where I: Iterator<Item = (T, U)>
{
    fn foo(self) -> Self {
        self
    }
}

fn main() {
    let v = vec![(1, 'a'), (2, 'b'), (3, 'c')];
    for x in v.iter().foo() {
        println!("{:?}", x);
    }
}
```

[The error is](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6d156770fb7bf83601c77a3d71592a02):

```
error: no method named `foo` found for type `std::slice::Iter<'_, ({integer}, char)>` in the current scope
  --> <anon>:15:23
   |
15 |     for x in v.iter().foo() {
   |                       ^^^
   |
   = note: the method `foo` exists but the following trait bounds were not satisfied: `&std::slice::Iter<'_, ({integer}, char)> : std::iter::Iterator`
   = help: items from traits can only be used if the trait is implemented and in scope; the following trait defines an item `foo`, perhaps you need to implement it:
   = help: candidate #1: `Foo`
```

The `note:` chose to report missing `&Iter: Iterator`, which is true, but it's not best thing it could have noted.  I guess it's looking at `&Iter` because of some auto-ref in the method call.  But if you force it to use `Iter` directly with UFCS, like `Foo::foo(v.iter())`, the note is more useful.

```
error[E0271]: type mismatch resolving `<std::slice::Iter<'_, ({integer}, char)> as std::iter::Iterator>::Item == (_, _)`
  --> <anon>:15:14
   |
15 |     for x in Foo::foo(v.iter()) {
   |              ^^^^^^^^ expected reference, found tuple
   |
   = note: expected type `&({integer}, char)`
              found type `(_, _)`
   = note: required because of the requirements on the impl of `Foo` for `std::slice::Iter<'_, ({integer}, char)>`
   = note: required by `Foo::foo`
```

So we *do* have an `Iterator`, just the wrong `Item`.
Repository: go
Issue: cmd/compile,runtime: avoid multiple returns from deferproc
Labels: compiler/runtime

We currently compile a defer to this:
```
x := deferproc(...)
if x != 0 { goto deferreturn }
...
deferreturn:
  deferreturn()
```
Normally deferproc returns 0.  However, when a subsequent panic is caught and the defer is run by the panic, and that defer recovers, then the runtime arranges the defer to return 1 at the same deferproc callsite.  The generated code then immediately jumps to deferreturn().

We should just make a recover'd panic return to the deferreturn callsite.  That may involve passing the pc of the deferreturn call to deferproc.

It would mean stack traces during panic point to the end of the function instead of to the site of the defer call.  That's arguably more correct (and matches the behavior on non-panic running of defers).

Part of the reason for this fix is that the code past deferproc() but before the branch gets executed twice in a defer/panic/recover scenario.  The SSA backend has been known to insert non-idempotent code in spots like that (See #19201.  That was for selectrecv not deferproc, but the same issue applies.)

The generated code may have originally been written this way because there was a push/pop sequence around the deferproc call, and the pops were required on the second return as well.  Those push/pop sequences were removed a long time ago.

@rsc @mdempsky 

See #19331
Repository: rust
Issue: std::process::Command no way to handle command-line length limits
Labels: T-libs-api,C-feature-accepted,A-process

The arg method doesn't track the total resulting command-line length and has no way of indicating to clients that the resulting command-line length would exceed the OS's underlying maximum length. This is fine for launching subprocesses with dozens of arguments, but renders it impossible to implement xargs or similar functionality.

Can I suggest a new method 

`fn try_add_arg<S: AsRef<OsStr>>(&mut self, arg: S) -> Option<S>`

with documentation saying that it's only preferable to `arg` when you're wanting multi-kilobyte command-lines?

`try_add_arg` would keep track of the number of args already added, and if the number of args or the resulting length would exceed the OS limits, then it ignores the argument and returns it back to the client. Otherwise it acts like the normal `arg` method and returns None.
Repository: react
Issue: No blur event fired when button is disabled/removed
Labels: Type: Bug,Component: DOM

**Do you want to request a *feature* or report a *bug*?**
Bug

**What is the current behavior?**
When a focussed button becomes disabled, React does not dispatch a blur event.

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/reactjs/69z2wepo/).**
1. Attach a blur event to a button
2. Focus the button
3. Make the button disabled or remove it from the DOM

**What is the expected behavior?**
A blur event will be dispatched.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**
15.1.0, not sure if it worked in previous versions.

Isolated test case: http://jsbin.com/fuvite/1/edit?html,css,js,output
Repository: TypeScript
Issue: type information from referenced file not available.
Labels: Bug,Domain: JavaScript

<!-- BUGS: Please use this template. -->

Excuse me if this is an issue in Visual Studio Code, please. I can move it.

But it seems I can't get type information from referenced files.... I can't seem to tell what I'm doing wrong.

**TypeScript Version:**  2.1.1 / nightly (2.2.0-dev.201xxxxx)

**rowdata.js**
```js
function RowData() {
   this.alpha = "";
   this.numeric = 0;
}
module.exports = RowData();
```

**data.js**
```js
/// <reference path="./rowdata.js" />
let RowData = require("./rowdata.js");
/** @type {RowData[]} */
let someArray = [];
someArray.push(new RowData());

/** @type {RowData} */
let someVal = new RowData(); // also not available
```

**Expected behavior:**

![image](https://cloud.githubusercontent.com/assets/769014/23767426/7ee09d62-04d6-11e7-825f-477104da7954.png)

Or something along these lines. This was just faked with a typedef higher in the file.

**Actual behavior:**

![image](https://cloud.githubusercontent.com/assets/769014/23767432/86526d96-04d6-11e7-86bf-d3f446beb59f.png)
Repository: neovim
Issue: execute() cannot be used with customlist command completion
Labels: bug-vim,has:repro

`execute()` appears to fail when being used in a completion function.

With the following Vim file, `MycommandRedir` will have completion, but `Mycommand` won't.

``` vim
function! MyComplete(ArgLead, ...)
  return [execute('echon 123')]
endfunction
function! MyCompleteRedir(ArgLead, ...)
  redir => r
  silent echon 123
  redir END
  return [r]
endfunction
command! -nargs=* -bar -complete=customlist,MyComplete Mycommand call Foo()
command! -nargs=* -bar -complete=customlist,MyCompleteRedir MycommandRedir call Foo()
```

I've reported this for Vim in https://github.com/vim/vim/issues/1141 a while ago, and then it worked in Neovim.

git-bisect shows that https://github.com/neovim/neovim/commit/7e7f01a3be90a4024d779a4032e5a914f850abdc broke it, which was meant to fix https://github.com/neovim/neovim/issues/5422.