sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Running a type through a mapped type loses polymorphic `this` type 
Labels: Bug


**TypeScript Version:**  4.0.0-dev.20200622

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**  polymorphic this mapped type

**Expected behavior:** `b.foo()` returns `B`

**Actual behavior:** `b.foo()` returns `A` even though the tooltip on `foo` says it returns `this`

<!-- Did you find other bugs that looked similar? -->
**Related Issues:** None

**Code**
```ts
interface A {
    foo(): this
}

interface B extends Pick<A, keyof A> {
    bar(): this
}

declare let b: B;
b.foo().bar() // error 
```



<details><summary><b>Output</b></summary>

```ts
"use strict";
b.foo().bar(); // error 

```


</details>


<details><summary><b>Compiler Options</b></summary>

```json
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "useDefineForClassFields": false,
    "alwaysStrict": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "downlevelIteration": false,
    "noEmitHelpers": false,
    "noLib": false,
    "noStrictGenericChecks": false,
    "noUnusedLocals": false,
    "noUnusedParameters": false,
    "esModuleInterop": true,
    "preserveConstEnums": false,
    "removeComments": false,
    "skipLibCheck": false,
    "checkJs": false,
    "allowJs": false,
    "declaration": true,
    "experimentalDecorators": false,
    "emitDecoratorMetadata": false,
    "target": "ES2017",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/play/?ts=4.0.0-dev.20200622#code/JYOwLgpgTgZghgYwgAgILIN4Chm+TAewIAoBKALmTAAtgBnLAXyy1ElkRQCFkIAPSCAAmdZAAVgCANYAeVABpkUiAE8CMNAD5MOPACM4UMpRr0mLIRAQAbQymsQwyPZS4BuLHoB0hEqS8GRqTIAPQhvFBQBFDIQA)
Repository: godot
Issue: Bitmap font format extension discrepancy through editor
Labels: bug,topic:editor,confirmed,usability,topic:gui

<!-- Please search existing issues for potential duplicates before filing yours:	
https://github.com/godotengine/godot/issues?q=is%3Aissue	
-->

**Godot version:**
3.2 branch - a662b853dd5de7d47a8c5ebee3ae35cf66490d3f


**OS/device including version:**
Arch Linux


**Issue description:**
I was using [Hiero](https://libgdx.badlogicgames.com/tools.html) by the Libgdx team to generate a bitmap font when I noticed a discrepancy on how the editor handles the loading of bitmap fonts. Hiero produces a usable font format, but the issues lie within Godot's editor itself.

There are three small issues here -- see the next section.

**Steps to reproduce:**
1. Drag and drop the `m5x7_size_20.font` over to the Custom Fonts property -- the font doesn't get loaded, but the font can be loaded by expanding the font property and clicking on `Load`.
2. On the load font window, take a look at the acceptable extensions: `.font` is listed but `.fnt` is not when it should since the Filesytem tab gives it a proper icon and you can also drag and drop this `.fnt` font to the custom font property and it works.
3. Speaking of the Filesystem tab, the `.font` file does not have a proper icon.

**Minimal reproduction project:**
[bitmap_font_debug.zip](https://github.com/godotengine/godot/files/4817161/bitmap_font_debug.zip)

**Credits**
Font: m5x7.ttf
Created by: Daniel Linssen
Download URL: https://managore.itch.io/m5x7
Repository: terminal
Issue: Add a "remember my decision" checkbox to our confirmation dialogs
Labels: Help Wanted,Area-UserInterface,Product-Terminal,Issue-Task,Priority-2

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement
Apart from the setting, it will be easier to have a checkbox at the bottom of the `CloseAll` dialog with the option "Don't ask again" (it will work alongside settings JSON and later GUI)

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
![Checkbox for dialog](https://user-images.githubusercontent.com/47545798/85361898-f92f1b80-b4d1-11ea-93b8-1b21424d5eab.jpg)
Repository: pytorch
Issue: Add a `like` argument to creation ops
Labels: triaged,module: tensor creation,function request

## 🚀 Feature
Add a `like` argument to all the creation ops such that, given a tensor `x`, `torch.eye(3, like=x)` has the same semantics as `torch.eye(3, dtype=x.dtype, device=x.device)`.

## Motivation

In many cases, you want to create a tensor with a matching `dtype` and `device` as some input to do computations with it. The idiomatic way to do so is as follows:

```python
def f(input):
    other = torch.eye(3, dtype=input.dtype, device=input.device)
    # do some computation with input and other
