sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Generators with extended unions, null and undefined produces compiler errors
Labels: Needs Investigation,Rescheduled

I've run into a weird problem in a project that uses async generators. I've reduced the problematic code to the example
below, which also fails in a similar way that my actual code does.

There seem to be several conditions that must be fulfilled:

1. Type `T` is a union.
2. The argument generator extends `T` (with `WithID` in the example).
3. The argument generator also accepts *both* `null` and `undefiened`.
4. The provided generator *has* a return signature.
5. The provided generator's return signature yields `T` and *either* `null` or `undefined` (but not both).

Change just any of these conditions in the playground, and the error goes away ...

**TypeScript Version:**  4.0.0-beta (and below)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** generator null undefined

**Expected behavior:** No errors.

**Actual behavior:** A strange error message when `doSomething()` is called.

<!-- Did you find other bugs that looked similar? -->
**Related Issues:** No

**Code**
```ts
interface WithID {
    id?: number;
}

type MyEvent = { type: "number", value: number } |  { type: "string", value: string };
//interface MyEvent { type: "number" | "string", value: number | string };

function doSomething<T extends object>(gen: Generator<T & WithID | undefined | null>) {
    // ...
}

function* readEvents(): Generator<MyEvent | undefined> {
    yield undefined;
}

doSomething(readEvents());

```



<details><summary><b>Output</b></summary>

```ts
"use strict";
//interface MyEvent { type: "number" | "string", value: number | string };
function doSomething(gen) {
    // ...
}
function* readEvents() {
    yield undefined;
}
doSomething(readEvents());

```


</details>


<details><summary><b>Compiler Options</b></summary>

