sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: User changeable activation button for Hold Shift key to activate zones while dragging
Labels: Idea-Enhancement,FancyZones-Hotkeys,Product-FancyZones

### Description of the new feature / enhancement

I would like to be able to hold down a different keyboard or mouse button while dragging a window to activate FancyZones.

### Scenario when this would be used?

The scenario would be when you want to drag your window and snap it to a FancyZone, but you don't want it to be a toggle or right click.

I think many would like to map this function to whatever button they would like. I would personally use one of my forward or back mouse buttons instead of shift.

Or better yet, just make both the hold down to activate and toggle functions to be remappable. 

### Supporting information

_No response_
Repository: rust
Issue: ICE: !ty.has_infer_types_or_consts() with instrument-coverage
Labels: I-ICE,T-compiler,C-bug,requires-debug-assertions,S-needs-repro

<!--
Thank you for finding an Internal Compiler Error! 🧊  If possible, try to provide
a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for
how to create smaller examples.

http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/

-->

### Code
`./src/test/ui/issues/issue-24013.rs`
you need debug-assertions enabled to reproduce this ICE
```Rust
fn main() {
    use std::mem::{transmute, swap};
    let a = 1;
    let b = 2;
    unsafe {swap::<&mut _>(transmute(&a), transmute(&b))};
    //~^ ERROR type annotations needed
}
```


### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
9a74608543d499bcc7dd505e195e8bfab9447315 built with debug assertions
```

### Error output
`rustc ./issue-24013.rs -Cprofile-generate=/tmp/foo`
`-Cinstrument-coverage` also works to reproduce the ICE.
```
<output>
```
Repository: kubernetes
Issue: enhance E2E failure handling
Labels: kind/feature,sig/testing,needs-triage

### What would you like to be added?

Current output from `framework.ExpectNoError` (after https://github.com/kubernetes/kubernetes/pull/109828)

```
INFO: Unexpected error: hard-coded error: 
    <*errors.errorString>: {
        s: "an error with a long, useless description",
    }
FAIL: hard-coded error: an error with a long, useless description
```

Better:
```
FAIL: Unexpected error: hard-coded error: an error with a long, useless description
    <*errors.errorString>: {
        s: "an error with a long, useless description",
    }
```

The failure message in JUnit needs to be just "Unexpected error: hard-coded error: an error with a long, useless description".

This can be achieved in ExpectNoError because we control it (defer printing the details, call Fail). It gets harder when a test calls `gomega.Expect`, but not impossible: `framework.Fail` could log the entire failure and then truncate after the first line. Some examples (from https://github.com/kubernetes/kubernetes/issues/105678):

```
      Apr 22 09:03:41.130: Expected
          <bool>: false
      to equal
          <bool>: true
```

First line is useless, we have to keep the entire failure message.

```
      Apr 22 09:08:49.598: Failed to do XYZ
      Expected
          <bool>: false
      to equal
          <bool>: true
```

Log output remains the same, failure message becomes:
```
Apr 22 09:08:49.598: Failed to do XYZ
   <see log for details>