```

However, this is quite verbose. Very often, people write the following code instead:
```python
def f(input):
    other = torch.eye(3).to(input)
```
This works, but has a couple of drawbacks:

1. We must create a tensor then potentially copy it to a different device, whereas in the first code example the tensor was created on the right device. This uses unnecessary memory and time.
2. `.to()` by default is a blocking operation (e.g. for a host->device transfer), which can have significant performance implications for python-heavy code. `torch.eye(3, dtype=input.dtype, device=input.device)` does the creation asynchronously.

## Pitch

Adding a `like` argument to all the creation ops such that, given a tensor `x`, `torch.eye(3, like=x)` has the same semantics as `torch.eye(3, dtype=x.dtype, device=y.device)` will alleviate this issue. This syntax is as succinct and clear as using `.to()`, so people will not use the less efficient method for clarity or out of laziness.

The current API already has functions of the form `torch.*_like` (e.g. `torch.ones_like`), which has similar behaviour to what I described above (except it also copies the shape). Thus, this new argument has some API symmetry, making it easy for new users to learn and existing users to adopt.

## Alternatives

Our new `like` argument can also ensure the new tensor has the same layout as the original, but `.to()` currently does not do this, and I think it would be best if `like` follows the semantics of `.to()`.

Instead of adding an argument, we can just add corresponding `torch.*_like` functions for all the creation ops. However, I think this would be confusing: `torch.*_like` creates tensors of the same shape, dtype, and device as the input; however most of the creation ops do not support making a tensor of the same shape necessarily (e.g. `torch.eye`, `torch.arange`, `torch.linspace`, etc). Furthermore, the signature would be confusing as `torch.*_like` functions typically have the other tensor as the first argument.


Thanks for considering this request, and please let me know if you have any feedback!
Repository: flutter
Issue: Integration testing: more realistic behaviour, taps and scrolls visualization.
Labels: a: tests,c: new feature,framework,t: flutter driver,c: proposal,f: integration_test,P3,team-framework,triaged-framework

As far as I can see, integration tests (driver tests) are good for running on a device and see how my program behaves. The problem is that it runs too fast and I can't see anything.
I'd like to look it more as if the application is being used by a real person.

I came up with solution to set artificial delays such as `await Future.delayed(Duration(seconds: 3));` in `setUpAll()` and after any significant action to at least see what is happenning on the screen.

I would like to also see Driver taps and scrolls simulation somehow.
I tried to enter Developer Settings on my Emulator and turn on "Show taps" and "Pointer location", but it doesn't help. It shows only real taps by mouse cursor and not by FlutterDriver.

And also I want a "fast re-run" ability to replay the test without rebuilding/reinstalling my app.
Repository: flutter
Issue: [web] support offline PWA
Labels: c: new feature,engine,customer: crowd,platform-web,c: proposal,P2,team-web,triaged-web

I would like to create a PWA app that's offline available. 

To test this feature I have enabled web support `flutter config --enable-web`, created a default demo app using `flutter create pwatest` and made it available on my phone through my local network with `flutter run -d chrome web-hostname=192.168.43.59 --web-port=80`. I succesfully load the webapp on my mobile, 'add to home screen', and open the PWA-app.

**Issue:** when I tap open my PWA-app on the homescreen, it tries to connect to my local flutter server (192.168.43.59) and cannot find it (which is correct, because it is now offline). When I turn off my phone internet, it just shows a default 'Flutter Demo' screen. Hence, my app is not offline available.

Is this expected behavior and how do I make my PWA app offline available?

Flutter doctor:
```
[√] Flutter (Channel beta, 1.19.0-4.1.pre, on Microsoft Windows [Version 10.0.18363.900], locale nl-NL)
    • Flutter version 1.19.0-4.1.pre at C:\src\flutter
    • Framework revision f994b76974 (13 days ago), 2020-06-09 15:53:13 -0700
    • Engine revision 9a28c3bcf4
    • Dart version 2.9.0 (build 2.9.0-14.1.beta)

