sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [Icon] fontSize prop not applied to Icon component
Labels: docs,component: Icon,package: styled-engine

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

The fontSize prop does not affect the <Icon /> component. Using sx doesn't affect size either. Tested in Chrome 89.0 and Safari 14.0.

See example in the new docs. The fontSize prop doesn't impact the size of the icons:

<img width="940" alt="Screen Shot 2021-04-18 at 8 21 29 AM" src="https://user-images.githubusercontent.com/3904758/115145347-1748a800-a01f-11eb-9463-2028e953d772.png">

https://next.material-ui.com/components/icons/#font-material-icons

## Expected Behavior 🤔

Expect same behavior as in v4, displayed in the current docs:

<img width="878" alt="Screen Shot 2021-04-18 at 8 22 26 AM" src="https://user-images.githubusercontent.com/3904758/115145378-3810fd80-a01f-11eb-867d-863e26e84cfa.png">

https://next.material-ui.com/components/icons/#font-material-icons


## Your Environment 🌎

<details>
  <summary>`npx @material-ui/envinfo`</summary>
  System:
    OS: macOS 10.15.7
  Binaries:
    Node: 14.15.0 - ~/.nvm/versions/node/v14.15.0/bin/node
    Yarn: Not Found
    npm: 7.6.0 - ~/Software/plynth/Current/plynth/plynth-frontend/node_modules/.bin/npm
  Browsers:
    Chrome: 89.0.4389.128
    Edge: Not Found
    Firefox: 81.0.1
    Safari: 14.0.3
  npmPackages:
    @emotion/react: ^11.1.5 => 11.1.5 
    @emotion/styled: ^11.1.5 => 11.1.5 
    @material-ui/core: ^5.0.0-alpha.27 => 5.0.0-alpha.27 
    @material-ui/icons: ^5.0.0-alpha.28 => 5.0.0-alpha.28 
    @material-ui/lab: ^5.0.0-alpha.27 => 5.0.0-alpha.27 
    @material-ui/styled-engine:  5.0.0-alpha.25 
    @material-ui/styles:  5.0.0-alpha.27 
    @material-ui/system:  5.0.0-alpha.27 
    @material-ui/types:  5.1.7 
    @material-ui/unstyled:  5.0.0-alpha.27 
    @material-ui/utils:  5.0.0-alpha.27 
    @types/react:  17.0.2 
    react: ^17.0.2 => 17.0.2 
    react-dom: ^17.0.1 => 17.0.1 
</details>
Repository: rust
Issue: Wrong error message shown when a `_` is used in place of generic constant
Labels: A-diagnostics,T-compiler,A-const-generics

<!--
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
static TEST : [i32; _] = [1i32, 2i32];
fn main() {}
```

The current output is:

```
error[E0658]: destructuring assignments are unstable
 --> src/main.rs:1:21
  |
1 | static TEST : [i32; _] = [1i32, 2i32];
  |                     ^
  |
  = note: see issue #71126 <https://github.com/rust-lang/rust/issues/71126> for more information
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0747]: type provided when a constant was expected
 --> src/main.rs:3:16
  |
1 | static TEST : [i32; _] = [1i32, 2i32];
  |                     ^
  |
  = help: const arguments cannot yet be inferred with `_`
```
The sample code doesn't seem to be related to the `destructuring assignment` feature nonetheless.

This, although quite artificial looking, use case too causes the wrong looking output

```rust
fn test() -> [i32; _] { [2, 1] }
fn main() {}
```

Output:

```
error[E0658]: destructuring assignments are unstable
 --> src/main.rs:3:20
  |
3 | fn test() -> [i32; _] { [2, 1] }
  |                    ^
  |
  = note: see issue #71126 <https://github.com/rust-lang/rust/issues/71126> for more information
  = help: add `#![feature(destructuring_assignment)]` to the crate attributes to enable

error: in expressions, `_` can only be used on the left-hand side of an assignment
 --> src/main.rs:3:20
  |
3 | fn test() -> [i32; _] { [2, 1] }
  |                    ^ `_` not allowed here
