sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Account for discrepancy between soft privacy of `private` vs hard privacy of `#`
Labels: Docs

With the upcoming TC39 class fields proposal landing in 2022, there is a soft private vs hard private discrepancy between vanilla JS' `#` and TypeScript's `private`. This discrepancy might not be obvious to all users and could cause issues.

Maybe the TS docs should highlight this discrepancy, or maybe we should have some kind of warning. Alternatively (and this would have to be raised elsewhere), maybe there should be a [TypeScript ESLint warning for this](https://github.com/typescript-eslint/typescript-eslint).

TypeScript's `private` is soft private and has escape hatches like the ability to use bracket notation to access a private field.

The new `#` private field prefix is hard private and doesn't allow for this. In the example below, TS compiles `private` and `#` differently, and the console log at the bottom shows that accessing these values produces different results.

```ts
class Dog {
  #barkAmount = 0;
  personality = "happy";

  constructor() {}
}

class Cat {
    private meowAmount = 0;
    personality = "angry";

    constructor() {}
}

const fido = new Dog();
const garfield = new Cat();

console.log(
    fido.#barkAmount, // no good
    fido['#barkAmount'], // no good
    garfield.meowAmount, // no good
    garfield['meowAmount'] // fine
);
```

Compiles to:

```js
"use strict";
class Dog {
    constructor() {
        this.#barkAmount = 0;
        this.personality = "happy";
    }
    #barkAmount;
}
class Cat {
    constructor() {
        this.meowAmount = 0;
        this.personality = "angry";
    }
}
const fido = new Dog();
const garfield = new Cat();
console.log(fido.#barkAmount, fido['#barkAmount'], garfield.meowAmount, garfield['meowAmount']);
```
Repository: terminal
Issue: Extremely slow performance when processing virtual terminal sequences
Labels: Area-Performance,Product-Conpty,Issue-Bug,Product-Meta,Priority-1,Impact-Correctness

### Windows Terminal version (or Windows build number)

1.8.1521.0

### Other Software

_No response_

### Steps to reproduce

Using any command line utility that produces virtual terminal sequences for setting the colors of individual characters, the performance of the terminal drops by a factor of around 40.

To measure this effect precisely, you can use the F2 key in termbench and observe the performance difference between color-per-character output and single-color output:

https://github.com/cmuratori/termbench/releases/tag/V1

### Expected Behavior

Despite the increased parsing load, modern CPUs should not have a problem parsing per-character color escape codes quickly. I would expect the performance of the terminal to be able to sustain roughly the same frame rate with per-character color codes as without, and if there was a performance drop, I wouldn't expect it to be anything close to 40x.

### Actual Behavior

The speed of per-character color output is 40x slower than the speed of single-color output.
Repository: node
Issue: Future of streams
Labels: stream

We are now making progress with WHATWG (web) streams  #39062. Which brings up the question, what is our long term strategy in terms of streams?

What is the preferred implementation for core modules? Do we always implement as node streams and then wrap to web streams? Or the other way around? If the other way around should we look into re-implementing existing apis?

Basically when do we use which streams type?

I haven’t personally looked at web streams so I don’t really have any opinions yet in regards to pros and cons relative node streams.
Repository: godot
Issue: PoolByteArray missing methods in GDNative
Labels: enhancement,topic:gdextension

### Godot version

3.3.stable

### System information

Does not matter

### Issue description

Currently, documentation presents you with such methods as [compress](https://docs.godotengine.org/en/3.3/classes/class_poolbytearray.html#class-poolbytearray-method-compress), [decompress](https://docs.godotengine.org/en/3.3/classes/class_poolbytearray.html#class-poolbytearray-method-decompress), [get_string_from_ascii](https://docs.godotengine.org/en/3.3/classes/class_poolbytearray.html#class-poolbytearray-method-get-string-from-ascii), [get_string_from_utf8](https://docs.godotengine.org/en/3.3/classes/class_poolbytearray.html#class-poolbytearray-method-get-string-from-utf8) and [hex_encode](https://docs.godotengine.org/en/3.3/classes/class_poolbytearray.html#class-poolbytearray-method-hex-encode) which are simply missing from GDNative's counterpart of this exact class. Maybe I am missing something, and it is currently already exposed to GDNative somehow, but I simply could not figure it out due to a complete lack of documentation regarding this.

### Steps to reproduce

1. Try using listed methods of PoolByteArray in GDNative.
2. Profit.

### Minimal reproduction project

_No response_
Repository: godot
Issue: Camera2D smoothing calculation appears incorrect
Labels: topic:core,documentation,topic:2d

### Godot version

8b692e88726bb7ab114a3a0b1b2ffd973dd4f054

### System information

MacOS/Windows/Linux

### Issue description

I noticed that my despite my player moving at 256 pixels per second, my Camera2D with smoothing enabled easily keeps up with the player when it's speed is set to 5. It looks like there's a discrepancy between the description of `smoothing_speed`/`smoothing_enabled` and what the code actually does. The description says that the speed is in "pixels per second," but the code that references the smoothing speed doesn't behave that way.

I'm happy to make a PR to address this assuming the documentation of the behavior is correct and the actual behavior is the incorrect one.

https://github.com/godotengine/godot/blob/master/scene/2d/camera_2d.cpp#L161

```
		if (smoothing_enabled &amp;&amp; !Engine::get_singleton()-&gt;is_editor_hint()) {
      
      
        			real_t c = smoothing * (process_callback == CAMERA2D_PROCESS_PHYSICS ? get_physics_process_delta_time() : get_process_delta_time());
      
      
        			smoothed_camera_pos = ((camera_pos - smoothed_camera_pos) * c) + smoothed_camera_pos;
      
      
        			ret_camera_pos = smoothed_camera_pos;
      
      
        			//camera_pos=camera_pos*(1.0-smoothing)+new_camera_pos*smoothing;
      
      
        		} else {
      
      
        			ret_camera_pos = smoothed_camera_pos = camera_pos;
      
      
        		}
```

The first line `real_t c = smoothing * [...]` looks right, as it gets the number of pixels the camera should move. The next line multiplies `c` by the delta of the actual position and the interim smoothed position. This should normalize the vector result of `camera_pos - smoothed_camera_pos` first. It should also check if `c` is greater than the distance between the two positions.

In its current state, if the smoothing speed is set very high, the camera won't settle at the correct position if the smoothing speed is set to a value higher than the frame rate, but rather oscillate back and forth. Additionally, as it gets farther from the desired position, it will speed up as the magnitude of `camera_pos - smoothed_camera_pos` increases.

Please advise on whether the documentation of "camera's speed in pixels per second" is the intended behavior. If so, I can address this. If not, we'll need to update the documentation. I think we'll also still want to handle the case of large values of smoothing speed, as it will behave strangely when it exceeds the framerate.

### Steps to reproduce

Any Camera2D node with smoothing enabled, observe the actual speed at which the camera moves relative to the smoothing value.

### Minimal reproduction project

_No response_
Repository: terminal
Issue: Document ConDrv headers (condrv.h and conmsgl*.h)
Labels: Product-Conhost,Issue-Docs,Area-Server,Issue-Task,Priority-3

As the ConDrv headers and `\Device\ConDrv\Server` are undocumented, it:
* Prevents the community from building their own, alternative conhost
* is a hindrance for MS employees to quickly understand how ConDrv works

In the name of https://github.com/microsoft/terminal/issues/10462#issuecomment-864446348 I'd like to thus ask for ConDrv to be documented.
Repository: pytorch
Issue: Two-element ModuleList results in error in inference_mode when jit'ed
Labels: oncall: jit

## 🐛 Bug

A `ModuleList` with more than one module results in an error in `inference_mode` when jit'ed . A `ModuleList` with only one module works fine with `inference_mode` and JIT. `inference_mode` + `ModuleList` work fine when not jit'ed.

## To Reproduce
```py
import torch

class MLP(torch.nn.Module):
    def __init__(self) -> None:
        super().__init__()

        # works with one module
        # self.layers = torch.nn.ModuleList([torch.nn.Linear(1, 1)])

        # fails with two modules
        self.layers = torch.nn.ModuleList(
            [torch.nn.Linear(1, 1), torch.nn.Linear(1, 1)]
        )

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        for layer in self.layers:
            x = layer.forward(x)
        return x

model = MLP()
model = torch.jit.script(model)

# training
optimizer = torch.optim.Adam(model.parameters())
optimizer.zero_grad()
model(torch.rand(100, 1)).mean().backward()
optimizer.step()
optimizer.zero_grad()

# testing
with torch.inference_mode():
    model(torch.rand(100, 1))
```
```sh
  File "/pool01/home/twoertwe/.cache/pypoetry/virtualenvs/python-tools-XWCSm5JO-py3.9/lib/python3.9/site-packages/torch/nn/modules/module.py", line 1051, in _call_impl
    return forward_call(*input, **kwargs)
RuntimeError: The following operation failed in the TorchScript interpreter.
Traceback of TorchScript (most recent call last):
RuntimeError: Inference tensors cannot be saved for backward. To work around you can make a clone to get a normal tensor and use it in autograd
```

## Expected behavior

No error is thrown.

## Environment

PyTorch version: 1.9.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 16.04.7 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-10ubuntu2~16.04) 9.3.0
Clang version: 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
CMake version: version 3.15.1
Libc version: glibc-2.23

Python version: 3.9 (64-bit runtime)
Python platform: Linux-4.13.0-36-generic-x86_64-with-glibc2.23
Is CUDA available: True
CUDA runtime version: 10.2.89
GPU models and configuration: GPU 0: GeForce RTX 2080 Ti
Nvidia driver version: 440.64
cuDNN version: /usr0/local/cuda-9.0/lib64/libcudnn.so.7.0.5
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.3
[pip3] torch==1.9.0+cu102
[pip3] torchvision==0.10.0+cu102
[conda] Could not collect

cc @gmagogsfm
Repository: go
Issue: x/playground: side scroll on long output doesn't include editor area
Labels: NeedsInvestigation

I don't recall it working this way but right now scrolling sideways on long outputs scrolls the editor off screen:

https://play.golang.org/p/9SkIeFGPv0W

![2021-06-20-003300](https://user-images.githubusercontent.com/11343221/122656923-4bdff980-d15f-11eb-8299-20b267c91a55.png)
Repository: rust
Issue: `guess_head_span` depends on untracked state when used with an imported file
Labels: T-compiler,A-incr-comp,C-bug

`guess_head_span` ends up calling `ensure_source_file_source_present`, which calls `add_external_src`. If the source file of the span is an imported file, then whether or not this method succeeds depends on the _current_ file on disk:

https://github.com/rust-lang/rust/blob/0f6ba39fd89cff295067d974c49fc64b0b52ad18/compiler/rustc_span/src/lib.rs#L1447-L1451

However, the hash of the external crate depends on the hash of the file at the time the _external_ crate was compiled, not the time the current crate is compiled. If the external crate is a Cargo dependency (in `~/.cargo/registry`), then changing a file in the dependency will _not_ cause it to be re-built, allowing a new compilation session to read in a different file than the one used to originally compile the external crate.

Since `guess_head_span` falls back to the passed-in span if reading the source file fails, the span that we end up using depends on global untracked state (the *current* contents of an _external_ crate's file on disk).
Repository: excalidraw
Issue: copy and paste improvement suggest
Labels: bug

hi,

when I copy the object 
![image](https://user-images.githubusercontent.com/48077575/122661524-e7a05280-d1bd-11eb-9fa9-2caf7ca47b38.png)
and then,double-click the text I want to paste out
![image](https://user-images.githubusercontent.com/48077575/122661551-2f26de80-d1be-11eb-8e1b-ad6630ec8a25.png)
as you see
![image](https://user-images.githubusercontent.com/48077575/122661579-6bf2d580-d1be-11eb-9119-d984b43f11ae.png)
the content I paseted is an **object**,not a text 
I suggest that can be optimized 
Thank you 

Best regards
Repository: ant-design
Issue: Can't scroll tree while dragging
Labels: Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/draggable-antd4163-forked-s3qlx?file=/index.js)

### Steps to reproduce
Have a list with enough content to overflow its container, or window.

### What is expected?
While dragging, mousewheel could be used to scroll down to currently not visible component.

### What is actually happening?
Mousewheel is lock, can't scroll. If user drags the item to the top/bottom of its container, the tree is scrolled but the drag operation is aborted after a few seconds (cursor turned to 'not-allowed' icon). Programmatically scroll the tree has the same result.

| Environment | Info |
|---|---|
| antd | 4.15.2 |
| React | 17.0.2 |
| System | Windows 10 |
| Browser | Chrome 91 |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: PowerToys
Issue: new UI haven't disable variable fresh rate like g-sync
Labels: Issue-Bug,Idea-Enhancement,Help Wanted,FancyZones-Editor,Product-FancyZones,Product-Image Resizer

### Microsoft PowerToys version

0.35.0

### Running as admin

- [ ] Yes

### Area(s) with issue?

FancyZones Editor, Image Resizer

### Steps to reproduce

set `Enable G-SYNC in windowed and fullscreen` in nvidia control panel.
open the `fancyzones editor` or `image resizer`.


may related: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/variable-refresh-rate-displays
may related: https://docs.microsoft.com/en-us/windows/win32/direct2d/improving-direct2d-performance
may related: https://github.com/microsoft/PowerToys/issues/5516  **But the settings window haven't any issue now**

### ✔️ Expected Behavior

fixed fresh/redraw rate like 30 or 60.

### ❌ Actual Behavior

![image](https://user-images.githubusercontent.com/32261870/122666841-45469600-d1e2-11eb-935e-7bf9455e53e7.png)
![image](https://user-images.githubusercontent.com/32261870/122666882-7aeb7f00-d1e2-11eb-8782-9c6c4bd77dbe.png)
fresh rates both less than 20fps and feel obvious latency

### Other Software

nvidia driver version:
<!--StartFragment-->
Version: | 466.77&nbsp;&nbsp;WHQL
-- | --
Release Date: | 2021.6.10
<!--EndFragment-->
Repository: rust
Issue: Actual crate name of renamed crate is leaked through unexpected type error
Labels: A-diagnostics,T-compiler,C-bug,D-incorrect

1. `cargo new issue_86485`
2. Add this to the `Cargo.toml`'s `dependencies` section:

    ```toml
    json = { version = "*", package = "serde_json" }
    ```
    Note that [`serde_json`](https://crates.io/crates/serde_json) is here renamed to `json` for the project.
3. Make this your `main.rs`:

    ```rs
    enum Value {}

    fn main() {
        let value: Value = json::Value::Null;
    }
    ```

The current output is:

```
error[E0308]: mismatched types
 --> src/main.rs:4:24
  |
4 |     let value: Value = json::Value::Null;
  |                -----   ^^^^^^^^^^^^^^^^^ expected enum `Value`, found enum `serde_json::Value`
  |                |
  |                expected due to this

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: could not compile `issue_86485`

To learn more, run the command again with --verbose.
```

Note that it says this:

> expected enum `Value`, found enum `serde_json::Value`

Instead of this:

> expected enum `Value`, found enum `json::Value`

It leaks the actual crate name (`serde_json`) instead of using the user's desired name (`json`) for the crate. 

Ideally the output should look like:

```
error[E0308]: mismatched types
 --> src/main.rs:4:24
  |
4 |     let value: Value = json::Value::Null;
  |                -----   ^^^^^^^^^^^^^^^^^ expected enum `Value`, found enum `json::Value`
  |                |
  |                expected due to this

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: could not compile `issue_86485`

To learn more, run the command again with --verbose.
```
Thanks to @ehuss for providing this reproduction. They also noted that:
> I think in this particular case, E0308 tries to shorten the path if it is unambiguous, and I suspect it is that path shortening which uses the "real" crate name instead of the resolve-based name. I see other errors use the resolve path. Since this is done in typechecking, I'm not sure if the resolver information is readily available, though. 
<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->
Repository: transformers
Issue: Add TFSpeech2Text
Labels: WIP

# 🚀 Feature request
Add TensorFlow implementation of Speech2Text model.

## Your contribution

I'll try to do this.

**Reviewers:** @patil-suraj
Repository: create-react-app
Issue: Issue while executing npm start for react application
Labels: stale

Created react applicaiton using "npm create-react-app my-react-app". using npm v6.14.8 & node v12.19.0. npm sart throws the below error all the time 
<img width="974" alt="Screenshot 2021-06-20 at 4 46 19 PM" src="https://user-images.githubusercontent.com/25685941/122672028-11ba3a80-d1e7-11eb-8fee-c6dbf4c32a14.png">

Methods tried to fix the issue:

I removed the package.lock.json file and node_modules directory, and ran npm install.

I reinstalled node and npm.

I reinstalled create-react-app and react-scripts-start

Additional information:
Node version: v12.19.0
Npm version: 6.14.8
Repository: vscode
Issue: Non-quoted attribute value in emmet abbreviation breaks parsing with attribute later down in abbreviation
Labels: bug,upstream,emmet,confirmed,upstream-issue-linked

Issue Type: <b>Bug</b>

In emmet abbreviations with several tag attributes included, a non-quoted attribute value causes the entire abbreviation until the next tag with an attribute to not be expanded.

Expected:

`a[href=#]>p>a[href=#]`

should expand into:

```
<a href="#">
  <p><a href="#"></a></p>
</a>
```

but instead expands into:

`a[href=#]>p><a href="#"></a>`

I.e., it expands as if everything up until the final `a[href=#]` was ignored.

This has been tried with extensions entirely disabled, with other emmet abbreviation structures, and with different attribute values, to the same result.

![vscode-1624192446163](https://user-images.githubusercontent.com/603204/122674297-c72fc280-d1d4-11eb-81c8-11378610d830.gif)

(edit: included recording)

VS Code version: Code 1.57.1 (507ce72a4466fbb27b715c3722558bb15afa9f48, 2021-06-17T13:28:07.755Z)
OS version: Windows_NT x64 10.0.19043
Restricted Mode: No

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-4690K CPU @ 3.50GHz (4 x 3498)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: enabled<br>opengl: enabled_on<br>rasterization: enabled<br>skia_renderer: enabled_on<br>video_decode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|7.94GB (1.76GB free)|
|Process Argv|--crash-reporter-id 378cd57f-0e8a-4c1c-ab47-db31f5325277|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (15)</summary>

Extension|Author (truncated)|Version
---|---|---
emmet-keybindings|agu|1.0.1
chronicler|arc|0.1.11
vscode-tailwindcss|bra|0.6.11
todo-tree|Gru|0.0.213
rest-client|hum|0.24.5
csharp|ms-|1.23.12
python|ms-|2021.6.944021595
vscode-pylance|ms-|2021.6.2
jupyter|ms-|2021.6.999406279
remote-wsl|ms-|0.56.5
cpptools|ms-|1.4.1
mono-debug|ms-|0.16.2
godot-csharp-vscode|nei|0.1.3
vim|vsc|1.21.3
vsc-jsonsnippets|wmo|0.9.3


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vsreu685:30147344
python383:30185418
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vstes627:30244334
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551cf:30311713
vspre833:30321513
pythonptprofiler:30281270
vshan820:30294714
pythondataviewer:30285071
vscus158:30321503
pythonvsuse255:30323308
vscorehov:30309549
vscod805:30301674
vscextlangct:30322307
binariesv615:30323119
vsccppwt:30322536

```

</details>

<!-- generated by issue reporter -->
Repository: godot
Issue: Hide the non-TileMap grid when the TileMap editor is active
Labels: enhancement,topic:editor,usability,topic:2d

### Godot version

3.3.2 mono stable oficial

### System information

win10 64

### Issue description

When I select a tilemap, only the tilemap guides should be shown, the standard guides don't make sense and shouldn't be shown. Showing themselves makes you look confused.

![gif gif](https://user-images.githubusercontent.com/19652075/122676714-7c677800-d1df-11eb-8e06-172f08c8f969.gif)


### Steps to reproduce

Select a tilemap node
select another type of node
observe the guides

### Minimal reproduction project

_No response_