sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Permutation of Sparse Tensor
Labels: module: sparse,triaged

### 🚀 The feature, motivation and pitch

I'm working with COO sparse tensors and would like to get a permutation of any COO sparse tensor.
In the current version, `torch.permute` throws the following error:
`RuntimeError: sparse tensors do not have strides`
Also, in-place modification of indices is not possible.

### Alternatives

I have considered the following solution (it wouldn't be the same as `torch.permute` since this one returns a view of the original tensor):

`torch.permute_sparse(input, dims) → Tensor`
Returns a copy of the original tensor input with its dimensions permuted.
- **input** (_Tensor_) – the input tensor.
- **dims** (_tuple of python:ints_) – The desired ordering of dimensions

The source code:
```
def permute_sparse(input, dims):
    dims = torch.LongTensor(dims)
    return torch.sparse_coo_tensor(indices=input._indices()[dims], values=input._values(), size=torch.Size(torch.tensor(input.size())[dims]))
```

An example:
```
>>> indices = torch.tensor([[1, 1],
                            [2, 1],
                            [1, 0],
                            [3, 3]])
>>> values = torch.tensor([ 1, -1])
>>> s = torch.sparse_coo_tensor(indices=indices, values=values, size=(2, 3, 4, 5))
>>> s.size()
torch.Size([2, 3, 4, 5])
>>> permute_sparse(s, (3, 2, 0, 1)).size()
torch.Size([5, 4, 2, 3])
```

### Additional context

_No response_

cc @nikitaved @pearu @cpuhrsch @amjames
Repository: next.js
Issue: Fast Refresh crashes with "TypeError: Component is not a function" when wrapping in memo
Labels: bug,Webpack

### Verify canary release

- [X] I verified that the issue exists in Next.js canary release

### Provide environment information

   Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.14.2
      npm: 8.5.0
      Yarn: 1.22.15
      pnpm: 6.11.0
    Relevant packages:
      next: 12.1.7-canary.11
      react: 0.0.0-experimental-82c64e1a4-20220520
      react-dom: 0.0.0-experimental-82c64e1a4-20220520

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_

### Describe the Bug

Start with code like

```js
export function Test() { 
  return <h1>hi</h1>
}
```

Save the file. Import it from another component.

Then edit it to:

```js
import { memo } from 'react';

export const Test = memo(function Test() { 
  return <h1>hi</h1>
});
```

You get:

```
Unhandled Runtime Error
TypeError: Component is not a function
```

But instead the module should invalidate and Fast Refresh should work. 

### Expected Behavior

No crash, Fast Refresh works.

### To Reproduce

Described above.
Repository: godot
Issue: MacOS crash with backtrace when toggling node visibility
Labels: bug,topic:editor,crash,regression

### Godot version

3.5.rc2

### System information

MacOS 12.2 M1

### Issue description

Happened once also in 3.5.rc1 - See https://github.com/godotengine/godot/issues/61199

Project crash while running after toggling node visibility in editor.

```
 handle_crash: Program crashed with signal 11
 Engine version: Godot Engine v3.5.rc.custom_build
 Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
 [1] 1   libsystem_platform.dylib            0x00000001913144e4 _sigtramp + 56
 [2] GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Variant::CallError&, GDScriptFunction::CallState*) (in Godot) (gdscript_function.cpp:0)
 [3] Object::call(StringName const&, Variant const**, int, Variant::CallError&) (in Godot) (object.cpp:899)
 [4] _Thread::_start_func(void*) (in Godot) (core_bind.cpp:2715)
 [5] Thread::callback(Thread*, Thread::Settings const&, void (*)(void*), void*) (in Godot) (thread.cpp:79)
 [6] void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(Thread*, Thread::Settings const&, void (*)(void*), void*), Thread*, Thread::Settings, void (*)(void*), void*> >(void*) (in Godot) (thread:299)
 [7] 7   libsystem_pthread.dylib             0x00000001912fd240 _pthread_start + 148
```

### Steps to reproduce

Not able to reproduce

### Minimal reproduction project

_No response_
Repository: rust
Issue: `Scrt1.o: contains a compressed section, but zlib is not available` with `rust-lld`, `*-musl` toolchain & `-C target-feature=-crt-static`
Labels: A-linkage,O-musl,C-bug,A-target-feature

<!--
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.
-->

Here's a minimal reproducible example:

```dockerfile
FROM rust:1.61-alpine

RUN mv $RUSTUP_HOME/toolchains/*/lib/rustlib/*/bin/rust-lld /bin/ld.lld
ENV RUSTFLAGS="-C target-feature=-crt-static -C link-arg=-fuse-ld=lld"
RUN set -eux; \
    cargo new hello; \
    cd hello; \
    cargo run

```

I expected it to build a docker image successfully.
Instead, this happened:

```
  = note: ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/Scrt1.o: contains a compressed section, but zlib is not available
          ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/Scrt1.o: contains a compressed section, but zlib is not available
          ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/Scrt1.o: contains a compressed section, but zlib is not available
          ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/Scrt1.o: contains a compressed section, but zlib is not available
          ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/Scrt1.o: contains a compressed section, but zlib is not available
          ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/crti.o: contains a compressed section, but zlib is not available
          ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/crti.o: contains a compressed section, but zlib is not available
          ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/crtn.o: contains a compressed section, but zlib is not available
          ld.lld: error: /usr/lib/gcc/x86_64-alpine-linux-musl/10.3.1/../../../../lib/crtn.o: contains a compressed section, but zlib is not available
          collect2: error: ld returned 1 exit status
```

For some reason, `rust-lld` and `librustc-driver-*.so` are statically linked on `musl` targets. I suspect this causes such an odd behavior.
I need `-C target-feature=-crt-static` to make `*-sys` correctly link dynamic libraries.
Repository: create-react-app
Issue: Can't Scaffold TypeScript Project Anymore...
Labels: needs triage,issue: bug report

When I run the command:
```
npx create-react-app cra-example-app --template typescript
```

it ends with this strange message and creates a js project that doesn't seem to build...
```

The react-scripts version you're using is not compatible with the --template option.

Installing react, react-dom, and react-scripts...


```
Repository: godot
Issue: No vertex array was bound and render pipeline expects vertices after using meshDataTool to edit vertex data
Labels: bug,topic:rendering

### Godot version

4.0 Alpha 7

### System information

Windows 10 Nvidia GTX 1060 Intel i5 4690k

### Issue description

I attempted to move vertex data from one mesh to another using MeshDataTool.
Specifically, I was attempting to move bone and weight data between the two meshes.

I used this script

```
@tool
extends Node
@export var initial_mesh_path : NodePath
@export var target_mesh_path : NodePath
var initial_mesh : MeshInstance3D
var target_mesh : MeshInstance3D
@export var attempt : bool = false:
	set(value):
		if value and initial_mesh_path != NodePath("") and target_mesh_path!= NodePath(""):
			initial_mesh = get_node(initial_mesh_path)
			target_mesh = get_node(target_mesh_path)
			var target_data :ArrayMesh = target_mesh.mesh#.surface_get_arrays(0)
			var initial_data :ArrayMesh= initial_mesh.mesh#.surface_get_arrays(0)
			var mdt_target :MeshDataTool = MeshDataTool.new()
			var mdt_initial:MeshDataTool = MeshDataTool.new()
			mdt_target.create_from_surface(target_data,0)
			mdt_initial.create_from_surface(initial_data,0)
			#If this works...
				#Test some form of sorting in regards to positional data?
			for i in range(mdt_target.get_vertex_count()):
				var target_vertex:Vector3 = mdt_target.get_vertex(i)
				for k in range(mdt_initial.get_vertex_count()):
					var initial_vertex : Vector3 = mdt_initial.get_vertex(k)
					#print(target_vertex.distance_to(initial_vertex))
					if target_vertex.distance_to(initial_vertex) < 0.000001:
						mdt_target.set_vertex_bones(i,mdt_initial.get_vertex_bones(k))
						#append?
						mdt_target.set_vertex_weights(i,mdt_initial.get_vertex_weights(k))
						continue
			mdt_target.surface_remove(0)
			mdt_target.commit_to_surface(target_data)
```

After use, the mesh works fine, except that in the console, 
![Untitled-1](https://user-images.githubusercontent.com/83078010/170767843-e605c148-7678-4800-bcf3-e0a45dee9379.png)

The error --> No vertex array was bound, and render pipeline expects vertices.

Simply by running the reproduction project, you can see that the mesh exists and works, however the console gets flooded with errors

The errors only appear when the mesh is visible on screen, so if you switch to the script editor, there is not an issue

### Steps to reproduce

1. Run the reproduction project
2. See the error


In terms of reproduction manually, I am not sure what is the cause, but I do know that using the given script with two meshes will result in a mesh that produces the above error. However, most reliable source comes from the reproduction project

### Minimal reproduction project
[RenderBug.zip](https://github.com/godotengine/godot/files/8788990/RenderBug.zip)
Repository: flutter
Issue: [plugins] consistent exception API across platforms for all plugins
Labels: team,package,c: proposal,team-ecosystem,P2,triaged-ecosystem

## Use case

consistent exception handling across platforms for all plugins

## Proposal

This is a follow up issue for the [camera privacy proposal](https://docs.google.com/document/d/1t_5FYzOTlBWC6arHc4_8VuG0BUOtIyP9xWvbDER5Y9I/edit) that proposes to provide consistent permission failure API across platforms. In my presentation @stuartmorgan pointed out that we should do the same for not just the camera permission exceptions, but also other exceptions, and for other plugins as well. 

CC @stuartmorgan @ditman @jmagman @cyanglaz @blasten @camsim99
Repository: go
Issue: cmd/objdump: confusing disassembly of arm64 BL instruction
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.18.2 linux/arm64
</pre>

This also happens in bazel with go version 1.17.6.

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/parallels/.cache/go-build"
GOENV="/home/parallels/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/parallels/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/parallels/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.18.2"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/parallels/gvisor/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build4026508879=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Ran `go tool objdump` on a binary.

### What did you expect to see?

There are many lines that look like:
```
  iptables.go:320       0x211214                97f9b198                CALL -413288(PC)
```
However, the offset displayed should be -1653152. Objdump appears to be incorrectly parsing the offset from the instruction `0x97f9b198`.

### What did you see instead?

-413288. This is because the 2 trailing 0 bits described by the [arm documentation](https://developer.arm.com/documentation/ddi0596/2020-12/Base-Instructions/BL--Branch-with-Link-?lang=en) appear not to be accounted for.
Repository: rust
Issue: Substantial debug-test-optimized-depedencies Performance Regression in 1.59
Labels: I-slow,P-medium,T-compiler,regression-from-stable-to-stable,C-bug,E-needs-bisection,E-needs-mcve

We were trying to change our Cargo.toml to

```
[profile.dev.package."*"]
opt-level = 2
```

to get opt on our dependencies during test but not on the crate being tested. In rustc 1.58.1, this is a performance improvement in the generated test suite. On rustc 1.59.0 this is a very substantial regression in total runtime of tests (~2 minutes CPU time on 1.58.1 to 18 minutes CPU time, not including compile time). This effect is robust with different opt-levels (swapping the 1s and 2s above) and between Debian rustc and rustup rustc. 

The increase in CPU time seems to almost all be in `std`/`core`, perf on the regressed binary for a single test (similar results for all tests) shows the following, but `core` itself doesn't show up at all in perf on 1.58.1.

```
+   26.40%    24.37%  ln::functional_  lightning-8c1dd3bce02d4ddc   [.] core::ptr::mut_ptr::<impl *mut T>::is_null
+   25.79%    23.79%  ln::functional_  lightning-8c1dd3bce02d4ddc   [.] <core::slice::iter::IterMut<T> as core::iter::traits::iterator::Iterator>::next
+   23.12%    21.85%  ln::functional_  lightning-8c1dd3bce02d4ddc   [.] core::ptr::mut_ptr::<impl *mut T>::guaranteed_eq
+   11.31%    10.16%  ln::functional_  lightning-8c1dd3bce02d4ddc   [.] std::io::readbuf::ReadBuf::initialize_unfilled_to
+    9.80%     6.16%  ln::functional_  lightning-8c1dd3bce02d4ddc   [.] core::ptr::non_null::NonNull<T>::as_ptr
+    8.65%     6.89%  ln::functional_  lightning-8c1dd3bce02d4ddc   [.] core::ptr::metadata::from_raw_parts_mut
+    2.46%     2.45%  ln::functional_  lightning-8c1dd3bce02d4ddc   [.] core::ptr::non_null::NonNull<T>::new_unchecked
```

This effect is also robust against `-Zbuild-std=panic_abort ` (and `ps aux` confirms that `core` is getting built with `opt-level=2`) and even `RUSTFLAGS="-C prefer-dynamic"` (which `ldd` confirms dynamically links libstd+libtest).

The PR to do this on our repo is at https://github.com/lightningdevkit/rust-lightning/pull/1497 which you should be able to simply check out locally and `cargo test` with 1.58 and 1.59 (well, run it twice to skip the compile part of the test) to see the regression. Specific numbers at https://github.com/rust-lang/rust/issues/97460#issuecomment-1140042374.

For those reading the comments there was some confusion about the cargo 1.57 change on the test profile, you can skip to https://github.com/rust-lang/rust/issues/97460#issuecomment-1140042374

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged
Repository: create-react-app
Issue: Upgrade jest to v28 so that sharding is available.
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

The more tests the slower jest runs.

### Describe the solution you'd like

Upgrade to jest v28 so sharding will be available.

### Describe alternatives you've considered

I don't have an alternative in mind.

### Additional context

Some links

https://medium.com/@mfreundlich1/speed-up-your-jest-tests-with-shards-776e9f02f637
https://jestjs.io/blog/2022/04/25/jest-28
Repository: material-ui
Issue: [TextField] Notched, outlined label incorrect when using InputLabelProps to override `required` prop
Labels: support: question

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

We have a form with all required fields. We would like to remove the `*` added to required fields as it is redundant when all fields are required. However, we still want to leverage the native HTML validation on input elements. 

In sum, we'd like to set `required={true}` on `TextInput` (and others), but *not* render an asterisk in the label.

This is almost achievable by passing `InputLabelProp={{required: false}}`. However, for outlined inputs, the notch is still rendered as if the asterisk is present.

<img width="672" alt="Screen Shot 2022-05-27 at 12 11 29 PM" src="https://user-images.githubusercontent.com/126461/170775831-51d2c070-53b2-4ac9-8492-f4840a14df11.png">

(Repro: https://codesandbox.io/s/elated-lewin-oge4dl?file=/index.js)

Note the extra space next to the label.

### Expected behavior 🤔

Ideally, if `InputLabelProps={{required: false}}` is set, the notched label would not render the extra space where the asterisk would be:

<img width="508" alt="Screen Shot 2022-05-27 at 12 16 31 PM" src="https://user-images.githubusercontent.com/126461/170776173-3951e617-fc8a-4f05-9cb4-56a9b120f455.png">



### Steps to reproduce 🕹

Steps:

1. Create a `TextField` with props `required={true}` and `InputLabelProps={{required: false}}`
2. Note the extra space in the label

https://codesandbox.io/s/elated-lewin-oge4dl?file=/index.js


### Context 🔦

I think a broader ability to customize the asterisk rendered on labels for required inputs is most desirable. 

### Your environment 🌎

<details>
  <summary>`npx @mui/envinfo`</summary>

```
  System:
    OS: macOS 12.3.1
  Binaries:
    Node: 16.13.2 - ~/.nvm/versions/node/v16.13.2/bin/node
    Yarn: 1.22.15 - ~/.nvm/versions/node/v16.13.2/bin/yarn
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.2/bin/npm
  Browsers:
    Chrome: 101.0.4951.64
    Edge: Not Found
    Firefox: 98.0.1
    Safari: 15.4
```
</details>
Repository: youtube-dl
Issue: Afreecatv not working
Labels: broken-IE,pending-fixes


## Checklist


- [x ] I'm reporting a broken site support
- [ ] I've verified that I'm running youtube-dl version **2021.12.17**
- [ ] I've checked that all provided URLs are alive and playable in a browser
- [ ] I've checked that all URLs and arguments with special characters are properly quoted or escaped
- [ ] I've searched the bugtracker for similar issues including closed ones


## Verbose log



C:\Users\Owner\Downloads>youtube-dl https://vod.afreecatv.com/player/87524568
[generic] 87524568: Requesting header
WARNING: Falling back on generic information extractor.
[generic] 87524568: Downloading webpage
[generic] 87524568: Extracting information
ERROR: Unsupported URL: https://vod.afreecatv.com/player/87524568

C:\Users\Owner\Downloads>youtube-dl https://vod.afreecatv.com/player/87524568 -v
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['https://vod.afreecatv.com/player/87524568', '-v']
[debug] Encodings: locale cp1252, fs mbcs, out cp437, pref cp1252
[debug] youtube-dl version 2021.12.17
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.19041
[debug] exe versions: none
[debug] Proxy map: {}
[generic] 87524568: Requesting header
WARNING: Falling back on generic information extractor.
[generic] 87524568: Downloading webpage
[generic] 87524568: Extracting information
ERROR: Unsupported URL: https://vod.afreecatv.com/player/87524568
Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 815, in wrapper
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 836, in __extract_info
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\common.py", line 534, in extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\generic.py", line 3489, in _real_extract
youtube_dl.utils.UnsupportedError: Unsupported URL: https://vod.afreecatv.com/player/87524568


## Description

Trying to download videos from afreecatv is not working at this time.
Repository: flutter
Issue: Clipboard dartdoc should have some hints on how to support it in tests
Labels: a: tests,a: text input,framework,d: api docs,customer: google,P2,team-framework,triaged-framework

Using the Clipboard APIs directly in widget tests can result in confusion since the platform channel calls are just dropped on the floor. The dartdoc https://api.flutter.dev/flutter/services/Clipboard-class.html could leave more breadcrumbs on what to do there. 

Such as a hint to consider using MockClipboard from https://github.com/flutter/flutter/blob/master/packages/flutter/test/widgets/clipboard_utils.dart and testing it like https://github.com/flutter/flutter/blob/master/packages/flutter/test/material/text_form_field_test.dart#L19.
Repository: pytorch
Issue: `index_fill` will trigger INTERNAL ASSERT when float tensor requiring grad + int tensor
Labels: module: autograd,triaged,actionable

### 🐛 Describe the bug

`index_fill` will trigger INTERNAL ASSERT when float tensor requiring grad + int tensor

```python
import torch
value = torch.rand([], dtype=torch.float64, requires_grad=True)

input = torch.randint(-2, 8, [], dtype=torch.int64)
index = torch.randint(-1, 1, [], dtype=torch.int64)
dim = 0
input.index_fill(dim, index, value)
# RuntimeError: isDifferentiableType(variable.scalar_type())INTERNAL ASSERT FAILED at "/Users/distiller/project/pytorch/torch/csrc/autograd/functions/utils.h":65, please report a bug to PyTorch. 
```

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: pytorch
Issue: `layer_norm` triggers INTERNAL ASSERT with input requiring grad + zero-size int tensor
Labels: module: autograd,triaged,actionable

### 🐛 Describe the bug

`layer_norm` triggers INTERNAL ASSERT with input requiring grad + zero-size int tensor

```python
import torch

input = torch.randint(0, 8, [0, 0, 1024], dtype=torch.int64)
normalized_shape = [1024]
eps = 1e-05

weight = torch.rand([1024], dtype=torch.float64, requires_grad=True)
bias = torch.rand([1024], dtype=torch.float64, requires_grad=True)
torch.nn.functional.layer_norm(input, normalized_shape, weight=weight, bias=bias, eps=eps, )
# RuntimeError: isDifferentiableType(variable.scalar_type())INTERNAL ASSERT FAILED at "/Users/distiller/project/pytorch/torch/csrc/autograd/functions/utils.h":65, please report a bug to PyTorch
```

`layer_norm` does check the dtype of zero-size tensor, like `input` in this example. If `input` is not zero-size, it will raise an error that `RuntimeError: "LayerNormKernelImpl" not implemented for 'Long'`

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7