sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Mapped type over string enum keys should have quick info showing computed enum members as keys, not identifiers/strings
Labels: Bug,Domain: Quick Info

<!-- 🚨 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 the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.5.3 - 3.7.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** enum, Record, Pick

**Code**

```ts
enum MyTypes {
  a = 'a',
  b = 'b',
}

type TypeMap = Record<MyTypes, string>;
// the language server tells us that this type is actually the same as the following annotationed type
// but, if I use the following type instead, then no error will occur
// type TypeMap = {
//   a: string;
//   b: string;
// };

const map: TypeMap = {
  a: 'text a',
  b: 'text b',
}

//   error TS2344: Type '"a"' does not satisfy the constraint 'MyTypes'.
type NewTypeMap = Pick<TypeMap, 'a'>;

const newMap: NewTypeMap = {
  a: 'abc',
}
```

**Expected behavior:**

Type inference works as expected, no error occurred.

**Actual behavior:**

```bash
 error TS2344: Type '"a"' does not satisfy the constraint 'MyTypes'.
```

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

<https://www.typescriptlang.org/play/?ssl=21&ssc=2&pln=1&pc=1#code/KYOwrgtgBAsgngFTgB2AZygbwFBSgQygF4oByfUgGlygCNizarsBfbbAFxWCiVRnzIGAJWABjAPYAnACYAeeH3SUoaDlICWIAOYA+ANzYA9EahdUvbgKEkcJvAQBcq9Vu2H7eWs7WadH0xZDbEkQNSgIQWclawYcPHxnUg5gAA8OAmYvJJT0umY2Tm4oADlgAHcYwQYABQ0xAGs5KuQVclIDdlDwkArrZzLKq2rbGkSyfFoxAqA>

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: create-react-app
Issue: .gitignore file 
Labels: issue: proposal

When executing npx create-react-app command .gitignore file is created after node_modules download, thus slowing down git checks, could it be created first?
Repository: TypeScript
Issue: need "libRoots" in tsconfig.json for private node-runtime type definition
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

can i write my own lib.*.d.ts for my node-runtime ?

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

add "libRoots" to tsconfig.json for personal runtime configuration (like "typeRoots")


## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->


for private node runtime ts type definition

## Examples

<!-- Show how this would be used and what the behavior would be -->

``` json
{
  "compilerOptions": {
    "libRoot": ["./node_modules/@eczn/my-node-runtime"],
     // or ... 
    "lib": [
      "es2017",
      "@eczn/my-node-runtime"
    ]
  }
}
```

## Checklist

My suggestion meets these guidelines:

* [x] 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
* [ ] 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: react
Issue: react-test-renderer: the findByType method doesn't work with memo components
Labels: Type: Bug,Component: Test Renderer

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**
Feature

**What is the current behavior?**
Whenever I try something like:

```
ReactTestRenderer.create(<SomeComponent />).root.findByType(SomeMemoComponent);
```

I get the following error: `No instances found with node type: "undefined"`. The only way I found for this to work was to reference the `type` property of memo components like this:

```
ReactTestRenderer.create(<SomeComponent />).root.findByType(SomeMemoComponent.type);
```

I am fine with this solution but then flow complains that `type` doesn't exist so I find myself fixing this with `$FlowFixMe` all over the place.

**What is the expected behavior?**

I would expect that passing a memo component to `findByType` would work. Or that flow would recognize the `type` property of memo components. I think both should work, specially the first option.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

No, it never worked as far as I know.
Repository: pytorch
Issue: torch.std() returns nan for single item tensors.
Labels: triaged,module: numpy,small

## 🐛 Bug

np.std(4) returns 0 whereas torch.std(torch.tensor(4)) returns NaN. This causes numerical instabilities in certain situations.

## To Reproduce

import numpy as np
np.std(4)  # returns 0

import torch
torch.std(torch.tensor(4.))  # returns NaN

## Expected behavior

It should also return 0 to be consistent.

## Environment

PyTorch 1.3

cc @ezyang @gchanan @zou3519 @jerryzh168
Repository: storybook
Issue: [RFC] A storyoutput addon, for storybook/html
Labels: feature request,addon: storysource

