sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking issue for deprecation lint `legacy_derive_helpers`
Labels: A-lints,A-macros,T-compiler,C-tracking-issue,S-tracking-ready-to-stabilize

This is a tracking issue for deprecating code like this:

```rust
#[trait_helper] // This helper attribute is used before it introduced by `#[derive(Trait)]` below.
#[derive(Trait)]
struct S;
```

Code like this works for historical reasons, but attribute expansion works in left-to-right order, so we have to use some hacks and "look into the future" to resolve `trait_helper`, but that future may never actually happen in cases like
```rust
#[trait_helper]
#[remove_all_derives] // removes the `#[derive(Trait)]` below
#[derive(Trait)]
struct S;
```
, so the resolution in this case is unreliable.

A deprecation lint for this case is added in https://github.com/rust-lang/rust/pull/79078 as warn-by-default.
Repository: flutter
Issue: Provide ability to create children of ExpansionTile by scroll
Labels: c: new feature,framework,f: material design,team-design,triaged-design

Provide ability to create children of ExpansionTile by scroll instead of creating all of them when initialize ExpansionTile. Currently, ExpansionTile accepts list of widgets as children, but when there are a lot of items in one sections it took some time and therefore list is choppy (jumpy) when scroll. It would be great to have something like childrenBuilder (similar to builder from ListView.builder()) which will create widgets only when we need them
Repository: flutter
Issue: MacOS Only use compositor in rasterizer.cc after smooth resizing is support
Labels: engine,platform-mac,a: desktop,P3,team-macos,triaged-macos

Currently on MacOS, FlutterMacOSGLCompositor does not support resizing.
Because of this, any app that has a platform view will default to use the current code path (to prevent regressions for resizing) and the compositor will be used only when there is a platform view.

Once the compositor supports smooth resizing, remove the extra branching logic in rasterizer.cc to avoid using the external view embedder when there is no platform view.

Additionally the `HasPlatformView` method can be removed from layer_tree.h and layer.h and the `SetRenderToSurface` method can be removed from `surface.h`
Repository: rust
Issue: Diagnostics Improvement: Same Body in Branches
Labels: A-lints,T-lang,C-bug,A-control-flow

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
#[derive(PartialEq, Eq, Debug)]
struct SortedEdge {
    a: usize,
    b: usize,
}

impl SortedEdge {
    fn new(a: usize, b: usize) -> SortedEdge {
        if b > a {
            SortedEdge { a, b }
        } else {
            // uh oh!
            // We really want:
            //   SortedEdge { a: b, b: a }
            SortedEdge { b, a }
        }
    }
}

fn main() {
    let x = SortedEdge::new(1, 2);
    let y = SortedEdge::new(2, 1);
    
    // The points should be equal after sorting indicies
    assert_eq!(x, y);
}
```

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=cc7599a28cfe7dd105f3f4d609c47b47

I expected to see this happen:

A compiler warning/diagnostic that both of my branches were equivalent.

Instead, this happened:

No warning was emitted

### 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.
-->

This happens on Rust 1.47.0 stable and Rust nightly 2020-11-18

CC @estebank, and the related discussion [on twitter](https://twitter.com/bitshiftmask/status/1329469548966408193)
Repository: go
Issue: proposal: internal/cpu, crypto/aes: support VAES and VPCLMULQDQ instructions in AES-GCM cipher functions
Labels: Performance,Proposal,NeedsInvestigation,FeatureRequest,Proposal-Crypto

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version 1.15.5 linux/amd64

</pre>

### Does this issue reproduce with the latest release? 
yes

### What operating system and processor architecture are you using (`go env`)? amd64 linux

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
amd64 linux
</pre></details>

### What did you do?
This is a request/proposal for two new features:
1. In internal/cpu:  detect CPU support for AVX-512 VAES and VPCLMULQDQ SIMD instructions
2. In crypto/aes: performance-optimize the AES-GCM cipher functions using VAES and VPCLMULQDQ instructions
<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->



### What did you expect to see?
in src/crypto/aes/gcm_amd64.s, the request is to support new AVX-512 SIMD crypto instructions VAES and VPCLMULQDQ.


### What did you see instead?
in src/crypto/aes/gcm_amd64.s currently there is existing support only for the scalar AES and PCLMULQDQ instructions

We have developed proposed patches for go v1.15.5 as follows:
1) internal/cpu:  check the cpu registers for presence of VAES and VPCLMULQDQ, set flags accordingly
2) crypto/aes:  performance-optimize AES-GCM using these instructions 

