sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Rust insufficiently optimizes loop { match { } } state machines
Labels: A-LLVM,I-slow,T-compiler,C-bug,A-mir-opt

This is how a typical state machine might look in Rust:

```rust
#[inline(never)]
fn print(s: &str) {
    println!("{}", s);
}

#[inline(never)]
fn exec(mut s: i32) {
    loop {
        match s {
            0 => { print("0"); s = 2; },
            1 => { print("1"); s = 3; },
            2 => { print("2"); s = 1; },
            _ => return
        }
    }
}

fn main() {
    exec(0);
}
```
One would expect that the first jump from function start into one of the states (0, 1, 2 or _) would be compiled as a jumptable or a series of cmp/conditional jump instructions and once the execution is in one of the states the remaining jumps would be deterministic (non-conditional) jumps.

And this is how equivalent code in [gcc](https://godbolt.org/z/3KGoM7) is optimized.

However Rust/LLVM at the end of each state performs needless comparisons to determine to which label to jump to next, even though the jump target can be computed statically. You can inspect the generated assembly in [Rust Playground](https://play.rust-lang.org/?version=stable&mode=release&edition=2018).

This is probably more of a LLVM issue rather than Rust directly, but it's important to get this fixed/optimized, because now it's impossible to efficiently write such state machines in Rust (because there is no `goto`)

### Meta

Tested with all versions available in Rust playground:

* 1.49.0
* 1.50.0-beta.2 (2020-12-31 25b3db3aa752d9d4633c)
* 1.51.0-nightly (2020-12-30 e2267046859c9ceb932a)
Repository: godot
Issue: KinematicBody2D: odd move_and_slide behaviour when exactly on tile edge
Labels: bug,confirmed,topic:physics,topic:2d

**Godot version:**
3.2.3-official

**OS/device including version:**
Ubuntu Linux 20.04

**Issue description:**
Possibly related to #33833.

When using `KinematicBody2D`'s `move_and_slide` or `move_and_slide_with_snap` to enact gravity, I've noticed that when a body is *exactly* on the diagonal edge of a tile:

* `is_on_floor()` returns false
* `is_on_wall()` returns true
* The body can't travel any further, but keeps gaining velocity (when setting it from the result of `move_and_slide`)

So we essentially end up with a Mario 64 speedrunner's dream:

![Screenshot from 2021-01-02 23-31-42](https://user-images.githubusercontent.com/4892574/103468623-e8017a00-4d52-11eb-9795-d646b118649e.png)

Interestingly, the value of `y` tends to fluctuate, and sometimes (seemingly non-deterministically) the body unhooks itself and so goes flying downwards.

**Steps to reproduce:**

* Position a `KinematicBody2D` on the edge of a tile
* Apply gravity to it
* Note the weird behaviour of its position and velocity

**Minimal reproduction project:**
[floor-wall-test.zip](https://github.com/godotengine/godot/files/5760996/floor-wall-test.zip)
Repository: godot
Issue: SoftBody ignores translation when using GLES2
Labels: bug,topic:rendering,confirmed,topic:physics,topic:3d

OS: Windows 10, 64-bit
Godot:  v3.2.3 stable
Processor: AMD Ryzen 7 3700X 
Graphics:  GeForce RTX 2060S, Nvidia driver v460.89

While in GLES2 mode, I placed a few scene instances involving RigidBodies into another scene, translated them into various positions, and hit the play button. 

**Expected:** the bodies should be rendered at the specified positions.

**Actual:** the bodies are all rendered overlapping at the origin (?) of the scene. The scene has a bit of gravity, so eventually all the bodies separate as they fall. 

**Workaround:** Use GLES3. 

This was extremely confusing and I thought I was doing something wrong for 3 or so hours, fiddling with various things to get such a basic scene working. I switched to GLES3 figuring maybe it was a bug, and the issue immediately resolved: the scene renders as expected with each RigidBody located where I placed them in the editor. 

I tried to look around for other reports of this and didn't see any mention [here](https://docs.godotengine.org/en/stable/tutorials/misc/gles2_gles3_differences.html). I see it mentions "INSTANCE_ID" but I have no idea if this is relevant. 
[Cell.zip](https://github.com/godotengine/godot/files/5761182/Cell.zip)
Repository: pytorch
Issue: torch.var and torch.std are not compatible with np.var and np.std
Labels: triaged,module: numpy,module: deprecation,module: reductions

torch.var and torch.std have the following signatures:

```
torch.var(input, dim, unbiased=True, keepdim=False, *, out=None)
torch.std(input, dim, unbiased=True, keepdim=False, *, out=None)
```

Which are incompatible with NumPy's signatures:

```
numpy.var(a, axis=None, dtype=None, out=None, ddof=0, keepdims=<no value>)
numpy.std(a, axis=None, dtype=None, out=None, ddof=0, keepdims=<no value>)
```

Because PyTorch's default of `unbiased=True` is equivalent a `ddof` of 1, but NumPy's default is `ddof=0`. 

PyTorch's use of the term "unbiased" is also problematic. While Bessel's correction (ddof=1) does produce an unbiased estimator of the variance, it DOES NOT produce an unbiased estimator of the standard deviation. See [this wiki article](https://en.wikipedia.org/wiki/Unbiased_estimation_of_standard_deviation) for a discussion.

I propose we deprecate PyTorch's default behavior by doing the following:

- [ ] adding a ddof kwarg
- [ ] warning when that kwarg is not set for a release (this requires auditing and updating PyTorch's internal callsites to avoid warnings when people use PyTorch)
- [ ] requiring the kwarg be set (this probably requires writing an upgrader for serialized torchscript programs)
- [ ] removing the "unbiased" arg and adding a default ddof value of zero

The net effect of this will be that PyTorch's var and std will lose "unbiased," gain "ddof," and change their default behavior to be the same as NumPy's. 



cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @rgommers @bdhirsh @jbschlosser @mruberry @heitorschueroff
Repository: pytorch
Issue: torch.Tensor.repeat is divergent from np.repeat
Labels: high priority,triaged,module: numpy,module: deprecation

[torch.Tensor.repeat](https://pytorch.org/docs/master/tensors.html?highlight=repeat#torch.Tensor.repeat), as its documentation notes, is divergent from [np.repeat](https://numpy.org/doc/stable/reference/generated/numpy.repeat.html?highlight=repeat#numpy.repeat) but similar to [np.tile](https://numpy.org/doc/stable/reference/generated/numpy.tile.html?highlight=tile#numpy.tile). Now that [torch.tile](https://pytorch.org/docs/master/generated/torch.tile.html?highlight=tile#torch.tile) is implemented, we can deprecate torch.repeat in favor of torch.tile by doing the following:

- [ ] deprecate `torch.Tensor.repeat` in favor of torch.tile for a release
  - [x] verify torch.tile implements the same behavior as np.tile and torch.repeat (see discussion and linked PRs)
  - [ ] audit and update internal callsites so PyTorch doesn't throw warnings by default
- [ ] remove torch.repeat for a release (possibly requires writing an upgrade for serialized torchscript)
- [ ] restore torch.repeat analogous to np.repeat  

np.repeat is a [top 50 NumPy function](https://github.com/Quansight-Labs/python-api-inspect/blob/master/data/csv/numpy-summary.csv), and torch.Tensor.repeat (note that torch.repeat does not exist) is popular with hundreds of uses within Facebook. 

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @mruberry @rgommers @heitorschueroff
Repository: opencv
Issue: Big Enedian
Labels: incomplete,needs reproducer

##### System information (version)
- OpenCV => :grey_question: any (4.5.1)
- Operating System / Platform => Debian Sid / Sparc 64 Bit BE
- Compiler => :grey_question: any ( but g++ (Debian 10.2.0-15) 10.2.0 )

##### Detailed description

The code is not careful when saving reading values. Most(all) save/load functions assume host and file formats are little endian. This breaks when host is big endian.

##### The solution

One could add a couple of read/write functions that would abstract reading/writing floats, doubles, (u)int16, (u)int32, (u)int64.
There should be no overhead as those functions would be compile time only (compiled away for the little endian).
Repository: rust
Issue: use PlaceRef abstraction more consistently
Labels: C-cleanup,E-mentor,T-compiler,A-MIR

We have quite a bit of code that needs to work with the `projections` that make up a [`Place`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html) or [`PlaceRef`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.PlaceRef.html). Much of it works with the `projections` array directly, which is rather verbose. We now have better APIs that avoid having to "break the abstraction" of `Place`/`PlaceRef`: we have `Place::iter_projections` and `PlaceRef::last_projection`.

It would be good to clean things up by using these higher-level APIs consistently. To do that, you'll need to find places where the lower-level API is used. One good way to find these places is to grep for `Place::ty_from` -- this helper function is only useful when a `PlaceRef` has been broken apart into its constituents, so it is a sign that some higher-level APIs can be used. In almost all cases, the code will either "do something with the last projection (if any)", in which case it should use `PlaceRef::last_projection`, or it will iterate all the projections, in which case it should use `Place::iter_projections` (usually iteration starts with the outermost projection, i.e., you should use `place.iter_projections().rev()`).

You can see https://github.com/rust-lang/rust/pull/80624 for some examples for the kinds of changes that are needed to perform this cleanup.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"ericmarkmartin"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: excalidraw
Issue: Helm chart?
Labels: enhancement,discussion

I have been using excalidraw for the last few months and have been loving it!  I am getting ready to move my installation from a local docker deployment to a permanent k8s cluster deployment.  I have been looking for a helm chart but have not found one.  Am I missing a helm chart somewhere?  If not I will start working on one and contribute it back.
Repository: bitcoin
Issue: duplicate wallet warning after closing and reopening wallet
Labels: Bug,GUI,Wallet

Built from the v0.21.0rc4 tag on Debian with an SSD. Kernel 4.19.0-13-amd64. Debian GNU/Linux 10 (buster). XFCE4, xfwm4.

I have 'wallet=x' (and several other similar lines) in my bitcoin.conf so wallet x loads every time I start the client.

I recently used the Qt GUI to close wallet x and then reopened it.

Later I shut down the client and restarted it and got a warning:

"Warning: Ignoring duplicate -wallet x."

It turns out that closing and reopening the wallet caused it to be listed in a file called settings.json which is used at startup in addition to the bitcoin.conf file. Now the x wallet is listed in 2 places and shows up as a "duplicate" just because I closed and reopened it. This seems like undesirable behavior.
Repository: node
Issue: Stream.pipeline always throw [ERR_STREAM_PREMATURE_CLOSE]
Labels: stream

Hello.
Stream.pipeline throws error `[ERR_STREAM_PREMATURE_CLOSE]: Closed prematurely`, but the stream throw error `new Error('destroy')`.

In a real application, a large file is uploaded, sometimes the server timed out the connection, and when using stream.pipeline it is not clear what error occurred, ERR_STREAM_PREMATURE_CLOSE is always returned.

Version: 15.5.0
Platform: Ubuntu 20.10 x64

```js
/* eslint-disable */
import http from 'https';
import { createWriteStream } from 'fs';
import { pipeline } from 'stream/promises';

const httpRequest = url => new Promise(resolve => http.get(url, res => resolve(res)));

const FILENAME_TMP = './1.tmp'
const linkFile = 'https://nodejs.org/dist/v15.5.0/node-v15.5.0-linux-x64.tar.xz';

const downloadStream = await httpRequest(linkFile, { responseType: 'stream' });

// view error
downloadStream.on('error', err => console.log('onError', err));

// break download
setTimeout(() => downloadStream.destroy(new Error('destroy')), 1000);

try {
  await pipeline(
    downloadStream,
    createWriteStream(FILENAME_TMP)
  );

  console.log('Done');
} catch (err) {
  console.log('onPipeline', err);
}
```

```bash
onError Error: destroy
    at Timeout._onTimeout (file:///home/user/Project/parser/3.js:17:41)
    at listOnTimeout (node:internal/timers:556:17)
    at processTimers (node:internal/timers:499:7)
onPipeline Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
    at new NodeError (node:internal/errors:278:15)
    at IncomingMessage.onclose (node:internal/streams/end-of-stream:117:38)
    at IncomingMessage.emit (node:events:376:20)
    at IncomingMessage._destroy (node:_http_incoming:169:10)
    at _destroy (node:internal/streams/destroy:67:23)
    at IncomingMessage.destroy (node:internal/streams/destroy:59:5)
    at Timeout._onTimeout (file:///home/user/Project/parser/3.js:17:33)
    at listOnTimeout (node:internal/timers:556:17)
    at processTimers (node:internal/timers:499:7) {
  code: 'ERR_STREAM_PREMATURE_CLOSE'
}
```

Thank's
Repository: TypeScript
Issue: Class with 'private [Symbol.iterator]' is iterable outside of the class body
Labels: Bug

<!-- 🚨 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.
-->

**TypeScript Version:**  4.2.0-dev.20210103, seems to be a regression in 3.6, probably introduced by strictly typed generators (cc @rbuckton)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** iteration, private

**Expected behavior:**

Errors like in v3.5:

```
Type 'C' is not assignable to type 'Iterable<string>'.
  Property '[Symbol.iterator]' is private in type 'C' but not in type 'Iterable<string>'.

Type 'D' is not assignable to type 'Iterable<string>'.
  Types of property '[Symbol.iterator]' are incompatible.
    Type '() => D' is not assignable to type '() => Iterator<string>'.
      Type 'D' is not assignable to type 'Iterator<string>'.
        Property 'next' is private in type 'D' but not in type 'Iterator<string>'.
```

**Actual behavior:**

No error on iteration inside and outside of the class body.

<!-- Did you find other bugs that looked similar? -->
**Related Issues:** #42051 and #42104

**Code**
```ts
class C {
    private [Symbol.iterator]() {
        return this;
    }

    public next() {
        return {value: 'a', done: false};
    }
}

class D {
    public [Symbol.iterator]() {
        return this;
    }

    private next() {
        return {value: 'a', done: false};
    }
}


function fn() {
    for (const _ of new C()) {
    }

    for (const _ of new D()) {}
}
```

<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": "ES2017",
    "jsx": "React",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/play?ts=4.2.0-dev.20210103#code/MYGwhgzhAEDC0G8BQ1XQA4CcCWA3MALgKbQDaAygJ4C2ARgPYgB02xmh9mAugBQCUiFGmGYiBAK6YAdtAIALbBADcQ1AF8kqjONohswaFKIAPAv0HCRYyTIT4Q4ogC5oAcjCuANNAAm9Iy4AZmAgEERqKsIaGkigkDAAIhZo6Dp6BhQ0DMysROwEnLwCyJZoohLSsgrKWjHCWHiEJEam5iWl0OU2iPaOLu5evv7O0MGh4ZFo0ZpIgeJSwATY-qNSbVqBnNA8wP4QBNAA+tD0gYZEAO5w-MW1msKbmNu7UvtHJ2dGVwk3iNFAA)
Repository: TypeScript
Issue: Class with private 'then' method can be awaited outside of the class
Labels: Bug

<!-- 🚨 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.
-->

**TypeScript Version:**  4.2.0-dev.20210103, goes all the way back to 3.3.3333 and probably further

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** await private then

**Expected behavior:**

Expected error when awaiting `C` outside of the class body:

```
Type 'C' is not assignable to type 'PromiseLike'.
  Property 'then' is private in type 'C' but not in type 'PromiseLike'.
```

**Actual behavior:**

Instance of `C` can be awaited inside and outside of the class body without an error.

<!-- Did you find other bugs that looked similar? -->
**Related Issues:** #42190

**Code**
```ts
class C {
    private then<T>(cb: (v: string) => PromiseLike<T> | T): Promise<T> {
        return null!;
    }
}

(async () => await new C())();
```


<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": "ES2017",
    "jsx": "React",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/play?ts=4.2.0-dev.20210103#code/MYGwhgzhAEDC0G8BQ1XQA4CcCWA3MALgKbQEAWRAdgDwAqAfABTABGAXNI7hxATpQHMAlNAC89aAAVMAewC22CEQAy2ANZE6EgD7RaQjtPmLNDRCjSXMRAgFdMlaJVsgQAQgDcF1AF8kfpEZIAE9KYE4RcWgwAHcwbAInIhi4RiEhNI8gA)
Repository: terminal
Issue: DISCUSSION: Continued commentary about the touch keyboard service
Labels: Issue-Question,Product-Terminal,Needs-Tag-Fix

MAINTAINER EDIT: <em> OP here is a rant that disparages my colleague, and frankly, I'm not gonna stand for that. </em>
<details>
<summary> 
You can click here to view it if you want, but I'm not gonna let a flame war evolve.
</summary>

> The five users we've encountered who have disabled this service and inexplicably have a working input stack are in the extreme minority, and they can _deal with it_ fairly trivially.

Congratulations, every response you gave so far on the issue of Touch Keyboard and Handwriting service warning just serves to reinforce the widespread opinion that most Microsoft developers are self-righteous assholes who enjoy antagonizing power-users and developers alike.

> We'll probably add a setting or something, but not after raising the hackles of power users who are certain they understand the operating system.

We seem to have better overall understanding of Windows than you do, not to mention that we were trying our best to be polite instead of condescending like you.

> You have an overview from some source called "lifewire" as to what ctfmon.exe does, and we have the person who owns that executable explaining to us how the input stack works and why it's required for modern apps. I know which one I'm inclined to trust.

Obviously your trust does not mean you actually understand their explanation or otherwise you would realize that said service is totally unnecessary for all apps on a desktop system and that you are being an ass by condemning a class of PC users (and not just power users and fellow developers mind you) to an otherwise totally avoidable annoyance because you are obviously on a power trip and like "slapping users in the face" with warnings. Good thing your reach does not extend beyond our desktop or you might try slapping us for real given the show of your character here.

I am sure there are many good people among developers in Microsoft -- Raymond Chen, Larry Osterman, and a few others come to mind. You Sir are not one of them and you should be ashamed of yourself.

I hope someone from Microsoft HR department sees this and the other threads here and your outright hostility towards customers gets taken down a notch or two.

</details>
Repository: rust
Issue: Allow a control flow statement to be decorated with #[allow(unreachable_code)]
Labels: A-attributes,A-lints,A-diagnostics,T-lang,C-feature-request

Currently it seems that the only way to silence an `unreachable_code` warning is via an interior `#![allow(unreachable_code)]` attribute that would apply to the entire scope or artificially creating a new scope with the inner attribute in question.

Would it be possible to allow a control flow statement to be individually tagged with a regular `#[allow(unreachable_code)]` statement to also suffice?

e.g. the following should not emit a warning about unreachable code:

```rust
pub fn foo() -> u32 {
    #[allow(unreachable_code)]
    return 0;

    let foo = 7;
    return foo;
}
```

[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&code=pub%20fn%20foo()%20-%3E%20u32%20%7B%0A%20%20%20%20%23%5Ballow(unreachable_code)%5D%0A%20%20%20%20return%200%3B%0A%0A%20%20%20%20let%20foo%20%3D%207%3B%0A%20%20%20%20return%20foo%3B%0A%7D%0A)
Repository: godot
Issue: Issue with editing dictionaries in the inspector in the remote scene tree
Labels: bug,topic:editor,confirmed

**Godot version:**
3.2.3 stable


**OS/device including version:**
Windows 10 x64


**Issue description:**
Vectors, Dictionaries, etc. can't be edited during runtime when placed inside a dictionary whether or not the dictionary has the export keyword


**Steps to reproduce:**
create a dictionary with a vector, dictionary, or array inside. Make sure the dictionary has the export keyword so it is visible in the editor, during runtime, switch to remote, select the node, open the dictionary, and attempt to edit any of the values


**Minimal reproduction project:**
[vector3dictionarybug.zip](https://github.com/godotengine/godot/files/5762850/vector3dictionarybug.zip)
Repository: pytorch
Issue: Inconsistent function name between stub and implementation in `torch.optim.swa_utils`
Labels: module: typing,triaged

## 🐛 Bug

The argument `avg_fun` in the stub file [here](https://github.com/pytorch/pytorch/blob/e44b2b72bd4ccecf9c2f6c18d09c11eff446b5a3/torch/optim/swa_utils.pyi#L9) is inconsistent with that in the implementation [here](https://github.com/pytorch/pytorch/blob/e44b2b72bd4ccecf9c2f6c18d09c11eff446b5a3/torch/optim/swa_utils.py#L87). 

Not including additional details, since the links are based on master branch. 

cc @ezyang @malfet @rgommers @xuzhao9 @gramster