sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Nested async closures result in exponential compilation time increase
Labels: P-medium,I-compiletime,A-closures,T-compiler,C-bug,A-async-await,AsyncAwait-Triaged

I've noticed exponential increases in compilation times as I nest async closures within each other. 

I tried this code:

```rust
macro_rules! compose_middleware_inner {
  ( $route:ident, $first:ident, $second:ident, $($tail:ident), +) => {
    $first(|| async {
        compose_middleware_inner!($route, $second, $($tail),+)
    }).await
  };
  ( $route: ident, $first:ident, $second:ident ) => {
    $first(|| async move { $second($route).await }).await
  };
}

macro_rules! compose_middleware {
    ( $name:ident, $($tail:ident), +) => {
        pub async fn $name<N, Fut>(route: N)
        where
            N: FnOnce() -> Fut,
            Fut: std::future::Future<Output = ()>,
        {
            compose_middleware_inner!(route, $($tail),+)
        }
    }
}

async fn log<N, Fut>(next: N)
where
    N: FnOnce() -> Fut,
    Fut: std::future::Future<Output = ()>,
{
    println!("log start");
    next().await;
    println!("log end");
}

compose_middleware!(
    my_middleware, log, log, log, log, log, log, log, log, log, log, log, log, log
);
```

That `compose_middleware!` macro invocation generates a function that looks something like this: 
```rust
pub async fn my_middleware<N, Fut>(route: N)
where
    N: FnOnce() -> Fut,
    Fut: Future<Output = ()>,
{
    log(|| async { log(|| async { log(|| async move { log(route).await }).await }).await }).await
}
```

I expected to see this happen:  I expected this code to build within seconds

Instead, this happened: At around 3 levels it takes less than a second to build. At around 9 levels it takes around a minute to build. At around 14 levels it takes around 10 minutes to build. 

### Meta

I've experienced this issue on nightly, stable, and beta. And I've sampled random nightly versions going back as far as 1.39 and still witnessed the problem. There was a good bit of variability in build times, but it generally seemed to increase exponentially.

I threw this little repo up to test the issue: https://github.com/blazzy/slow-rust-async/blob/master/src/lib.rs

I thought it might be related to this issue https://github.com/rust-lang/rust/issues/72408 with nested closures. Or this issue https://github.com/rust-lang/rust/issues/75992 with levels of async, but those look to be resolved.
Repository: rust
Issue: Extend "similarly named" to handle different word order (like assert_debug)
Labels: A-diagnostics,T-compiler

Personally, I often write things like "assert_debug!" (instead of debug_assert)

I would find it useful if Rust's "there is a similarly named operator" would check splitting names on underscores (and possibly also on CamelCase?), when trying to find similarly named names.

I realise that the search for similar names could go on forever, but I at least hit this one frequently.
Repository: electron
Issue: [Feature Request]: Allow resource files containing multiple icons to be used for MenuItem icons
Labels: enhancement :sparkles:,platform/windows

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

To add an icon to a MenuItem, we can currently provide either the path to a single icon (JPEG, PNG, or ICO) or a nativeImage made from one of the three file types. If I have a resource file containing multiple icons, I'm unable to specify an icon within it to be displayed.

### Proposed Solution