```json
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "moduleResolution": 2,
    "target": "ES2019",
    "jsx": "React",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/play?target=6&ts=4.0.0-beta#code/JYOwLgpgTgZghgYwgAgOrDACwJIBFkDeAUMqcsACYD8AXMiAK4C2ARtANxEC+RRYAngAcUAWX4BRAG4RwyALyFkA4XQBEjVtFUAaZJLgAbBhDoa2UZF2QAfUgSVCTyVQGcwUUAHMdew8bpuHiCelpwA9GGgkLCIohLSsvbKTurM5qo2zoFePvpGTmbQmdnBobwwDCAIYMAA9iDIFLUAyrVMEFheADwAKsgQAB6QIBQuyLUsAFYQ1QB8ABSeMnQA4jLQcGC1UL3IAGRoGDj4tpUUEDCgEBSZjAYGswCUhCRkEcgAdF-c5ZXVdSAAFTIKAQOAUKQyMAueaPVbrKCbbZdMSQ2SnEYXK4UWYvMjIfjACAGG5nLEga6cHhEJqtdqdYLzUHgtHQ2GPThAA)
Repository: flutter
Issue: Im using Stepper in hebrew, the continue button appears in hebrew text but there is an overflow
Labels: framework,f: material design,a: internationalization,team-design,triaged-design


![Screen Shot 2020-08-14 at 13 12 16](https://user-images.githubusercontent.com/67031389/90239183-d06f3680-de2f-11ea-8d19-700c13f6b113.png)
<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Steps to Reproduce

<!-- You must include full steps to reproduce so that we can reproduce the problem. -->

1. Run `flutter create bug`.
2. Update the files as follows: ... <!-- include every file that is different from the template app! -->
3. ... <!-- describe how to reproduce the problem -->

**Expected results:** <!-- what did you want to see? -->

**Actual results:** <!-- what did you see? -->

<details>
  <summary>Logs</summary>

<!--
      Run your application with `flutter run --verbose` and attach all the
      log output below between the lines with the backticks. If there is an
      exception, please see if the error message includes enough information
      to explain how to solve the issue.
-->

```
```

<!--
     Run `flutter analyze` and attach any output of that command below.
     If there are any analysis errors, try resolving them before filing this issue.
-->

```
```

<!-- Finally, paste the output of running `flutter doctor -v` here. -->

```
```

</details>
Repository: excalidraw
Issue: behavior: closing multi-point shapes
Labels: discussion

Currently when you move/create last point close to the first (~10px), we auto-close the shape. This is not a real point merge, the two points are still retained separately.

This has following behavior:

1. It creates a sharp corner:

   ![image](https://user-images.githubusercontent.com/5153846/90244714-9bfc7a00-de31-11ea-8310-065f5507068a.png)

2. During edit, moving one of the terminal points does not move the other one:

	![excal_drag_terminal_point](https://user-images.githubusercontent.com/5153846/90244783-bd5d6600-de31-11ea-8c08-6f5fe4641d17.gif)

Both of these could be considered bugs or features. 

For example, (1) is good for creating shapes like the above heart. But it's bad for creating other shapes where you want to make all corners round.

(1) can be "fixed" by physically merging the two points instead of just overlaying them across one another, but we'd then lose the ability for sharp corner. Or it can be fixed by implementing a separate "fully-round" sharpness option as [suggested](https://github.com/excalidraw/excalidraw/pull/1931#issuecomment-674017879) by @dai-shi.

(2) can be good for disconnecting the two shapes, but bad when you try to move them both. On the whole I think (2) should be fixed, and the ability to disconnect would be done simply by deleting the point. If we don't want physically merging, we can just dynamically move both points when moving one of them.
Repository: PowerToys
Issue: [KBM] Swapping Win and Alt does not work for shortcuts like Win-R (Run)
Labels: Issue-Bug,Product-Keyboard Shortcut Manager

<!--
**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.
-->

## ℹ Computer information

- PowerToys version: v0.20.1
- PowerToy Utility: what's this?
- Running PowerToys as Admin: No
- Windows build number:  Version 1909 (OS build18363.1016)

## 📝 Provide detailed reproduction steps (if any)

I wanted to swap my Windows and Alt keys, so my keyboard shortcuts are more like macOS, since I have to work on both systems now.

I went into Keyboard Manager and mapped left Alt key to left Windows key, and left Windows key to left Alt key.  Now pressing my (physical) Alt + R does NOT bring up the Run dialog.  Neither does pressing my (physical) Win +r.

### ✔️ Expected result

Pressing Alt (remapped to Win) + R brings up the Run dialog.

### ❌ Actual result

The screen just sort of blinks.

But nothing happens.

## 📷 Screenshots

_Are there any useful screenshots? WinKey+Shift+S and then just paste them directly into the form_
Repository: rust
Issue: Improve "visibility" of rustdoc books ("stable" and unstable ones)
Labels: T-rustdoc,A-docs

Currently, very few people know the existence of https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/ and of https://doc.rust-lang.org/rustdoc/what-is-rustdoc.html, which is a shame considering how huge is the amount of available options and tips.

I suggested adding those links (the unstable one only in unstable build of course) at the beginning of the "help display".
Repository: storybook
Issue: Controls: string literal union types render as text fields when args supplied
Labels: bug,addon: controls

**Describe the bug**

For string literal union types, text fields should render as select dropdowns when args are supplied.

**To Reproduce**
Steps to reproduce the behavior:

1. Create a TypeScript React component with a string literal union type (e.g., `'foo' | 'bar' | 'baz'`).
2. Create a story for the component and supply a value in `<Story>.args`
3. Observe a text field containing the value

**Expected behavior**

In 3, I expect to see a dropdown instead of a text field (which is the behavior when args is not supplied)

**Screenshots**

Here I have a story with a component that has a string literal union type repeated for props `icon`, `startIcon`, and `endIcon`. Only `icon` is supplied via args (see code snippet below).

<img width="1213" alt="Screen Shot 2020-08-14 at 8 44 29 AM" src="https://user-images.githubusercontent.com/1571918/90267450-685a2980-de0a-11ea-88c3-7f6d18d34561.png">

**Code snippets**

```ts
interface ButtonProps {
  startIcon?: "fullscreen" | "style" | ...;
  endIcon?: "fullscreen" | "style" | ...;
  icon?: "fullscreen" | "style" | ...;
}

const Template = (args) => <Button {...args} />;