```

/cc @aojea 


### Why is this needed?

The failure messages get aggregated. Including too much information makes it hard to identify identical failures.

On the other hand, the additional details generated by hand or with gomega are useful.

See also https://kubernetes.slack.com/archives/C09QZ4DQB/p1654236320527119
Repository: pytorch
Issue: Remove const from function return type if returning const value
Labels: module: cpp,triaged

### 🚀 The feature, motivation and pitch

It is better to avoid the `const` qualifier on function return type if the function returns by value. The `const` qualifier may prevent move semantics if the type is movable. https://quuxplusone.github.io/blog/2022/01/23/dont-const-all-the-things/#return-types-never-const

From [Scott Meyer](https://www.aristeia.com/BookErrata/ec++3e-errata.html):
> Declaring by-value function return values const will prevent their being bound to [rvalue references in C++0x](http://www.artima.com/cppsource/rvalue.html). Because rvalue references are designed to help improve the efficiency of C++ code, it's important to take into account the interaction of const return values and the initialization of rvalue references when specifying function signatures.

### Alternatives

Leave it as it is if the `const` qualifiers are there for some reasons.

### Additional context

I'd like to merge [this commit](https://github.com/nglee/pytorch/commit/10bdb79a0a4c1b0ae3e3dc1ba61b5929982994b4).

cc @jbschlosser
Repository: pytorch
Issue: Improving clarity in the docs of different losses
Labels: module: docs,module: nn,triaged,module: python frontend

### 📚 The doc issue

Looking at the following losses [BCELoss](https://pytorch.org/docs/stable/generated/torch.nn.functional.binary_cross_entropy.html#torch.nn.functional.binary_cross_entropy) vs [CrossEntropyLoss](https://pytorch.org/docs/stable/generated/torch.nn.functional.cross_entropy.html#torch.nn.functional.cross_entropy) it seems that there's not clear indication of the type of data expected for `input` and `target`. 

We see that for other variables it clearly indicates if its `int`, `bool`, `float`, etc, but not for `input` and `target`.

Also we see this discrepancy where `BCELoss` expects the `target` to be of type `float` instead `CrossEntropyLoss` expects it to be `int`.

Why `BCELoss` doesn't accept `target` of type `int` and expects `float`?

Another thing that really would allow more clarity is to have links from the doc directly to the source code of the forward and backward calls for each loss.

I know that you might say but there are these links, for instance like the following `SOURCE`:


<img width="856" alt="image" src="https://user-images.githubusercontent.com/2902390/171992728-e4835a16-4075-4a09-98cd-dd8b5166697d.png">


But following the `SOURCE` link brings us to the following definition:

<img width="352" alt="image" src="https://user-images.githubusercontent.com/2902390/171992840-177cf94f-4ef8-4629-a6a4-e78a9681760c.png">


With the following dispatch code:

<img width="600" alt="image" src="https://user-images.githubusercontent.com/2902390/171992880-9fa7b750-1940-4f71-94a7-a73f758546b8.png">


As we can see to find the actual implementation we'll have to go and find the definition of `torch._C._nn.cross_entropy_loss(input, target, weight, _Reduction.get_enum(reduction), ignore_index, label_smoothing)`

This prevents folks from directly retrieving relevant pieces of information on how different parts work directly from the docs. One would have to spend a would chunk of time searching through the github code base until they reach what they are looking for.

### Suggest a potential alternative/fix

1. The types of data inputs should be clearly indicated for all arguments and there should be some consistency in terms of the types for the first two inputs `input` and `target`.

2. Improve navigation from docs to source code, linking directly each method to its actual forward/backward pass instead to some dispatch function.


cc @svekars @holly1238 @albanD @mruberry @jbschlosser @walterddr @kshitij12345
Repository: pytorch
Issue: fatal_signal_asan_no_sig_test in current master hang.
Labels: module: cpp,triaged,module: deadlock,module: testing

### 🐛 Describe the bug

Our docker build with pytorch timed out recently and we found the fatal_signal_asan_no_sig_test always hangs.
It occupies ~700% CPU on a 36-thread system, so I guess something's spinning.

```
[root@15f31169863c build]# bin/fatal_signal_asan_no_sig_test 
Running main() from ../third_party/googletest/googletest/src/gtest_main.cc
[==========] Running 7 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 7 tests from fatalSignalTest
[ RUN      ] fatalSignalTest.SIGABRT8
```

This issue on exists on CentOS 7.
Debian 11 seems fine.
Old version of pytorch is also fine.

The build is a CUDA build on non-CUDA system.

### Versions

Current master of pytorch.
rh-python38 scl on CentOS 7.


cc @jbschlosser
Repository: storybook
Issue: Refs to other localhosts do not work
Labels: bug,help wanted,composition,sev:S3

Bug:
```
Access to fetch at 'http://localhost:3000/stories.json' from origin 'http://localhost:3020' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
```
You can not use the wildcard * when the credentials mode is true. At the moment it is not set so I think chrome is placing:
```
Access-Control-Allow-Credentials: true
```
by default. I think when this is set to:
```
Access-Control-Allow-Credentials: false
```
it should work.
Repository: godot
Issue: Visual create shader node window vanishes instantly in tiling window manager sway
Labels: bug,platform:linuxbsd,topic:editor,topic:porting,topic:shaders

### Godot version

4.0 alpha 9

### System information

Arch linux, wayland, sway

### Issue description

When right clicking Add Node in the visual shader editor, the "Create Shader Node" appears for just a moment, before vanishing again. It appears that sway is attempting to tile the Create Shader Node popup.

### Steps to reproduce

Run Godot in Sway
Create an object that uses a visual shader
Click add node in the visual shader 

### Minimal reproduction project

_No response_
Repository: material-ui
Issue: [LoadingButton] Add ability to control size of circular progress
Labels: new feature,component: LoadingButton

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

Hello all,
I think LoadingButton could have the `componentProps` property, and let us pass props for the circularProgress that is being rendered. I think it will improve our experience!


Let me know what you think :)

### Examples 🌈

I had written something like this          
```<LoadingButton
            size="large"
            onClick={() => createDraftTicket()}
            loading={isCreatingDraftTicket}
            sx={{ mt: 4 }}
            loadingIndicator={<CircularProgress color="inherit" size={24} />} // I wrote this to enlarge the loading indicator.
          >
            <Typography variant="h5">
                 Text
                <br>
                Even More Text
            </Typography>
          </LoadingButton>```

Would feel neat if we had something like this:
```<LoadingButton
            ....
            componentProps={{circularProgress: { size: 24 }}}
          >
           ....
          </LoadingButton>```


### Motivation 🔦

The motivation would be to try and avoid passing custom components/elements to solve props issues :)
Repository: pytorch
Issue: Cannot build master on AWS cluster: error: ‘__fatDeviceText’ was not declared in this scope
Labels: module: build,module: cuda,triaged

### 🐛 Describe the bug

```
FAILED: third_party/gloo/gloo/CMakeFiles/gloo_cuda.dir/nccl/gloo_cuda_generated_nccl.cu.o /fsx/users/ezyang/pytorch-tmp/build/
third_party/gloo/gloo/CMakeFiles/gloo_cuda.dir/nccl/gloo_cuda_generated_nccl.cu.o
cd /fsx/users/ezyang/pytorch-tmp/build/third_party/gloo/gloo/CMakeFiles/gloo_cuda.dir/nccl && /fsx/users/ezyang/conda/bin/cmak
e -E make_directory /fsx/users/ezyang/pytorch-tmp/build/third_party/gloo/gloo/CMakeFiles/gloo_cuda.dir/nccl/. && /fsx/users/ez
yang/conda/bin/cmake -D verbose:BOOL=OFF -D build_configuration:STRING=Release -D generated_file:STRING=/fsx/users/ezyang/pyto
rch-tmp/build/third_party/gloo/gloo/CMakeFiles/gloo_cuda.dir/nccl/./gloo_cuda_generated_nccl.cu.o -D generated_cubin_file:STRI
NG=/fsx/users/ezyang/pytorch-tmp/build/third_party/gloo/gloo/CMakeFiles/gloo_cuda.dir/nccl/./gloo_cuda_generated_nccl.cu.o.cub
in.txt -P /fsx/users/ezyang/pytorch-tmp/build/third_party/gloo/gloo/CMakeFiles/gloo_cuda.dir/nccl/gloo_cuda_generated_nccl.cu.
o.Release.cmake
In file included from /tmp/tmpxft_0000ff6b_00000000-5_nccl.cudafe1.stub.c:9:0,
                 from tmpxft_0000ff6b_00000000-5_nccl.cudafe1.stub.c:1:
