sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [docs] Add migration guide from alternative UI libraries
Labels: docs,discussion

- [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.

## Summary 💡

Add documentation on how to migrate from alternative UI libraries.

## Examples 🌈

- I have seen this idea implemented in https://github.com/vercel/next.js/issues/17455, https://github.com/vercel/next.js/issues/17454, https://github.com/vercel/next.js/issues/17453.
- It's also something we would see frequently in traditional products.

## Motivation 🔦

As a user of another UI library, I have built my habit, trying another library requires a learning curve that I discouraging. We can't document everything but we can likely cover the most important differences. I can also help developers to compare objectively the different libraries, based on things they can directly see.

Libraries we could cover:

- [ ] Bootstrap/react-bootstrap. We could explain the difference in style utilities and customization
- [ ] Ant Design: We could explain the difference in customization
- [ ] Chakra: We could explain how to port the theme structure
- [ ] TailwindCSS: We could explain the difference in the CSS utilities with the MUI System
- [ ] ReachUI: Once we ship the unstyled components, we could explain the main differences
- [ ] KendoUI
- [ ] etc.

⚠️ These guides won't be meant to marketing one solution over another, this would have to been done upstream in the pipeline. This step would be meant to reduce the friction in the transition.
Repository: godot
Issue: Kinematic/Character bodies cause slowdown/crash when colliding with convex collision shapes
Labels: bug,confirmed,topic:physics,topic:3d,performance

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
Godot 3.3.


**OS/device including version:**
Linux Manjaro, Intel Kaby Lake


**Issue description:**
Noticeable slowdown when a kinematic body collides with stuff. I managed to "manage" most of it by a) optimizing the collision shape of the AI and b) reducing the number of "slides" attempted to 1. (I tried to change the physics to move_and_collide() but failed :(  I am also looking at kinematic mode rigidbodies as a possible solution - I really like how smooth movement/AI code are with kinematic bodies as opposed to VehicleBody )

This is Bullet physics BTW - if you change to Godot physics and collide with a building, the game freezes, no output in log.

Cars: kinematicbody3d with a box collision shape
Ground: staticbody with a box collision shape
Buildings and some part of the road: convex collision, autogenerated (I will likely try replacing those with simpler shapes next)


**Steps to reproduce:**
Run the project, drive around. The fastest way to trigger AI crashing into stuff is to start a race (red flag on minimap, red marker on ground) because the AI crash into stuff after crossing finish line (unfinished [pun intended] AI handling xD)

**Minimal reproduction project:**
Not minimal, because it takes several AI going around and crashing into obstacles for stuff to happen, but: 
https://github.com/Zireael07/FreeRoamRoguelikeRacerPrototype

master branch: drops to single digits when an AI or two crash into stuff
develop: drops to 20-ish fps

@Calinou  and whoever else told me to make a new issue
Repository: neovim
Issue: Unified diff format is not supported for external diffs
Labels: bug,diff

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: NVIM v0.5.0-dev+1302-g8a93d1028

### Steps to reproduce using `nvim -u NORC`

```
" s.vim
function MyDiff()
  silent execute "!diff  -u " . v:fname_in . " " . v:fname_new . " > " . v:fname_out
endfunction
set diffexpr=MyDiff()
```

```
# Steps to reproduce
nvim -u NORC -O a b
# Inside Neovim:
:source s.vim
:windo diffthis
```

### Actual behaviour

Vim outputs `E97: Cannot create diffs`

### Expected behaviour

Vim turns on the diff mode without producing an error.

### Notes

This is a bug, because documentation claims that Neovim should handle unified diffs (https://neovim.io/doc/user/diff.html, C^F "unified"). 

Neovim does handle unified diffs for internal diffs since https://github.com/neovim/neovim/commit/cf1ffa91667a482c6355f5999b9e97ccc0b4126a, but it seems that this functionality has not been plugged into external diffs, and there's even a smoke check that tests that the external diff complies with the ed-style format:
https://github.com/neovim/neovim/blob/1186f7dd96b054d6a653685089fc845a8f5d2f27/src/nvim/diff.c#L985-L992
Repository: neovim
Issue: Neovim doesn't correctly handle ed-style diffs
Labels: bug,diff

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: : NVIM v0.5.0-dev+1302-g8a93d1028

### Steps to reproduce using `nvim -u NORC`

```
" s.vim
function MyDiff()
  " Circumvent https://github.com/neovim/neovim/blob/1186f7dd96b054d6a653685089fc845a8f5d2f27/src/nvim/diff.c#L985-L992
  if match(readfile(v:fname_in),"line1") != -1
    silent execute "!diff " . v:fname_in . " " . v:fname_new . " > " . v:fname_out
  else
    silent execute "!cat eddiff " . " > " . v:fname_out
  endif
endfunction
set diffexpr=MyDiff()
```
```
# eddiff
1d0
< 2021-05-01 Entry #1
1a1
> 2021-05-02 Entry #2
2d1
< 2021-05-03 Entry #3
```
```
# left.txt
2021-05-01 Entry #1
2021-05-03 Entry #3
```
```
# right.txt
2021-05-02 Entry #2
```

```
nvim -u NORC -O left.txt right.txt
:source s.vim
:windo diffthis
```

### Actual behaviour
![grafik](https://user-images.githubusercontent.com/722385/117581748-b59bcb00-b0fe-11eb-94cb-627e7d1dec7c.png)


### Expected behaviour

The hungs should be sorted by date in vim's display:
```
2021-05-01 Entry #1  |
                     | 2021-05-02 Entry #2 
2021-05-03 Entry #3  |
```

### Notes

If this expected behaviour is unconvincing, then I can produce even worse cases where valid ed hunks lead to surprising behaviours.

The problem is that Neovim doesn't seem to correctly handle Ed hunks that are adjacent to each other, that is, Neovim would only correctly handle the diff as:

```
1,2c1
< 2021-05-01 Entry #1
< 2021-05-03 Entry #3
---
> 2021-05-02 Entry #2
```

Unfortunately, that expectation prevents some potentially valid inputs that would give more information about the hunk order and granularity.
Repository: rust
Issue: Verbose `Sized` errors when `for`-looping over an error type
Labels: A-diagnostics,T-compiler,C-bug

This code: ([playground](https://play.rust-lang.org/?version=beta&mode=debug&edition=2018&gist=beff6ac84372de1e4da1eecc5579ab92))

```rust
fn foo(x: &str) {}

fn misspelled() -> Vec<String> {unimplemented!()}

fn main() {
    for x in mispelled() {
        foo(&x);
    }
}
```

Would compile if the call to `misspelled` wasn't misspelled, but since it is type inference concludes that `x` is a `str` and the compiler emits *three* E0277s:

```
error[E0425]: cannot find function `mispelled` in this scope
 --> src/main.rs:6:14
  |
3 | fn misspelled() -> Vec<String> {unimplemented!()}
  | ------------------------------ similarly named function `misspelled` defined here
...
6 |     for x in mispelled() {
  |              ^^^^^^^^^ help: a function with a similar name exists: `misspelled`

error[E0277]: the size for values of type `str` cannot be known at compilation time
 --> src/main.rs:6:9
  |
6 |     for x in mispelled() {
  |         ^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `str`
  = note: all local variables must have a statically known size
  = help: unsized locals are gated as an unstable feature

error[E0277]: the size for values of type `str` cannot be known at compilation time
 --> src/main.rs:6:14
  |
6 |     for x in mispelled() {
  |              ^^^^^^^^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `str`
  = note: all local variables must have a statically known size
  = help: unsized locals are gated as an unstable feature

error[E0277]: the size for values of type `str` cannot be known at compilation time
 --> src/main.rs:6:5
  |
6 | /     for x in mispelled() {
7 | |         foo(&x);
8 | |     }
  | |_____^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `str`
  = note: required by `None`

error: aborting due to 4 previous errors
```

That last one's span puts squiggles over the whole `for` loop in an IDE, making it hard to find the actual problem.
Repository: material-ui
Issue: Slider component crashes with marks displayed
Labels: new feature,component: slider

[ 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 😯

When rendering a slider with `marks=true`, `step=1` and a large range (`min=MIN_SAFE_INTEGER` and `max=MAX_SAFE_INTEGER`, a RangeError: Invalid array length is thrown.

## Expected Behavior 🤔
Component renders correctly

<!-- Describe what should happen. -->

## Steps to Reproduce 🕹

Steps:

1. Go to https://codesandbox.io/s/nostalgic-monad-zyq6q?file=/src/Demo.tsx:234-328
2. Error is displayed

## Context 🔦

I am trying to produce a reusable Slider component. I sent the defaults for the the min and max props to min and max safe integers.  With marks enabled, the Range Error is thrown.  If I remove the marks prop, all is OK.  To work around this I set the defaults for min and max to 0 and 100 respectively per the API.

The error occurs al line 496 in the Slider.js file:

`
  var marks = marksProp === true && step !== null ? (0, _toConsumableArray2.default)(Array(Math.floor((max - min) / step) + 1)).map(function (_, index) {
    return {
      value: min + step * index
    };
  }) : marksProp || [];
`

In particular, `Array(Math.floor((max - min) / step) + 1)` is the issue as with large numbers for min and max, an attempt is made to create an array with too many elements.

Suggested fix would be a check that the max range for an array is not exceed, something like

`
var marks;
if (Math.floor((max - min) / step) + 1 > 2**32 {
 marks = [];
} else {
// existing logic
`

## Your Environment 🌎

```
PS D:\Users\steve\Development\wom-app> npx @material-ui/envinfo
npx: installed 2 in 3.911s

  System:
    OS: Windows 10 10.0.19042
  Binaries:
    Node: 14.16.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 6.14.11 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Spartan (44.19041.906.0), Chromium (90.0.818.56)
  npmPackages:
    @material-ui/core: ^4.11.4 => 4.11.4
    @material-ui/icons: ^4.11.2 => 4.11.2
    @material-ui/lab: ^4.0.0-alpha.58 => 4.0.0-alpha.58
    @material-ui/styles:  4.11.4
    @material-ui/system:  4.11.3
    @material-ui/types:  5.1.0
    @material-ui/utils:  4.11.2
    @types/react: ^17.0.4 => 17.0.4
    react: 17.0.2 => 17.0.2
    react-dom: 17.0.2 => 17.0.2
    typescript: ^4.2.4 => 4.2.4
```
Repository: godot
Issue: Default Environment with Additive Bloom enabled. Shader goes crazy
Labels: topic:rendering,documentation,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
[3.3-stable](https://github.com/godotengine/godot/releases/tag/3.3-stable) 8e68f2e5f48c66bfa80b9bb7746a488afb70086d


**OS/device including version:**
macOS Big Sur `11.3.1`


**Issue description:**
Godot 3D env shader goes crazy when you enable additive bloom in canvas mode to the default environment. It reacts to moving your mouse and resizing the window.

![bloom_bug](https://user-images.githubusercontent.com/1355559/117584097-a2b5d600-b0bf-11eb-966f-eafb44bcd304.gif)

**Steps to reproduce:**
Run a Godot project with a `default_env.tres` with an Environment with at least these settings:
```
Background->Mode: "Canvas"
Glow->Enabled: True
Glow.Levels->Bloom: 1.0
Glow.Levels->Blend Mode: "Additive"
```


**Minimal reproduction project:**
[bloom_env_bug.zip](https://github.com/godotengine/godot/files/6448224/bloom_env_bug.zip)
Repository: rust
Issue: Document error suppression in standard stream & move upstack
Labels: T-libs-api,C-tracking-issue

## Background

This is a long-standing issue related to rust-lang/rfcs#1014 "Don't panic when stdout doesn't exist" ([rendered](https://github.com/retep998/rfcs/blob/println/0000-stdout-existential-crisis.md)), implemented in #25977

The RFC aimed to make the "convenience macros" writing to stdout/stderr not panic in case of a non-existing or closed standard stream.

## Issues

None of the convenience macros actually documents this error suppression. All of them claim that they panic on write errors which is sort-of true from their internal perspective but not really from the user's.

More annoyingly, because of the way it was implemented, not only do convenience macros not error anymore (which was intended), the error-reporting macros don't get the errors either: the actual stream was wrapped in a `Maybe` which converts `EBADF` / `ERROR_INVALID_HANDLE` to a success, as well as the stream being missing entirely (on Windows). 
 
Direct usage of `write!` or `Write` methods on standard streams would indicate a desire to be notified of and handle errors, including (and possibly especially) the standard streams being closed or full. But currently in order to get that information on Unices it's necessary to notice that this information is not delivered, and re-create the standard stream using the relevant raw fds. This is unexpected, and not exactly consistent I feel.

## Possible solution

* document the error suppression on the relevant macros
* move the error suppression outside of the stream objects
  - make a missing stream bubble up a sensible-ish synthetic error code on windows?

## Alternate solution

Don't touch anything but document the behaviour clearly on the standard stream pages.

## Aside

`EPIPE` and `ENOSPC` are somewhat oddly *not* suppressed in the same conditions, despite the logical failure and issues being similar to `EBADF` (when  writing to a closed pipe), cf #57931, #82791

## Related issues

#83904
#47271
Repository: vscode
Issue: Couldn't open two folders with almost equal names, except for capitalization on Windows via SSH
Labels: bug,remote,workbench-workspace

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
- VS Code Version: 1.56.0
- OS Version: Windows_NT x64 10.0.18363

Steps to Reproduce:

1. Create two folders with names, e.g. `test` and `Test` on a Linux machine
2. Open in VSCode from a Windows machine first folder `test` on the Linux machine via SSH
3. Open another new window of VSCode from the Windows machine . Try to connect to the Linux machine via SSH and then try to open second folder `Test` on this Linux machine. It will just redirect to the first window.

I guess the issue is related to native Windows functions, just because Windows is case insensitive.

<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Repository: rust
Issue: Add information about why a closure is inferred to be FnMut
Labels: A-diagnostics,T-compiler

Given the following code:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6a655a94cd06a72a9da17b0ebe8c7c74

```rust
use futures::stream::{self, StreamExt};

#[tokio::main]
async fn main() {
    let key1: String = "/helloa".to_string();

    dbg!(&key1);

    let futlist = stream::iter(0..10);
    let _stringvec: Vec<String> = futlist.map(move |_| {
        async {
            key1.clone()
        }
    }).buffer_unordered(10).collect::<Vec<String>>().await;
}

```

The current output is:

```
    Checking asyncinfererr v0.1.0 (/home/frederik/Programmeren/rust/asyncinfererr)
error: captured variable cannot escape `FnMut` closure body
  --> src/main.rs:11:9
   |
5  |       let key1: String = "/helloa".to_string();
   |           ---- variable defined here
...
10 |       let _stringvec: Vec<String> = futlist.map(move |_| {
   |                                                        - inferred to be a `FnMut` closure
11 | /         async {
12 | |             key1.clone()
   | |             ---- variable captured here
13 | |         }
   | |_________^ 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

error: aborting due to previous error

error: could not compile `asyncinfererr`

To learn more, run the command again with --verbose.
```
I think it would be quite nice if the user was also told why the closure was inferred to be FnMut. It may not be possible to suggest to the user that they should remove the move to solve this problem, because that might not align with what they want to accomplish, but I think that informing them of that the move keyword caused the closure to be inferred as FnMut would be quite helpful.
Repository: pytorch
Issue: [JIT] provide a pass for alias reduction
Labels: oncall: jit

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
PyTorch has operators that create tensor views for buffer sharing. We'd like to have a JIT pass that can replace these alias operators with functional equivalents that do not have the alias semantics when it is possible, like what PyTorch already has for [mutation_revomal](https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/remove_mutation.h).

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->
We are working on the integration with [oneDNN Graph](https://github.com/pytorch/pytorch/issues/49444) which only has pure functional operators. As a result, there are semantics gaps between PyTorch operators and oneDNN Graph operators. We'd like to reduce the alias and mutation with best effort so that oneDNN Graph could get a more complete graph instead of a series of sub-graphs, as a result it is able to do fusion on the complete graph.
For example in bert, we have this pattern:
```
                     aten::linear
                              |
aten::linear           aten::view
       |                      |
aten::view          aten::permute
       |                      |
aten::permute     aten::transpose       
           \           /
           aten::matmul
```
Since oneDNN Graph does not have the operators with alias semantics, we could not pass this complete pattern to it, thus we lose the chance to fuse this whole pattern into one operator.

## Pitch

<!-- A clear and concise description of what you want to happen. -->
We'd like to have a JIT pass that removes alias with equivalent copying operators that oneDNN invokes.

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->
None
## Additional context

<!-- Add any other context or screenshots about the feature request here. -->
None

cc @jgong5
Repository: go
Issue: cmd/compile: only use sequential compile queue algorithm for -v compiles, not all -c=1 compiles
Labels: NeedsFix,compiler/runtime

The other day I was seeing issues with "toolstash -cmp" failing because compiler output seemed non-deterministic. I submitted golang.org/cl/318229 to change non-concurrent builds to have a deterministic order, on the assumption that concurrent builds are expected to have non-deterministic output. But @josharian points out that's not the case.

However, I can no longer immediately reproduce the non-determinism issue, even with high -c values.

This is a tracking issue to check that with all the compiler refactoring this cycle we haven't broken deterministic output.

/cc @randall77 @cuonglm
Repository: godot
Issue: Manual Process Animation Tree not updating Player
Labels: bug,topic:animation

**Godot version:**
Godot 3.2.3 stable


**OS/device including version:**
Windows 10
CPU: 
GPU: GeForce GTX 1650
GLES3



**Issue description:**
Animation Trees process mode set to manual does not update its Animation Player immediately when advanced.
If an Animation Player's process mode used is IDLE or PHYSICS its animation at least with sprites is always one frame behind. By using MANUAL and advancing in script this doesn't happen. However the problem returns if the Animation Player is connected to an Animation Tree. Regardless of the Animation Tree's process mode MANUAL, IDLE or PHYSICS it is always one frame behind which makes the animation out of sync with the character. When jumping they appear to 'stand' in the air for a frame.
I recorded and pulled frames to demonstrate this:
The character on the left uses an Animation Tree and Animation Player
The character on the right uses just an Animation Player
Both are set to MANUAL process mode and advanced through code and use the same physics code only their animation code differs.
![Godot_Frames](https://user-images.githubusercontent.com/17762781/117608002-89d12180-b1a0-11eb-87b6-68ece8ffdea1.png)

**Steps to reproduce:**
Run sample project and press up arrow key to jump. Note that the left hand characters animation is one frame behind. This is quite hard to see but is noticeable.
[Sprite_Lag.zip](https://github.com/godotengine/godot/files/6449554/Sprite_Lag.zip)
Repository: create-react-app
Issue: failed to compile 
Labels: needs triage

just created react app by command "create-react-app" but when I used command "npm start" it shows this error... please help
![Screenshot 2021-05-10 104603](https://user-images.githubusercontent.com/83941205/117613135-d48e7180-b17f-11eb-9aba-eae030d96672.jpg)