export const IconButton = Template.bind({});
IconButton.args = {
  icon: 'star',
  tooltip: 'Star Icon',
  dsOnClick: asyncAction('dsOnClick'),
};
```
Repository: pytorch
Issue: torch.dot throws an error for input tensors of different dtypes
Labels: triaged,enhancement,module: numpy,module: type promotion

We should add type promotion for `torch.dot` and [`[WIP]torch.vdot`](https://github.com/pytorch/pytorch/pull/43004) to have numpy like API.

```
>>> torch.dot(torch.tensor([1j]), torch.tensor([2]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: dot : expected both vectors to have same dtype, but found ComplexFloat and Long
```

cc @mruberry @rgommers @nairbv
Repository: PowerToys
Issue: [Run] Switch to running app instead of opening a new one
Labels: Idea-Enhancement,Product-PowerToys Run

## 📝 PowerToys Run Auto Focus

PowerToys opens a new instance of an app even if there is an instance. Focusing on that instance instead of opening a new one would be quite handy. Maybe a checkbox for toggling this behaviour?

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: pytorch
Issue: LSTM::permute_hidden breaks Liskov substitution principle
Labels: module: rnn,module: typing,triaged

While working on PR https://github.com/pytorch/pytorch/pull/43068, I found a method on `LSTM` which breaks the Liskov substitution principle. The class `LSTM` inherits from `RNNBase` and redefines a method called `permute_hidden` which returns two tensors ([ref](https://github.com/pytorch/pytorch/blob/fcc10d75e1a0c1c2474de559124620ca6b580313/torch/nn/quantized/dynamic/modules/rnn.py#L396-L400)):

```python
class LSTM(RNNBase):
    ...
    def permute_hidden(self, hx, permutation):
        # type: (Tuple[Tensor, Tensor], Optional[Tensor]) -> Tuple[Tensor, Tensor]
        if permutation is None:
            return hx
        return apply_permutation(hx[0], permutation), apply_permutation(hx[1], permutation)
```

`RNNBase` defines this method returning only one tensor ([ref](https://github.com/pytorch/pytorch/blob/fcc10d75e1a0c1c2474de559124620ca6b580313/torch/nn/quantized/dynamic/modules/rnn.py#L189-L193))

```python
class RNNBase(torch.nn.module):
    ...
    def permute_hidden(self, hx, permutation):
        # type: (Tensor, Optional[Tensor]) -> Tensor
        if permutation is None:
            return hx
        return apply_permutation(hx, permutation)

```

Given this difference, it is not possible to correctly type `permute_hidden` because of the Liskov substitution principle. Should `LSTM` not inherit from `RNNBase`?

cc @ezyang @malfet @rgommers @zou3519
Repository: flutter
Issue: Ensure root a11y view is not redundantly invalidated on Android
Labels: team,platform-android,engine,a: accessibility,P2,team-android,triaged-android

Requested labels: accessibility, android, engine, (and maybe others).

According to [this code in AccessibilityBridge.java](https://github.com/flutter/engine/blob/dbf7e831199d1af7f9f5e334a08b9cca669fd119/shell/platform/android/io/flutter/view/AccessibilityBridge.java#L943), it looks like the `rootAccessibilityView` should be manually [invalidated ](https://developer.android.com/reference/android/view/View#invalidate()) when a node is focused, **if** there was no previously focused node.

According to the comment at the code linked above:

> When Android focuses a node, it doesn't invalidate the view.
> (It does when it sends ACTION_CLEAR_ACCESSIBILITY_FOCUS, so
> we only have to worry about this when the focused node is null.)

However, before this code is reached, the `TYPE_VIEW_ACCESSIBILITY_FOCUSED` [event is sent](https://github.com/flutter/engine/blob/dbf7e831199d1af7f9f5e334a08b9cca669fd119/shell/platform/android/io/flutter/view/AccessibilityBridge.java#L941), which will trigger `ACTION_CLEAR_ACCESSIBILITY_FOCUS`, which both sets `accessibilityFocusedSemanticsNode` [to null](https://github.com/flutter/engine/blob/dbf7e831199d1af7f9f5e334a08b9cca669fd119/shell/platform/android/io/flutter/view/AccessibilityBridge.java#L933) and invalidates the `rootAccessibilityView` (according to the comment above) before this code runs. Since `accessibilityFocusedSemanticsNode` will be set to null, this condition should always pass, which sounds like it will make a redundant call to `rootAccessibilityView.invalidate()`.

I am unsure of performance impact, and whether or not there are situations where sending `TYPE_VIEW_ACCESSIBILITY_FOCUSED` might not trigger Android/TalkBack to respond by sending `ACTION_CLEAR_ACCESSIBILITY_FOCUS`, or if there are situations where `ACTION_CLEAR_ACCESSIBILITY_FOCUS` does not invalidate the root view. Further investigation is required.

I no longer have access to the testing conditions where I discovered this anomaly, so I can't include output from `flutter doctor -v`.

Device: `Pixel 3a`
Flutter version: `approximately 1.21`
Repository: rust
Issue: Expotential compile time with recursive trait bounds
Labels: A-trait-system,I-compiletime,T-compiler,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

While developing diesel we've hit a surprising increase in compile time caused by our trait impls for tuples. See https://github.com/diesel-rs/diesel/issues/2480 for details. I've extracted a somewhat minimal example [here](https://gist.github.com/rust-play/f628be0a9405ef11c752ddea91f2c5af). There is an option to control the tuple size up to which traits should be implemented in line [861](https://gist.github.com/rust-play/f628be0a9405ef11c752ddea91f2c5af#file-playground-rs-L861). For a size of 16 the compilation of the example succeeds in less then 2 seconds using the rust-playground + the current stable compiler. For a tuple size > 20 the playground is terminated. (Diesel takes ~30s to build while implementing traits for tuples up to 16 elements, and 17 minutes while implementing traits for tuples up to 32 elements for my local setup).

I suspect that this is caused by the combination of a having a [recursive trait bound here](https://gist.github.com/rust-play/f628be0a9405ef11c752ddea91f2c5af#file-playground-rs-L91-L94) + enforcing that bound for each tuple size [here](https://gist.github.com/rust-play/f628be0a9405ef11c752ddea91f2c5af#file-playground-rs-L80). Diesel itself has not only one trait that requires `Self: SqlType`, but probably the problem is increased by that.
Repository: pytorch
Issue: Enable torch.optim typechecks during CI 
Labels: module: typing,triaged

`TestTypeHints.test_run_mypy_strict` should pass with `[mypy-torch.optim.*]` deleted from `mypy.ini`.

Depends on gh-43089, which moves type annotations inline.

cc @ezyang @malfet @rgommers
Repository: rust
Issue: Missing lifetime in associated type triggers suggestion that requires `generic_associated_types`
Labels: A-diagnostics,T-compiler,C-bug,A-suggestion-diagnostics

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
struct Foo<'a,R>{
    phantom: std::marker::PhantomData<&'a R>
}
#[derive(Debug)]
pub struct FooIter<'a, R>
{
    reader: &'a mut R,
}

impl<R:'static> Iterator for FooIter<'_, R>
{
    type Item = Foo<R>;

    fn next(&mut self) -> Option<Self::Item> {
        None
    }
}
```

I expected to see this happen: Not sure, but not this

Instead, this happened:

```
Compiling playground v0.0.1 (/playground)
error[E0106]: missing lifetime specifier
  --> src/lib.rs:12:21
   |
12 |     type Item = Foo<R>;
   |                     ^ expected named lifetime parameter
   |
help: consider introducing a named lifetime parameter
   |
12 |     type Item<'a> = Foo<<'a>R>;
   |              ^^^^       ^^^^
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->
This occurs both on my local machine and on the playground [LINK](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=82fd50ea04fe3ddab972453ae4bfdeb1)

Looks like it returns an error with valid syntax at least on nightly, which just leads to GATs.

```
error[E0106]: missing lifetime specifier
  --> src/lib.rs:12:21
   |
12 |     type Item = Foo<R>;
   |                     ^ expected named lifetime parameter
   |
help: consider introducing a named lifetime parameter
   |
12 |     type Item<'a> = Foo<'a, R>;
   |              ^^^^       ^^^
```

`rustc --version --verbose`:
```
rustc 1.45.2 (d3fb005a3 2020-07-31)
binary: rustc
commit-hash: d3fb005a39e62501b8b0b356166e515ae24e2e54
commit-date: 2020-07-31
host: x86_64-pc-windows-msvc
release: 1.45.2
LLVM version: 10.0
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
<backtrace>
```

</p>
</details>
Repository: godot
Issue: C# Visual Studio Code - Start Debugging
Labels: bug,topic:editor,topic:dotnet

The ability to edit the project and solution in visual studio code and studio is amazing and works great.  The only issue I have run into is when I use Visual Studio Code to start debugging it prevents the main Godot IDE from being able to start the debugging.  

**NOTE:: I am using the extension C# Tools for Godot**.  I realize this is most likely caused by the extension, however, I was curious if there are logs I could look into.

**_Steps To Replicate_** 
- Open Project -> Click Play -> Close / Stop
- Open .cs file which opens VS Code.
- Click Play in Editor -> Game works and Debugs GREAT!! -> Close / Stop
- Go back to Godot IDE and Click Play
- I recieve a weird non Error error.  It tried to start but just exits.  Sometimes with the error resource not found ./
- Go Back To VS Code and hit Play in Editor and it works great!!

Issue goes away when you restart and reload the project.
Repository: flutter
Issue: Enable image_decoder_unittests on Fuchsia
Labels: a: tests,customer: fuchsia,engine,platform-fuchsia,P2,team-engine,triaged-engine

This test suite is hardcoded to use OpenGL
Repository: transformers
Issue: BERT and SpanBERT for Coreference Resolution
Labels: New model

# 🌟 New model addition

## Model description

This is a recent approach for co-reference resolution using BERT, implemented from the papers [BERT for Coreference Resolution: Baselines and Analysis](https://arxiv.org/abs/1908.09091) and [SpanBERT: Improving Pre-training by Representing and Predicting Spans](https://arxiv.org/abs/1907.10529), which is the current state of the art on OntoNotes (79.6 F1). It uses tensorflow 1.14.0.

Reason why this is interesting is it achieves strong improvements on the OntoNotes (+3.9 F1) and GAP (+11.5 F1) benchmarks. Also, I think it would be a nice addition to huggingface library, as it has only the neuralcoref as the coreference resolution module.

## Open source status

* [x] the model implementation is available: (https://github.com/mandarjoshi90/coref)
* [x] the model weights are available: (https://github.com/facebookresearch/SpanBERT)
* [x] who are the authors: (@mandarjoshi90, @jkkummerfeld, @wenyudu)
Repository: pytorch
Issue: New function for CTC decoding
Labels: module: nn,triaged,enhancement,needs design

## 🚀 Feature
New function for decoding the results trained from CTC Loss.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

1.  I want a function that can help me decode the results obtained from a model using CTC Loss.
2. There is such a function in PaddlePaddle as [ctc_greedy_decoder](https://www.paddlepaddle.org.cn/documentation/docs/en/api/layers/ctc_greedy_decoder.html).

## Pitch

<!-- A clear and concise description of what you want to happen. -->
This op ought to be able to decode sequences  the following steps:
1. Get the indexes of maximum value for each row in input. a.k.a. numpy.argmax(input, axis=0).
2. For each sequence in result of step1, merge repeated tokens between two blanks and delete all blanks.

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->
See  [ctc_greedy_decoder in PaddlePaddle](https://www.paddlepaddle.org.cn/documentation/docs/en/api/layers/ctc_greedy_decoder.html).


cc @albanD @mruberry
Repository: svelte
Issue: contenteditable with removed by user html nodes inside "if" block throws an error on update
Labels: stale-bot,temp-stale

**Describe the bug**
If you have html nodes inside `contenteditable` block, which are wrapped with `{#if}{/if}` — removing that nodes will throw an error after update.

**Logs**
`Uncaught (in promise) TypeError: Cannot read property 'removeChild' of null
    at detach
    at Array.forEach
    at HtmlTag.d
    at HtmlTag.p
    at Object.update [as p]
    at Object.update [as p]
    at update
    at flush`

**To Reproduce**
That behavior is reproducible, here is REPL https://svelte.dev/repl/fa601199d8d345d3977bf48bdb8d14f4?version=3.24.1