/tmp/tmpxft_0000ff6b_00000000-2_nccl.fatbin.c:30:14: error: ‘__fatBinC_Wrapper_t’ does not name a type; did you mean ‘__nv_hdl
_wrapper_t’?
 static const __fatBinC_Wrapper_t __fatDeviceText __attribute__ ((aligned (8))) __attribute__ ((section (__CUDAFATBINSECTION))
)=
              ^~~~~~~~~~~~~~~~~~~
              __nv_hdl_wrapper_t
In file included from /tmp/tmpxft_0000ff6b_00000000-5_nccl.cudafe1.stub.c:8:0,
                 from tmpxft_0000ff6b_00000000-5_nccl.cudafe1.stub.c:1:
/tmp/tmpxft_0000ff6b_00000000-5_nccl.cudafe1.stub.c: In function ‘void __sti____cudaRegisterAll()’:
/tmp/tmpxft_0000ff6b_00000000-5_nccl.cudafe1.stub.c:13:44: error: ‘__fatDeviceText’ was not declared in this scope
 static void __sti____cudaRegisterAll(void){__cudaRegisterBinary(__nv_cudaEntityRegisterCallback);}
                                            ^
/tmp/tmpxft_0000ff6b_00000000-5_nccl.cudafe1.stub.c:13:44: note: suggested alternative: ‘cuDeviceGet’
CMake Error at gloo_cuda_generated_nccl.cu.o.Release.cmake:277 (message):
  Error generating file
  /fsx/users/ezyang/pytorch-tmp/build/third_party/gloo/gloo/CMakeFiles/gloo_cuda.dir/nccl/./gloo_cuda_generated_nccl.cu.o