The patches will be contributed and submitted to the Go Gerrit for review. 

References:
1.  https://www.tomshardware.com/news/intel-10nm-xeon-ice-lake-sp-sunny-cove-core-architecture
2.  https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
Repository: go
Issue: x/net/ipv4: calling SetTOS doesn't work on Windows
Labels: OS-Windows,NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.5 darwin/amd64
</pre>

### 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="amd64"
GOBIN=""
GOCACHE="/Users/jfl/Library/Caches/go-build"
GOENV="/Users/jfl/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/jfl/.gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jfl/.gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/yt/fs5f0tjj0w1bj2md7j4r5t2c0000gn/T/go-build812979714=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

I try to use the `ipv4.Conn.SetTOS()` function on Windows. It works well on Mac OS but it silently fail on Windows (no error and no TOS marking). Should it work on Windows? No bugs about it listed on https://godoc.org/golang.org/x/net/ipv4#pkg-note-bug.

To reproduce:

```
package main

import (
	"fmt"
	"net"

	"golang.org/x/net/ipv4"
)

func main() {
	raddr, err := net.ResolveUDPAddr("udp", "8.8.8.8:12345")
	if err != nil {
		panic(err)
	}
	c, err := net.DialUDP("udp", nil, raddr)
	if err != nil {
		panic(err)
	}

	nc := ipv4.NewConn(c)
	if err := nc.SetTOS(184); err != nil {
		panic(err)
	}
	tos, err := nc.TOS()
	if err != nil {
		panic(err)
	}
	fmt.Printf("ToS is %d\n", tos)

	_, err = c.Write([]byte("Test1234"))
	if err != nil {
		panic(err)
	}
}
```

### What did you expect to see?

Outbound packet with the ToS field set to 184 (0xb8, DSCP EF).


### What did you see instead?

ToS is 0x0 on Windows. It is 0xb8 on MacOS.
Repository: godot
Issue: [macOS] Using viewport transform in editor behaves differently in 3.2.3
Labels: platform:macos,topic:editor,confirmed,regression

**Godot version:**
3.2.2 stable / 3.2.3 stable


**OS/device including version:**
Retina MacBook Pro 2015
macOS Mojave


**Issue description:**
I can't seem to achieve the same behavior and display scaling in 3.2.3 that I had in 3.2.2. Particularly, behavior related to a tool script that uses get_viewport_transform to move a node along with the viewport:

```
func _process(delta):
	position.y = -get_viewport_transform()[2].y + 320
```

I use Godot on my LG 4k display which is set scaled in system preferences to "2048 x 1152 (low resolution)" mode. Now with 3.2.2 I was running Godot on this monitor with Godot display scale set to 100%, and everything looked the way I wanted. Here is what that looks like, with the above tool snippet on the sprite (sorry for poor quality). Note how the sprite stays in the same relative position in the viewport:


![3 2 2 100% LG](https://user-images.githubusercontent.com/33777501/99715303-82d01e80-2a5b-11eb-9818-f5fbfe67b6c9.gif)


In 3.2.3 with the same settings (100% editor scale), scrolling is correct but everything is too small:

![3 2 3 100% LG](https://user-images.githubusercontent.com/33777501/99716289-c5dec180-2a5c-11eb-94f8-27c5769224b2.gif)


At 200% display scale, things are the size I want, but now the sprite scrolls twice as fast as it should:

![3 2 3 200% LG](https://user-images.githubusercontent.com/33777501/99716998-a3997380-2a5d-11eb-8422-0376583242ef.gif)

Perhaps worth noting that if I use Godot on my MacBook display (running in default display mode), I cannot get the desired behavior, regardless of settings or version. So the only way it's "correct" is on scaled 4k LG display with Godot 3.2.2 at 100%.

I don't know what might have been the relevant change, but whether this was a bug or a bug fix, the previous behavior was useful to me. Is there some setting I can use? I don't even know how the new "Hidpi mode" in 3.2.3 is supposed to work, it's very unclear since you can set it to any number and there's no description.

**Steps to reproduce:**
I'm not sure exactly, see above.

**Minimal reproduction project:**
Here is the simple project shown above
[DisplayScaleViewportIssue.zip](https://github.com/godotengine/godot/files/5569396/DisplayScaleViewportIssue.zip)
Repository: pytorch
Issue: torch.multinomial example is incorrect
Labels: module: distributions,module: docs,triaged

## 📚 Documentation
The [`torch.multinomial` documentation page](https://pytorch.org/docs/stable/generated/torch.multinomial.html) has an example that seems out-of-date or just wrong 🤷‍♂️ 

> ```
> >>> weights = torch.tensor([0, 10, 3, 0], dtype=torch.float) # create a tensor of weights
> >>> torch.multinomial(weights, 2)
> tensor([1, 2])
> >>> torch.multinomial(weights, 4) # ERROR!
> RuntimeError: invalid argument 2: invalid multinomial distribution (with replacement=False,
> not enough non-negative category to sample) at ../aten/src/TH/generic/THTensorRandom.cpp:320
> >>> torch.multinomial(weights, 4, replacement=True)
> tensor([ 2,  1,  1,  1])
> ```

Here is a link to the example in the code
https://github.com/pytorch/pytorch/blob/8819bad86cd15c74dd076012c59e7b1f6081fda4/torch/_torch_docs.py#L5588-L5597

The example seems to contradict the note that says
> The rows of input...must be non-negative, finite and have a non-zero sum.

I am fairly sure that 0 is non-negative and finite, so as long as there are other positive inputs in the input tensor (to satisfy the non-zero sum requirement), it should work.

Here is the output that I see when I run the example code in Google Colab.

```python
>>> weights = torch.tensor([0, 10, 3, 0], dtype=torch.float) # create a tensor of weights
>>> torch.multinomial(weights, 2)
tensor([1, 2])
>>> torch.multinomial(weights, 4)
tensor([2, 1, 0, 3])
>>> torch.multinomial(weights, 4, replacement=True)
tensor([2, 1, 1, 2])
```

I think it is also worth noting that the example shows the following runtime error
> `invalid multinomial distribution (with replacement=False, not enough non-negative category to sample)`

Which gives me the impression that you can have negative numbers in the input tensor, and it just will not sample them. This is **not** the case, however. Note the observed runtime error when I change the 0's in the weight tensor to -1's:
```python
>>> weights = torch.tensor([-1, 10, 3, -1], dtype=torch.float)
>>> torch.multinomial(weights, 2)
RuntimeError: probability tensor contains either `inf`, `nan` or element < 0
```

And just for the sake of being thorough, this is the runtime error that shows up when you try to take too many samples:
```python
>>> weights = torch.tensor([0, 10, 3, 0], dtype=torch.float) # create a tensor of weights
>>> torch.multinomial(weights, 5)
RuntimeError: cannot sample n_sample > prob_dist.size(-1) samples without replacement
>>> torch.multinomial(weights, 5, replacement=True)
tensor([1, 2, 1, 1, 2])
```

cc @fritzo @neerajprad @alicanb @vishwakftw @nikitaved @jlin27 @mruberry
Repository: flutter
Issue: New Google app doesn't appear to support high refresh screens on Android
Labels: engine,c: performance,customer: money (g3),P2,team-engine,triaged-engine

https://b.corp.google.com/issues/173709150.
Repository: godot
Issue: Spinbox does not consider key inputs as handled while it did
Labels: bug,topic:input,topic:gui

Hello, I encountered an issue that seems logical but that in my opinion should be handled.

**Godot version:**
3.2.3.stable


**OS/device including version:**
OS : Linux Mint 20
Linux linux-mint 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux



**Issue description:**
I have multiple Controls and among them a Spinbox.

I want my controls to consume inputs before my game receive them so my Input handler uses the function `_unhandled_input` to process them after the controls had the opportunity to handle them as describe here : https://docs.godotengine.org/en/stable/_images/input_event_flow.png.

It works with all my controls except for the Spinbox.
When I use the keyboard in order to change the Spinbox's value (which works), the key inputs are not considered as handled and thus my game processes them while it shouldn't as they have already been handled.

It seems like the `pressed` events are handled but not the releases.

**Steps to reproduce:**
- Create a scene with a Spinbox.
- Adds this script :
```gdscript
extends Node2D


func _unhandled_input(event):
	if event is InputEventKey:
		if event.pressed:
			print("Pressed")
		else:
			print("Released")

```
- Run the scene.
- Press a key.
- Click on the Spinbox and press the same key.
- You should see an output in the console, confirming the input has not been fully considered handled by the Spinbox.

**Proposed solution:**
Consider the InputKeyEvents as handled as long as the Spinbox has the focus.

Thank you for your consideration,
Luc.
Repository: flutter
Issue: RenderObjects of WidgetSpan.child not scaled according to textScaleFactor
Labels: framework,a: typography,d: devtools,has reproducible steps,P2,found in release: 3.7,found in release: 3.9,team-framework,triaged-framework

In the code below, it seems that the `RenderObject` associated with the child of a `WidgetSpan` is not getting rescaled according to `textScaleFactor`. The blue `Container` is in a `WidgetSpan` in a `Text.rich` with `textScaleFactor: 2.0`, but look where the DevTools widget inspector thinks the `Container` is: completely unscaled. (The tooltip and outlined square are from DevTools.)

The way I came across this bug in production is when obtaining the size and position of the `WidgetSpan.child` using `context.findRenderObject()`: the scaling done by `Text.rich`/`WidgetSpan` is not taken into account.

![WidgetSpan_scaling](https://user-images.githubusercontent.com/66305960/99709540-9a30fb00-2a9f-11eb-8dd8-8837e08ce940.png)

```dart
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Directionality(
          textDirection: TextDirection.ltr,
          child: Container(
            color: Colors.white,
            alignment: Alignment.center,
            child: Container(
              color: Colors.green,
              child: Text.rich(
                TextSpan(
                  children: [
                    TextSpan(text: "Unscaled"),
                    WidgetSpan(
                      child: Container(width: 40, height: 40, color: Colors.blue),
                    ),
                    TextSpan(text: "RenderObject?"),
                  ],
                ),
                textScaleFactor: 2.0,
              ),
            ),
          ),
        ),
      ),
    );
  }
}
```

The expected behaviour is that the underlying `RenderBox` should point to the full `Container`.

(Originally asked as comment:
https://github.com/flutter/flutter/issues/69835#issuecomment-730566330_)
Repository: flutter
Issue: High identity matrix allocation in web engine.
Labels: team,engine,platform-web,P2,team-web,triaged-web

There are several optional parameters in shaders and other engine code that allocate identity matrices.

To optimize:
1- Use a const matrix, to protect against mutation down the line, add assert isIdentical.
2- On the web Matrix4.zero().setIdentity is used which is wasteful since Float32List(s) are initialized by default.
Repository: godot
Issue: Rainbow sparks in the Visual Script editor
Labels: bug,topic:rendering,topic:editor,confirmed,regression

<!-- 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. -->
Godot v3.2.4-beta2


**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->

- Windows 10 (64-bit) version (build) 2009 (10.0.19042).
- Intel® UHD Graphics 620 driver version 27.20.100.8935.
- GLES3


**Issue description:**
<!-- What happened, and what was expected. -->
In some of my scripts, rainbow sparks appear in the Visual Script editor, as shown [here](https://photos.app.goo.gl/BpysV88FfxUGrTEV6). I expected to see no sparks in the editor.

**Note:** I don't know if this will be related. In Godot v3.2.4-beta1, the Visual Script editor crashed on me every time which I reported in #43108. In Godot v3.2.4-beta2, it's not crashing anymore. However, I got the sparks as I had described.

In Godot v3.2.3-stable, no crash and no rainbow sparks occur.


**Steps to reproduce:**
1. Open the project.
2. Open the script (Look.vs). The rainbow sparks will appear.


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[3D Targeting System.zip](https://github.com/godotengine/godot/files/5570287/3D.Targeting.System.zip)
Repository: create-react-app
Issue: fork-ts-checker-webpack-plugin not called with --max-old-space from NODE_OPTIONS
Labels: needs triage,issue: bug report

### Describe the bug

The _fork-ts-checker-webpack-plugin_ is not called with `--max-old-space` from `NODE_OPTIONS`.

### Did you try recovering your dependencies?

```
$ npm --version
6.14.8
$ node --version
v12.19.1
$ cat package.json | grep \"react-scripts\"
    "react-scripts": "~3.4.3"
$ cat package-lock.json | grep -A 2 \"react-scripts\"
    "react-scripts": {
      "version": "3.4.4",
      "resolved": "https://registry.npmjs.org/react-scripts/-/react-scripts-3.4.4.tgz",
```

### Environment

`FROM node:12.19.1-alpine3.12`

```
PID   USER     TIME  COMMAND
    1 root      0:00 {node} npm
   16 root      0:00 node /opt/app/node_modules/.bin/react-scripts build
   23 root      1:18 node /opt/app/node_modules/react-scripts/scripts/build.js
   34 root      0:51 /usr/local/bin/node --max-old-space-size=2048 /opt/app/node_modules/fork-ts-checker-webpack-plugin/lib/service.js
   45 root      0:00 /bin/sh
   54 root      0:00 ps
/opt/app # cat /proc/34/environ | tr '\0' '\n' | grep NODE_OPTIONS
NODE_OPTIONS=--max-old-space-size=4096
/opt/app # cat .env.production | grep NODE_OPTIONS
NODE_OPTIONS=--max-old-space-size=4096
```

### Steps to reproduce

_.env.production_
`NODE_OPTIONS=--max-old-space-size=4096`

`npm run build` inside `node:12.19.1-alpine3.12` docker image.

### Expected behavior

The configured `max-old-space-size` value from `NODE_OPTIONS` is used.

### Actual behavior

`--max-old-space-size=2048` is always used.

Which leads to:

```
<--- Last few GCs --->

[23:0x55822a148e00]   183795 ms: Mark-sweep 987.2 (995.5) -> 986.4 (995.5) MB, 804.3 / 0.2 ms  (average mu = 0.210, current mu = 0.191) allocation failure scavenge might not succeed
[23:0x55822a148e00]   185184 ms: Mark-sweep 987.0 (995.5) -> 986.5 (995.8) MB, 1249.9 / 0.1 ms  (average mu = 0.148, current mu = 0.100) allocation failure GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x558228289b39]
Security context: 0x25445edc08d1 <JSObject>
    1: SourceNode_walk [0x22ffba46da21] [/opt/app/node_modules/webpack-sources/node_modules/source-map/lib/source-node.js:~221] [pc=0x3d2731fba85](this=0x31ad9ffd6409 <SourceNode map = 0x3d40622bbfd9>,0x1b75d4f9e431 <JSFunction (sfi = 0x348957ffd339)>)
    2: SourceNode_walk [0x22ffba46da21] [/opt/app/node_modules/webpack-sources/node_modules/source-map/lib/...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
npm ERR! code ELIFECYCLE
npm ERR! errno 1
```
Repository: pytorch
Issue: Batched inplace mm changes stride when out size is correct
Labels: triaged,module: memory format,module: linear algebra,module: correctness (silent)

## 🐛 Bug

When `torch.matmul(A, B, out=A)` is called for batched `A` and square `B`, `A`'s strides are changed, even though it has the correct size!

## To Reproduce

![image](https://user-images.githubusercontent.com/5674597/99738873-808cb500-2a99-11eb-9207-052b69520494.png)


Code:
no batch:
```py
base = torch.randn(2, 4)
x = base[..., ::2]
m = torch.zeros(2, 2)
print(f"before matmul")
print(f"base: shape={tuple(base.shape)} stride={tuple(base.stride())})")
print(f"x: shape={tuple(x.shape)} stride={tuple(x.stride())})")
print(base)
torch.matmul(x, m, out=x)
print(f"after matmul")
print(f"base: shape={tuple(base.shape)} stride={tuple(base.stride())})")
print(f"x: shape={tuple(x.shape)} stride={tuple(x.stride())})")
print(base)
```
batched:
```py
base = torch.randn(2, 2, 4)
x = base[..., ::2]
m = torch.zeros(2, 2)
print(f"before matmul")
print(f"base: shape={tuple(base.shape)} stride={tuple(base.stride())})")
print(f"x: shape={tuple(x.shape)} stride={tuple(x.stride())})")
print(base)
torch.matmul(x, m, out=x)
print(f"after matmul")
print(f"base: shape={tuple(base.shape)} stride={tuple(base.stride())})")
print(f"x: shape={tuple(x.shape)} stride={tuple(x.stride())})")
print(base)
```

cc @vishwakftw @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @walterddr @VitalyFedyunin @jamesr66a @ppwwyyxx