sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Custom attention
Labels: module: nn,triaged

## 🚀 Feature
There have been a tremendous increase in different attention modules over the recent years. It would be nice to have an ability to pass a custom attention module to either `Transformer` methods (`TransformerEncoder`, `TransformerDecoder`, `etc`).

## Motivation

Currently the `Transformer` module only implements attention module that uses the Vaswani et al 2017 paper's Scaled Dot-Product alignment score function. It would be great if one could change either the whole attention module or maybe only the alignment score function.

## Pitch

`Transformer` modules could accept an attention parameter that would fallback to current implementation. This would enable to use the module in a more generalized manner. 

## Alternatives

A hard alternative would be not to include the custom attention and leave it for other libraries to implement. But it is my belief that more and more domains will be using transformers in the coming years and adding flexibility to the library would benefit everyone.

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @zhangguanheng66
Repository: flutter
Issue: [web] flutter_service_worker.js should be generated from template file
Labels: c: new feature,tool,platform-web,c: proposal,P3,team-web,triaged-web

Currently flutter_service_worker.js is automatically generated when running 'flutter build web' from a string template that is in the flutter_tools source code.

It should be possible to generate the service worker from a template file in the project directory. This would allow the developer to customize the service worker's behavior, giving the option to implement different caching strategies.
Repository: tensorflow
Issue: Using SYSTEM cURL (build against OpenSSL) conflicts with BoringSSL
Labels: stat:awaiting tensorflower,type:build/install,subtype: ubuntu/linux,TF 2.3

**System information**
- OS Platform and Distribution (e.g., Linux Ubuntu 16.04): RHEL 7.5
- TensorFlow installed from (source or binary): source
- TensorFlow version: 2.3.1

**Describe the problem**