```

I used the standard instructions at https://www.internalfb.com/intern/wiki/PyTorch/PyTorchDev/Workflow/PyTorch_environment_setup/pytorch_aws_setup/

### Versions

master

cc @malfet @seemethere @ngimel
Repository: godot
Issue: [4a9] App Crashes on exit when Node is in memory but not attached to the Scene Tree
Labels: bug,topic:gdscript,needs testing,crash

### Godot version

v4.0.alpha9.official

### System information

Ubuntu 20.04.4 LTS, Vulkan API 1.2.131 - Using Vulkan Device #0: AMD - AMD RADV NAVI10

### Issue description

Expected App to exit cleanly. Got this:

```================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.alpha9.official (fc18891dbceace03c3867ac26c15b79cfbc673df)
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x43090) [0x7f77e51e7090] (??:0)
[2] /home/user/bin/godot4() [0x3b50f8b] (??:0)
[3] /home/user/bin/godot4() [0x3be6102] (??:0)
[4] /home/user/bin/godot4() [0x3bd9121] (??:0)
[5] /home/user/bin/godot4() [0x37694eb] (??:0)
[6] /home/user/bin/godot4() [0xdc5971] (??:0)
[7] /home/user/bin/godot4() [0xda9b4a] (??:0)
[8] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f77e51c8083] (??:0)
[9] /home/user/bin/godot4() [0xdc3aae] (??:0)
-- END OF BACKTRACE --
================================================================
```

I don't recall this happening in Alpha 8.

### Steps to reproduce

```

# Main.gd attached to Main.tscn
extends Node

# LoadScreen is a ColorRect with a ProgressBar, vars, and logic
@onready var load_screen: LoadScreen = $LoadScreen

# At some point, the scene is loaded. So "load_screen" is removed from the SceneTree.
func _change_scene() -> void:
  var new_scene: Node = ResourceLoader.load_threaded_get(loaded_path).instantiate()
  loaded_path = ""

  current_scene = new_scene
  add_child(current_scene)
  remove_child(load_screen)

# Called when pushing a "quit" button in the UI. Uncommenting "load_screen.free()" prevents crash.
func _on_quit2desktop() -> void:
  #load_screen.free()
  get_tree().quit(0)

```



### Minimal reproduction project

_No response_
Repository: flutter
Issue: Flutter tool should only create its own files in a .flutter directory
Labels: tool,c: proposal,P3,team-tool,triaged-tool

## Use case

My team uses a monorepo, and we use VSCode devcontainers for the backend and also for. The devcontainer version of flutter is constantly fighting with the system version of flutter over  `.flutter-plugins`, and `.flutter-plugins-dependencies`. This isn't an issue with `.dart_tool`, because I can mount a volume there in the VSCode devcontainer so the two don't fight.

## Proposal
It would be simpler for my use case (and many others) to simply have flutter place all of its generated system-dependent configuration inside a `.flutter` directory, matching the behavior of dart and most other CLI tools. This would also make it easier to maintain `.gitignore` files.

EDIT: Mistakenly also included `.packages` in this list, but that seems to already be fixed with #99677
Repository: PowerToys
Issue: PowerToys Run : Support double tap as activation shortcut.
Labels: Idea-Enhancement,Product-PowerToys Run,Needs-Triage

### Description of the new feature / enhancement

That will be great if PowerToys Run support double tap activation shortcut.
Example :  SPACE SPACE

### Scenario when this would be used?

Everywhere in Windows

### Supporting information

_No response_
Repository: rust
Issue: Macro typos generating exponentially growing token streams cause rustc to take exponentially long
Labels: I-compiletime,A-macros,C-bug,I-hang

<!--
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.
-->

I tried this code:

```rust
#![recursion_limit="32"]
macro_rules! m { ($($args:tt)*) => { m! { $($args)* $($args)* } } }
m! { test }
```

**I expected to see this happen:** compilation would terminate after a reasonable amount of time.

**Instead, this happened:** process aborted with a stack overflow after six minutes of pegging a single core.

([The actual code which ran into this issue.](https://twitter.com/CAD97_/status/1532913123006590977?s=20&t=1DbdSrb0SVclkQz5NAHiBg) Above is a minimal reproducer.)

I did some additional timing. On my AMD Ryzen 7 3700X 8-Core Processor, I got the following timings:

recursion limit | time to compilation failure
------- | -------
24 | 4 seconds
25 | 8 seconds
26 | 16 seconds
27 | 32 seconds

The suggested mitigation would be to keep track of token lengths of streams to catch degenerate macros like the above. Ideally this should track the *deep* length, but tracking shallow length (not including the length of nested token trees) should still catch unbounded growth like this, just a bit slower. If we assume the average token length is eight bytes, 2<sup>27</sup> tokens is a GiB of expanded code.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.63.0-nightly (a6b8c6954 2022-06-03)
binary: rustc
commit-hash: a6b8c6954829669a5c4fa320c3e6132edf04fcfc
commit-date: 2022-06-03
host: x86_64-pc-windows-msvc
release: 1.63.0-nightly
LLVM version: 14.0.4
```
Repository: rust
Issue: `#[allow(...)]` doesn't work on expressions
Labels: A-diagnostics,T-compiler

Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=01f0dcf3b636948e5c1cf8baeeedb35c