```

Some code seems to print correct the error messages (kinda?):

```rust
struct T<const U : usize>([i32; U]);
fn test() -> T<_> { T([2, 1]) }
fn main() {}
```

Output

```
error[E0747]: type provided when a constant was expected
 --> src/main.rs:3:16
  |
3 | fn test() -> T<_> { T([2, 1]) }
  |                ^
  |
  = help: const arguments cannot yet be inferred with `_`

error[E0121]: the type placeholder `_` is not allowed within types on item signatures
 --> src/main.rs:3:16
  |
3 | fn test() -> T<_> { T([2, 1]) }
  |                ^ not allowed in type signatures
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->

# Meta

This happens on stable, beta and nightly.
Repository: godot
Issue: Project Manager down-up hotkey is bugging
Labels: bug,topic:editor,usability

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.x

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 8.1

**Issue description:**
<!-- What happened, and what was expected. -->
When you have more project in the project manager, the down and up key working is weird.
If you keep it pressed, the selection will be incorrect, especially if you type something to the filter.
You can hardly select a project and an option together, what is a weird solution, and
after a selection when you press enter, that won't open the project, but also run a function, option, what is selected too.
It's an uncontrollable solution.

Idea: up/down keys should be controll just the stepping between projects, like before 3.2.x, correctly, and the Tab key should be
for the selection of functions, options.

**Steps to reproduce:**
Trying hotkeys in project managers, especially up-down keys to select a project, when you have multiple project in the manager,
especially if you type something to the filter.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Don't need.
Repository: pytorch
Issue: log_softmax(x) != x - logsumexp(x)
Labels: module: numerical-stability,triaged

## 🐛 Bug

There is a rather large numerical difference between `log_softmax` as computed by `torch.nn.functional.log_softmax` and `x - logsumexp(x)`.

```python
import torch

def log_softmax(x, dim=-1):
    return x - torch.logsumexp(x, dim=dim, keepdim=True)

a = torch.tensor([[800, 800, 400]], dtype=torch.float32)
pt = torch.nn.functional.log_softmax(a, dim=-1)
print(pt)
# tensor([[  -0.6931,   -0.6931, -400.6931]])

my = log_softmax(a, dim=-1)
print(my)
# tensor([[  -0.6932,   -0.6932, -400.6932]])

print(torch.abs(pt - my))
# tensor([[2.9087e-05, 2.9087e-05, 3.0518e-05]])

print(torch.allclose(pt, my))
# False
```

## To Reproduce

https://colab.research.google.com/drive/1B1exQKAC_sMBMqiMzY42gw97YYq1PVvP?usp=sharing

## Expected behavior

`torch.allclose` should pass.

## Environment

Colab.

```
PyTorch version: 1.8.1+cu101
Is debug build: False
CUDA used to build PyTorch: 10.1
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.12.0

Python version: 3.7 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: 11.0.221
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.4
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.4
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.4
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.4
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.4
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.4
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.4
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.5
[pip3] torch==1.8.1+cu101
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.9.1
[pip3] torchvision==0.9.1+cu101
[conda] Could not collect
```
Repository: deno
Issue: Support for Named Pipes in Deno.connect
Labels: public API,suggestion

**Why?**

