sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: `ERROR: Condition "det == 0" is true.` is spammed when GPUParticles3D has its scale set to `(0, 0, 0)`
Labels: bug,topic:rendering,regression,topic:3d

*Related to https://github.com/godotengine/godot/issues/63010 and https://github.com/godotengine/godot/issues/63011.*

### Godot version

4.0.alpha (5fec0d232)

### System information

Fedora 36, GeForce GTX 1080 (NVIDIA 510.68.02)

### Issue description

This error message is printed regularly *(but not every frame)* when GPUParticles3D (or any of its parents) has its scale set to `(0, 0, 0)`. The frequency of prints seems to be every `1.0 / fixed_fps` (where `fixed_fps` is the GPUParticles3D property of the same name).

```
ERROR: Condition "det == 0" is true.
   at: invert (core/math/basis.cpp:64)
```

This doesn't occur with other 3D nodes such as MeshInstance3D. I also can't reproduce this on 3.5.rc 3f0201335.

### Steps to reproduce

- Add a GPUParticles3D node (even without a mesh and a process material).
- Set its scale to `Vector3(0, 0, 0)`.

### Minimal reproduction project

[test_gpuparticles3d_scale_0.zip](https://github.com/godotengine/godot/files/9116639/test_gpuparticles3d_scale_0.zip)
Repository: go
Issue: proposal: x/net/http2: distinguish no body from empty body
Labels: Proposal,Proposal-Hold

<!--
Our proposal process is documented here:
https://go.dev/s/proposal-process
-->

### Issue
A server cannot differentiate between the below two scenarios:
1. No body was sent - The final header frame of the h2 request contains the `END_STREAM` and `END_HEADERS` flag and no data frame was sent after that
2. An empty body was sent - The final header frame of the h2 request only contains the `END_HEADERS` flag. Subsequently, an empty data frame with an `END_STREAM` flag is sent.

When reading the body on `http.Request`, both immediately return `io.EOF` and 0 bytes are read. 

### Proposal

Create `http2.NoBody` and `http2.EmptyBody` to represent the two scenarios and set the `req.Body` to them. `http2.NoBody` can equal `http.NoBody` as well.

### Use Case

Some servers differentiate between the two kinds of requests. We're running a MITM proxy that needs to read which kind of request a client is making and forward the same to the target server. 

### Alternatives Considered

Add a method to `http.Request` (named `ReadDataFrame`?) that returns whether or not a client sent a data frame.

Personally, I prefer adding `http2.NoBody` and `http2.EmptyBody`.

### Additional Notes
- When `req.Body` is set to `nil` or `http.NoBody`, no data frame is sent by `http2.Transport`. If it's set to another reader that returns 0 bytes (ex: `ioutil.NopCloser(strings.NewReader(""))`), then an empty data frame is sent. This gives a way to differentiate between the two scenarios when sending requests but not when accepting requests through `http.Server` or `http2.Server`
Repository: flutter
Issue: Separate the handling of the three Android Platform View modes
Labels: platform-android,engine,a: platform-views,P2,a: plugins,team-android,triaged-android

In support of https://github.com/flutter/flutter/issues/107313 and after reading through [PlatformViewsController.java](https://github.com/flutter/engine/blob/main/shell/platform/android/io/flutter/plugin/platform/PlatformViewsController.java), I think we should separate the logic of the three PlatformView modes with delegates. 

The organization of [PlatformViewsController.java](https://github.com/flutter/engine/blob/main/shell/platform/android/io/flutter/plugin/platform/PlatformViewsController.java), makes it hard to decipher what is specifically being done in for each mode. I'm not entirely sure how interconnected each mode is, but there are many methods, fields, and classes that are only used by a single mode.

My suggestion is to create `PlatformViewsControllerDelegate`s to help separate the logic:

```
io/flutter/plugin/platform
\
 \_PlatformViewsController.java
\
 \_controllerDelegates
  \
   \_virtualDisplay
       \
        \_VirtualDisplayDelegate.java
  \
   \_hybridComposition
       \
        \_HybridCompositionDelegate.java
  \
   \_textureLayerHybridComposition
       \
        \_TextureLayerHybridCompositionDelegate.java
``` 

- [ ] Virtual Display
- [ ] Hybrid Composition
- [ ] Texture Layer Hybrid Composition


cc @cyanglaz @stuartmorgan @dnfield @GaryQian
Repository: godot
Issue: Use directional LightmapGI information to display specular lobes for fully baked (static) lights
Labels: enhancement,topic:rendering,confirmed,topic:3d

### Godot version

v4.0.alpha.custom_build [e5a1640cf]

### System information

Ubuntu 21.04. RTX 2060

### Issue description

Baked a Directional Light set as static with the LightmapGI set to directional does not bake specular information

Realtime Directional Light

![image](https://user-images.githubusercontent.com/1168582/179137151-7e8f7b98-938d-464c-b7bf-271a724bf32f.png)

Baked Lightmap set to directional

![image](https://user-images.githubusercontent.com/1168582/179137212-ba4b7250-66bc-404b-8cd2-e5b31a49658e.png)

Ignore know issue about direct light power on the backed map image

### Steps to reproduce

Bake lightmap set to directional on the minimal project

### Minimal reproduction project

[Specular.zip](https://github.com/godotengine/godot/files/9117321/Specular.zip)
Repository: pytorch
Issue: CapabilityBasedPartitioner doesn't support horizontal (vertical?) fusion
Labels: triaged,module: nvfuser

### 🐛 Describe the bug

steps to reproduce:

```
diff --git a/test/test_fx_passes.py b/test/test_fx_passes.py
index 39fe501f44..9fe5e4002e 100644
--- a/test/test_fx_passes.py
+++ b/test/test_fx_passes.py
@@ -158,6 +158,12 @@ class TestPartitionFunctions:
         out = torch.stack([add_1, add_2, add_3])
         return out
 
+    @staticmethod
+    def forward12(a):
+        add_1 = a + 1
+        add_2 = a + 2
+        return add_1, add_2
+
 # A mock OperatorSupport class, where only operator.add is supported
 class MockOperatorSupport(OperatorSupport):
     def is_node_supported(self, submodules, node: torch.fx.Node) -> bool:
@@ -179,6 +185,7 @@ class TestFXGraphPasses(JitTestCase):
         (TestPartitionFunctions.forward9, [['add_3', 'add_2', 'add_1', 'add']]),
         (TestPartitionFunctions.forward10, [['add_3', 'add_2', 'add', 'add_1']]),
         (TestPartitionFunctions.forward11, [['add_1'], ['add']]),
+        (TestPartitionFunctions.forward12, [['add_1', 'add_2']]),
     ])
     def test_partitioner(self, fn, expected_partition):
         traced = symbolic_trace(fn)
@@ -188,7 +195,7 @@ class TestFXGraphPasses(JitTestCase):
         partitions = partitioner.propose_partitions()
 
         partitions_name = [[node.name for node in partition.nodes] for partition in partitions]
-        assert len(partitions_name) == len(expected_partition)
+        assert len(partitions_name) == len(expected_partition), partitions_name
         for i in range(len(partitions_name)):
             assert set(partitions_name[i]) == set(expected_partition[i])
 
```

I don't know if nvFuser supports horizontal fusion or not, but if the backend supports it (e.g., cuda graphs does) loss of fusion here is bad as you are doubling your memory traffic.

cc @SherlockNoMad @Chillee 

### Versions

master
Repository: pytorch
Issue: CapabilityBasedPartitioner treats non-compute ops inconsistently
Labels: triaged,module: fx,module: CapabilityBasedPartitioner,module: fx.passes

### 🐛 Describe the bug

Currently, only these two ops are treated as non-compute: `non_compute_ops = {"torch.ops.aten.view", "_operator.getitem"}`. However, there are plenty of  other non-compute ops, e.g. all view operations. It is also unclear why view ops need to get treated specially at all; it seems like this ought to be configurable.

cc @ezyang @SherlockNoMad 

### Versions

master
Repository: pytorch
Issue: Linking pytorch libraries causes sstream behavior to be overridden globally
Labels: module: build,triaged

### 🐛 Describe the bug

Some details here: https://github.com/ros2/geometry2/issues/540

I ran into an issue when integrating ROS2 TF2 libraries with pytorch. Here's a simple C++ file that reproduces the bug:

main.cpp

```C++
#include <sstream>
#include <iostream>

int main(int argc, char * argv[])
{
    long unsigned int num = 0xdeadbeef;
    std::stringstream sstream;
    sstream << "transform_listener_impl_" << std::hex << reinterpret_cast<size_t>(num);
    std::cout << "transform_listener_impl_" << std::hex << reinterpret_cast<size_t>(num) << std::endl;
    std::cout << std::string(sstream.str()) << std::endl;
}
```

CMakeLists.txt

```
cmake_minimum_required(VERSION 3.8)
project(torch_bug)


# Default to C++14
if(NOT CMAKE_CXX_STANDARD)
  set(CMAKE_CXX_STANDARD 14)
endif()

if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  add_compile_options(-Wall -Wextra -Wpedantic)
endif()

find_package(Torch REQUIRED)


add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME}
  ${TORCH_LIBRARIES}
)
```


Expected output:
```
transform_listener_impl_deadbeef
transform_listener_impl_deadbeef
```

Actual output:
```
transform_listener_impl_deadbeef
transform_listener_impl_de,adb,eef
```

What could cause this bug? In the case of ROS, it really hates having those commas inserted and throws a run time exception. I wonder what other situations this is problematic in.

I installed libtorch using this binary link: https://download.pytorch.org/libtorch/cu116/libtorch-cxx11-abi-shared-with-deps-1.12.0%2Bcu116.zip


### Versions

Collecting environment information...
PyTorch version: 1.10.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 8.4.0-3ubuntu2) 8.4.0
Clang version: Could not collect
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.8.10 (default, Mar 15 2022, 12:22:08)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-122-generic-x86_64-with-glibc2.29
Is CUDA available: True
CUDA runtime version: 11.7.64
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1080
Nvidia driver version: 515.48.07
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.4.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy==0.902
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.4
[pip3] torch==1.10.0
[pip3] torchaudio==0.10.0+cu113
[pip3] torchvision==0.11.1
[pip3] torchviz==0.0.2
[conda] Could not collect

cc @malfet @seemethere
Repository: PowerToys
Issue: Success Feedback Notification when 'saving' and 'arranging' Layouts
Labels: Idea-Enhancement,FancyZones-Editor,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

This would be nice to have when working with and arranging layouts:

**Summary**

On the 'FancyZones Layout Editor' - Please add success feedback of any type

Click save, so we know that it 'saved' or some feedback, even a notification or anything. A button would be good, but something to let the user know that _'this is saved, if you hit close, you do not have to be afraid that it will not save'_



Note: 

I originally posted this suggestion here: https://github.com/microsoft/PowerToys/issues/19240#issuecomment-1179934944 

### Scenario when this would be used?

In most all other applications, there is some sort of 'success' feedback when settings are saved. Generally speaking, success feedback can be something like:

* The button goes from disabled to enabled
* A ['Toastr or Noty' appears on the screen](https://getbootstrap.com/docs/5.0/components/toasts/)
* A pop-up appears asking the user if they want to save
* Many other common methods.

The idea is that there is some sort of visual feedback or recognition when something is 'saved'.  With FancyZones, this does not exist. 

### Supporting information

_No response_
Repository: PowerToys
Issue: [Fancy Zone] Ability to add and save 'Layout Profiles' so that I can switch layouts depending on my current activity on the computer
Labels: Idea-Enhancement,Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

It would be nice to have multiple 'layout profiles' configured.  Depending on my task, I can switch between layouts.  

* I will have the ability to create new layout profiles
* I will have the ability to create layout profile titles
* I will have the ability to create a short layout profile description (this is incase I do not use the layout for a long time, and perhaps I forgot why I created the layout profile in the first place. This is helpful to have for memory purposes.
* At my own will, I can switch between layout profiles easily without 're-selecting the exact layout profile within the FancyZones layout editor


----

Originally I mentioned this request here: https://github.com/microsoft/PowerToys/issues/19240#issuecomment-1179934944

### Scenario when this would be used?

For example, I am a C# developer with (3) monitors:

* I have (2) Horizontal Monitors
* I have (1) Vertical Monitor

## Development Profile Example

I will have a layout profile called "Development", which will have my layouts of my monitors saved for my development purposes. Perhaps it is:

* Vertical screen has (2) Rows
* One of the horizontal monitors has (2) columns
* One of the horizontal monitors has no layout applied (it is normal).

## Research profile example

Perhaps I am in a learning or research mood, and now I want:

*  all of my horizontal monitors to have (2) columns each
* My vertical monitor to have (3) rows

I can easily select my 'research layout profile' and this layout will be applied to my screens.


### Supporting information

_No response_
Repository: flutter
Issue: InteractiveViewer doesn't update scale when rotating device
Labels: framework,has reproducible steps,P2,found in release: 3.0,found in release: 3.1,team-framework,triaged-framework

`InteractiveViewer` has a `minScale` and `maxScale` property. If those properties change when the device is rotated, `InteractiveViewer` doesn't update its content.

This problem might also occur when resizing a window on desktop. I haven't tried. But I get the sense that `interactiveViewer` is not taking appropriate action when its own bounds change.

I think something like the following might reproduce the issues:

```dart
InteractiveViewer(
  minScale: MediaQuery.of(context).size.width / 2000,
  child: ConstrainedBox(
    constraints: const BoxConstraints(
      minWidth: MediaQuery.of(context).size.width,
      minHeight: MediaQuery.of(context).size.height,
    ),
    child: Center(
      child: Container(
        width: 2000,
        height: 1000,
        color: Colors.white,
      ),
    ),
  ),
);
```

Run that interactive viewer on a tablet in portrait and zoom out as much as possible. Then rotate the device to landscape.

Expected: the white `Container` automatically scales down to be exactly as wide as the screen.

Actual: the white `Container` appears smaller than the screen, with large gaps on all sides.
Repository: material-ui
Issue: [InputAdornment] Textfield autofill background color isn't applied to InputAdornment
Labels: new feature,component: text field

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

An autofilled textfield's InputAdornment doesn't get the same background color as the TextField.
![image](https://user-images.githubusercontent.com/4462478/179167520-187ffb0d-7d7e-4200-9090-9c480cc7d85f.png)


### Expected behavior 🤔

I expected the InputAdornment to have the same background color as the TextField.

### Steps to reproduce 🕹

```
<TextField
  id="password"
  type={showPassword ? 'text' : 'password'}
  label="Password"
  placeholder="Password"
  autoComplete="current-password"
  InputProps={{
    endAdornment: (
      <InputAdornment position="end">
        <IconButton aria-label="toggle password visibility" onClick={togglePassword} edge="end">
          {showPassword ? <VisibilityOff /> : <Visibility />}
        </IconButton>
      </InputAdornment>
    )
  }}
/> 
```

Steps:

1. Have saved credentials
2. Refresh your page to trigger autofill

### Context 🔦

Could just be me but with the missing background color the field looks bugged.

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: Windows 10 10.0.19042
  Binaries:
    Node: 16.13.2 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 8.12.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 103.0.5060.114
    Edge: Spartan (44.19041.1266.0), Chromium (103.0.1264.49)
  npmPackages:
    @emotion/react: ^11.8.2 => 11.9.3
    @emotion/styled: ^11.8.1 => 11.9.3
    @mui/base:  5.0.0-alpha.85
    @mui/icons-material: ^5.5.1 => 5.8.4
    @mui/material: ^5.7.0 => 5.8.4
    @mui/private-theming:  5.8.4
    @mui/styled-engine:  5.8.0
    @mui/system:  5.8.4
    @mui/types:  7.1.4
    @mui/utils:  5.8.4
    @mui/x-data-grid: ^5.10.0 => 5.12.1
    @mui/x-date-pickers: ^5.0.0-alpha.2 => 5.0.0-alpha.6
    @types/react: ^18.0.12 => 18.0.12
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^4.7.3 => 4.7.3
```
</details>
Repository: rust
Issue: Use inference to fill in missing type parameters
Labels: A-diagnostics,T-compiler

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
struct Wrapper<T>(T);

fn make_wrapper() -> Wrapper {
    Wrapper(())
}
```

The current output is:

```
error[[E0107]](https://doc.rust-lang.org/nightly/error-index.html#E0107): missing generics for struct `Wrapper`
 --> src/lib.rs:3:22
  |
3 | fn make_wrapper() -> Wrapper {
  |                      ^^^^^^^ expected 1 generic argument
  |
note: struct defined here, with 1 generic parameter: `T`
 --> src/lib.rs:1:8
  |
1 | struct Wrapper<T>(T);
  |        ^^^^^^^ -
help: add missing generic argument
  |
3 | fn make_wrapper() -> Wrapper<T> {
  |                      ~~~~~~~~~~

For more information about this error, try `rustc --explain E0107`.
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[[E0107]](https://doc.rust-lang.org/nightly/error-index.html#E0107): missing generics for struct `Wrapper`
 --> src/lib.rs:3:22
  |
3 | fn make_wrapper() -> Wrapper {
  |                      ^^^^^^^ expected 1 generic argument
  |
note: struct defined here, with 1 generic parameter: `T`
 --> src/lib.rs:1:8
  |
1 | struct Wrapper<T>(T);
  |        ^^^^^^^ -
help: add missing generic argument
  |
3 | fn make_wrapper() -> Wrapper<()> {
  |                      ~~~~~~~~~~~

For more information about this error, try `rustc --explain E0107`.
```

Possibly with a note explaining that the argument was inferred?

Rationale: This could reduce the number of compiler invocations in the case where the type checker is used to figure out the actual return type by not having to insert a bogus type parameter which is then type checked.
Repository: PowerToys
Issue: Powertoys Run - plugins sorting by drag & drop
Labels: Idea-Enhancement,Product-PowerToys Run,Product-Settings,Needs-Triage

### Description of the new feature / enhancement

Just a simple drag-and-drop feature to sort plugins. 
The higher on the list the plugin is the higher priority is given to it.

### Scenario when this would be used?

When trying to organise search results. for example apps first, folder second and so on.

### Supporting information

![image](https://user-images.githubusercontent.com/91010735/179199265-411ca95e-edf5-479d-a712-7e47b90951ed.png)
Repository: rust
Issue: “captured variable cannot escape `FnMut` closure body” diagnostic can be more confusing than the basic “may outlive current function” diagnostic
Labels: A-diagnostics,T-compiler

Consider the following example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a3f2f6dc2254b8d395e510b9a401ea9f)):

```rust
fn is_fnmut<R, F: FnMut() -> R>(_: F) {}

fn bad() {
    let mut x = 5;
    is_fnmut(|| async {
        x += 1;
    });
}
```

Here the `x` is captured by-value by the closure but the `async` block then captures it by-reference and the resulting future is being immediately returned from the closure. This is the standard example of returning function-local variables by reference.

The diagnostic thus reads as:

```
error: captured variable cannot escape `FnMut` closure body
 --> src/lib.rs:5:17
  |
4 |       let mut x = 5;
  |           ----- variable defined here
5 |       is_fnmut(|| async {
  |  _______________-_^
  | |               |
  | |               inferred to be a `FnMut` closure
6 | |         x += 1;
  | |         - variable captured here
7 | |     });
  | |_____^ returns an `async` block that contains a reference to a captured variable, which then escapes the closure body
  |
  = note: `FnMut` closures only have access to their captured variables while they are executing...
  = note: ...therefore, they cannot allow references to captured variables to escape
```

There are a couple of problems with this diagnostic – first, it places a lot of the blame on the closure being inferred as `FnMut`. This can and does confuse people reading this diagnostic that the solution is to somehow change the closure to _not_ be an `FnMut`. However, in practice there is rarely anything sensible that the author can do to affect the traits a closure implements. These auto-traits will always be implemented for all the applicable closures. Second, making closure be something else than `FnMut` doesn’t actually help in any way – the return value still references its captures by a reference!

I’d like to argue that as it stands the generic “returned value may outlive the current function” diagnostic is [much more understandable](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f774a9935f66b0af8a3bd0c018359477). Not to mention that it triggers the actual most-likely correct `help` suggestion:

```
error[E0373]: async block may outlive the current function, but it borrows `x`, which is owned by the current function
 --> src/lib.rs:6:15
  |
6 |         async { x += 1; }
  |               ^^-^^^^^^^^
  |               | |
  |               | `x` is borrowed here
  |               may outlive borrowed value `x`
  |
note: async block is returned here
 --> src/lib.rs:6:9
  |
6 |         async { x += 1; }
  |         ^^^^^^^^^^^^^^^^^
help: to force the async block to take ownership of `x` (and any other referenced variables), use the `move` keyword
  |
6 |         async move { x += 1; }
  |               ++++
```