sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [JIT] Metaprogram non-type based expression trees
Labels: oncall: jit

## 🚀 Feature - Metaprogram non-type based expression trees

Currently in TorchScript we metaprogram if statements with conditionals that have type-based logic in them.

In the following example, we reason that `torch.Tensor` is statically never none, so we do not compile the True branch. 

```
@torch.jit.script
def foo(x: torch.Tensor):
      if x is None:
           return "abc" / 3
      return x + 2
````

We also metaprogram on a select number of other builtins `is_scripting`, `is_tracing`, `hasattr`, as well as module attribute booleans which are annotated constant. 

I propose that we extend this behavior to expression trees which have constant inputs. Take the example given [here]( https://github.com/pytorch/pytorch/issues/51018), which currently fails to compile.

```
from typing import Final

import torch


class Test(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.models: Final = torch.nn.modules.container.ModuleList([])

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        if len(self.models) != 0:
            x = self.models[0](x)
        return x


print(torch.__version__)  # 1.7.1+cu101
model = Test()
torch.jit.script(model)

```

At the time of emitting `if len(self.models) != 0` we would see that the input to the if statement as:  
```
  %1 : int = prim::Constant[value=0]() # test/temp.py:5:7
  %2 : bool = aten::ne(%1, %1) # test/temp.py:5:7
   = prim::If(%2) # test/temp.py:5:4
``` 
And know that we can constant-fold `%2` at the time of compilation. We would only handle immutable types - tuples & scalars. We would also need to make `len(self.models)` emit as a constant but that should not be too tricky to do. 



cc @gmagogsfm
Repository: go
Issue: cmd/compile: match Aux/AuxInt more strictly in rewriting rules
Labels: NeedsDecision,compiler/runtime

Currently, in a rewriting rule, on the LHS if a value's Aux or AuxInt is not specified, it is ignored by the rule matcher. This is error-prone. One example is a rule introduced in CL https://go-review.googlesource.com/c/go/+/280456, where the ignored Aux/AuxInt causes miscompilation (#44823).

To make it less error-prone, maybe we want the rule matcher to require Aux/AuxInt to be always specified on the LHS (using _ to explicitly ignore)? Or maybe we want it to match the zero value if not specified? 

Discussion from CL https://go-review.googlesource.com/c/go/+/299289:
@randall77 :
>> maybe we want the rule matcher require Aux/AuxInt to be always specified on the LHS
>
> Yes please. Now with strongly typed rules it should be fairly straightforward.
>
> Speaking of which, I was hoping at some point to get rid of the distinction between Aux and AuxInt. Now that everything is typed, we can just have Aux types for everything, and some of them might be {Sym, int32} pairs or whatever. Value.Aux and Value.AuxInt would just be the storage for those aux values.
(Which should be great for rewrite rules. I'm not sure how great/terrible it would be for other compiler passes.)

@josharian :
> the value of auxint is that it avoids an alloc.
Repository: pytorch
Issue: [bug][JIT] Error when tracing model with partial hooks in PyTorch v1.8.0
Labels: oncall: jit

## 🐛 Bug

:wave: Hello! Well done on releasing v1.8.0 with so many new great features.

I might have found a bug which was not in previous versions (tested against 1.7.0 and 1.7.1). It's related to the use of `torch.jit.script` after registering a forward hook prepared with `functools.partial`.

## To Reproduce

This is a minimal reproducible example:

```
import torch
import torchvision
from functools import partial

def hook(module, input, output, foo):
    print(foo)

model = torchvision.models.resnet18()
hook_fn = partial(hook, foo="bar")
model.layer4.register_forward_hook(hook_fn)

torch.jit.script(model)
model(torch.rand(7, 3, 224, 224))
```

v1.8.0 output:
```
Traceback (most recent call last):
  File "test_jit.py", line 12, in <module>
    torch.jit.script(model)
  File ".../.env/lib/python3.6/site-packages/torch/jit/_script.py", line 943, in script
    obj, torch.jit._recursive.infer_methods_to_compile
  File ".../.env/lib/python3.6/site-packages/torch/jit/_recursive.py", line 391, in create_script_module
    return create_script_module_impl(nn_module, concrete_type, stubs_fn)
  File ".../.env/lib/python3.6/site-packages/torch/jit/_recursive.py", line 448, in create_script_module_impl
    script_module = torch.jit.RecursiveScriptModule._construct(cpp_module, init_fn)
  File ".../.env/lib/python3.6/site-packages/torch/jit/_script.py", line 391, in _construct
    init_fn(script_module)
  File ".../.env/lib/python3.6/site-packages/torch/jit/_recursive.py", line 428, in init_fn
    scripted = create_script_module_impl(orig_value, sub_concrete_type, stubs_fn)
  File ".../.env/lib/python3.6/site-packages/torch/jit/_recursive.py", line 405, in create_script_module_impl
    hook_stubs, pre_hook_stubs = get_hook_stubs(nn_module)
  File ".../.env/lib/python3.6/site-packages/torch/jit/_recursive.py", line 664, in get_hook_stubs
    if hook.__name__ in hook_map:
AttributeError: 'functools.partial' object has no attribute '__name__'
```

## Expected behavior

For the example above we should expect no error and `bar` on stdout.

## Environment

```
Is debug build: True
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.4 LTS (x86_64)
GCC version: (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
Clang version: Could not collect
CMake version: Could not collect

Python version: 3.6 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: 9.0.176
GPU models and configuration: GPU 0: GeForce GTX 960M
Nvidia driver version: 450.80.02
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.5
[pip3] torch==1.7.0, 1.7.1 when it's working. 1.8.0 when it fails
[pip3] torchvision==0.8.1 or 0.8.2 when it's working. 0.9.0 when it fails
[conda] Could not collect
```


cc @gmagogsfm
Repository: godot
Issue: RigidBody gets stuck on collision boundaries
Labels: bug,confirmed,topic:physics,topic:3d

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.2-stable, 3.2.3-stable, 3.2.4rc3 (GodotPhysics), 4-4de0768cd (GodotPhysics3D and Bullet)

**OS/device including version:**
Windows 10 20H2, Kubuntu 20.10

**Issue description:**
When moving a RigidBody in character mode across a flat surface composed of one or more static collision bodies, it will frequently get stuck at the edges of triangles, convex hulls, and collision primitives, as if running into a wall at these points. Exactly which edges will be collided with in this way is difficult to predict, but the RigidBody still gets stuck very consistently. This issue occurs instead of #46596 if using GodotPhysics in the same scenario in 3.2, and happens with either physics engine in 4 (as of this morning).

**Steps to reproduce:**
1. Create a RigidBody in character mode that can be moved around by the user
2. Create a flat, static terrain with any type of collision shapes side-by-side (I used a GridMap)
3. (In 3.2) Switch to GodotPhysics
4. Enable "Visible Collision Shapes" option in the editor
5. Run the scene, attempt to move your RigidBody around, and enjoy the glitch

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
For 3.2:
[3.2_godotphysics_sticky.zip](https://github.com/godotengine/godot/files/6094046/3.2_godotphysics_sticky.zip)
For 4:
[StickyRigid_4_4de0768cd.zip](https://github.com/godotengine/godot/files/6094050/StickyRigid_4_4de0768cd.zip)
(Arrow keys/space to jump move the RigidBody. Orange terrain is trimesh planes, red is trimesh cubes, yellow is convex cubes, green is BoxShapes. There are a couple different scenes with different sizes of character RigidBody)
Repository: pytorch
Issue: Backward compute time in DDP logging may not be accurate 
Labels: oncall: distributed,triaged

## 🐛 Bug

We start recording backwards compute time in `Reducer::prepare_for_backward`: https://github.com/pytorch/pytorch/blob/master/torch/lib/c10d/reducer.cpp#L901. However, prepare_for_backward is actually called at the end of the forward pass, and thus the model still generally has at least loss computation and could potentially do other operations before actually calling backwards. Hence the absolute time logged here may not be accurate. 

On the other hand, at least in cases where loss computation is relatively quick and we immediately go into bwd after forward pass, this inaccuracy may not be too much. But the case I'm concerned about is the following:
```
outputs = ddp(inputs) # runs reducer::prepare_for_bwd
# ... any arbitrary, long-running code
loss = CrossEntropy(outputs)
# possibly compute multiple losses
# ... any arbitrary, long-running code
loss.backward() # backwards actually starts 
```




cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu
Repository: flutter
Issue: Create System to Hook into Flutter CLI commands
Labels: tool,c: proposal,P3,team-tool,triaged-tool

## Use case

- If you want to create a web app that uses Rust WASM Bindgen, you could have the WASM build whenever the app starts, and whenever there is a hot reload and there are changes in the Rust code directory
- If you are using C++ code in an App, you can have it regenerate whenever the app is being built for production.
- If you are using Codegen frameworks like MobX, you could have it automatically update the generated files on a run, build, or reload with their base-files changed. This is better than having them generate every time a file changes because they can be only generated when they are needed. 
- Run Flutter Format and Flutter Test when publishing to pub.dev

## Proposal

I believe a structure similar to Github Actions would work extremely well for this. A `.flutter/scripts/` folder could contain individual yaml files for different actions.

an example of this could be
`./flutter/scripts/build-rust.yaml`

```yaml
on:
    run:
    reload:
           # IF THIS DIRECTORY HAS CHANGES
            - rust/

commands:
       run: rustc rust/main.rs
       run: cp rust/main assets/wasm
```
Repository: godot
Issue: iOS 12.5.1 improperly renders mesh instances with skeletons, but not on earlier or later iOS versions (GLES3)
Labels: bug,platform:ios,topic:rendering,needs testing

**Godot version:**
Currently tested with 3.2.4 rc3, haven't setup the project to back test.


**OS/device including version:**
iPhone 6 and 6 plus running 12.5.1, their most up-to-date version


**Issue description:**
I was working with a rigged/animated model in blender, exported to gltf and imported into Godot.  The model rendered and was animated properly on Windows 10, M1 macOS, iOS 14.4, but would end up with a completely twisted up model on iOS 12.5.1, which is the highest available iOS version for all devices older than and including the iPhone 6 plus.  Here's a comparison of the correct rendering on an iPhone 7 running 14.4, vs an iPhone 6 running 12.5.1:

![dolphin_good](https://user-images.githubusercontent.com/482282/110191287-86629800-7df5-11eb-85a1-788d4a45b747.png)
![dolphin_bad](https://user-images.githubusercontent.com/482282/110191288-86629800-7df5-11eb-8352-a84291033cd7.png)

However, I found another device that had not been been updated to 12.5.1, and I believe was running 11.3 (might have been another 11.X), that _did not_ have the same issue.  I played with the model every way I could in blender, modifying the objects, removing materials, and then only thing that made a difference was removing the armature in the hierarchy, or applying the armature modifier (which is effectively removing it's ability to be used for animation).

This caused no skeleton to be present in Godot, and I found that just taking something that had been imported and created a skeleton, and then removing it and just keeping the mesh instance would resolve the rendering issue.  Worried that it was my model, I found another and had the same behavior.  I then grabbed the [IK project](https://godotengine.org/asset-library/asset/523) from the Godot documentation on [Skeletons](https://docs.godotengine.org/en/stable/classes/class_skeleton.html), and modified it to just display a scene with the model that includes a skeleton, and this produced similar behavior:

![robot_good](https://user-images.githubusercontent.com/482282/110191882-ee66ad80-7df8-11eb-8f10-361ea310184d.png)
![robot_bad](https://user-images.githubusercontent.com/482282/110191881-ee66ad80-7df8-11eb-9ae0-819020eaa6aa.png)

So at this point, it seems that something about iOS 12.5.1, or I presume other 12.X versions does not play nicely with godot's skeletons.  I've included my modified version of the Skeleton example IK project as the minimal repro project, you'll need to export it for iOS as I didn't want to include an entire Xcode archive here if not necessary.


**Steps to reproduce:**

Run any project that attempts to render a mesh instance with a skeleton on an iOS device running 12.5.1, or possibly other 12.x versions, which is up-to-date version for all iOS devices older than and including the 6 plus.


**Minimal reproduction project:**
[ik.zip](https://github.com/godotengine/godot/files/6094545/ik.zip)
Repository: pytorch
Issue: Pipe should automatically build appropriate partitions.
Labels: triaged,pipeline parallelism

## 🚀 Feature

The Pipe API accepts an `nn.Sequential` and builds as many partitions as number of elements in nn.Sequential. As a result, this implies that if the nn.Sequential has multiple elements on the same device, the pipeline becomes inefficient as it performs a bunch of processing between partitions that is unnecessary. This slows down pipeline execution quite a bit.

## Pitch

To resolve this, the Pipe API itself can walk through the list of modules and combine a list of modules on the same device into an nn.Sequential automatically to avoid having partitions on the same device.


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu
Repository: pytorch
Issue: Add complex support for torch.unique
Labels: triaged,module: complex,module: numpy,complex_autograd,function request,module: python array api

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
ComplexFloat support for torch.unique 

## Motivation
I need to use this during training my network
<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

## Pitch
I am using this to find unique values per row in 2d tensor much faster.

<!-- A clear and concise description of what you want to happen. -->

## Alternatives
The alternative is to do a for loop over each row and use torch unique on each row which slows the training significantly
<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->
   complex_tensor =  tensor([[ 2.+0.j,  3.+0.j,  9.+0.j,  3.+0.j, 10.+0.j, 10.+0.j,  4.+0.j,  3.+0.j, 10.+0.j,  8.+0.j], 
                                              [ 9.+10.j,  1.+10.j,  8.+10.j,  2.+10.j,  6.+10.j,  6.+10.j,  6.+10.j,  1.+10.j, 8.+10.j,  5.+10.j]
                                             ])

u, ind, cnt = torch.unique(complex_tensor return_inverse=True, return_counts=True)

RuntimeError: "unique" not implemented for 'ComplexFloat'

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved @rgommers @pmeier @asmeurer @leofang @AnirudhDagar @asi1024 @emcastillo @kmaehashi @aocsa @heitorschueroff
Repository: rust
Issue: Method resolution fails when through a reference to a trait object on Self: Sized methods
Labels: A-trait-system,T-compiler,T-types,A-trait-objects

```
trait Trait {
    fn static_call(&self) where Self: Sized;
    
    fn maybe_dynamic_call(&self) {
        unimplemented!("unsupported maybe_dynamic_call");
    }
}

impl<T: ?Sized + Trait> Trait for &T {
    fn static_call(&self) where Self: Sized {
        (**self).maybe_dynamic_call();
    }
}

fn foo(x: &dyn Trait) {
    // Works.
    (&x).static_call();
    
    // Doesn't work (goes through `dyn Trait: Trait`,
    // despite `static_call` not being object-safe)
    x.static_call();
}
```
(playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8d985c6ac7adc1a9835d4c7b5cd74f31)

To me it appears that method resolution should autoref and find the impl on the `&T` automatically, as the `Self: Sized` should be 

Note that this is specific to &self/&mut self methods, and by-value receivers work, like MANY of the methods on `Iterator`:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4dbe34cf1ffec880d225d96bd2370907 (rustc even gives an extremely good diagnostic about & vs &mut), though its unclear to me why in that cause, `next` is callable in that case, but I think it's because it lacks the `Self: Sized` bound)

(note that the origin of this issue is me investigating how to stabilize the not-yet implemented `std::stream::Stream::next` https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7e9fe3092902bafe9e5ae607a12e9b4e)

Thanks @eddyb for helping me minimize this and suggesting that this may be possible to resolve in a simple way.
Repository: go
Issue: cmd/compile: pass pointer-shaped receivers using context register
Labels: Performance,NeedsDecision,binary-size,compiler/runtime

TL;DR: We should look into passing pointer-shaped receivers using the context register.

Today, receiver parameters are effectively simply prepended to the parameter list. This was convenient when Go only had method expressions (i.e., expressions like `T.M`, where `T` is a type), because the same function code could be used for both method calls and method expressions.

However, Go later added method values (i.e., expressions like `x.M`, where `x` is a value), which require generating wrapper functions and also requires rather complex trampoline code within package reflect. This complexity is needed to adapt between the function closure calling convention (which passes the closure pointer using a dedicated context register) and the method calling convention (which passes receivers using a regular parameter).

If we change the internal calling convention so that receiver arguments are passed using the context register too, then we'd be able to avoid generating method value wrappers. We'd instead need just a single simple, universal wrapper, which could be used by both the compiler and package reflect. (For methods with non-pointer-shaped receivers, we would wrap the interface-calling-convention wrapper for the method, which always uses a pointer-shaped receiver parameter.)

Another benefit (pointed out by @dr2chase) is this would free up an extra register for passing arguments to pointer-receiver methods.

The only downside I see at the moment is that method expressions for pointer-shaped receiver types (e.g., `(*T).M`) would now need compiler-generated wrappers instead. However, the mitigating factors here are: (1) method expressions can only appear in source so we can always statically generate them (unlike for method values); (2) method expressions seem much less commonly used than method values (caveat: based on my anecdotal experience); and (3) it would be easy to reuse wrappers for methods with the same GC shape.

/cc @aclements @dr2chase @mknyszek
Repository: pytorch
Issue: Conjugate gradient Descent, and Linear operator are not present in pytorch.
Labels: module: sparse,triaged,module: complex,module: linear algebra,complex_autograd,function request,module: lazy

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

Conjugate gradient descent, and Linear operator as implemented in scipy needs to have a place in pytorch for faster gpu calculations.

## Motivation

Conjugate gradient Descent and Linear operator are a powerful tool for solving linear equations which many of the optimizer uses. Currently we have to work in scipy, and shift the vectors between numpy and pytorch to utilize the autograd function of pytorch. 

We can try cupy for faster access but again cupy isn't supported in pytorch, so it increases additional dependencies namely, converting between cupy, numpy, and pytorch tensors.

## Pitch

Adding linear Operator, and then conjugate gradient method next is a great way to improve pytorch. These are the only reasons I am using Scipy, it would be a great way for welcoming scipy community in pytorch too.



cc @nikitaved @pearu @cpuhrsch @IvanYashchuk @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @jianyuh @heitorschueroff @walterddr @xwang233 @aocsa @vincentqb
Repository: PowerToys
Issue: [KBM] Special behaviour for dead keys
Labels: Idea-New PowerToy

## 📝 Provide a description of the new feature

I'm not sure if you can check if a dead key is pressed, but when yes I wish a special mode that I can activate in KBM.

### Normal behabiour
Normally you press a dead key. For example \` and if you then press a key that can have your accent (e.g. e) it will write è and if not (e.g. d) it will write \`d.

### What I want
When you press a dead key (e.g. ~) it writes the ~ and if you then press a compatible key (e.g. a) it deletes the ~ and writes ã.

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: pytorch
Issue: IRSimplifier performs unsafe transformation on mod: m*n%m -> 0
Labels: triaged,NNC

## 🐛 Bug
The transformation in IRSimplifier for integers: `m*n % m -> 0` is not safe because `m` is not guaranteed to be non-zeros. We need to forbid this optimization.
Repository: PowerToys
Issue: [FZ Editor] Add Show spaces around zones in canvas layout
Labels: Idea-Enhancement,FancyZones-Editor,Product-FancyZones

Please, please, please
Add Show spaces around zones in Custom zones as well it is in static zones, 
this point is a much plus feature i have been waiting for along time
Repository: svelte
Issue: Allow slot='...' attribute on single top level element
Labels: feature request

**Is your feature request related to a problem? Please describe.**
I am working on a Component Library for myself. I would like to use the `slot='...'` attribute in a component without being a child of the component. Currently i get the following error: 

`Element with a slot='...' attribute must be a child of a component or a descendant of a custom element`

REPL:
https://svelte.dev/repl/9fbd3ef30184481a9edae5dbde4e574b?version=3.35.0

Currently i have to use the slot name on the Component itself like this:
```html
<Navbar>
	...
	<NavItem>
		<NavIcon slot="icon">Icon 1</NavIcon>
		<NavLabel slot="label">Label</NavLabel>
	</NavItem>
	...
</Navbar>
```

This feels somewhat redundant.

**Describe the solution you'd like**
I would like to be able to directly insert the children without the slot name, because the child itself knows the slot name:
```html
<Navbar>
	...
	<!-- I would like to use it like this, where the Component itself knows the slot -->
	<NavItem>
		<NavIcon>Icon 3</NavIcon>
		<NavLabel>Label 3</NavLabel>
	</NavItem>
	...
</Navbar>
```

and in NavIcon.svelte:
```html
<div slot="icon">
	<slot />
</div>
```

Technically the component **is** a child of a component or a descendant of a custom element, If the `slot='...'` attribute is restricted to be a single top level element of a component.

**How important is this feature to you?**
Nice to have.