sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Compiler performance when compiling built-in derives is worse than desired
Labels: I-compiletime,A-macros,T-compiler

This is a follow-up issue to #80050 which was closed due to the implementation not being 100% correct. 

Currently, adding `#[derive]` annotations for built-in traits such as a `PartialOrd` or `Debug` causes slower compile times than if the user implements these traits by hand. We should aim for getting these derives to be as close to "free" as possible when it comes to amount of time it takes to compile the code. 

## The Current State 

We currently track the performance of derives in the [rustc-perf "derives" benchmark](https://github.com/rust-lang/rustc-perf/blob/e095f5021bf01cf3800f50b3a9f14a9683eb3e4e/collector/benchmarks/derive/src/lib.rs). 

`PartialOrd` is by far the most expensive to derive of the traits in std. The derive benchmark with `#[derive(PartialEq, PartialOrd)]` takes 9.1s on my machine while just `#[derive(PartialEq)]` takes 1.9s. 

The following is a short experiment where we create a struct with one field 10,000 times and benchmark what happens when the structs have various derives on them. The code is generated using the following ruby script:
```ruby
File.open('src/lib.rs', 'w') do |file|
  0..10_000.times do |n|
      file.write("pub struct MyType#{n} { pub field: i32 }\n")
  end
end
```
* Base (i.e., no derives): 061.s
* `#[derive(Debug)]`: 13.33s
* `#[derive(PartialEq)]`: 9.78s
* `#[derive(PartialEq, PartialOrd)]`: **47.46s**
* `#[derive(Clone)]`: 6.32s
*  `#[derive(Clone, Copy)]`: 5.32s
* `#[derive(PartialEq, Eq)]`: 14.13s
* `#[derive(Default)]`: 4.33s
* `#[derive(Hash)]`: 6.52s

It should be noted that it does not appear that any of the overhead is coming from the code expansion itself. When compiling the traits with the code copy/pasted from output from `cargo expand`, the performance is comparable to deriving the traits. 

However, there's definitely some wiggle room beyond "just making compilation in general faster, will make derives faster". I manually implemented `Debug` and ran the test again, and it compiles 10% faster. 

It seems like the plurality of time (~13%)  for most of these derives is being spent in type checking though a deeper investigation into each class of derive is warranted. You can see a `summarize` comparison of `derive` vs. expanded vs manually implemented [here](https://gist.github.com/rylev/14430d2e1ea384b1f10efae6b5c385f2). 

## Discussion

This topic is already being discussed [on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Slow.20Builtin.20Derives). 

Some discussion has suggested we might want to look into MIR shims as a possible solution but since MIR still needs to undergo type checking and we're spending most of the time in type checking, this probably won't help.
Repository: tensorflow
Issue: Invalid index list in batch_scatter_ops_test.py 
Labels: stat:awaiting tensorflower,type:bug,comp:gpu,regression issue,TF 2.11

**Describe the current behavior**

For current master the tests in batch_scatter_ops_test.py produce an invalid index list/tensor.

Check: https://github.com/tensorflow/tensorflow/blob/dec8e0b11f4f87693b67e125e67dfbc68d26c205/tensorflow/python/kernel_tests/batch_scatter_ops_test.py#L59-L62

The comment says, non-duplicate values are required but `randint` is used which does produce duplicates. Hence the test fails.

**Standalone code to reproduce the issue**
A reduced test code which reproduces this on my machine:

```
import numpy as np
from tensorflow.python.ops import state_ops
from tensorflow.python.ops import variables
from tensorflow.python.framework import ops

def _NumpyUpdate(ref, indices, updates):
  for i, indx in np.ndenumerate(indices):
    indx = i[:-1] + (indx,)
    ref[indx] = updates[i]

def _VariableRankTest(vtype, itype):
  np.random.seed(8)
  indices_shape = (2,)
  for extra_shape in (), (5,):
    # Generate random indices with no duplicates for easy numpy comparison
    sparse_dim = len(indices_shape) - 1
    indices = np.random.randint(indices_shape[sparse_dim], size=indices_shape, dtype=itype)
    updates = np.random.randn(*(indices_shape + extra_shape)).astype(vtype)

    old = np.random.randn(*(indices_shape + extra_shape)).astype(vtype)
    print("indices: %s" % indices)
    if not extra_shape:
      continue

    # Scatter via numpy
    new = old.copy()
    _NumpyUpdate(new, indices, updates)
    # Scatter via tensorflow
    ref = variables.Variable(old)
    variables.variables_initializer([ref])

    #state_ops.batch_scatter_update(ref, indices, updates)
    ref.batch_scatter_update(ops.IndexedSlices(indices=indices, values=updates))
    ref = ref.numpy()
    assert np.allclose(ref, new, rtol=1e-6, atol=1e-6), "Failed:\nlhs: %s\nrhs: %s" % (ref, new)

_VariableRankTest(np.float32, np.int32)
```

I see an output of `indices: [1 1]` followed by:
```
AssertionError: Failed:
lhs: [[-0.37835857 -0.79161525  0.8595481  -0.23078899 -0.06566103]
 [-2.2964916   2.4098344   1.7278361   2.2045562   0.79482764]]
rhs: [[-0.37835857 -0.79161525  0.8595481  -0.23078899 -0.06566103]
 [ 0.9764211  -1.1834271   1.9163636  -1.1233268  -0.6640355 ]]
```

**Other info / logs**
tensorflow/python/kernel_tests/scatter_ops_test.py contains a valid implementation using `arange` and `shuffle` which would fix the issue

Side note: the code raises a warning:
> tensorflow/python/ops/resource_variable_ops.py:1124: batch_scatter_update (from tensorflow.python.ops.state_ops) is deprecated and will be removed after 2018-11-29.
Instructions for updating:
Use the batch_scatter_update method of Variable instead.

Note how the date is well passed but there is not even a way to avoid this as I'm already doing what is suggested.
Repository: create-react-app
Issue: Could not create react app with custom react-scripts
Labels: needs triage,issue: bug report

```bash
yarn create react-app react-app-demo --scripts-version 3.4.4
```
**then**
```
✨  Done in 48.51s.
internal/modules/cjs/loader.js:883
  throw err;
  ^

Error: Cannot find module 'cra-template'
Require stack:
- /Users/jesse/workspace/react-app-demo/node_modules/react-scripts/scripts/init.js
- /Users/jesse/workspace/react-app-demo/[eval]
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:880:15)
    at Function.resolve (internal/modules/cjs/helpers.js:94:19)
    at module.exports (/Users/jesse/workspace/react-app-demo/node_modules/react-scripts/scripts/init.js:110:13)
    at [eval]:3:14
    at Script.runInThisContext (vm.js:132:18)
    at Object.runInThisContext (vm.js:309:38)
    at internal/process/execution.js:77:19
    at [eval]-wrapper:6:22
    at evalScript (internal/process/execution.js:76:60)
    at internal/main/eval_string.js:23:3 {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/Users/jesse/workspace/react-app-demo/node_modules/react-scripts/scripts/init.js',
    '/Users/jesse/workspace/react-app-demo/[eval]'
  ]
}

Aborting installation.
  node  has failed.

Deleting generated file... node_modules
Deleting generated file... package.json
Deleting generated file... yarn.lock
Deleting react-app-demo/ from /Users/jesse/workspace
Done.
error Command failed.
Exit code: 1
Command: /usr/local/bin/create-react-app
Arguments: react-app-demo --scripts-version 3.4.4
Directory: /Users/jesse/workspace
Output:

info Visit https://yarnpkg.com/en/docs/cli/create for documentation about this command.

```
Repository: pytorch
Issue: Improve AssertionError for torch.nn.functional.pad 'replicate'
Labels: module: bootcamp,module: nn,triaged,enhancement,better-engineering

Minor issue: the current AssertionError for torch.nn.funcional.pad mode='replicate' is confusing, if I run:
```
data = torch.zeros(100,3,63,64)
out = F.pad(data,(0,0,0,1,0,0,0,0),mode='replicate')
```
the error is: 
```
AssertionError: 4D tensors expect 4 values for padding
```
given that there is a `value` input to `pad`,  I thought I had to specify `value` also. I see now its because for `mode='replicate'` and a 4D tensor, it can only pad the last 2 dimensions, so you specify a pad tuple of 4 `(pad_left,pad_right,pad_bot,pad_top)`. I would suggest modifying the AssertionError to more accurately reflect that. 

cc @albanD @mruberry
Repository: create-react-app
Issue: Update babel-preset-react-app package.json to use a more permissive dependency versions
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Currently `babel-preset-react-app` pulls in specific babel dependency of `7.12.3` for core, and `7.12.1` for several plugins. 

As a result when installing packages using yarn it ends up pulling `7.12.10` for most packages, and a separate copy of `7.12.3` just for this preset. This boosts the time it takes for the CI server to load caches / install dependencies / save caches.

### Describe the solution you'd like

Update the `package.json` in the `babel-preset-react-app` to use the [caret syntax](https://github.com/npm/node-semver#caret-ranges-123-025-004) to specify a major version, and the minimum minor/patch version, so that the system can make use of a single babel install.

This would change the file as follows:

```js
{
  "name": "babel-preset-react-app",
  "version": "10.0.0",
  "description": "Babel preset used by Create React App",
  "repository": {
    "type": "git",
    "url": "https://github.com/facebook/create-react-app.git",
    "directory": "packages/babel-preset-react-app"
  },
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/facebook/create-react-app/issues"
  },
  "files": [
    "create.js",
    "dependencies.js",
    "dev.js",
    "index.js",
    "webpack-overrides.js",
    "prod.js",
    "test.js"
  ],
  "dependencies": {
    "@babel/core": "^7.12.3",
    "@babel/plugin-proposal-class-properties": "^7.12.1",
    "@babel/plugin-proposal-decorators": "^7.12.1",
    "@babel/plugin-proposal-nullish-coalescing-operator": "^7.12.1",
    "@babel/plugin-proposal-numeric-separator": "^7.12.1",
    "@babel/plugin-proposal-optional-chaining": "^7.12.1",
    "@babel/plugin-transform-flow-strip-types": "^7.12.1",
    "@babel/plugin-transform-react-display-name": "^7.12.1",
    "@babel/plugin-transform-runtime": "^7.12.1",
    "@babel/preset-env": "^7.12.1",
    "@babel/preset-react": "^7.12.1",
    "@babel/preset-typescript": "^7.12.1",
    "@babel/runtime": "^7.12.1",
    "babel-plugin-macros": "2.8.0",
    "babel-plugin-transform-react-remove-prop-types": "0.4.24"
  }
}
```

### Describe alternatives you've considered

This issue can be worked around by specifying custom resolutions for all the dependencies of the preset, but that results in warnings, and requires continuous monitoring.
Repository: rust
Issue: Passing `--no-doc` to ./x.py test causes panic_abort tests to fail
Labels: A-testsuite,T-bootstrap,C-bug

Running `./x.py test --stage 1 --no-doc` on the latest version of nightly (#80114) causes the test suite to crash with the following error: 

```
error: building tests with panic=abort is not supported without `-Zpanic_abort_tests`

error: aborting due to previous error

error: could not compile `panic_abort`

```

This seems like a bug in the bootstrapper where `--no-doc` causes tests to be erroneously compiled with the abort panic strategy, since tests pass as expected with `./x.py test --stage 1` (`--no-doc` omitted) 

This error can be also triggered with a subset of the test suite by running `./x.py test library/panic_abort --stage 1 --no-doc`
Repository: create-react-app
Issue: Bug: "useState, useEffect is called conditionally" -- while they aren't
Labels: needs triage,issue: bug report

Since an update to `react-scripts` 4.0.0, `react-scripts build` started failing for us in a weird way.

As viewed from an editor:

![sZUmKWWzEDsZ](https://user-images.githubusercontent.com/365338/102516601-b7092000-4097-11eb-9222-50e2c44d12f7.jpg)

It fails in exactly the same way on CI — so it's not about my editor or dev environment setup.

There're **26** lines with `useState` up to line 180.

This happens once I comment out, e.g. line 178:

![8DlggENq_VMG](https://user-images.githubusercontent.com/365338/102516621-bc666a80-4097-11eb-9817-617d2a7b8447.jpg)

If you can see, a completely different set of lines gets flagged with the error now.

Similar errors are also emitted about `useEffect` several hundred lines below.

### Did you try recovering your dependencies?

No.

### Which terms did you search for in User Guide?

I did read https://reactjs.org/docs/hooks-rules.html and I understand what's it about. It isn't the case in our code; the linter is wrong.

### Environment

```
$ npx create-react-app --info
...
  System:
    OS: Linux 5.4 Arch Linux
    CPU: (4) x64 Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz
  Binaries:
    Node: 15.4.0 - /usr/bin/node
    Yarn: 1.22.10 - /usr/bin/yarn
    npm: 6.14.8 - /usr/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: 83.0
  npmPackages:
    react: ^16.8.6 => 16.14.0 
    react-dom: ^16.8.6 => 16.14.0 
    react-scripts: 4.0.0 => 4.0.0 
  npmGlobalPackages:
    create-react-app: Not Found
```

### Steps to reproduce

Unfortunately, the project where this bit me is 22 kSLoC (not counting `node_modules`).

I've lost ~20 minutes trying to minimize the issue, but didn't succeed.

As a workaround, I've downgraded `eslint-plugin-react-scripts`' errors to warnings — that fixed the build.

This isssue is a matter of courtesy for assistance on `#reactjs` IRC.
Repository: flutter
Issue: Refactor Spawn->Kill Integration test to be more independent
Labels: a: tests,engine,P3,team-engine,triaged-engine

related issue: https://github.com/flutter/flutter/issues/72319

When I implemented the integration test to fix the attached issue I piggy backed on an existing integration test, the "Bogus Font Text" test.  I planned on splitting it out but my environment became unworkable (I keep getting kernel version mixmatch errors).  So, I'm punting on that refactor for now.
Repository: rust
Issue: Opt-out of std linking system libraries
Labels: A-linkage,T-libs-api,C-feature-request

In `library/std/src/sys/windows/mod.rs` some libraries, for either uwp or win32, get linked. The block that follows these linking statements contain no declarations, so to me it seems that these libraries are just linked for the sake of linking them, but it doesn't look like anything depends on them.

```rust
cfg_if::cfg_if! {
    if #[cfg(target_vendor = "uwp")] {
        #[link(name = "ws2_32")]
        // For BCryptGenRandom
        #[link(name = "bcrypt")]
        extern "C" {}
    } else {
        #[link(name = "advapi32")]
        #[link(name = "ws2_32")]
        #[link(name = "userenv")]
        extern "C" {}
    }
}
```  

Even when `no-default-libraries` is set to true in a target config they are still getting linked. This is very unfortunate, because I have to make something that relies on `/NODEFAULTLIB` to exclude the linking of these libraries. The [commit](https://github.com/rust-lang/rust/commit/6f3872a14c73a74c55e0854641f4dfe5e3b7000e) that made this change was to clean up the build script. The build script where they got originally linked also didn't have a way to opt-out of them, but I would like to have a method to opt-out of the linking of these libs, so that I can provide my own set of windows libraries.
Repository: flutter
Issue: Spawn->Kill Integration test for Android
Labels: a: tests,platform-android,engine,P2,team-android,triaged-android

We implemented the test for iOS here: https://github.com/flutter/flutter/issues/72319   It was broken for a while because of errors in the embedder code.  That points to a need to have an equivalent test for Android. 

cc @xster
Repository: go
Issue: cmd/compile: missed opportunity to coalesce loads that compare with constants
Labels: Performance,NeedsInvestigation,compiler/runtime

```go
func f(x *[16]byte) bool {
	return x[0] == 0 && x[1] == 0 &&
		x[2] == 0 && x[3] == 0 &&
		x[4] == 0 && x[5] == 0 &&
		x[6] == 0 && x[7] == 0 &&
		x[8] == 0 && x[9] == 0 &&
		x[10] == 0xff && x[11] == 0xff
}
```

This could compile on amd64 to something like MOVQ to load the first 8 bytes, TESTQ to check whether the first 8 bytes are zero, MOVL to load the next 4 bytes, CMPL to test those bytes. Instead, we currently generate a series of 12 CMPBs.

Low priority.
Repository: go
Issue: crypto/tls: Sending multiple messages via tcp4 connection encrypted by TLS1.3 doesn't work
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
<pre>
$ go version
go version go1.15.6 linux/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="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/Documents/repos/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/Documents/repos/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build262060463=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
My code receives and sends text messages to Haproxy (I've tried 1.8 and 2.2) via TCP connection.
It works w/o encryption and with TLS1.2. But doesn't work with TLS1.3 except when I send only one message per connection.
I undestand that it may be a bug in Haproxy but I haven't found one and also I have another Haproxy and Java programs that do the same job w/o errors. Haproxy config sets minimum encryption level to TLS1.2.

A piece of code that sends multiple messages to TLS connection: https://play.golang.org/p/x5RWpwrcvLh
Full code is [here](https://github.com/nixargh/groxy/blob/2.0.0-release/main.go).

### What did you expect to see?
I expect Haproxy receive and process those messages.

### What did you see instead?
Almost all (~95%) of message finished with *CD* error that means (from [here](https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#8.5)):
```
     CD   The client unexpectedly aborted during data transfer. This can be
          caused by a browser crash, by an intermediate equipment between the
          client and haproxy which decided to actively break the connection,
          by network routing issues between the client and haproxy, or by a
          keep-alive session between the server and the client terminated first
          by the client.

```
Log message example:
`Dec 17 19:34:37 haproxy-secure haproxy[7240]: *.*.*.*:33308 [17/Dec/2020:19:34:37.674] test~ test/test 100/1/198 0 CD 2/2/1/0/0 0/0
`
Repository: flutter
Issue: Lower the default Dart VM old space size on Android
Labels: platform-android,engine,c: performance,perf: memory,P2,team-android,triaged-android

https://github.com/flutter/engine/pull/20473 introduced setting the `old_gen_heap_size` by default to roughly half of available physical memory.

This lowered the default from 32GB to something more sensible and safer, in a way that was intended to avoid introducing performance regressions for customers.

Ideally, we should really be looking at what the OS provides as the expected memory class for the device, potentially using the large memory class. We should still allow customers to override this in the manifest if they wish to use a higher limit.

Before changing this value, we should gather some benchmark data around setting it lower and see if it's possible to mitigate those numbers.
Repository: PowerToys
Issue: [KBM] Allow additional modifiers
Labels: Idea-Enhancement,Product-Keyboard Shortcut Manager

I would like to be able to map keys to modifiers that are not in general use. There are a couple of ways I can think of doing this:

1. Allow keys to be toggled as modifier keys, e.g. I could map the key [right alt] to vk0, then toggle vk0 to be a modifier, then map vk0 + A to [HOME].
2. Invent new modifier keys e.g. similar to the above example, I could map the key [right alt] to [virtual mod 0], then map the shortcut [virtual mod 0] + A to [HOME].
3. Expose modifier keys that are not on the keyboard. e.g. My keyboard does not have the Alt Gr key on it, thus the Alt Gr key does not show up in the list of possible keys that I can map to. Maybe there are other modifier keys that already exist that can just be allowed to be added? I know Alt Gr is already baked into windows and maybe can just be exposed, is mod/meta/extend/super/etc. already baked into windows as well?
4. Similar to [#4584](https://github.com/microsoft/PowerToys/issues/4584) allow more combinations to be mapped to a key. I cannot map they key combo [alt + ctrl] to [right alt], but if I could, I would essentially have access to the alt gr key. By allowing keys to be mapped to combinations of the 4 modifier keys that aren't generally used (ctrl + win, alt + win, alt + shift, shift + win) it's possible to essentially hack new modifiers in with the combinations of mapping keys and shortcuts.
Repository: pytorch
Issue: Update jit/OVERVIEW.md
Labels: oncall: jit,weeks

[jit/OVERVIEW.md](https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/OVERVIEW.md) is an extremely valuable resource to anyone interested in the JIT's internals. 

A few parts of that document are incomplete and/or out-of-date though:

- TODO: differentiation, symbolic autograd
- TODO: fusion, operators
- TODO: Script Module, torch.jit.trace, constant handling, weak script modules
- placeholder [interpreter](https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/OVERVIEW.md#interpreter-1) section
    (there's already a section on the interpreter, is this placeholder just a left over?) [Peng Wu]
- placeholder [fusion group](https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/OVERVIEW.md#fusiongroup) section

cc @gmagogsfm
Repository: godot
Issue: Key record mode keeps spamming errors if it's enabled when Animation is closed
Labels: bug,topic:editor,usability

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.4 beta4

**Steps to reproduce:**
1. Add AnimationPlayer
2. Enable recording
![image](https://user-images.githubusercontent.com/2223172/102551185-5d1c5080-40bf-11eb-8c75-1ffa1841ccd3.png)
3. Delete the AnimationPlayer
4. Move some Node2D
5.
![image](https://user-images.githubusercontent.com/2223172/102551254-73c2a780-40bf-11eb-969d-124788701795.png)
Repository: godot
Issue: print() doesn't handle null characters (\u0000) correctly 
Labels: bug,topic:core

**Godot version:**
`4.0.dev.custom_build.5332d212f`


**OS/device including version:**
`Linux pc 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux`


**Issue description:**
When printing a string with a null character (`\u0000`), everything after that character is not printed. This issue is also present in 3.2.3.


**Steps to reproduce:**
```gdscript
extends MainLoop


func _idle(_delta):
	print("With: '%s'" % "aaaa\u0000bbbb")
	print("Without: '%s'" % "aaaa\bbbb")
	return true
```

Output:
```
With: 'aaaa
Without: 'aaaabbbb'
```


**Minimal reproduction project:**
See above.