sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Editing EditorSettings Shortcuts causes  "This control can't grab focus" warning
Labels: bug,topic:editor

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2, 3.2.3, 3.2.4b4 (didn't test older ones)

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows, Linux (Ubuntu)

**Issue description:**
<!-- What happened, and what was expected. -->
When editing a Shortcut  (in EditorSettings), the warning appears:
```
 scene/gui/control.cpp:2177 - This control can't grab focus. Use set_focus_mode() to allow a control to get focus
```
- The warning doesn't appear first time when a project is opened, but after that it is printed each time
- I didn't see this warning when editing InputMap Shortcuts (in Project Settings)

**Steps to reproduce:**
1. Open any project or create a new one
2. Open Shortcuts dialog (EditorSettings->Shortcuts)
3. Press a button that edits a Shortcut (any button with pencil icon) to open `Press a Key` popup
(as you can see nothing happens in Output now)
4. Press escape key or close `Press a Key` popup any other way (Cancel/Ok/Close buttons etc)
5. Repeat (3)
Now you should see the warning in Output
This warning will be printed each time you do (5)

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: rust
Issue: Rustdoc has different URLs for re-exported builtin derives than in the current crate
Labels: T-rustdoc,A-macros,C-bug

I tried this code:

```rust
#![no_std]
#[doc(no_inline)]
pub use core::marker::Copy;
```

I expected to see this happen: Rustdoc links to https://doc.rust-lang.org/nightly/core/macro.Copy.html.

Instead, this happened: Rustdoc links to https://doc.rust-lang.org/nightly/core/marker/derive.Copy.html.

This is wrong in two ways:

1. It uses `macro.Item.html` and `derive.Item.html` inconsistently
2. It links to the `marker` submodule in the re-export crate but not when documenting `core` (https://github.com/rust-lang/rust/issues/74355).

This issue is only for tracking 1.

Thanks @danielhenrymantilla for the bug report!

### 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.
-->

`rustdoc --version`: rustdoc 1.50.0-nightly (0edce6f4b 2020-12-24)
Repository: rust
Issue: Iterator-based approach performs 10x worse than manual implementation
Labels: I-slow,C-bug

I'm not sure if this qualifies as a bug or not.

In short, the following two functions give the same output, but `fft` performs about 10x worse than `fft_manaul`.

```rust
const LUT: [i16; 8] = [0, 1, 2, 3, 4, 5, 6, 7];

pub fn fft(samples: &[i16; 16]) -> (i32, i32) {
    let sin = LUT.iter().cycle();
    let cos = LUT.iter().cycle().skip(LUT.len() / 4);
    sin.zip(cos).zip(samples).fold(
        (0, 0), |(mut real, mut imag), ((sin, cos), &sample)| {
            real += sample as i32 * (*cos as i32);
            imag += sample as i32 * (*sin as i32);
            (real, imag)
    })
}
```

```rust
const LUT: [i16; 8] = [0, 1, 2, 3, 4, 5, 6, 7];

pub fn fft_manual(samples: &[i16; 16]) -> (i32, i32) {
    const LUT_LEN: usize = LUT.len();
    let mut real = 0;
    let mut imag = 0;
    for i in 0..(samples.len() / LUT_LEN) {
        for j in 0..LUT_LEN {
            let sin = LUT[j];
            let cos = LUT[(j + (LUT_LEN / 4)) % LUT_LEN];
            let sample = samples[i * LUT_LEN + j];
            real += sample as i32 * (cos as i32);
            imag += sample as i32 * (sin as i32);
        }
    }
    (real, imag)
}
```

I originally ran into this in an embedded context, targeting `thumbv7em-none-eabihf`. The original function took a `GenericArray` and used fixed-point types from the `fixed` crate, but I was able to reproduce the issue using only primitive types targetting `x86_64-pc-windows-msvc`.

Here are the results of benchmarks from selected `nightly` versions from the past 18 months. The benchmarks were run using the code [here](https://github.com/bradleyharden/fft_iter_bench).


| Version | Results |
| -------- | -------- |
| nightly-2020-12-21 | test tests::bench_fft        ... bench:          63 ns/iter (+/- 16) <br> test tests::bench_fft_manual ... bench:           5 ns/iter (+/- 1) |
| nightly-2020-06-01 | test tests::bench_fft        ... bench:          36 ns/iter (+/- 15) <br> test tests::bench_fft_manual ... bench:           4 ns/iter (+/- 2) |
| nightly-2020-01-02 | test tests::bench_fft        ... bench:          45 ns/iter (+/- 20) <br> test tests::bench_fft_manual ... bench:           5 ns/iter (+/- 1) |
| nightly-2019-06-01 <br> (with `#![feature(const_slice_len)]`) | test tests::bench_fft        ... bench:          52 ns/iter (+/- 23) <br> test tests::bench_fft_manual ... bench:           5 ns/iter (+/- 1) |

I took a look at the output of `cargo asm` for each version. The output of `fft` has 28 branch instructions, while the output of `fft_manual` has none. I guess the compiler is able to completely unroll the loop when it's written manually, but not when it's written using `Iterator`s.

Unfortunately, this is about the limit of my debugging ability currently. With some guidance, I might be able to do more of the leg work on my own.

Is this a known/expected performance difference? I hope not. I was really impressed at the elegance of the `Iterator`-based approach. I would be disappointed if the performance is really that bad.
Repository: go
Issue: gccgo: incorrectly rejects import declaration that shadows predeclared identifier
Labels: NeedsFix

gccgo incorrectly rejects the package below. cmd/compile and go/types correctly accept it.

The Go spec says the imported package name `copy` is declared in a.go's file block, whereas the predeclared `copy` function used in b.go is declared in the universe block. It's only an error to declare the same identifier in file and package block, not file and universe block.

```
-- a.go --
package p

import new "bytes"

var _ new.Buffer

-- b.go --
package p

var _ = new(int)
```

```
# command-line-arguments
./b.go:3:9: error: ‘new’ defined as both imported name and global name
    3 | var _ = new(int)
      |         ^
./a.go:3:8: note: ‘new’ imported here
    3 | import new "bytes"
      |        ^
```

/cc @ianlancetaylor
Repository: godot
Issue: Closing game window when it has crashed doesn't stop the game in the editor
Labels: bug,topic:editor

**Godot version:** 3.2.3, and 3.3.2

**OS/device including version:** Windows 7
 
**Issue description:**

Closing game window when it has crashed doesn't stop the game in the editor

**Steps to reproduce:**

1) A any sort of scripting error to a project:
```
func _ready():
	This isn't even slightly valid code
```

2) Run the application (F5).
You'll see it immediately gets the parser error.

3) Close the Game/Application window.
Godot Editor will show the game/application as still running and you have to hit stop (F8) to actually "stop" it. This despite the fact that the actual executable was shut down when the application was closed.
Repository: material-ui
Issue: [DatePicker] Improve popup placement
Labels: new feature,component: pickers