Currently, `Deno.connect` only supports IPC for unix (using unstable `transport: "unix"`). There should be named pipes support too, which would allow IPC on Windows (as NodeJS' `net` mode does, it supports both, [reference](https://nodejs.org/api/net.html#net_ipc_support)).

**Additional info**

I have tried using `Deno.open` but it doesn't work too well here. A native addon to Deno.connect would be way better.
Repository: rust
Issue: rustdoc: Get rid of `Item::Attributes`
Labels: C-cleanup,T-rustdoc,E-mentor,E-medium,I-compilemem

This is a special case of https://github.com/rust-lang/rust/issues/76382. `Attributes` is 72 bytes large and used in quite a few places:

- [`Item::attrs`](https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/clean/types/struct.Item.html#structfield.attrs)
- [`FnDecl::attrs`](https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/clean/types/struct.FnDecl.html#structfield.attrs)
- [`ExternalCrate::attrs`](https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/clean/types/struct.ExternalCrate.html#structfield.attrs)

This has two downsides:
1. Attributes takes up a lot of space in memory, so this bloats memory usage
2. It means attributes have to calculated ahead of time, instead of on-demand. In particular, this requires adding a new attrs field whenever `render` needs to look at the attrs of a specific `clean` type (https://github.com/rust-lang/rust/pull/83900#discussion_r615363572).

It would be better to calculate this on-demand, so it uses less memory and doesn't have to be calculated for each and every item.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: excalidraw
Issue: Feat Request: Markdown Support for texts
Labels: enhancement,discussion

We have currently text editing options such as:

- Hand drawn
- Normal Text
- Code

Wouldn't it be interesting idea to integrate markdown capabilities while writing text?
Should be a simple implementation by using a lib and a util func.

Needs good discussion with the team; would love to work on this!

This feature can give help a lot, especially devs who's not a single day goes by without using `markdown`.

Thanks, looking forward for my first contribution to my fav devtool `Excalidraw`.
Repository: rust
Issue: `matches!(n, -1 | 1)` for signed NonZero suboptimal
Labels: I-slow,A-codegen,E-needs-test,T-compiler,C-bug

The code generated when comparing a signed non-zero type to `-1` or `1` varies wildly, and *appears* to generate suboptimal branching code.

*A more in-depth analysis of the generated assembly can be found here: https://godbolt.org/z/qxzGrv9nn.*

## Basic

Looking at these two functions, one would expect them to generate the same assembly.

```rust
pub fn is_one_1(len: NonZeroI32) -> bool {
    matches!(len.get(), -1 | 1)
}

pub fn is_one_2(len: NonZeroI32) -> bool {
    len.get() == -1 || len.get() == 1
}
```

However that is not the case, with `is_one_1` in fact branching as seen below. Whilst I have not run benchmarks to see if branching is more performant, one would expect it not to be.

```asm
example::is_one_1:
        cmp     edi, 1
        je      .LBB0_3
        cmp     edi, -1
        jne     .LBB0_2
.LBB0_3:
        mov     al, 1
        ret
.LBB0_2:
        xor     eax, eax
        ret

example::is_one_2:
        cmp     edi, -1
        sete    cl
        cmp     edi, 1
        sete    al
        or      al, cl
        ret
```

## What if we include `0` in the comparison?

Since `len` is a `NonZeroI32`, it is guaranteed that `len.get() != 0` otherwise it is undefined behaviour. This means that the function below should behave the same as `is_one_1`.

```rust
pub fn is_one_3(len: NonZeroI32) -> bool {
    matches!(len.get(), -1 | 0 | 1)
}
```

In fact the generated assembly for this is the smallest yet.

```asm
example::is_one_3:
        add     edi, 1
        cmp     edi, 3
        setb    al
        ret
```

This assembly is actually also generated when we include `0` in the comparison in the style of `is_one_2`.

```rust
pub fn is_one_4(len: NonZeroI32) -> bool {
    len.get() == -1 || len.get() == 0 || len.get() == 1
}
```

```asm
example::is_one_4:
        add     edi, 1
        cmp     edi, 3
        setb    al
        ret
```

## Expected behaviour

The expected behaviour of the compiler would be to generate assembly that matches between the different implementations of this check.
Repository: rust
Issue: Rust compiler attempting to resolve unrelated trait methods.
Labels: A-diagnostics,T-compiler,D-confusing

I am using rustc version` 1.51.0 (2fd73fabe 2021-03-23)`

Please see the following code snippet and the build errors. It appears that rustc is getting confused trying to resolve method name from a completely unrelated trait and pointing to those in the error logs. This makes error logs unclear and harder to understand:

```
#[test]
    fn trial() {
        struct MyOption<T> {
            item: T,
        }

        impl<U: Copy> MyOption<&U> {
            fn copied(self) -> U {
                *self.item
            }
        }

        let v = vec![1, 2, 3];
        let ov = MyOption { item: &v };
        let ovc = ov.copied();
    }
```

<img width="947" alt="image" src="https://user-images.githubusercontent.com/9190057/115154602-66cbba00-a099-11eb-8704-df808b014ce2.png">
Repository: godot
Issue: In a canvas_item shader, accessing `COLOR` in an `if` statement will affect `COLOR` even if the `if` condition isn't met
Labels: documentation,topic:shaders

**Godot version:**
v3.2.3.stable.official


**OS/device including version:**
GPU: AMD Radeon RX 5700
Backend: GLES3


**Issue description:**
Accessing `COLOR` in an `if` statement will make the sprite white even if the `if` condition isn't met, which means we need to explicitly set `COLOR` in an `else` block. 

Without the `else` block:
![image](https://user-images.githubusercontent.com/9066587/115155954-fdb35a80-a036-11eb-91d5-481a6280bbe3.png)

With the `else` block:
![image](https://user-images.githubusercontent.com/9066587/115156018-3c491500-a037-11eb-9090-b45d238dd8df.png)

The expected outcome: `COLOR` should not be affected if control flow doesn't go into that `if` block.


**Steps to reproduce:**
Set up a sprite with a `canvas_item` shader and enter in the code as per the screenshots above.


**Minimal reproduction project:**
[bug_shader-color.zip](https://github.com/godotengine/godot/files/6331922/bug_shader-color.zip)
Repository: rust
Issue: [ER] Array bound tests in a simple enough case
Labels: A-LLVM,I-slow,T-compiler

This comes from reduction of code that implements a binary heap (sift up) on an array:

```rust
pub fn foo(data: &[u32]) -> u32 {
    let i = data.len();
    if i / 2 == 0 {
        return 0;
    }
    data[i - 1] + data[i / 2 - 1]
}
```

rustc (1.53.0-nightly 392ba2ba1 2021-04-17) seems unable to remove the array bound tests, despite I think the code should be panic-less:

```asm
foo:
        sub     rsp, 8
        mov     rdx, rsi
        shr     rdx
        je      .LBB0_6
        mov     rcx, rsi
        sub     rcx, 1
        jb      .LBB0_4
        lea     rax, [rdx - 1]
        cmp     rax, rsi
        jae     .LBB0_5
        mov     eax, dword ptr [rdi + 4*rdx - 4]
        add     eax, dword ptr [rdi + 4*rcx]
        pop     rcx
        ret
.LBB0_6:
        xor     eax, eax
        pop     rcx
        ret
.LBB0_4:
        lea     rdx, [rip + .L__unnamed_1]
        mov     rdi, rcx
        xor     esi, esi
        call    qword ptr [rip + core::panicking::panic_bounds_check@GOTPCREL]
        ud2
.LBB0_5:
        lea     rdx, [rip + .L__unnamed_2]
        mov     rdi, rax
        call    qword ptr [rip + core::panicking::panic_bounds_check@GOTPCREL]
        ud2
```

I expected it to compile to something closer to:

```asm
foo:
        mov     rax, rsi
        shr     rax
        je      .LBB0_1
        mov     eax, dword ptr [rdi + 4*rax - 4]
        add     eax, dword ptr [rdi + 4*rsi - 4]
        ret
.LBB0_1:
        xor     eax, eax
        ret
```
Repository: PowerToys
Issue: Allow for manual zone numbers
Labels: Idea-Enhancement,FancyZones-Editor,Product-FancyZones

## 📝 Provide a description of the new feature

Manual zone numbers would allow for specific applications to be in certain areas during quick layout changes. This would give more control when choosing layouts with more or less zones.

_What is the expected behavior of the proposed feature?  What is the scenario this would be used?_

I'm using the quick layouts on a super ultra wide monitor to quickly change app focus while having useful associated apps in smaller zones. Being able to have an app switch from say zone 1 to zone 3 during a quick change would increase functionality. 

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: rust
Issue: rustdoc: search URLs should be based off the documentation root
Labels: T-rustdoc,A-rustdoc-js

When you do a search on a rustdoc page, we use the history API to modify the URL bar and represent the current search. For instance if you search for "vec" from the String page, you'd get:

https://doc.rust-lang.org/std/string/struct.String.html?search=vec

But if you searched for "vec" from the slice page, you'd get:

https://doc.rust-lang.org/std/slice/index.html?search=vec

Conceptually, though, these are the same: the search results for "vec" within /std/. Since [`History.pushState()`](https://developer.mozilla.org/en-US/docs/Web/API/History/pushState) lets us choose whatever URL we want within the same origin, we should remove the part that's specific to the page you started on, and generate a URL like so:

https://doc.rust-lang.org/std/index.html?search=vec

(note the index.html rather than just /std/, so this works properly when loading local files).

I'm happy to work on this.
Repository: flutter
Issue: [proposal] ProxyAnimation should support generic
Labels: c: new feature,framework,a: animation,c: API break,c: proposal,P3,team-framework,triaged-framework

I'm was working in a `LocationTween` for geo-interpolations when I noticed that `ProxyAnimation` only supports double-based animation (Animation<double>). 

I have to refactor the class for my application uses. Likewise, I have made some changes into my flutter fork and since it's my first contribution can somebody helps me to submit a pull request correctly. 

```dart
class ProxyAnimation<T> extends Animation<T>
```

```dart
    const Offset begin = Offset(0.0, 1.0);
    const Offset end = Offset.zero;
    final Tween<Offset> offsetTween = Tween<Offset>(begin: begin, end: end);
    final Animation<Offset> offsetAnimation =
        controller.drive<Offset>(offsetTween);

    controller.value = 0.5;
    final ProxyAnimation<Offset> animation = ProxyAnimation<Offset>()
    animation.parent = offsetAnimation;
   
   var value = animation .value;
```

### Implemented test use case:

```dart
  test(
      'ProxyAnimation<T> generic different than double, set parent generates value changed',
      () {
    final AnimationController controller = AnimationController(
      vsync: const TestVSync(),
    );

    const Offset defaultValue = Offset.zero;
    const Offset begin = Offset(0.0, 1.0);
    const Offset end = Offset.zero;
    final Tween<Offset> offsetTween = Tween<Offset>(begin: begin, end: end);
    final Animation<Offset> offsetAnimation =
        controller.drive<Offset>(offsetTween);

    controller.value = 0.5;
    bool didReceiveCallback = false;
    final ProxyAnimation<Offset> animation =
        ProxyAnimation<Offset>(defaultValue: defaultValue)
          ..addListener(() {
            didReceiveCallback = true;
          });
    expect(didReceiveCallback, isFalse);
    expect(animation.value, equals(defaultValue));
    animation.parent = offsetAnimation;
    expect(animation.value, equals(const Offset(0.0, 0.5)));
    expect(didReceiveCallback, isTrue);
    didReceiveCallback = false;
    expect(didReceiveCallback, isFalse);
    controller.value = 0.6;
    expect(didReceiveCallback, isTrue);
    expect(animation.value, equals(const Offset(0.0, 0.4)));
  });

```
Repository: rust
Issue: rustdoc: remove redundant toggles for "undocumented items"
Labels: T-rustdoc,C-enhancement,A-rustdoc-ui

Rustdoc has some code to hide "undocumented items." As far as I can tell, that applies to trait implementors (on trait pages) and trait implementations (on struct pages). However, there's already an outer layer of toggles for both the implementors and implementations. For instance, this is what the "implementations" section looks like for the Read trait, if your settings expand implementations by default:

-------

<img src="https://user-images.githubusercontent.com/220205/115167059-d8d8da80-a06a-11eb-9bad-6394fc431b28.png" width=300>

-------

The toggle for each implementation is redundant with the inner toggle for the undocumented items. I think we should remove either the outer toggle or the inner. I'm not sure which is better. One argument in favor of removing the outer toggles: If someone has gone to the trouble of documenting a trait implementation, we should try to display that by default. For instance, here's what the implementations section looks like for String, by default:

-------

<img src="https://user-images.githubusercontent.com/220205/115167242-ae3b5180-a06b-11eb-9dc1-ba7866e3351f.png" width=400>

-------

However, if you know to expand it, there's actually some really nice documentation there:

-------

<img src="https://user-images.githubusercontent.com/220205/115167300-e9d61b80-a06b-11eb-86cd-7e08007e1d9c.png" width=550>

-------


There's a similar situation in `rustls`: Its `Read` implementation has important documentation on how to use it properly, but you wouldn't know that documentation was there because it's toggled closed by default.