[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at C:\Users\matre\AppData\Local\Android\sdk
    • Platform android-29, build-tools 29.0.2
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Android Studio (version 3.5)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 42.1.1
    • Dart plugin version 191.8593
    • Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b03)

[√] VS Code (version 1.46.1)
    • VS Code at C:\Users\matre\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.11.0

[√] Connected device (2 available)
    • Web Server • web-server • web-javascript • Flutter Tools
    • Chrome     • chrome     • web-javascript • Google Chrome 83.0.4103.106

• No issues found!
```
Repository: excalidraw
Issue: Excalidraw does not work with a lot of users
Labels: performance ⚡️,collaboration

First of all, thank you for this awesome project!

We just tried it in a lecture, but with 43 people on one board, users had different amounts of lag between 0-5min each, making the real-time update collaboration pretty much unusable.

When looking at the websocket connection used to make this all possible, it seems like excalidraw opens a connection for each user, resulting in a lot of connections: 

![excalidraw-ws](https://user-images.githubusercontent.com/13721712/85371871-40002e00-b531-11ea-80df-5f80bf178757.gif)

You can see in the gif there were already 21K messages after just one minute, which makes roughly 1 message each 3ms. That seems quite a lot.

To improve this, it may be an idea to let each client have just one connection to a server which then aggregates and distributes the messages.

To me 43 concurrent users does not seem like a lot but I'm not sure if excalidraw has been built with that use case in mind.

EDIT: Maybe related to #1115
Repository: pytorch
Issue: Can we make torch.inverse FP16? - RuntimeError: "inverse_cuda" not implemented for 'Half'
Labels: module: cuda,triaged,enhancement,has workaround,module: linear algebra,module: amp (automated mixed precision)

## 🚀 Feature
Can we make torch.inverse FP16?

## Motivation

RuntimeError: "inverse_cuda" not implemented for 'Half'



cc @ngimel @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @walterddr @IvanYashchuk @xwang233 @Lezcano @mcarilli @ptrblck
Repository: rust
Issue: Error converting from i32 to f64 when type parameter implements From<f64>
Labels: A-type-system,T-compiler,C-bug,T-types

I tried this code:

```rust
fn foo<T>(x: T, y: i32) -> f64 where f64: From<T> {
    f64::from(y)
}
```

I expected to see this happen: should compile and do the right thing.

Instead, this happened:

```rust
error[E0308]: mismatched types
 --> src/lib.rs:2:15
  |