**Is your feature request related to a problem? Please describe.**
With storybook/html, we document CSS only components.
So for each story of a component, we just need the right markup using the right CSS classes.
I don't want to duplicate in each story the markup, so I use JS by using a `render` function that takes some params.
There is the storysource addon, but if I use it to show the code, it will show me the JS code, the `render` function call, while in a storybook/html context, I care only about the output, the markup that is rendered in the canvas.

**Describe the solution you'd like**
A storyoutput addon, that will render the story output markup.

**Describe alternatives you've considered**
Using the storysource addon with story functions being just HTML rendering, but this will duplicate the HTML markup, while I'd prefer it to be centralized in a JS function (BTW, that function can be used in other component stories, for compound components).

**Are you able to assist bring the feature to reality?**
no, I feel that such addon is too advanced for my JS skills (I'm PHP developer)

**Additional context**
I thought about this idea in the context of storybook/html only, but maybe it can useful for others
Repository: vscode
Issue: The horizontal wheel of mouse is invalid
Labels: bug,upstream,trackpad/scroll,chromium

Issue Type: <b>Bug</b>

mouse: logi m590
The horizontal wheel of mouse does not work in VS code.

VS Code version: Code 1.39.2 (6ab598523be7a800d7f3eb4d92d7ab9a66069390, 2019-10-15T15:35:18.241Z)
OS version: Windows_NT x64 10.0.18362


<!-- generated by issue reporter -->
Repository: pytorch
Issue: [jit] Saving a `ScriptFunction` to a buffer doesn't work
Labels: oncall: jit,triaged

```python
@torch.jit.script
def fn(x):
    return x

# Works fine
torch.jit.save(fn, io.BytesIO())

# Doesn't work
fn.save(io.BytesIO())
```

cc @suo
Repository: rust
Issue: Can't use DoubleEndedIterator for inclusive ranges 
Labels: C-enhancement,T-libs-api,A-iterators

Code:
```rust
fn main() {
    let size = 10;
    let h = size / 2;
    let _iter = (-h..=h).step_by(size as usize).rev();
}
```

Error:
```
error[E0277]: the trait bound `std::ops::RangeInclusive<i32>: std::iter::ExactSizeIterator` is not satisfied
 --> src/main.rs:4:48
  |
4 |     let iter = (-h..=h).step_by(size as usize).rev();
  |                                                ^^^ the trait `std::iter::ExactSizeIterator` is not implemented for `std::ops::RangeInclusive<i32>`
  |
  = help: the following implementations were found:
            <std::ops::RangeInclusive<i16> as std::iter::ExactSizeIterator>
            <std::ops::RangeInclusive<i8> as std::iter::ExactSizeIterator>
            <std::ops::RangeInclusive<u16> as std::iter::ExactSizeIterator>
            <std::ops::RangeInclusive<u8> as std::iter::ExactSizeIterator>
  = note: required because of the requirements on the impl of `std::iter::DoubleEndedIterator` for `std::iter::StepBy<std::ops::RangeInclusive<i32>>`
```

I think Rust is not getting safer without ExactSizeIterator implementation for RangeInclusive. The behavior like the one above is not obvious for average Rust coder. Moreover, the workaround exists:
```rust
fn main() {
    let size = 10;
    let h = size / 2;
    let _iter = (-h..h+1).step_by(size as usize).rev();
}
```

related: #36386
Repository: pytorch
Issue: [feature request] torch.kthvalue to support a new argument largest
Labels: triaged,module: sorting and selection

Sometimes we want the second largest element/indices. torch.topk can be used as workaround, but it would be nice if `kthvalue` directly supported a new `largest=True` argument.
Repository: three.js
Issue: CameraHelper needs 2 frames to update itself
Labels: Bug

https://jsfiddle.net/et67ogua/ comment line 49 (requestAnimationFrame). the result:
![Screen Shot 2019-11-07 at 20 03 34 ](https://user-images.githubusercontent.com/242577/68419335-4f955700-019a-11ea-867b-78d02cd659fe.png)

the expected look is still this:
![Screen Shot 2019-11-07 at 20 03 56 ](https://user-images.githubusercontent.com/242577/68419323-486e4900-019a-11ea-83bc-bcc20c069226.png)
Repository: pytorch
Issue: [RFC] RPC timeout
Labels: triaged,module: rpc

# Issue

Now we have an arumgnet called `rpc_timeout` in the `def init_model_parallel` function.
The name feels like it's a client-perspective, round-trip RPC timeout.

While, looking at it's [implementation](https://github.com/pytorch/pytorch/blob/26f57cbe5eef74949dbd37193e297b18d33092df/torch/csrc/distributed/rpc/process_group_agent.cpp#L371-L392), it's actually the server-side processing timeout. Client side takes no action at the moment.
That means, if the server-side failed to send the response, the user side future would wait forever.

# API

I suggest that we provide an `rpc_timeout` arg on the 2 RPC entries,
- `rpc.rpc_async(func, args, kwargs, to, timeout: Optional[timedelta] = None) -> Any`
- `rpc.rpc_sync(func, args, kwargs, to, Optional[timeout] = None) -> FutureMessage`.

If `timeout` is not provided (passed as `None`), server side uses the global timeout set in `def init_model_parallel`.

If `timeout` is provided, it means a per-RPC timeout is specified. 
- For `rpc.rpc_async`, the `future_message` returned to the client should automatically cancle on timeout, and if users call `future_message.wait()`, it should raises a `TimeoutError`. For `rpc.rpc_sync`, it should block untill timeout and raise a `TimeoutError`.
- The `Message` being passed from client to server should also contains this per-RPC timeout. On the server side, the timeout caontained in the message should be treated as `per_rpc_server_proessing_timeout`, thus overwriting the server-side global processing timeout.

Since the  `rpc_timeout` passed to `def init_model_parallel` could be overwritten by per-RPC call, it should be renamed to `global_rpc_server_processing_timeout`.

Implied by the above, for supporting client-side timeout, the generic Future (#28923) needs to support timeout. A reference implementation is [`folly::Future::within(..)`](https://github.com/facebook/folly/blob/master/folly/futures/Future.h#L853).

# Policy

> For user RPCs, we always fill that in with the default rpc timeout.
> For system RPCs, it'll default to 0 (which would be infinite) unless the system RPC sets it.

See https://github.com/pytorch/pytorch/issues/29018

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528
Repository: flutter
Issue: Long tap on Scaffold Edge should start Drawer dragging behavior
Labels: c: new feature,framework,a: animation,f: material design,f: gestures,P3,team-design,triaged-design

## Use case

Right now, the two ways to open a drawer are either by having it to open by a button (in an `AppBar`, for example), or by swipping from the sides.

Since Android Q (10), if an user enables the Gesture Navigation, it can no longer open the Drawer menu by swipping from the edges, since that is the gesture for "Back". Flutter should provide a third Drawer opening method, by letting users tap and hold in the edges of a scaffold, and start the drag behavior of the scaffold's `Drawer`.

## Proposal

Enable the drawer to be open from a `onLongPress` in the Edges of a `Scaffold`.

This behavior can be observed in some Google apps, like the Gmail App:

![gmail drawer dragging behavior](https://media.giphy.com/media/S3bTmD80Mz7bj9slMh/giphy.gif)
Repository: TypeScript
Issue: Suggestion: flip the assignment direction of generated enums to save some bits
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

enum assignment

## Suggestion

Flip the assignment order

## Use Cases

enums

## Examples

```ts
enum Action {
  foo
  bar
  baz
  thequickbrownfoxjumpsoverthelazydog
}
```

currently generates:

```ts
"use strict";
var Action;
(function (Action) {
    Action[Action["foo"] = 0] = "foo";
    Action[Action["bar"] = 1] = "bar";
    Action[Action["baz"] = 2] = "baz";
    Action[Action["thequickbrownfoxjumpsoverthelazydog"] = 3] = "thequickbrownfoxjumpsoverthelazydog";
})(Action || (Action = {}));
```

Suggesting instead:

```ts
"use strict";
var Action;
(function (Action) {
    Action[Action[0] = "foo"] = 0;
    Action[Action[1] = "bar"] = 1;
    Action[Action[2] = "baz"] = 2;
    Action[Action[3] = "thequickbrownfoxjumpsoverthelazydog"] = 3;
})(Action || (Action = {}));
```

## Checklist

My suggestion meets these guidelines:

* [x] 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: TypeScript
Issue: Generator functions which have a return type of a union of Iterator/AsyncIterator have a yield type of never
Labels: Needs Investigation

**TypeScript Version:**  3.7.2

**Search terms:** generator iterator asynciterator type union never 

**Code**

example.ts
```ts
type NumberIterator = Iterator<number> | AsyncIterator<number>;
type NumberGenerator = Generator<number> | AsyncGenerator<number>;

function *numbers(): NumberIterator {
    yield 1;
}
```
A type alias which is a union of `Iterator` and `AsyncIterator` is used as the return type of a synchronous generator.

**Expected behavior:**

Code compiles.

**Actual behavior:**

```
example.ts(5,11): error TS2322: Type '1' is not assignable to type 'never'.
```

If you replace `NumberIterator` with `NumberGenerator` as the return type the function above, the code correctly type-checks. Something is wrong here.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

https://www.typescriptlang.org/play/index.html?target=99&ssl=5&ssc=2&pln=1&pc=1#code/C4TwDgpgBAcgrgWwEYQE4ElhoIbAPapQC8UmO+qAPAHaIqoB8UAPlAIIDOI1AxmargI06aBgG4AUBIBmcXsACWealABUtZGg4AKAJQAuWCIxYBFKAG8JUG1BAKIAGwAmUAIySAvkA

The playground link won’t work because the playground doesn’t support async iterators yet (https://github.com/microsoft/TypeScript-Website/issues/15).

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
#30790 Strongly-typed iterator PR
Repository: rust
Issue: Should std::future::Future be marked #[fundamental]
Labels: T-lang,C-feature-request,T-types

`Fn` is marked `#[fundamental]` which makes it possible to do

```rust
trait Test {
}

impl Test for bool { }
impl<F, T> Test for F: where F: Fn() -> T { }
```

but since `std::future::Future` is not marked as `#[fundamental]` it is not possible to do the same with futures.

Marking things as `#[fundamental]` should be done with care but at least the superficial simlarity with ``Fn` seems to indicate that `Future` would also be a candidate for the attribute?
Repository: flutter
Issue: Fonts do not load when specifying current project as package 
Labels: c: new feature,framework,a: assets,a: typography,c: proposal,P3,team-framework,triaged-framework

Currently the way that Images and Fonts handle the package parameter is inconsistent. 

When using images, you can define the image like so: 
assets:
    - packages/demo1/images/logo.png

Then, the image will load fine with the: Image.asset("images/logo.png", package: "demo1"). This works when the image is in a standalone project, and also when it is imported as a package into another project.

However, fonts works differently. If I define a font as 
asset: packages/demo1/fonts/Poppins-Bold.ttf

And use: TextStyle(fontFamily: "Poppins", package: "demo1")

The font does not render correctly in the root project ("demo1"). If I reference this package from another package, then the font **will** load correctly.

So, to recap:
* Images w/ package specifier work in their own package, and as dependancies. 
* Fonts w/ package specifier, do not work in their own package, but do work as dependancies
Repository: pytorch
Issue: IValue can't be constructed from one of `int`, `long`, or `long long`.
Labels: oncall: jit,triaged

## 🐛 Bug

IValue can't be constructed from one of `int`, `long`, or `long long`.

## To Reproduce

Attempt to compile this:

```cpp
#include <vector>
#include <torch/script.h>

void func() {
  std::vector<torch::jit::IValue> inputs;
  inputs.push_back((int)0);
  inputs.push_back((long)0);
  inputs.push_back((long long)0);
}
```

```
/home/dreiss/work/demo-libtorch/example-app.cpp:8:32: error: conversion from ‘long long int’ to ‘std::vector<c10::IValue, std::allocator<c10::IValue> >::value_type’ {aka ‘c10::IValue’} is ambiguous
    8 |   inputs.push_back((long long)0);
      |                                ^
/home/dreiss/opt/libtorch/include/ATen/core/ivalue.h:251:3: note: candidate: ‘c10::IValue::IValue(const char*)’
  251 |   IValue(const char* v): IValue(std::string(v)) {}
      |   ^~~~~~
/home/dreiss/opt/libtorch/include/ATen/core/ivalue.h:226:3: note: candidate: ‘c10::IValue::IValue(bool)’
  226 |   IValue(bool b)
      |   ^~~~~~
/home/dreiss/opt/libtorch/include/ATen/core/ivalue.h:215:3: note: candidate: ‘c10::IValue::IValue(int32_t)’
  215 |   IValue(int32_t i)
      |   ^~~~~~
/home/dreiss/opt/libtorch/include/ATen/core/ivalue.h:209:3: note: candidate: ‘c10::IValue::IValue(int64_t)’
  209 |   IValue(int64_t i)
      |   ^~~~~~
/home/dreiss/opt/libtorch/include/ATen/core/ivalue.h:192:3: note: candidate: ‘c10::IValue::IValue(double)’
  192 |   IValue(double d)
      |   ^~~~~~
```


## Expected behavior

Should construct an IValue?

## Environment

```
OS: Fedora release 30 (Thirty)
GCC version: (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
CMake version: version 3.14.4

cat ~/opt/libtorch/build-version 
1.4.0.dev20191107+cpu
```

## Additional context

The issue here is that IValue has constructors for `int32_t` and `int64_t`, which (on my machine) are `int` and `long`.  So the constructor for `long long` is ambiguous.  On another machine, `int64_t` might be `long long`, so trying to construct with `long` will be ambiguous.

My proposal is to replace the IValue constructors for `int32_t` and `int64_t` with constructors for `int`, `long`, and `long long`.  I can put up a PR for this if the plan is acceptable.


cc @suo
Repository: pytorch
Issue: NLLLoss reduce=True returning nan in float16
Labels: module: nn,triaged

## 🐛 Bug
**Version**
torch 1.3.1
torchvision 0.4.1

**Notes**
NLLLoss reduce=True doesn't seem to work in float16.
Also, training a model with loss1 in float16 doesn't seem to decrease the loss. (The model trains fine with loss1 in float32)
Possible related to #14878

**Code to reproduce**
```
#Input
input = torch.rand(32,11,256,256).cuda().half()
target =torch.LongTensor(32,256,256).random_(0, 10).cuda()
loss1 = nn.NLLLoss(reduce=False).cuda().half()
loss2 = nn.NLLLoss(reduce=True, reduction='mean').cuda().half()
print(torch.mean(loss1(input,target)) )
print(loss2(input,target))
```

```
#Output
tensor(-0.4995, device='cuda:0', dtype=torch.float16)
tensor(nan, device='cuda:0', dtype=torch.float16)
```
Repository: opencv
Issue: /usr/local/lib/libopencv_imgcodecs.so.3.4:undefined symbol: _ZN2cv6detail17check_failed_autoEmmRKNS0_12CheckContextE.
Labels: priority: low,category: build/install,incomplete

##### System information (version)
- OpenCV => 3.4.7
- Operating System / Platform => Ubuntu16.04.6
- Compiler => gcc5.5

##### Detailed description
After making matcaffe (caffe with matlab) successfully, when I make mattest (a test), I met the follow problem:
Invalid MEX-file '/home/caffe/matlab/+caffe/private/caffe_.mexa64':/usr/local/lib/libopencv_imgcodecs.so.3.4:undefined symbol: _ZN2cv6detail17check_failed_autoEmmRKNS0_12CheckContextE.
 
Error in caffe.set_mode_cpu (line 5)
caffe_('set_mode_cpu');
 
Error in caffe.run_tests (line 6)
caffe.set_mode_cpu();

I don't know how to solve it,  and there seems be the same problem in #13811.
Repository: flutter
Issue: CupertinoDateTime Picker not changing format when language is changed
Labels: framework,a: internationalization,f: cupertino,P2,team-design,triaged-design

the date format in ios 13 look like
"Wed 6 Nov"
![Image from iOS](https://user-images.githubusercontent.com/13308845/68446615-3d9bce80-0203-11ea-9673-20271a19fab8.png)
but when we apply widgets it's different
"Wed Nov 6"
![Screen Shot 2019-11-07 at 12 39 31](https://user-images.githubusercontent.com/13308845/68446638-52786200-0203-11ea-9f04-d1097bb35d82.png)

My flutter doctor output:
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.9.1+hotfix.6, on Mac OS X 10.13.6 17G65, locale
    en-IN)
 
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.1)
[✓] Xcode - develop for iOS and macOS (Xcode 10.1)
[✓] Android Studio (version 3.5)
[✓] VS Code (version 1.39.2)
[✓] Connected device (1 available)

• No issues found!