This is a subset of mui-org/material-ui-pickers#1648 focused on the placement of the popup on desktop. I believe we should apply the following changes:

1. Similar to https://github.com/mui-org/material-ui/pull/18289, it would make sense to move the `ref` from the root of the renderInput params to the `InputProps` key. This would avoid showing the helper message when the popup is open.
1. The popper should be positioned to start on the right side, not at the center.

<img src="https://user-images.githubusercontent.com/3165635/79081168-29607e00-7d1b-11ea-8546-efea151e1566.png" width="400" />
Repository: PowerToys
Issue: [FancyZones] Win+arrow on maximized PowerPoint presenter window doesn't resize correctly
Labels: Product-FancyZones,Area-App Compat

## ℹ Computer information

- PowerToys version: 0.27.1
- PowerToy Utility: FancyZones
- Windows build number: 19042.685 (20H2) but happens on other GA versions
- PowerPoint version: 2019 (16.0.13426.20352) 64-Bit

## 📝 Provide detailed reproduction steps (if any)

1. Start a PowerPoint presentation with the Presenter Windows Enabled
2. Leave the presenter window maximized / full screen
3. Use [Windows]+[arrow] to snap the presenter window to a fancy zone

### ✔️ Expected result

Expected the window to resize and reposition to a window zone.

### ❌ Actual result

The window is repositioned, but it remains at the maximized sized, overflowing to other monitors (the projector output in my case). This only seems to happen with the PowerPoint Presenter window; other maximized windows are correctly resized.