```rust
#![feature(stmt_expr_attributes)]

// Compiles successfully
#[allow(arithmetic_overflow)]
pub fn attr_on_func() -> u8 {
    200 + 200
}

// Yields compiler error
pub fn attr_on_expr() -> u8 {
    #[allow(arithmetic_overflow)]
    200 + 200
}
```

The current output is:

```
   Compiling playground v0.0.1 (/playground)
error: this arithmetic operation will overflow
  --> src/lib.rs:11:5
   |
11 | /     #[allow(arithmetic_overflow)]
12 | |     200 + 200
   | |_____________^ attempt to compute `200_u8 + 200_u8`, which would overflow
   |
   = note: `#[deny(arithmetic_overflow)]` on by default

error: could not compile `playground` due to previous error
```

The same thing occurs for clippy lints:
```rust
// Lint correctly silenced
#[allow(clippy::unused_unit)]
pub fn clippy_attr_on_func() {
    ()
}

// Lint erroneously not silenced
pub fn clippy_attr_on_expr() {
    #[allow(clippy::unused_unit)]
    ()
}
```

```
warning: unneeded unit expression
  --> src\lib.rs:10:5
   |
10 |     ()
   |     ^^ help: remove the final `()`
   |
   = note: `#[warn(clippy::unused_unit)]` on by default
```

To reiterate: the issue is that attributes for silencing warnings are ignored when placed on expressions. I realize now the first example might be an issue with higher precedence, but the second example with clippy is obviously faulty.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"est31"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: project crash when pressing a dead key and W
Labels: bug,platform:windows,topic:editor

### Godot version

at least from 3.0 to 4.0 (c0bf18e)

### System information

Windows 10

### Issue description

when a project is launched from the editor (not from the Godot project manager or a built project)
pressing a dead key like (on a French AZERTY keyboard)  "^", "¨", "`" or "~" and then "W"
will close the game without any error message or console output

I tested it in Godot 3.0, 3.4.2, 3.4.4 and the latest 4.0 version on GitHub at the time of writing (c0bf18e) 

### Steps to reproduce

1) launch any project from the editor
2) press a dead key such as the ones circled bellow (for a French AZERTY keyboard)
![image](https://user-images.githubusercontent.com/43811128/171969853-7d57a93c-c21d-4a52-a68f-a3ecc979edfc.png)

3) press "W"

Note that for it to crash you cannot press another key in between the two, you can't press the dead key twice in a row and it doesn't work if you hold shift while pressing "W"

so it follows the rules of how dead keys work when writing text and only crashes if the input sequence is something you would type to try to write "ŵ", "ẅ", "ẁ" or "w̃"
(which are not characters my keyboard can write btw, I had to copy them)

### Minimal reproduction project

it works on any project
Repository: flutter
Issue: IconButton has wrong talk back reading order when only set tooltip, not set semanticLabel
Labels: platform-android,framework,f: material design,a: accessibility,P3,found in release: 3.1,team-design,triaged-design

After upgrading to the latest master/beta flutter, I found that when using the IconButton, there is a problem with the order of the talk back read aloud if only the tooltip is set and not the semanticLabel.
For example, using BackButton, the talk back is now read aloud as
"Button Back"
In the previous 2.X version of flutter or stable 3.0.1, the talk back was read aloud:
"Back Button"
This will cause users who use talk back to listen to the control type before they can learn the label of the control, which will reduce the efficiency of the user's operation.