Add the ability to specify an arbitrary resource file (including EXEs and DLLs) as the iconPath and then specify an iconIndex of the icon to be displayed. This approach is currently available for some things like Tasks (https://www.electronjs.org/docs/api/structures/task) and JumpListItems (https://www.electronjs.org/docs/api/structures/jump-list-item), but not for MenuItems.

### Alternatives Considered

None

### Additional Information

None
Repository: rust
Issue: rustdoc: Fix inconsistencies in `const` value rendering
Labels: C-cleanup,T-rustdoc,A-const-eval

The topic of this issue has changed since it was first opened. See https://github.com/rust-lang/rust/issues/83035#issuecomment-989336938 for a more up-to-date summary.

-----

The way they're displayed is both different (one use a `BodyId` whereas the other is forced to use its `DefId`. But ultimately, it'd be nice to be able to merge them.

_Originally posted by @GuillaumeGomez in https://github.com/rust-lang/rust/pull/82873#discussion_r592711179_

This will be done after #82873 is merged.
Repository: godot
Issue: Adding certain floats to a Control node's rect_position results in rect_size distortion
Labels: bug,topic:gui

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
v3.2.3.stable.official

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 10

**Issue description:**
<!-- What happened, and what was expected. -->
I'm adding `delta` to a `MarginContainer`'s `rect_position.x` and `rect_position.y` properties in `_process(delta)`.
I would expect `rect_size` to remain constant but instead it varied by very small amounts. It seems like `rect_size` gets truncated when the pixels are rendered onto the screen which means this can have a visual impact as well
https://user-images.githubusercontent.com/28541089/110866244-be1d8400-82bc-11eb-8abb-0c9667af247e.mp4

A workaround is using the `Control`'s `min_size` property or setting the `rect_size` manually but this isn't ideal and `min_size` won't fix the issue where `rect_size` increases slightly

**Steps to reproduce:**
1. Add a Control node to a scene (the issue seems to be worse with MarginContainers)
2. Add a float to its `rect_position.x`/`rect_position.y` property in `_process(delta)` (`delta` works but `0.5` does not)

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
The small window size is not required, it just makes it easier to see the issue
[MRP.zip](https://github.com/godotengine/godot/files/6126357/MRP.zip)
Repository: vscode
Issue: 3rd button in "Cannot reconnect" dialog that allows you to disconnect
Labels: feature-request,api,remote-connection

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
![image](https://user-images.githubusercontent.com/2644648/110870611-a83e9d80-8281-11eb-9515-ee63cd9477d3.png)

When I see this, sometimes I want to just "disconnect" so I can open a different Codespace or open a folder locally. Today I have to:

* close that window, reopen VS Code, open codespace I want (takes 3 actions)
* (BROKEN See https://github.com/microsoft/vscode/issues/118772) click cancel, disconnect in Codespaces view, connect to Codespace I actually want to connect to (takes 3 actions)
* reconnect (takes time), disconnect in Codespaces view, connect to Codespace I actually want to connect to (takes 3 actions)

If there was a 3rd button to disconnect, I could do what I want in 2 actions (disconnect, connect to other codespace)
Repository: terminal
Issue: [DefApp] Document how it works
Labels: Product-Conhost,Issue-Docs,Area-Server,Product-Terminal,Priority-2,Area-DefApp

@miniksa and @cinnamon-msft to document how this works.

_Originally posted by @miniksa in https://github.com/microsoft/terminal/pull/7489
```[tasklist]
### Tasks
- [ ] Document how the app extension goo works
- [ ] document the com server interface
- [ ] probably add a way to do defterm unpackaged as well
```
Repository: pytorch
Issue: After the source code is compiled, an error will be reported fvcore
Labels: oncall: jit

python:3.7.9
pytorch:1.7
linux:centos
Traceback (most recent call last):
  File "demo/demo.py", line 12, in <module>
    from detectron2.data.detection_utils import read_image
  File "/home/loongson/detectron2/detectron2/data/__init__.py", line 4, in <module>
    from .build import (
  File "/home/loongson/detectron2/detectron2/data/build.py", line 12, in <module>
    from detectron2.structures import BoxMode
  File "/home/loongson/detectron2/detectron2/structures/__init__.py", line 7, in <module>
    from .masks import BitMasks, PolygonMasks, polygons_to_bitmask
  File "/home/loongson/detectron2/detectron2/structures/masks.py", line 9, in <module>
    from detectron2.layers.roi_align import ROIAlign
  File "/home/loongson/detectron2/detectron2/layers/__init__.py", line 19, in <module>
    from .blocks import CNNBlockBase, DepthwiseSeparableConv2d
  File "/home/loongson/detectron2/detectron2/layers/blocks.py", line 4, in <module>
    import fvcore.nn.weight_init as weight_init
  File "/usr/local/python3/lib/python3.7/site-packages/fvcore/nn/__init__.py", line 4, in <module>
    from .focal_loss import (
  File "/usr/local/python3/lib/python3.7/site-packages/fvcore/nn/focal_loss.py", line 51, in <module>
    sigmoid_focal_loss
  File "/usr/local/python3/lib/python3.7/site-packages/torch/jit/_script.py", line 940, in script
    qualified_name, ast, _rcb, get_default_args(obj)
TypeError: Object of type 'module' is not an instance of 'function'



cc @gmagogsfm
Repository: frp
Issue: support mulit-link(path) aggregation and failover
Labels: proposal

<!-- From Chinese to English by machine translation, welcome to revise and polish. -->

**The solution you want**
<!--A clear and concise description of the solution you want. -->
A server or client machine may have multiple IP addresses, that means, you can reach your server via multiple paths(or links), if we aggregate these links to one virtual path, we will speed up the tunnel, and get a stable tunnel if implemented failover.

**Alternatives considered**
<!--A clear and concise description of any alternative solutions or features you have considered. -->
The following alternatives are not easy to use, they all are written in C, you need root to run it, and doesn't work in Windows:
Linux Kernel implementation of [MultiPath TCP (MPTCP)](https://multipath-tcp.org/)
[Glorytun](https://github.com/angt/glorytun) is a small, simple and secure multipath UDP tunnel.
[MLVPN](https://github.com/zehome/MLVPN) - Multi-Link Virtual Public Network

**How to implement this function**
<!--Implementation steps for the solution you want. -->

**Application scenarios of this function**
<!--Make a clear and concise description of the application scenario of the solution you want. -->
Repository: pytorch
Issue: Add comprehensive subgroup testing to torch.distributed
Labels: oncall: distributed,triaged,module: c10d,module: ddp

We currently don't test DDP/torch.distributed comprehensively with subgroups, and instead use the world-wide process group for nearly all DDP/torch.distributed tests, besides a small amount of tests that test subgroups in specific cases.

This has let to subtle bugs such as https://github.com/pytorch/pytorch/pull/53793 where we used `dist.get_rank()` instead of `dist.get_rank(self.process_group)`; the former could lead to issues if DDP is operating on a subgroup instead of the whole world.

We should add comprehensive testing for subgroups to `distributed_test` as well as test_c10d.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu
Repository: pytorch
Issue: [JIT][Static Runtime] Memory optimization for output tensors
Labels: oncall: jit

One of the unique features of Static Runtime is the MemoryPlanner, which aggregates all the memory allocation of the intermediate tensors into a single malloc and caches all the TensorImpls into Static Runtime. It helps speed up inference by reducing the number of mallocs and the time it takes to create/destry Tensor objects and the associated refcount bumps on the fly. However, MemoryPlanner only manages the intermediate tensors, which exclude model inputs and outputs. If we can extend MemoryPlanner to include the output tensors, we can speed up models with multiple outputs dramatically.

First, we'll need some bookkeeping for the output tensors:

```
  std::vector<std::pair<size_t, std::vector<c10::StorageImpl*>>> managed_output_storage_;
  size_t managed_output_bytes_{0};
  at::DataPtr output_buffer_; // for outputs only
```
For implementation, see https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/runtime/static/impl.cpp
Similar to the intermediates, for outputs, MemoryPlanner can only manage output tensors of ops with out variants. For ops without out variants, their output tensors will be dynamically created by the op. There is nothing the MemoryPlanner can do.

Do pay attention to aliases. We'll need to exclude model input and input aliases. Aliases of intermediate tensors and output tensors need to handled carefully.

For testing, there are a lot of unit tests in https://github.com/pytorch/pytorch/blob/master/benchmarks/static_runtime/test_static_runtime.cc and https://github.com/pytorch/pytorch/blob/master/test/test_static_runtime.py.


cc @gmagogsfm
Repository: rust
Issue: rustdoc: `broken_intra_doc_links` triggers on link to private item
Labels: T-rustdoc,E-hard,P-low,C-bug,A-intra-doc-links

#### ⚠️ Warning ⚠️ 

Discussion needs to take place and agreement needs to be reached before implementing this! See https://github.com/rust-lang/rust/issues/83049#issuecomment-798995424.

-----

This should succeed, but it does not.

```rust
mod foo {
    //! Look at [super::bar::baz].
}

mod bar {
    fn baz() {}
}
```

```
$ rustdoc foo.rs --document-private-items
warning: unresolved link to `super::bar::baz`
 --> foo.rs:2:18
  |
2 |     //! Look at [super::bar::baz].
  |                  ^^^^^^^^^^^^^^^ no item named `baz` in module `bar`
  |
  = note: `#[warn(broken_intra_doc_links)]` on by default

warning: 1 warning emitted
```
Repository: pytorch
Issue: [JIT] Bad interaction between if-else-style and assert-style type refinement
Labels: oncall: jit

## 🐛 Bug

```
import torch
from typing import Any

def fn(x: Any) -> int:
    if isinstance(x, torch.Tensor):
        res = int(x.item())
    else:
        assert isinstance(x, int)
        res = x

    return res

torch.jit.script(fn)
```

Error:
```
RuntimeError:
Type mismatch: x is set to type Tensor in the true branch and type int in the false branch:
```

This is a common pattern used in type refinement, but it breaks in TS. It seems TorchScript treats `assert isinstance(x, int)` in else-branch as an unconditional type refinement that applies to scope outside of else-branch. 


cc @gmagogsfm @nikithamalgifb , this is one example of rough edges when using `any` and `union` in type refinement
Repository: storybook
Issue: Need a reliable way to test if storybook page is ready programatically
Labels: question / support,core

**Is your feature request related to a problem? Please describe**
Start-server-and-test is very reliable with storybook <= 5 because the HTTP endpoint isn't available until everything is built, but stop working with storybook 6 because the webserver is up before it is ready and shows a `building n/m modules` screen, therefore the endpoint test doesn't work anymore


![image](https://user-images.githubusercontent.com/6635904/110896561-f91cc780-834f-11eb-947d-82cb54dae64c.png)

Then in my CI, the timeout error happens a lot

   TimeoutError: page.goto: Timeout 30000ms exceeded.
    =========================== logs ===========================
    navigating to "http://localhost:5002/iframe.html?id=taskfilterlist--story&viewMode=story", waiting until "domcontentloaded"
    ============================================================
    Note: use DEBUG=pw:api environment variable and rerun to capture Playwright logs.page.goto: Timeout 30000ms exceeded.
    =========================== logs ===========================
    navigating to "http://localhost:5002/iframe.html?id=taskfilterlist--story&viewMode=story", waiting until "domcontentloaded"
    ============================================================
    Note: use DEBUG=pw:api environment variable and rerun to capture Playwright logs.:
      15 | 
      16 | const gotoStory = async (page: Page, id) => {
    > 17 |   await page.goto(`http://${hostname}:5002/iframe.html?id=${id}&viewMode=story`, {
         |              ^
      18 |     waitUntil: 'domcontentloaded',
      19 |   });

**Describe the solution you'd like**
A cli option to disable the progress screen

**Describe alternatives you've considered**
noo

**Are you able to assist to bring the feature to reality?**
no

**Additional context**

This [ticket](https://github.com/microsoft/playwright/issues/3151) for Playwright was most likely caused by the same issue
Repository: pytorch
Issue: [JIT] TorchScript errors out when assigning a value to an existing variable that's defined in outer block
Labels: oncall: jit

## 🐛 Bug

```
import torch
from typing import List

def fn(x: torch.Tensor, b: bool):

    a: List[int] = []
    if b:
        a: List[int] = [1]

    return a

print(fn(torch.ones(3), True))
scripted = torch.jit.script(fn)
```

Error:
```
RuntimeError:
Attempting to declare and annotate the type of variable 'a' but it is already defined in an outer block:
  File "reannotate.py", line 8
    a: List[int] = []
    if b:
        a: List[int] = [1]
        ~ <--- HERE

    return a
```

This is problematic because in certain cases like assigning `[]` or `tensor.tolist()` value to a variable requires type annotation. And since this bug makes python3-style type annotation not usable, users would have to resort to `torch.jit.annotate`, which is less pythonic and less known to users. 

cc @gmagogsfm
Repository: godot
Issue: Function signature hint tooltip doesn't work when calling another script function
Labels: bug,topic:gdscript

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
tested on `3.2.3`, `3.2.4rc4`

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Lunux

**Issue description:**
<!-- What happened, and what was expected. -->
Function signature hint tooltip works only for
- Godot API functions (`Color()`, `connect()` etc)
- functions created in the current script
- and inner classes functions

![works](https://user-images.githubusercontent.com/16458555/110898603-59484500-8321-11eb-911a-1d4ebf7dca6b.png)


![signature_hint_works](https://user-images.githubusercontent.com/16458555/110897304-066d8e00-831f-11eb-9f9d-954597d558ff.png)

This doesn't work for another script functions

![doesnt_work](https://user-images.githubusercontent.com/16458555/110898825-c6f47100-8321-11eb-858b-181756699d4f.png)



**Steps to reproduce:**
1. create `new_script.gd`:
```gdscript
extends Node

func f(a,b):
	pass

```

2. create `new_script2.gd`:

```gdscript
extends Node

func _ready():
	preload("res://new_script.gd").new().f()
```
As you can see, when you type `..new().f(`, `f` signature tooltip doesn't appear.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: PowerToys
Issue: Refactor "Settings.UI.Library" 
Labels: Product-Settings,Area-Quality,Cost-Large

`Settings.UI.Library` contains view model and model definitions for the Setting UI app.
It also contains other classes used by other modules (see https://github.com/microsoft/PowerToys/issues/10146)

We want to refactor this library in multiple libraries and make each library clean and consistent.
Repository: godot
Issue: TextureArray imported with VRAM mode won't correctly appear on mobile (ios) devices.
Labels: bug,platform:ios,topic:rendering

**Godot version:**
3.2.3


**OS/device including version:**
iPhone 6S, ios 14.4


**Issue description:**
TextureArray imported with VRAM mode won't correctly appear on mobile (ios) devices.


**Steps to reproduce:**
Import image as TextureArray with VRAM mode, add ColorRect node with a custom shader. Export project to iPhone.
There is a shader for drawing TextureArray:
```glsl
shader_type canvas_item;

uniform sampler2DArray TEX;
uniform float idx;

void fragment() {
	COLOR = texture(TEX, vec3(UV.x, UV.y, idx));
}
```

There is how the project looks on desktop:
![IMAGE 2021-03-12 11:11:57](https://user-images.githubusercontent.com/122736/110911438-c52bad00-8323-11eb-926b-a98fbbef492c.jpg)
There is how it looks on a mobile device:
![IMAGE 2021-03-12 11:11:44](https://user-images.githubusercontent.com/122736/110911421-be049f00-8323-11eb-9566-341dd7b60c01.jpg)


**Minimal reproduction project:**
[bug-texture-array-allocation.zip](https://github.com/godotengine/godot/files/6128490/bug-texture-array-allocation.zip)
Repository: neovim
Issue: Ignore modified state with buftype prompt 
Labels: enhancement

[nvim-dap](https://github.com/mfussenegger/nvim-dap) uses `buftype=prompt` for the debug REPL.

It looks as if by default any input to a prompt buffer sets the `modified` flag. This is a bit annoying for the REPL case, because users usually don't care whether the REPL is modified or not and they shouldn't get a "Did not save [dap-repl]" message. So I added something like this:


```
api.nvim_buf_attach(buf, false, {
  on_lines = function(b)
    api.nvim_buf_set_option(b, 'modified', false)
  end;
  on_changedtick = function(b)
    api.nvim_buf_set_option(b, 'modified', false)
  end;
  ...
```

But this workaround had the side effect of [breaking the backspace key](https://github.com/mfussenegger/nvim-dap/issues/119) in that after you type something you can no longer remove the characters with backspace.


Is there any other good way to that would allow to treat a prompt buffer like a terminal or `nofile` where modifications don't matter?