## 📷 Screenshots

Expected:
![image](https://user-images.githubusercontent.com/29103360/103181455-27215e00-486f-11eb-8323-06cd9996641f.png)

Actual: (notice red-hashed portion overflowing to the second monitor)
![image](https://user-images.githubusercontent.com/29103360/103181460-2e486c00-486f-11eb-9ff6-d8cfb35aba4c.png)
Repository: rust
Issue: Fn[Mut] trait missing lifetime parameter
Labels: A-lifetimes,A-trait-system,T-lang,C-feature-request

<!--
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.
-->

As far as I can tell, there is no way to write a trait bound for this closure:
```
    let mut k : usize = 0;
    let mut closure = || &mut k;
```
The closure's call function takes `&'something mut self`, but there is no way to talk about the lifetime `something`.  But it is necessary to talk about 'something because the return value borrows from it.

The following program compiles and works, using `transmute` to promise that the lifetimes are fine.  Without the transmute, and removing the spurious `'static`, there does not seem to be a way to write the bound on `F`.
```
use std::ops::FnMut;
use std::mem;

fn x<F>(f: &mut F)
    where F: FnMut() -> &'static mut usize
{
    *(f())= 42;
}

fn main() {
    let mut k : usize = 0;
    let mut closure = || unsafe { mem::transmute(&mut k) };
    x(&mut closure);

    println!("Hello, world! {}", k);
}
```
https://gist.github.com/rust-play/dd4471240c781ec26d07139045097b26

I hope I am right in describing this as a bug, although it seems like it's an API/language bug :-/.  I tried various approaches, including `for<>`, and various lifetime annotation approaches, without anything resembling success.  ISTM that what's really needed is for the `FnMut` and `FnOnce` traits to have a lifetime parameter for the self reference that the call function gets.  I looked in the Reference and the Nomicon and various other places but the documentation in this area was rather thin and informal and didn't seem to come close to addressing this matter.

To demonstrate that what I am doing here is not unreasonable, here is a program which achieves the same thing with a "closure" which is actually a struct so has to be called with a method.
```
trait NullaryCallableMut<'f> {
    type Output;
    fn call(&'f mut self) -> Self::Output;
}

fn x<'f, F>(f: &'f mut F)
    where F: NullaryCallableMut<'f, Output=&'f mut usize>
{
    *(f.call())= 42;
}

struct Closure<'r>(&'r mut usize);

impl<'f> NullaryCallableMut<'f> for Closure<'f> {
    type Output = &'f mut usize;
    fn call(&'f mut self) -> &'f mut usize { self.0 }
}

fn main() {
    let mut k : usize = 0;

    let mut closure = Closure(&mut k);
    x(&mut closure);

    println!("Hello, world! {}", k);
}
```
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f5add6be7376191011c0367159b8a617

All of these experiments were in the Rust playground, stable channel.  1.48 currently.
Repository: godot
Issue: Unfocusing game window causes the FPS to drop to 1 when v-sync is enabled and SwayWM/Wayland is used
Labels: bug,platform:linuxbsd,topic:rendering

**Godot version:**
3.2.3

**OS/device including version:**
OS: Arch Linux
Window Manager: Sway
GPU: RX 5700 XT
CPU: Ryzen 7 3700X
Backend: GLES3

**Issue description:**
With an empty scene, when I unfocus the game's  window, the FPS will drop down to 1. Refocusing the window causes the FPS to climb back up to 60. If I disable v-sync, the problem seems to disappear. This problem only seems to happen on SwayWM, because running the scene with GNOME didn't reproduce the problem.

**Steps to reproduce:**
1. Create an empty scene
2. Print `Engine.get_frames_per_second()` within `physics_process`
3. Unfocus the window

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[MinimalReproductionProject.zip](https://github.com/godotengine/godot/files/5745664/MinimalReproductionProject.zip)

**Video**

https://user-images.githubusercontent.com/20866468/103185353-e1659500-4870-11eb-860b-312b624a8d37.mp4
Repository: create-react-app
Issue: Generated .gitignore should include .eslintcache
Labels: issue: proposal,needs triage

### Describe the solution you'd like

The `.gitignore` generated by `create-react-app` should include `.eslintcache`.
Repository: create-react-app
Issue: How can i custom config Webpack without "npm run eject"
Labels: needs triage

Sometimes I want to add webpack plugins externally. But how can I do this without "reject"?

i see a `node_modules/react-script/config/webpack.config.js` file. 

However, there is more than one "plugin" definition in this file. Is there any way to configure here? Or can a separate file be specified for the configurations in the next version? for example:

like this `node_modules/react-script/config/custom/webpack.config.js`

Thank you
Repository: flutter
Issue: [proposal] listen for individual staggered animation status
Labels: c: new feature,framework,a: animation,c: proposal,P3,team-framework,triaged-framework

I have created an staggered animation and I want to listen to status of each sequential animation individually.
```dart
late final AnimationController controller;
late final Animation<double> opacity;

@override
  void initState() {
    super.initState();

    controller =
        AnimationController(vsync: this, duration: Duration(seconds: 2));
    opacity = CurvedAnimation(
      parent: controller,
      curve: Interval(0.0, 0.5),
    );
    controller.forward();
    opacity.addStatusListener((status) {
      if (status == AnimationStatus.completed) {
        print('opacity completed: ${DateTime.now().toString()}');
      }
    });

    controller.addStatusListener((status) {
      if (status == AnimationStatus.completed) {
        print('controller completed: ${DateTime.now().toString()}');
      }
    });
  }

```

**Expected results:** 
the opacity animation completes in half of controller duration so I expect opacity status listener gets invoked 1 second earlier.

**Actual results:**
but both statusListener gets invoked at the same time, I mean all sequenced animations status gets invoked when controller completes.

**is this and intended behavior or a bug?**
so how can I observe the status of each child animation correctly?

**Flutter: 1.25.0-8.1.pre**
Repository: flutter
Issue: FlutterJNI.getBitmap generate wrong result when the screenshot has alpha channel
Labels: platform-android,engine,has reproducible steps,P2,team-android,triaged-android,found in release: 3.19,found in release: 3.22

## Steps to Reproduce

1. Create a smallest MaterialApp with transparent background and a `Container` with 50% alpha white(#80FFFFFF) in it. 
2. Use `RenderRepaintBoundary` in Flutter to take a screenshot.
3. Use `FlutterImageView` in Android Java side to take a screenshot.
4. Use `FlutterEngine.getRenderer().getBitmap();` in Java side to take a screenshot of this flutter app.

**Expected results:** 
Step 2/3/4: A rectangular filled with #80FFFFFF centered in transparent background and the screenshot saved to a Bitmap.

**Actual results:**
In step 2 and 3, I get expected result.
I saved result as PNG and it looks like this in PhotoShop:
![1](https://user-images.githubusercontent.com/4949937/103211795-20184f80-4944-11eb-8d74-4670dc8dd41d.png)

In step 4, a rectangular filled with #80808080 centered in transparent background.
I saved it to PNG:
![wrong](https://user-images.githubusercontent.com/4949937/103211443-2f4acd80-4943-11eb-8656-fef962f05d11.png)

<details>
  <summary>Codes</summary>

```
MaterialApp(
      debugShowCheckedModeBanner: false,
      builder: (context, child) {
        return Material(
          type: MaterialType.transparency,
          child: Container(
            alignment: Alignment.center,
            color: Colors.transparent,
            child: Container(
              width: 50,
              height: 50,
              color: Color.fromARGB(128, 255, 255, 255),
            ),
          ),
        );
      },
    );
```

</details>
Repository: electron
Issue: [Feature Request]: Delete from disk a session created with fromPartition
Labels: enhancement :sparkles:

As stated in https://github.com/electron/electron/issues/27018, there is no documented way to delete from disk the directory 

    C:\Users\User\AppData\Roaming\<electron-app-name>\Partitions\sessionD76Z687AX789W

created by the [session](https://github.com/electron/electron/blob/master/docs/api/session.md) API

    sess = session.fromPartition('persist:sessionD76Z687AX789W', { cache: true });

Feature request: instead of manually using filesystem functions to delete the directory  `C:\Users\User\AppData\Roaming\<electron-app-name>\Partitions\sessionD76Z687AX789W` and its content, could we add:

    session.deleteStorage()

or something similar?

NB: clearCache does not do it already (see https://github.com/electron/electron/blob/master/docs/api/session.md#sesclearcache)
Repository: godot
Issue: Offline stable in-editor documentation pointing to lastest documentation
Labels: bug,topic:editor,documentation

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
Current 3.2.3 stable

**OS/device including version:**
All

**Issue description:**
<!-- What happened, and what was expected. -->
All external online doc links in stable editor points to lastest instead, leading to 404 errors

![image](https://user-images.githubusercontent.com/23405122/103214353-79ff2200-4910-11eb-8b28-623464191dc9.png)

![image](https://user-images.githubusercontent.com/23405122/103214450-b9c60980-4910-11eb-87b0-8d46daaae876.png)

Issue not present in 3.0 (tested with in-editor help on *JavaScript* with online doc link).

**Steps to reproduce:**
SHIFT+F1, open help for *Resource* or *JavaScript*

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Any
Repository: rust
Issue: Tracking Issue for `box_into_inner`
Labels: T-libs-api,proposed-final-comment-period,C-tracking-issue,disposition-merge,Libs-Tracked,A-box

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(box_into_inner)]`

This is a tracking issue for consuming a `Box` and returning its wrapped value.

The language actually supports `*x` as a special case. However it can't be generalized to other types easily. It also doesn't consume the `Box` value immediately if `T` is `Copy`, which is quite a footgun.

An explicit version is added here to make the API more consistent with `Pin`, `Cell`, `RefCell` etc.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
impl<T, A: Allocator> Box<T, A> {
     pub fn into_inner(boxed: Self) -> T;
}
```

### Steps / History

<!--
In the simplest case, this is a PR implementing the feature followed by a PR
that stabilises the feature. However it's not uncommon for the feature to be
changed before stabilization. For larger features, the implementation could be
split up in multiple steps.
-->

- [x] Implementation: #80438
- [ ] https://github.com/rust-lang/rust/pull/98523
- [ ] Final commenting period (FCP)
- [ ] Stabilization PR

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.
Repository: storybook
Issue: Doc Plugin doesnt pick up jsdoc Information
Labels: feature request,addon: docs

**Describe the bug**
The Stroybook docs plugin does not pick up my jsdoc description of my react components. No knobs are created and the component description contains the raw jsdoc information

**To Reproduce**
Create any functional component and describe the params with jsdoc

**Expected behavior**
The docs page contains the proper parameter descriptions based on my jsdoc definition

**Screenshots**
![Screenshot 2020-12-28 141500](https://user-images.githubusercontent.com/63824317/103216867-63a89480-4917-11eb-998a-66242d6f87f0.png)


**Code snippets**
```
import React from "react";
const sizes = { small: "max-w-sm", large: "max-w-2xl", full: "w-full" };

/**
 * Box Layout Component
 *
 * @param {Object} props
 * @param {Boolean=} props.scrollable
 * @param {Boolean=} props.padded
 * @param {(JSX.Element | String)=} props.children
 * @param {function():any=} props.onClick
 * @param {('small'|'large'|'full')=} props.size
 * @param {String=} props.className
 */
export default function Container({
  children,
  padded,
  scrollable,
  className,
  size,
  ...props
}) {
  return (
    <div
      className={`flex flex-col flex-auto ${
        scrollable ? "overflow-auto" : "overflow-hidden"
      } ${padded && "p-4"} ${sizes[size]} ${className}`}
      {...props}
    >
      {children}
    </div>
  );
}
```
**System**
  System:
    OS: Linux 4.19 Ubuntu 20.04.1 LTS (Focal Fossa)
    CPU: (8) x64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
  Binaries:
    Node: 15.0.1 - ~/.nvm/versions/node/v15.0.1/bin/node
    npm: 7.0.3 - ~/.nvm/versions/node/v15.0.1/bin/npm
  npmPackages:
    @storybook/addon-actions: ^6.1.11 => 6.1.11 
    @storybook/addon-essentials: ^6.1.11 => 6.1.11 
    @storybook/addon-links: ^6.1.11 => 6.1.11 
    @storybook/node-logger: ^6.1.11 => 6.1.11 
    @storybook/preset-create-react-app: ^3.1.5 => 3.1.5 
    @storybook/react: ^6.1.11 => 6.1.11