Due to a hard-coded configure value of cURL (see https://github.com/tensorflow/tensorflow/issues/40065#issuecomment-667129086) we build TensorFlow with a system-installed cURL via `TF_SYSTEM_LIBS=curl`. This curl uses the systems OpenSSL library (for security reasons this has to be managed by the system)

Some parts of TF use BoringSSL, e.g. grpcio (build as a dependency) seems to contain/build a BoringSSL itself.
Now loading the TF lib (via an import in Python) loads cURL, which loads OpenSSL which causes conflicts with the BoringSSL used and ultimately leads to invalid free calls:

**Provide the exact sequence of commands / steps that you executed before running into the problem**

- build TensorFlow with TF_SYSTEM_LIBS=curl
- Run any code using cURL through TF in Python. Example below:

```
import tensorflow_datasets as tfds

builder = tfds.builder('stanford_dogs')
builder.download_and_prepare()
```

**Any other info / logs**
```
*** Error in `python': free(): invalid pointer: 0x00000000046bfd08 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81299)[0x7f2b1dba9299]
<prefix>/lib/python3.7/site-packages/tensorflow/python/../libtensorflow_framework.so.2(ASN1_STRING_free+0x35)[0x7f2aac3d0205]
<prefix>/lib/python3.7/site-packages/tensorflow/python/../libtensorflow_framework.so.2(ASN1_primitive_free+0xbd)[0x7f2aac3d371d]
<prefix>/lib/python3.7/site-packages/tensorflow/python/../libtensorflow_framework.so.2(ASN1_template_free+0x8f)[0x7f2aac3d3b1f]
<prefix>/lib/python3.7/site-packages/tensorflow/python/../libtensorflow_framework.so.2(asn1_item_combine_free+0x2a0)[0x7f2aac3d39f0]
<prefix>/lib/python3.7/site-packages/tensorflow/python/../libtensorflow_framework.so.2(ASN1_item_free+0x17)[0x7f2aac3d3a77]
<prefix>/lib/libcurl.so.4(+0x57a20)[0x7f2aaae7ea20]
<prefix>/lib/libcurl.so.4(+0x593fb)[0x7f2aaae803fb]
<prefix>/lib/libcurl.so.4(+0x59fd7)[0x7f2aaae80fd7]
<prefix>/lib/libcurl.so.4(+0x110e2)[0x7f2aaae380e2]
<prefix>/lib/libcurl.so.4(+0x30215)[0x7f2aaae57215]
<prefix>/lib/libcurl.so.4(curl_multi_perform+0x83)[0x7f2aaae58473]
<prefix>/lib/libcurl.so.4(curl_easy_perform+0x11b)[0x7f2aaae50a6b]
<prefix>/lib/python3.7/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so(_ZN10tensorflow15CurlHttpRequest4SendEv+0x2b9)[0x7f2ac88c34f9]
```

Is there any solution from the side of TF to avoid this? From reading the docs of BoringSSL it should be possible to define `BORINGSSL_PREFIX` to something, so the symbols from OpenSSL and BoringSSL do not clash. But I'm not sure if I understood that correctly as BoringSSL would need to use that when being built already
Repository: create-react-app
Issue: Setting the git author when initialising a repo with `create-react-app`
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?
Currently, when initialising a repo using `create-react-app`, the committer of the code is taken to be the configured git user for that system/repo/session. Ideally, it should be a pre-set value.

(Write your answer here.)

### Describe the solution you'd like

It should be as simple as adding two `-c` command line arguments to the `git commit` command for `user.name` and `user.email`. However, I am unsure as to what values can be put there
Repository: excalidraw
Issue: copying styles should set it as default
Labels: enhancement

When you copy element styles via shortcut/contextmenu, it should set it as default props so that you don't have to copy/paste for every new element you create.
Repository: create-react-app
Issue: Bug: Comment in root of the return() works fine on development build and breaks the component/app on production
Labels: stale

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: 16.13.1

## Steps To Reproduce

1. create a new `create-react-app` with `yarn create react-app`.
2. create a minimal component as shown below:
```
import React from "react";

const HelloBug = () => {
  return (
    // What is this behaviour here ???? wrong comment
    <div>
      {/* Correct Comment */}
      <h1>Hello Componnet</h1>
    </div>
  );
};

export default HelloBug;
``` 

_The js comment style `//` comment in first line of `return()` before `<div>`_

3. include that component in `App.js` as below:
```
import React from "react";
import "./App.css";
import HelloBug from "./components/HelloBug";

function App() {
  return (
    <div className="App">
      <HelloBug />
    </div>
  );
}

export default App;
```

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example: https://github.com/chankruze/react-comment-issue-demo

**Note:** for simplicity of serving prod build, i installed `serve` with `yarn global add serve` and added a script `prod` to `package.json` which builds and serves the compiled prod code.

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

## The current behavior

The code seems to work fine in development as shown below:

![Screenshot (379)](https://user-images.githubusercontent.com/29806845/95480543-a2c6e980-09a9-11eb-9a4d-223ac9e25a14.png)

![Screenshot (380)](https://user-images.githubusercontent.com/29806845/95480614-b4a88c80-09a9-11eb-94b0-62a14d5c1b36.png)


But in production build, nothing renders as shown below but there are some error which were not present in development, which links to [Error Decoder](https://reactjs.org/docs/error-decoder.html/?invariant=152&args[]=Component):

![Screenshot (381)](https://user-images.githubusercontent.com/29806845/95480787-ef122980-09a9-11eb-966f-1566515dfbed.png)

![Screenshot (382)](https://user-images.githubusercontent.com/29806845/95480805-f2a5b080-09a9-11eb-8188-a3949d9d7766.png)

## The expected behavior

Expectation was either warning/build error/syntax highlight on dev or working behavior on prod.

**Video of ES Lint auto comment suggestion:** https://www.youtube.com/watch?v=Q3S2maNV3gA
Repository: godot
Issue: Plugin class_name type hints and singleton dependency loop
Labels: bug,topic:editor,topic:plugin

<!-- 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.3

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
n/a

**Issue description:**
<!-- What happened, and what was expected. -->
When you have a class in a plugin that depends on a Singleton loaded by that plugin (with `add_autoload_singleton`) you can end up in a dependency loop very easily.

In this specific case the plugin script defines a member variable with a type hint of the class (that depends on the Singleton). This will prevent you from enabling the plugin with script errors:
`Unable to load addon script from path
[plugin_class_singleton_dep_loop.zip](https://github.com/godotengine/godot/files/5349488/plugin_class_singleton_dep_loop.zip)
: 'res://addons/class_singleton_dep_loop/plugin.gd' There seems to be an error in the code, please check the syntax.`

```gdscript
tool
extends EditorPlugin

var test_node: TestNode

func _enter_tree():
	add_autoload_singleton("Singleton", "res://addons/class_singleton_dep_loop/singleton.gd")


func _exit_tree():
	remove_autoload_singleton("Singleton")
```

Here `TestNode` type hint is a class that depends on another class, `TestClass`, that depends on the autoload singleton.
This shows that you can easily trip over yourself by having a long dependency chain, before you realise the problem.
To make it more challenging, once a plugin is loaded, you can write your way into this loop without realising, because you need to disable the plugin, and clear the system by restarting Godot for the problem to present itself.

**Steps to reproduce:**
1. Create a plugin.
2. Use `add_autoload_singleton` in the class to load a singleton.
3. Create a class that depends on the singleton.
4. Use that class as a type hint in the plugin script.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[plugin_class_singleton_dep_loop.zip](https://github.com/godotengine/godot/files/5349499/plugin_class_singleton_dep_loop.zip)
Repository: storybook
Issue: Storybook composition without stories
Labels: bug,has workaround,composition

**Describe the bug**
I would like to create a storybook composition created of multiple URLs without having any of the stories defined in the project (empty projects with just refs to other live storybooks). This is in a way possible, but the UI is buggy and does not seem to support this very well. The UI is stuck in "loading" state.

**Expected behavior**
There should be no loading indicators and the story of the first composed storybook should be selected.

**Screenshots**
<img width="1680" alt="Screenshot 2020-10-08 at 18 41 12" src="https://user-images.githubusercontent.com/8524109/95488712-28d93500-0996-11eb-9275-ebea44737b22.png">
Repository: go
Issue: x/tools/gopls: unimported completions offer circular imports
Labels: NeedsFix,gopls,Tools,gopls/completion

To reproduce:

Type `cache.New` inside of `golang.org/x/tools/internal/lsp/cache` and accept the completion.

Related: https://github.com/golang/go/issues/36077.

/cc @heschik
Repository: create-react-app
Issue: while installing the react app getting error
Labels: stale,needs triage

C:\Users\Administrator>create-react-app demok

Creating a new React app in C:\Users\Administrator\demok.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...


> core-js@2.6.11 postinstall C:\Users\Administrator\demok\node_modules\babel-runtime\node_modules\core-js
> node -e "try{require('./postinstall')}catch(e){}"


> core-js@3.6.5 postinstall C:\Users\Administrator\demok\node_modules\core-js
> node -e "try{require('./postinstall')}catch(e){}"


> core-js-pure@3.6.5 postinstall C:\Users\Administrator\demok\node_modules\core-js-pure
> node -e "try{require('./postinstall')}catch(e){}"

+ cra-template@1.0.3
+ react-scripts@3.4.3
+ react@16.13.1
+ react-dom@16.13.1
added 1596 packages from 745 contributors and audited 1600 packages in 571.654s

71 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities


/*Above data only display that only i am waiting for more than 2 hr and I am trying to solve the error, I have no idea to solve the error*/
Repository: TypeScript
Issue: Should disallow using the result of calling a void-returning function
Labels: Suggestion,Awaiting More Feedback

**TypeScript Version:**  4.1.0-dev.20201008

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** disallow function call void return usage warn error

**Code**

```ts
function doesntReturn() {
    // no return statement
}

const foo: string = doesntReturn() + 'foo'; // should be an error
```

**Expected behavior:**

The expression `doesntReturn() + 'foo'` should be an error because it uses the value of a `void`-returning function call. As far as I can tell, there is literally no good reason to use the return value of a function with no return statements like this.

This is similar to the current behavior of disallowing void-returning expressions inside control flow (issue #26262). It is also similar to the reasoning behind the warning that occurs when using a function value (instead of calling it) in an `if` condition.

**Actual behavior:**

No error message is given.

**Playground Link:** [here](https://www.typescriptlang.org/play?ts=4.1.0-dev.20201008#code/GYVwdgxgLglg9mABAEzgUwM5igJTVEAJzAAoBKRAbwChE7EB6BxMORQ-IpDKAQyjQBbNNmoBfatQgIeiYHDgAuRD0IwwAc0QBeFOiy5OxcogDUiAOTy4FgNxA)

**Related Issues:** #26262
Repository: rust
Issue: New "warning incompatible with previous forbid in same scope" error
Labels: C-enhancement,A-lints

I tried this code:

```rust
#![forbid(unused_extern_crates)]
#![warn(unused_extern_crates)]

fn main() {}
```

I expected to see this happen: an error that can be disabled via `--cap-lints=warn`

Instead, this happened: a hard error

```console
> rustc temp.rs --cap-lints=warn
error[E0453]: warn(unused_extern_crates) incompatible with previous forbid in same scope
 --> temp.rs:2:9
  |
1 | #![forbid(unused_extern_crates)]
  |           ---------------- `forbid` level set here
2 | #![warn(unused_extern_crates)]
  |         ^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
```

After writing this up, looking back through the history (https://github.com/rust-lang/rust/pull/77534, https://github.com/rust-lang/rust/issues/70819) it appears this is fixing a regression, but given that this has been accepted by the stable compiler for over 3 years at this point, maybe it's still worth having a deprecation period? (This was noticed by a user on the discord as their code started failing to compile).

### Meta

```
> rustc --version --verbose
rustc 1.49.0-nightly (91a79fb29 2020-10-07)
binary: rustc
commit-hash: 91a79fb29ac78d057d04dbe86be13d5dcc64309a
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.49.0-nightly
LLVM version: 11.0
```
Repository: rust
Issue: Short backtrace sometimes includes unnecessary `core::ops::function::FnOnce::call_once` line
Labels: A-runtime,C-bug,T-libs

Given this file `foo.rs`:

```rust
fn main() {
    panic!();
}
```

A [short backtrace](https://blog.rust-lang.org/2020/10/08/Rust-1.47.html#shorter-backtraces) for this panic would ideally include only `std::panicking::begin_panic` and `foo::main`. And, indeed, the [implementing PR](https://github.com/rust-lang/rust/pull/75048) has a test for this output:

https://github.com/rust-lang/rust/blob/5792840bf52e4cf77ebb7b3bd93e9c90dd23f4e7/src/test/ui/panics/issue-47429-short-backtraces.run.stderr#L1-L5

However, this is how the backtrace actually looks with various flags:

`rustc` (no flags; debug mode)

```
   0: std::panicking::begin_panic
   1: foo::main
   2: core::ops::function::FnOnce::call_once
```

`rustc -O` (release mode)

```
   0: std::panicking::begin_panic
   1: foo::main
```

`rustc -O -C debuginfo=1` (release mode with debuginfo)

```
   0: std::panicking::begin_panic
             at ./.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:505
   1: foo::main
             at ./foo.rs:2
   2: core::ops::function::FnOnce::call_once
             at ./.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
```

So I think the `__rust_begin_short_backtrace` implementation needs to account for this extra stack frame when it isn't optimized out by release mode. The test mentioned above only passes because it's compiled with `-O`:

https://github.com/rust-lang/rust/blob/5792840bf52e4cf77ebb7b3bd93e9c90dd23f4e7/src/test/ui/panics/issue-47429-short-backtraces.rs#L3

I tested this on 1.47.0 stable and a nightly version:

<details><summary><code>rustc --version --verbose</code></summary>

```
rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.47.0
LLVM version: 11.0

rustc 1.49.0-nightly (91a79fb29 2020-10-07)
binary: rustc
commit-hash: 91a79fb29ac78d057d04dbe86be13d5dcc64309a
commit-date: 2020-10-07
host: x86_64-unknown-linux-gnu
release: 1.49.0-nightly
LLVM version: 11.0
```

</details>

ref #75048
cc @eggyal
Repository: godot
Issue: Possible race-condition when setting parameter multi-threaded
Labels: bug,topic:core

**Godot version:**
Godot v3.2.3.stable.official

**OS/device including version:**
AMD Athlon 2 X4
Linux Mint 20 Cinnamon
AMD Radeon Rx 570, mesa 20.2.0,
OpenGL ES 3.0 multi threaded renderer !

**Issue description:**
project becomes unresponsive after a pretty random time, if the
`position`, `rotation`, `scale` or `visibility`
of eg. sprites is set by multiple threads when the multi-threaded renderer.
With unsafe single-threaded renderer it just keeps running.
When setting `offset` of canvas layers it also keeps running with the multi-threaded renderer.

**Steps to reproduce:**
Run the reproduction project and go to your well deserved break and check if the project is still running when you come back.
The time it takes is pretty random, but if the objects (sprites or canvas layers) are not in the scene tree, it hangs pretty fast,
normally within minutes.
Every object is only accessed by one single thread, so I have no clue what could cause a race condition.
But I'm certain the code in the scripts is thread-safe.
You can also change the property that's being changed by uncommenting another property in Sprite.gd or by changing the scene that's being loaded in Threading.gd (sprite or canvas layer).

**Minimal reproduction project:**
[ThreadingRaceCondition.zip](https://github.com/godotengine/godot/files/5351627/ThreadingRaceCondition.zip)
The project uses 4 threads.
With cpus with more threads it will take longer to become unresponsive.
Repository: pytorch
Issue: Support undispatched ops in codegen
Labels: triaged,module: codegen

Currently there are dispatched ops whose signatures don't involve Tensors. For these, the dispatcher adds no obvious value, only overhead. (Is there any nonobvious value?) 

Recent (10/1/20) master:
```
- func: _use_cudnn_rnn_flatten_weight() -> bool
- func: _cufft_get_plan_cache_size(int device_index) -> int
- func: _cufft_get_plan_cache_max_size(int device_index) -> int
- func: _cufft_set_plan_cache_max_size(int device_index, int max_size) -> ()
- func: _cufft_clear_plan_cache(int device_index) -> ()
- func: is_vulkan_available() -> bool
- func: _nnpack_available() -> bool
- func: result_type.Scalar_Scalar(Scalar scalar1, Scalar scalar2) -> ScalarType
- func: can_cast(ScalarType from, ScalarType to) -> bool
- func: promote_types(ScalarType type1, ScalarType type2) -> ScalarType
```

Further, these are currently registered using a `catchAll` kernel, and so now require a wrinkle in the new dispatch key setup (explicit registrations to `DispatchKey::Undefined`).

The idea is that if we teach codegen about undispatched ops (whose bindings call `at::native` functions directly) then we decouple the convenience of `native_functions.yaml` from dispatcher overhead.

How do we tell an op in native_functions is undispatched? Could do it implicitly today: 
- no `Tensor` arguments or or return values
- no explicit `dispatch` entry
Can add something explicit later if this becomes too imprecise (`dispatch: none`?)

For JIT/Eager parity, codegen would need to generate both Python bindings and JIT PrimOps registrations. Not sure whether the latter capability already exists, but I don't think so. Alternative (handwritten JIT bindings) would be a regression. 

If we added this capability, some number of hand-fastpathed ops like `numel` could be brought back into the fold.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar @jiayisuse @agolynski @ailzhang to make sure I captured everything we talked about 😁
Repository: node
Issue: Terminal callback error
Labels: http2

* **Version**: v14.0.0
* **Platform**: win / *nix

# Background 
In a multi-threaded scenario, above a certain number of threads, a particular API has recently started firing the `end` event for all open threads with truncated response data (less than the reported value in headers). Essentially, all threads seem to be cut off prematurely.

I'm reasonably certain that this is a firewall or server error on the API side, causing all outgoing connections to my IP to be terminated prematurely. (Although I am not positive)

# Issue

The reason I'm filing this issue is that in these cases, it throws an uncatchable `Error [ERR_HTTP2_ERROR]: The user callback function failed`.

request.on('error') does fire, which would allow me to gracefully reject the promise, however I've not found any official way to stop or catch the `ERR_HTTP2_ERROR` throw which terminates the process.

As a workaround, I'm using `process.on('uncaughtException' ...)` to catch and ignore that code.

It seems likely that there may be a better way to handle this. Such an error also may seem excessive in the case of events like early termination, where a total application exit would not be ideal.
Repository: pytorch
Issue: TestDataLoader.test_proper_exit takes 2.5min to finish
Labels: module: dataloader,module: ci,module: tests,triaged

According https://app.circleci.com/pipelines/github/pytorch/pytorch/224304/workflows/2571002d-2075-4e53-877b-4bac675037de/jobs/8062979
```
TestDataLoader.test_proper_exit  time: 158.54 seconds
TestDataLoaderPersistentWorkers.test_proper_exit  time: 158.44 seconds
```

cc @ezyang @seemethere @malfet @walterddr @SsnL @VitalyFedyunin @ejguan @mruberry