1 | fn foo<T>(x: T, y: i32) -> f64 where f64: From<T> {
  |        - this type parameter
2 |     f64::from(y)
  |               ^ expected type parameter `T`, found `i32`
  |
  = note: expected type parameter `T`
                       found type `i32`
  = help: type parameters must be constrained to match other types
  = note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
```

On the other hand, this code compiles fine:

```rust
fn foo<T>(_: T, y: i32) -> f64 {
    f64::from(y)
}
```

### Meta

I was surprised about this, so after running this with 1.44.0 and 1.44.1 I checked older versions, but 1.39.0, 1.31.0 and 1.15.0 all give the same error. Seems likely that there is an issue about this already, but no clue how to look for it.
Repository: vscode
Issue: Extension doesn't activate after install
Labels: feature-request,extension-host

Windows 10

Steps:
- install extension https://marketplace.visualstudio.com/items?itemName=ban.spellright
- Run any SpellRight command

Observe: you get an error

- Run command `Show Running extension`

Observe: 

Spell Right is not running

Inspect the spell right package.json. It has

```
	"activationEvents": [
		"*"
	]
```
Repository: flutter
Issue: Chrome doesn't offer to translate https://sharezone.net
Labels: engine,customer: crowd,platform-web,e: web_canvaskit,P3,team-web,triaged-web

https://sharezone.net is one such site. Since it's in a language I don't speak (German) and I'm interested in the content, that's a problem for me. However, if Chrome can't translate Flutter web apps in general, that's a general-purpose problem. In this case, the site is using CanvasKit, which I suspect is the root of the problem.
Repository: rust
Issue: Segfault of binary produced with `relocation-model=static` for `x86_64-unknown-linux-musl`
Labels: P-medium,T-compiler,O-musl,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.
-->

I tried this code:

```rust
fn main() {
    println!("main = {:#x}", &main as *const _ as usize);
}
```

I expected to see this happen:
```console
$ rustc -C relocation-model=static --target x86_64-unknown-linux-musl hello.rs
$ ./hello
main = 0x43b008
```

Instead, this happened:
```
$ rustc -C relocation-model=static --target x86_64-unknown-linux-musl hello.rs
$ ./hello
Segmentation fault (core dumped)
```

This code works, though:
```rust
fn main() {
    println!("main = {:#?}", &main as *const _);
}
```

### Meta
Also happens with current nightly.

`rustc --version --verbose`:
```console
$ rustc --version --verbose
rustc 1.44.1 (c7087fe00 2020-06-17)
binary: rustc
commit-hash: c7087fe00d2ba919df1d813c040a5d47e43b0fe7
commit-date: 2020-06-17
host: x86_64-unknown-linux-gnu
release: 1.44.1
LLVM version: 9.0
 
$ rustc +nightly --version --verbose
rustc 1.46.0-nightly (6bb3dbfc6 2020-06-22)
binary: rustc
commit-hash: 6bb3dbfc6c6d8992d08431f320ba296a0c2f7498
commit-date: 2020-06-22
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0
```
Repository: rust
Issue: Tracking Issue for `core::mem::variant_count`
Labels: T-lang,T-libs-api,B-unstable,C-tracking-issue,F-variant_count,S-tracking-design-concerns

The feature gate for the issue is `#![feature(variant_count)]`.

### Steps

- [x] Implement the intrinsic
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions

None

### Implementation history

- #73418 
- #92568
Repository: go
Issue: x/pkgsite: add statistics about module usage
Labels: NeedsInvestigation,FeatureRequest,pkgsite,UX

Thanks for the great work on `go.dev` website!

A given package has a ["Imports"](https://pkg.go.dev/github.com/golang/protobuf/proto?tab=imports) and ["Imported By"](https://pkg.go.dev/github.com/golang/protobuf/proto?tab=importedby) tab, which allows you to get a sense of the dependency graph for a single package.

I propose adding a [similar feature for modules](https://pkg.go.dev/mod/github.com/golang/protobuf), such that it would gain a "Requires" and a "Required By" tab that similarly presents the following information:
* For the "Requires" tab, it shows the set of modules required by the latest version of this module.
  * For example, the latest version of `github.com/golang/protobuf`  depends on [3 other modules](https://github.com/protocolbuffers/protobuf-go/blob/a9513ebdb86068803ccda83ded57e8330a72961e/go.mod#L6-L8). I'd expect these to be readily displayed without needing to go to the `go.mod` file.
* For the "Required By" tab, it shows the set of modules at their latest version that requires this module.
  * For example, the `github.com/golang/protobuf` module is required by 8577 modules. I'd like to see this number and get a brief sample of some of these modules.
  * It'd be additionally be useful if the "Required By" tab could show the dependencies on specific versions of this module. For example, I'd like to easily see statistics similar to the following:
    * 1435x (16.7%) at v1.4
    * 6199x (72.3%) at v1.3
    * 721x (8.4%) at v1.2
    * 77x (0.9%) at v1.1
    * 45x (0.5%) at v1.0
    * 100x (1.2%) at v0.0

At the present moment, I obtain such information through a series of expensive queries on the module proxy.
Repository: godot
Issue: Some shortcuts for switching scripts in the editor don't work
Labels: bug,topic:editor

**Godot version:**
3.2.2.rc

**OS/device including version:**
Debian Buster amd64, Radeon RX550

**Issue description:**
I'm trying to map a good shortcut to "Next Script"/"Previous Script" actions.

I want to switch scripts with Ctrl+PgUp/Ctrl+PgDn, like it has been in Gnome Terminal and other places from time immemorial. This does not work - probably because the editor intercepts this shortcut and gives it some useless function, which is not configurable (though it looks to me like it's doing the same as just PgUp/PgDn).

Alt+PgUp/Alt+PgDn is the same.

Ctrl+Alt+Up/Ctrl+Alt+Down work fine. But I would have preferred an easier combination.

But Ctrl+Alt+PgUp/Ctrl+Alt+PgDn do not work - they act as simply PgUp/PgDn instead.

Even Alt+Period/Alt+Comma don't work - they just type Period/Comma as if I wasn't holding Alt.

Ctrl+Up/Ctrl+Down don't seem to do anything at all, but they still do not switch scripts when mapped for that... Oh, they actually do something else, it's just not obvious. But there is no way to remap their "original" action. In this case, shouldn't we 1) give a warning that the assigned shortcut collides with something else, and 2) still have the "remappable" part take priority over "non-remappable"? Meaning, we should be able to use this shortcut for what we want, even if we can not remap the shortcut we are overwriting to something else.

Also, could it be possible to add a shortcut for "Last Script" (Ctrl+Tab by default) for switching between the current script and the last used script? The difference from "History Previous" is that pressing Ctrl+Tab for the second time would get you back to the current script, rather than going further back in history like "History Previous". This is convenient for several uses. First, for comparing two scripts or working with a reference. Second, when I'm working on a script and want to see "the script I just saw", I don't want to think whether must I go back in history or "forward", in case I already went "back" for the script I'm seeing now.
Repository: vscode
Issue: Debug console: introduce ctrl + up / down to focus output
Labels: feature-request,debug,accessibility

To be consistent with the terminal the debug console could also navigte to output using ctrl + up / down.
The current functionality of Shit + Tab, and up / down would still work as it is today, and ctrl + up / down would behave like an alias of sort.
Repository: pytorch
Issue: [feature request] batch_apply, a general-purpose device-agnostic batch iterator
Labels: triaged,module: batching

## 🚀 Feature
`batch_apply`, a general-purpose device-agnostic batch iterator that applies some function to each element in a batch for efficient kernels.

## Motivation & Pitch

Sometimes each element in a batch might require specific processing, for example, imagine raising matrices to powers, or any other input-specific linear algebra operation. It would be great to have a device-agnostic function that performs this iteration efficiently, while preserving the high-level functionality (**iterate and return tensors, not pointers**).
Would be great to have an efficient universal tool for any batch-wise manipulation.

A quick look at `BatchedLinearAlgebra.cpp` shows that the batch dimensions are traversed in a simple CPU for-loop,
which will cause a major slowdown for large batches of CUDA-allocated tensors (especially if they are small).

## Additional context

While this function can easily be implemented on CPU with, say, parallel for loop, I am not sure it is that easy for CUDA.
**Is it even possible**, unless high-level Tensor functions are allowed to be run from within CUDA kernels?
Repository: godot
Issue: KinematicBody2D slides across screen when C# script is added.
Labels: topic:dotnet



**Godot version:**
<!-- Specify commit hash if using non-official build. -->
Godot Version 3.2 Stable Mono

**OS/device including version:**
Microsoft Windows 10 Pro N
Version 10.0.18362 Build 18362


**Issue description:**
When generating a Kinematic2D body with a sprite and a collision2d child, if a c# script is applied to the kinematic2d body, it will begin to move across the screen even if the script is empty. This issue will stop once the script has been removed.


**Steps to reproduce:**
N/A


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[My platformer Game.zip](https://github.com/godotengine/godot/files/4820998/My.platformer.Game.zip)
Run Player2.tscn to see issue.