sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: std panicking implementation comments suggest we might make double-panic not abort
Labels: C-cleanup,T-lang,T-compiler,A-technical-debt

https://github.com/rust-lang/rust/blob/efb171e2350de2bec6dd1f035b99bc00535c1c15/library/std/src/panicking.rs#L707-L714

At this point, I think we've effectively guaranteed in practice that a panicking while already unwinding leads to a full-process abort, and changing this to attempt to unwind the inner panic or even just to abort the thread but not the whole process is likely *far* to breaking. We're even considering [making unwinds from drops always abort](https://github.com/rust-lang/lang-team/issues/97), though AIUI this cannot replace the panic while unwinding immediate abort check.

Best guess at appropriate labels...

@rustbot modify labels +T-compiler +T-lang +C-cleanup +A-technical-debt
Repository: pytorch
Issue: make_fx doesn't work with truly dynamic argument functions (e.g. fx.Interpreter)
Labels: triaged,module: fx

### 🐛 Describe the bug

sample which breaks:

```
make_fx(lambda *args: torch.cat(args))(torch.randn(2), torch.randn(2))
```

Fails with

```
  File "test/test_dynamo_cudagraphs.py", line 145, in cudagraphs
    make_fx(lambda *args: torch.cat(args))([torch.randn(2), torch.randn(2)])
  File "/raid/ezyang/pytorch-scratch2/torch/fx/experimental/proxy_tensor.py", line 281, in wrapped
    t = dispatch_trace(wrap_key(f, args), tracer=fx_tracer, concrete_args=tuple(phs))
  File "/raid/ezyang/pytorch-scratch2/torch/fx/experimental/proxy_tensor.py", line 177, in dispatch_trace
    graph = tracer.trace(root, concrete_args)
  File "/raid/ezyang/torchdynamo/torchdynamo/eval_frame.py", line 88, in _fn
    return fn(*args, **kwargs)
  File "/raid/ezyang/pytorch-scratch2/torch/fx/_symbolic_trace.py", line 667, in trace
    fn, args = self.create_args_for_root(
  File "/raid/ezyang/pytorch-scratch2/torch/fx/_symbolic_trace.py", line 524, in create_args_for_root
    raise RuntimeError(
RuntimeError: Tracing expected 0 arguments but got 1 concrete arguments
```

The problem is FX knows how to see through varargs if there is an inner function its wrapping that has a true argument list, but cannot deal with truly dynamic lists. This is fine for vanilla FX as FX is unwilling to burn in the number of tensors in the list but for AOTAutograd/ProxyTensor we should burn in the list count and trace anyway.

cc @ezyang @Chillee @zdevito @jamesr66a 

### Versions

master
Repository: rust
Issue: API Request: pointer::[op]_assign
Labels: C-feature-request

It is often the case that you want to edit a pointer that you've got during a loop. In this case you need code like

```rust
loop {
  // do work
  ptr = ptr.add(1);
}
```

However, the same as we've got `Add::add`, we also have `AddAssign::add_assign`. Adding to pointers is `unsafe`, so we can't provide the AddAssign trait impl directly, but we can provide a method of the same name (as we already did with `add`).

```rust
loop {
  // do work
  ptr.add_assign(1);
}
```

Similarly, `sub` and `offset` can have the same "_assign" treatment.
Repository: rust
Issue: param env construction cycles with `feature(generic_const_exprs)`
Labels: T-compiler,A-const-generics,F-generic_const_exprs,I-cycle

the following [code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=73665d949cd16a9d65eb2d445a870389)
```rust
#![feature(generic_const_exprs)]

trait Trait<const N: usize> {
    type Assoc;
}

fn foo<T, const N: usize>()
where
  T: Clone,
  T: Trait<{ N + 1 }, Assoc = Box<T>>,
  <T as Trait<{ N + 1 }>>::Assoc: Clone, {}
```
cycles with:
```
error[[E0391]](https://doc.rust-lang.org/nightly/error-index.html#E0391): cycle detected when building an abstract representation for the const argument foo::{constant#1}
  --> src/lib.rs:11:15
   |
11 |   <T as Trait<{ N + 1 }>>::Assoc: Clone, {}
   |               ^^^^^^^^^
   |
note: ...which requires building THIR for `foo::{constant#1}`...
  --> src/lib.rs:11:15
   |
11 |   <T as Trait<{ N + 1 }>>::Assoc: Clone, {}
   |               ^^^^^^^^^
note: ...which requires type-checking the const argument `foo::{constant#1}`...
  --> src/lib.rs:11:15
   |
11 |   <T as Trait<{ N + 1 }>>::Assoc: Clone, {}
   |               ^^^^^^^^^
note: ...which requires computing normalized predicates of `foo::{constant#1}`...
  --> src/lib.rs:11:15
   |
11 |   <T as Trait<{ N + 1 }>>::Assoc: Clone, {}
   |               ^^^^^^^^^
note: ...which requires trying to unify the generic constants foo::{constant#1} and foo::{constant#0}...
  --> src/lib.rs:11:15
   |
11 |   <T as Trait<{ N + 1 }>>::Assoc: Clone, {}
   |               ^^^^^^^^^
   = note: ...which again requires building an abstract representation for the const argument foo::{constant#1}, completing the cycle
note: cycle used when trying to unify the generic constants foo::{constant#1} and foo::{constant#0}
  --> src/lib.rs:11:15
   |
11 |   <T as Trait<{ N + 1 }>>::Assoc: Clone, {}
   |               ^^^^^^^^^
```

This is noticably different than most generic_const_exprs cycles as this is caused by the `tcx.param_env` query normalizing the paramenv which requires equating the two `N + 1` anon consts in order to normalize `<T as Trait<{ N + 1 }>>::Assoc` to `Box<T>`.
Repository: godot
Issue: Black normals
Labels: bug,needs testing,topic:import,topic:3d

### Godot version

4 alpha 11

### System information

Windows 10, Vulkan,  RX560

### Issue description

Hi,

I've recently got a problem with normal maps.
I tried different model formats (gltf, fbx) and normal maps but can't get rid of this black sides of the model.

Is this a bug or is there a workaround?

Regards
abgenullt

### Steps to reproduce

Import a model and a normal map. Assign a new material with a normal map to it.

### Minimal reproduction project

![Screenshot](https://user-images.githubusercontent.com/34768615/177403500-c9a07005-f0cd-41ed-b190-2fccba4148e4.PNG)

[test.zip](https://github.com/godotengine/godot/files/9049009/test.zip)
Repository: PowerToys
Issue: PT Run does not dismiss when it loses focus 
Labels: Issue-Bug,Product-PowerToys Run,Priority-3,Needs-Team-Response

### Microsoft PowerToys version

0.59.1

### Running as admin

- [X] Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

This one is bugging me. Another version of this (I think underlying reasons are the same):

1. Open non elevated cmd
2. Open elevated cmd
3. Click the non-elevated cmd
4. Open PTRun*
5. Click the elevated cmd

* I am using elevated PT, Win+Space for activation, and central kb hook

You will see that PT Run does not get dismissed. 

Bonus fun: it might work for you (PT Run is hidden). If it works for you swap 3 and 5. It likely will not break (PT Run does not dismiss).

The only way I can get PT Run to reliably dismiss when it's not supposed to is to never click anything that is elevated. This is a tall order. 



### ✔️ Expected Behavior

If you click ANY window/desktop, anything that is not PT Run, PT Run should go away. 

### ❌ Actual Behavior

Sometimes it does not. It stays on the screen and is confusing. Because it depends on the elevation level of the item you clicked it can seem random. 

### Other Software

_No response_
Repository: material-ui
Issue: Multiline TextField Fires onInvalid Without Interaction
Labels: bug 🐛,test,component: text field

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

When using `TextField` with `multiline` the `onInvalid` event fires repeatedly without any interaction when testing with jsdom.

### Expected behavior 🤔

The `onInvalid` event should not fire at all. In the test below if you remove `multiline` it behaves as expected.

A regular `textarea` element also passes the test.

### Steps to reproduce 🕹

Jest spec, I used `create-react-app textarea --template typescript` and added the dependencies below:

```typescript
import { TextField } from '@material-ui/core';
import { render } from '@testing-library/react';
import React from 'react';

const Component = ({onInvalid}: {onInvalid: () => void}): JSX.Element => {
  return (
    <TextField
      required
      onInvalid={onInvalid}
      multiline
      label="Text Area"
      placeholder="fill this in"
    />
  );
};

it('should not trigger onInvalid', () => {
  const handleInvalid = jest.fn();
  render(<Component onInvalid={handleInvalid}/>);
  expect(handleInvalid).not.toBeCalled();
});
```

Dependencies:
```
"dependencies": {
    "@testing-library/jest-dom": "^5.16.4",
    "@testing-library/react": "^12.1.2",
    "@testing-library/user-event": "^13.5.0",
    "@types/jest": "^27.5.2",
    "@types/node": "^16.11.43",
    "@types/react": "^16.14",
    "@types/react-dom": "^16.9",
    "react": "^16.14",
    "react-dom": "^16.14",
    "react-scripts": "5.0.1",
    "typescript": "^4.7.4",
    "web-vitals": "^2.1.4",
    "@material-ui/core": "~4"
  },
  ```

### Context 🔦

This has caused a text that uses `onInvalid` to enter an infinite loop, although it works fine in an actual browser (tested with Chrome, Firefox, and Safari).

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: macOS 12.1
  Binaries:
    Node: 16.14.2 - ~/.asdf/installs/nodejs/16.14.2/bin/node
    Yarn: Not Found
    npm: 8.5.5 - ~/.asdf/plugins/nodejs/shims/npm
  Browsers:
    Chrome: 103.0.5060.53
    Edge: Not Found
    Firefox: 98.0.1
    Safari: 15.2
  npmPackages:
    @types/react: ^16.14 => 16.14.28
    react: ^16.14 => 16.14.0
    react-dom: ^16.14 => 16.14.0
    typescript: ^4.7.4 => 4.7.4
```
</details>
Repository: godot
Issue: Godot doesn't crop 8-pixel overscan area when playing Ogg Theora video
Labels: bug,confirmed,topic:gui

- *Related to https://github.com/godotengine/godot/issues/87705.*

### Godot version

3.4.4, 3.5.rc5, 4.0.alpha11

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 510.68.02)

### Issue description

Godot doesn't crop the 8-pixel overscan area at the bottom when playing an [Ogg Theora video](https://commons.wikimedia.org/wiki/File:Big_Buck_Bunny_medium.ogv) in a VideoStreamPlayer node (VideoPlayer in 3.x). This is most noticeable when the video plays, rather than when it's paused, so I recommend trying out the MRP locally if you can't notice the issue on the screenshots.

Notice how the last 8 rows of pixels are duplicated in Godot, but not in mpv:

### Screenshot from Godot (bad)

*Cropped to show only the video area (896×**512**).*

![image](https://user-images.githubusercontent.com/180032/177421232-870433e5-183e-49fb-8ad6-411a28f8f21f.png)

![image](https://user-images.githubusercontent.com/180032/177421604-12b823e8-1cbe-4c96-b835-fbeb335a8df4.png)


### Screenshot from mpv (good)

896×**504**.

![image](https://user-images.githubusercontent.com/180032/177419422-dc69de05-a3f5-4c09-9b9b-f246d668bc6d.png)

![image](https://user-images.githubusercontent.com/180032/177421576-4434697f-ce83-4808-b8c1-71084542ed1c.png)

This happens even if I re-encode the video using FFmpeg using `ffmpeg -i Big_Buck_Bunny_medium.ogv bb.ogv`.

### ffprobe information (on original video file)

```
[ogg @ 0x55c00d5965c0] Broken file, keyframe not correctly marked.
Input #0, ogg, from '/tmp/test_ogg_theora/Big_Buck_Bunny_medium.ogv':
  Duration: 00:09:56.47, start: 0.000000, bitrate: 1317 kb/s
  Stream #0:0: Data: none
  Stream #0:1: Video: theora, yuv420p, 896x504, 24 tbr, 24 tbn
    Metadata:
      ENCODER         : ffmpeg2theora-0.25
      SOURCE_OSHASH   : cc9e38e85baf7573
  Stream #0:2: Audio: vorbis, 48000 Hz, stereo, fltp, 96 kb/s
    Metadata:
      ENCODER         : ffmpeg2theora-0.25
      SOURCE_OSHASH   : cc9e38e85baf7573
Unsupported codec with id 0 for input stream 0
```

### Steps to reproduce

- Add VideoStreamPlayer node and specify an Ogg Theora video file.
- Disable **Expand** on the VideoStreamPlayer.
- Run the project and look at the video's bottom pixels.
- Play the video in another video player such as [mpv](https://mpv.io/) or [VLC](https://www.videolan.org/vlc/), and compare the visual output.

### Minimal reproduction project

N/A (previous link has expired)
Repository: pytorch
Issue: Interpolation artifacts when using nn.interpolate, trilinear mode for 3D label images
Labels: module: nn,triaged,module: interpolation

### 📚 The doc issue

It seems a functional bug. I have use nn.interpolate trilinear to umsample a 2 classes(and background) 3D image. The function tend to interpolate a "1" between label 2 and the background using trilinear. I could be solved by transfer the label image into one-hot format and than resample. Or i can also use nearest mode of nn.interpolate, its ok with label image.
It seems trilinear is not a suitable method for label image. If i use trilinear to upsample the training images, and use nearest to upsample the labels. If there could be some errors between images and labels because of the different upsample method?


### Suggest a potential alternative/fix

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
Repository: pytorch
Issue: Position embedding aware global circular convolution
Labels: feature,module: nn,triaged

### 🚀 The feature, motivation and pitch

Recently, we propose a new basic operation position embedding aware global circular convolution (GCC). Differing from previous convolution operations, the proposed GCC has global receptive field.  Experimental results show that GCC  uniformly
improves performance of various typical models.  

This work has been accpted by ECCV 2022, we hope the proposed GCC can be used by other researchers. Someone may refer to https://arxiv.org/abs/2203.03952 to find more details. 





### Alternatives

We will prepare a CUDA optimized version GCC following tutorial in https://pytorch.org/tutorials/advanced/cpp_extension.html.

We also want to propose a pull request to merge our code into Pytorch.  Will such a pull request be accpted ? If it is acceptable, is there anyone can provide us a demo of proposing this kind of pull request to Pytorch?



### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
Repository: excalidraw
Issue: Better Mono repo setup 
Labels: discussion,build

Right now we are having mono repo (have multiple packages in same repo) but still not really as the dependencies are not as per the repo.
We should start looking into managing bit better using mono repo tools like `lerna`, `yarn workspaces` and similar and of course making sure the development setup is not impacted at the same time.
Lot of existing OSS follows the similar setup like `react`, `create-react-app` as well. This way it will be easier to visualise the deps which are used for that package, making it more manageable and also reduce friction for more packages as we release
Repository: flutter
Issue: findChildIndexCallback returning negative values causes unusual error message
Labels: c: crash,framework,f: scrolling,has reproducible steps,P2,found in release: 3.7,found in release: 3.11,team-framework,triaged-framework

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Steps to Reproduce

Create a `SliverChildBuilderDelegate` that has a `findChildIndexCallback` that returns `-1`:

```
          SliverChildBuilderDelegate(
            ...,
            findChildIndexCallback: (key)  => -1),
```

**Expected results:** <!-- what did you want to see? -->

**Actual results:** <!-- what did you see? -->

```
════════ Exception caught by widgets library ═══════════════════════════════════
The following assertion was thrown building RawGestureDetector-[LabeledGlobalKey<RawGestureDetectorState>#644bc](state: RawGestureDetectorState#58dd7(gestures: <none>, behavior: opaque)):
'package:flutter/src/rendering/sliver_multi_box_adaptor.dart': Failed assertion: line 258 pos 16: 'child == null || indexOf(child) > index': is not true.
package:flutter/…/rendering/sliver_multi_box_adaptor.dart:258
2

Either the assertion indicates an error in the framework itself, or we should provide substantially more information in this error message to help you determine and fix the underlying cause.
In either case, please report this assertion by filing a bug on GitHub:
  https://github.com/flutter/flutter/issues/new?template=2_bug.md
```


</details>

<details>
  <summary>Logs</summary>

<!--
      Run your application with `flutter run --verbose` and attach all the
      log output below between the lines with the backticks. If there is an
      exception, please see if the error message includes enough information
      to explain how to solve the issue. If there is a crash, please include
      the entirety of the crash log including the backtrace.
-->

```
```

<!--
     Run `flutter analyze` and attach any output of that command below.
     If there are any analysis errors, try resolving them before filing this issue.
-->

```
```

<!-- Finally, paste the output of running `flutter doctor -v` here. -->

```
```

</details>


<!--
      Consider also attaching screenshots and/or videos to better
      illustrate the issue.

      You can upload them directly on GitHub.
      Beware that video file size is limited to 10MB.
-->
Repository: pytorch
Issue: [jit] script backward wrong gradient
Labels: oncall: jit

### 🐛 Describe the bug

Consider the following simple pnorm implementation
```py
def pnorm(x: torch.Tensor, p: torch.Tensor) -> torch.Tensor:
    return x.abs().pow(p).sum().pow(1 / p)

script_pnorm = torch.jit.script(pnorm)
```

When `x` contains any entry of *zero*, gradient of `p` will become `NaN` for script version, but works normally (not `NaN`) for eager version.

See this gist for full example.
https://gist.github.com/SsnL/07f58873766a2e8456741b1281e04c24

### Versions

```
PyTorch version: 1.11.0+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.5 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.5
Libc version: glibc-2.26

Python version: 3.7.13 (default, Apr 24 2022, 01:04:09)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.188+-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: False
CUDA runtime version: 11.1.105
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.5
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.11.0+cu113
[pip3] torchaudio==0.11.0+cu113
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.12.0
[pip3] torchvision==0.12.0+cu113
[conda] Could not collect
```
Repository: flutter
Issue: Platform messages to method channels serviced on the background task queue will only run after activity resume
Labels: engine,customer: money (g3),P2,team-engine,triaged-engine

## Steps to Reproduce

https://github.com/jiahaog/hello_flutter/commit/64d7453f8f25802e11016b8abea9d82e828ec6fa is a repro, on top of a flutter app created with `flutter create`. I only tested with `flutter run --release` on an Android device. This is a simplified version of how `customer: money` sets up their android embedding.


In `MainApplication.kt`, we set up a method channel handler that handles method channels on the background task queue. This means we expect platform messages there to never travel to the main thread. Shortly after that, we add a `Thread.sleep` to deliberately when activity resume happens.

In `main.dart`, we post a message on this method channel immediately.

**Expected results:** <!-- what did you want to see? -->

The method call returns quickly.

**Actual results:** <!-- what did you see? -->

The method call is delayed by 3 seconds, the same delay we added to `Thread.sleep`.

## Cause

This is happening because when [`route_messages_through_platform_thread_`](https://github.com/flutter/engine/blob/d7b6d9bbc0f2a275521fa9974b47c5875ef070dc/shell/common/shell.cc#L1221) is `true`, which is during startup, messages are scheduled from the UI thread -> Platform thread -> UI thread -> background thread for the method channel handler. 

The first UI Thread -> Platform thread scheduling is the problem. It happens [here](https://github.com/flutter/engine/blob/d7b6d9bbc0f2a275521fa9974b47c5875ef070dc/shell/common/shell.cc#L1227), but for some reason, the task does not run until activity resume happens. I believe this is due to somehow due to the implementation of the platform thread's [`ALooper`](https://github.com/flutter/engine/blob/d433fe4b2f9ca897fffdef466f7c879aeb4d3f1a/fml/platform/android/message_loop_android.cc#L17) for `fml::MessageLoopAndroid`. Not sure if this is related to the similar delay addressed in https://github.com/flutter/engine/pull/34363.

Removing [this](https://github.com/flutter/engine/blob/d7b6d9bbc0f2a275521fa9974b47c5875ef070dc/shell/common/shell.cc#L659-L665) which leaves `route_messages_through_platform_thread_` as always `true` causes the error to go away. 

The change to post messages to the platform thread first was introduced in https://github.com/flutter/engine/pull/30697.

Some more details in the internal b/238154217.

---

```
$ flutter --version
Flutter 3.1.0-0.0.pre.1284 • channel unknown • unknown source
Framework • revision fae31eecce (3 weeks ago) • 2022-06-16 19:58:05 -0700
Engine • revision f8c0dc87bc
Tools • Dart 2.18.0 (build 2.18.0-189.0.dev) • DevTools 2.14.0
```