sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Scaling issue with non-conventional monitor sizes.
Labels: topic:core,topic:rendering

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
Godot 3.2.2.stable.official
<!-- Specify commit hash if using non-official build. -->


**OS/device including version:**
Windows/PC  GLES3
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->


**Issue description:**
A game with a native resolution of 2560x1440p, the stretch mode set to 2D, and the aspect mode to expand is displaying unusual outputs on a 3440 x 1440p monitor, below.  We suspect the issue lies with the engine, but would appreciate confirmation on this point.
![image (9)](https://user-images.githubusercontent.com/39195489/92835294-107ef600-f3a9-11ea-99d6-b8381ffec11c.jpg)


**Steps to reproduce:**
Run exported Godot project on a 3440 x 1440p monitor.

**Minimal reproduction project:**
[MonitorTestCase.zip](https://github.com/godotengine/godot/files/5226562/MonitorTestCase.zip)
Repository: go
Issue: x/tools/gopls: document how to run the daemon in docker
Labels: Documentation,help wanted,NeedsInvestigation,gopls,Tools

<!--
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`)?

go1.12.17 darwin/amd64

### Does this issue reproduce with the latest release?

YES recent version of gopls 0.4.4

### What operating system and processor architecture are you using (`go env`)?

```
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/ninja/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/ninja/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/ninja/Documents/<name>/<project>/go.mod"
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/65/7_p4zdgn2llfqf6fvn1zymjw0000gn/T/go-build716194075=/tmp/go-build -gno-record-gcc-switches -fno-common"
```

### What did you do?

I am trying to setup gopls for neovim with the builtin lsp. But I have a dependency on linux to build the source I cannot build it on mac. So I tried setting up docker gopls server to listen at 7050.
### Dockerfile
```
FROM golang:1.12.16-stretch
RUN apt-get update && apt-get install -y libudev-dev

ARG GOPATH
ENV GOPATH $GOPATH

ARG MY_PWD
ENV MY_PWD ${MY_PWD}

RUN mkdir -p $GOPATH
RUN mkdir -p $MY_PWD

ENV PATH="/usr/local/go/bin:$GOPATH/bin:${PATH}"
RUN GOPROXY=https://proxy.golang.org GO111MODULE=on go get golang.org/x/tools/gopls@latest
WORKDIR $MY_PWD

CMD /go/bin/gopls  -listen=":7050"
```

I opened nvim and it throws the same build error as the one I got on mac. 
### Neovim config
```
:lua << EOF
require'nvim_lsp'.gopls.setup{
cmd = {"gopls","-remote","localhost:7050"};
}
EOF
```

I initially tried this docker setup for a simple hello world example and that worked. But now I am not sure whether it actually compiled inside docker and communicated the results outside or it just compiled in mac itself. 
Gopls listen inside docker doesn't give any logs other than connected and exited (atleast when I run docker logs <id>).

**PS: I execed into docker and built the source and it worked as expected.**
### What did you expect to see?
I expect gopls -remote to build the source inside docker and give back the results to the client.


### What did you see instead?
 
I see the same build error which I got on mac, which might mean gopls is not forwarding the commands to the remote and doing it locally.
Repository: pytorch
Issue: DataLoader consumes extremely large shared memory (shm) in its initialization.
Labels: module: dataloader,triaged

## 🐛 Bug

DataLoader consumes extremely large shared memory (shm) in its initialization (when calling `iter(dataloader)`) compared to following training steps. For example, it consumes up to 150GB shm in its initialization (when set num_workers=7), and then decrease to 0 (I sleep the program for 30s after its initialization), and then consumes round 0~12GB shm in the following training steps.

## To Reproduce

Steps to reproduce the behavior:

1. set your every batch data size to be 0.76GB.
2. set your num_workers in DataLoader to be 7 (or more).
3. start distributed training on two servers (each with 8 GPUs) using torch.distributed.launch.
4. your nn model can be very simple LSTM.

## Expected behavior

The shm consumed in /dev/shm will not vary too much between its initialization and following training steps.

## Environment

Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```

 - PyTorch Version (e.g., 1.0): 1.5.0
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source):
 - Python version: 3.7.6
 - CUDA/cuDNN version: 10.1/7.6
 - GPU models and configuration: 2080Ti

cc @SsnL @VitalyFedyunin @ezyang
Repository: godot
Issue: Control nodes return incorrect get_rotation value when they a child for a Container node
Labels: bug,topic:gui

**Godot version:**
Godot v3.2.1-stable_win64
Godot v3.2.2-stable_win64


**OS/device including version:**
Surface Pro 7
Windows 10 Home build 19041.450
Intel UHD Graphics driver version 26.20.100.7641
GLES3 (appears to also affect GLES2)



**Issue description:**
When a ~~`TextureRect`~~`Control` is rotated inside a ~~`Popup`~~`Container` before the ~~`Popup`~~`Container` is shown (either programmatically, set in the Inspector, or rotated while the ~~`Popup`~~`Container` was previously ~~opened then closed~~ shown), it doesn't actually get rotated *(edit: because the `Container` is controlling the `Control`'s rect)*. The `get_rotation` function will return the value that ~~it's supposed to be~~ it was rotated but it's not actually shown as rotated.

Once the ~~`Popup`~~`Container` is visible then rotating the ~~`TextureRect`~~ works properly *(edit: as in the visual rotation matches the value returned by `get_rotation`)*.


**Steps to reproduce:**
1. Put a `TextureRect` inside a pop up.
2. Rotate it (This can be done either in the Inspector or programmatically.)
3. Show the pop up
4. *added* Call `get_rotation` on the `Control` (returns a non-zero result even though the `Control` is no longer rotated)

**Minimal reproduction project:**
[rotation bug.zip](https://github.com/godotengine/godot/files/5205565/rotation.bug.zip)
Repository: PowerToys
Issue: [Run][Calculator Plugin] Support for unmatched parentheses
Labels: Idea-Enhancement,Product-PowerToys Run,Run-Plugin

Quite simply, the calculator in Run does not support expressions like `3/(1+2` or `1+2)/3` that have unmatched parentheses. Support for these isn't critical, but it would be nice to have.

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: pytorch
Issue: “doxygenfunction: Unable to resolve multiple matches for function ...” in C++ documentation
Labels: module: docs,module: cpp,triaged

## 📚 Documentation

For some C++ functions (for example, torch::load), the [function documentation](https://pytorch.org/cppdocs/api/function_namespacetorch_1a4b369494adfb10b9a005aeb0bb6207cb.html?highlight=load) page shows a warning:  

```
"doxygenfunction: Unable to resolve multiple matches for function “torch::load” with arguments (std::vector<torch::Tensor>&, LoadFromArgs&&…) in doxygen xml output for project “PyTorch” from directory: /var/lib/jenkins/workspace/docs/cpp/build/xml."
```

![image](https://user-images.githubusercontent.com/39305301/92850084-9ab57180-f41e-11ea-8e73-47015c71c87e.png)


cc @yf225 @glaringlee @jlin27
Repository: go
Issue: cmd/compile: missing BCE case 
Labels: NeedsInvestigation,compiler/runtime

<!--
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
go version go1.15.2 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/cholerae/Library/Caches/go-build"
GOENV="/Users/cholerae/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/cholerae/Documents/gopath/pkg/mod"
GONOPROXY="code.byted.org,git.byted.org"
GONOSUMDB="code.byted.org,git.byted.org"
GOOS="darwin"
GOPATH="/Users/cholerae/Documents/gopath"
GOPRIVATE="code.byted.org,git.byted.org"
GOPROXY="https://goproxy.cn,direct"
GOROOT="/Users/cholerae/Documents/gopath/go"
GOSUMDB="sum.golang.google.cn"
GOTMPDIR=""
GOTOOLDIR="/Users/cholerae/Documents/gopath/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"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
https://godbolt.org/z/31M9no
```
package main

//go:noinline
func test(val uint, dst []byte) byte {
    if val+3 > val {
        _ = dst[val+3]
        dst[val] = 1
        dst[val+1] = 1
        dst[val+2] = 1
        dst[val+3] = 1
    }
    return 1
}

func main() {
    println(test(100, make([]byte, 10)))
}
```
Bound checks in function test after `_ = dst[val+3]` could be eliminated, but not.

### What did you expect to see?
Only one bound check exists in function test.

### What did you see instead?
There are three bound checks in function test.
Repository: flutter
Issue: Add copyright header check presubmit
Labels: team,engine,P2,team-engine,triaged-engine

A recent grep through the code uncovered [a few files](https://github.com/flutter/engine/pull/21089) with missing or incorrectly formatted copyright headers. We should add a presubmit to the engine and framework repos that enforces the correct copyright header style in the engine/framework repos so we don't let these slide again.
Repository: pytorch
Issue: too large data in Queue cause dead lock in Multiprocessing 
Labels: module: multiprocessing,triaged

The model has two parts, and I want to parallel two parts, so I used multiprocessing.
One part can be seen as provider, another can be seen as consumer.
It always lock in consumer needs data, but it seems provider also provide data.

I tried to change data size in queue, the process became dead lock in different running iters.
Repository: neovim
Issue: VIMINIT does not like *
Labels: enhancement

I can see the number line in neovim when setting the VIMINIT to the following:
```
export VIMINIT ="
set number
autocmd VimResized * :wincmd =
"
```

However swapping the configuration order the number line is no longer turned on:
```
export VIMINIT ="
autocmd VimResized * :wincmd =
set number
"
```

This happend's more often and it looks like the `*` character is causing the problem. Not sure if this is a bug or expected behavior. Or am I missing something?

```
NVIM v0.3.4
Build type: Release
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-PpSRXj/neovim-0.3.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=1 -DDISABLE_LOG -Wdate-time -D_FORTIFY_SOURCE=1 -Wconversion -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim-PpSRXj/neovim-0.3.4/build/config -I/build/neovim-PpSRXj/neovim-0.3.4/src -I/usr/include -I/build/neovim-PpSRXj/neovim-0.3.4/build/src/nvim/auto -I/build/neovim-PpSRXj/neovim-0.3.4/build/include
Compiled by team+vim@tracker.debian.org

Features: +acl +iconv -jemalloc +tui 
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info
```
Repository: react-native
Issue: App sometimes reloads the js bundle when switching from background to foreground.
Labels: Needs: Repro,Newer Patch Available

## Description
App sometimes reloads the js bundle when switching from background to foreground.

## React Native version:
0.63

## Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.

Create a new react-native application. Install react-navigation. Create a stack navigator. Open app, go trough several screens. Switch app to another one in the background. Open as many apps as you can so you have a lot of them in the memory. Switch back and the react-native app reloads the bundle.

## Expected Results
I should be able to manually disable this reaload. Since I don't kill the app I should go back to where I was. This is very annoying when you try to fill a form and you go to another application to copy and come back to paste.
Repository: flutter
Issue: Color.withOpacity on Arabic letters does not fully cover the whole word
Labels: engine,a: quality,a: typography,c: rendering,has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-engine,triaged-engine

When using any color with an opacity on Arabic letters, the opacity does on apply on all of the letters.
here's an image that shows the same color for Arabic and english letters, notice the opacity working fine on english letters however some parts of the Arabic letters do not have the specified opacity.
![Screenshot 2020-09-11 at 3 17 48 PM](https://user-images.githubusercontent.com/60091652/92926724-2510cc00-f445-11ea-9f87-e967936cb16e.png)

Here's the code snippet of the image shown above
```
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: MyHomePage(),
    );
  }
}

class MyHomePage extends StatefulWidget {
  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Align(
        child: Container(
          width: MediaQuery.of(context).size.width,
          height: MediaQuery.of(context).size.height,
          color: Colors.black,
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: [
              Text(
                "أحرف العربية",
                style: TextStyle(
                  fontSize: 60.0,
                  color: Colors.green.withOpacity(0.25),
                ),
              ),
              Text(
                "English letters",
                style: TextStyle(
                  fontSize: 60.0,
                  color: Colors.white.withOpacity(0.25),
                ),
              ),
            ],
          ),
        ),
      ),
    );
  }
}
```
Repository: pytorch
Issue: torch.norm does not broadcast for dim > 2
Labels: module: docs,triaged

## 📚 Documentation
[From the docs:](https://pytorch.org/docs/stable/generated/torch.norm.html)

`torch.norm(input, p='fro', dim=None, keepdim=False, out=None, dtype=None)`

> **dim** (int, 2-tuple of python:ints, 2-list of python:ints, optional) – [...] If the input tensor has more than two dimensions, the vector norm will be applied to last dimension.

The docs say that by default the norm will be applied to the last dimension, when the input tensor has more than two axes. I see different behaviour:
```
a = torch.rand(3, 4, 5)
torch.norm(a)
# tensor(4.7850)
```

cc @jlin27
Repository: godot
Issue: Editor canvas tool lines inaccurate and offset.
Labels: topic:editor,documentation,topic:gui

<!-- 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. -->
d38eb29f2e713b65a214e3fcdee7e8375c9fc493


**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Win10 64-bit

**Issue description:**
<!-- What happened, and what was expected. -->
The editors lines in some situations can be offset, when they should follow the border of the rendered content.

![godot windows tools 64_TaglOJvQ0k](https://user-images.githubusercontent.com/13004169/92944242-69f42d00-f45c-11ea-9a69-b0b95fbd69c6.png)


**Steps to reproduce:**
Not entirely sure what happened.  Was making some dummy controls for tests.  I switched to snapping, and then noticed the boundary lines of this GUI button and it's child Polygon2D are not where its actually rendered.  Seems to be caused by the Button and passed down to the Polygon2D.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[Editor Line Issue.zip](https://github.com/godotengine/godot/files/5209989/Editor.Line.Issue.zip)
Repository: bitcoin
Issue: [Idea] Wallet UTXO Pruning
Labels: Feature,Wallet

**Is your feature request related to a problem? Please describe.**
As we all know the more TXes in a Bitcoin wallet the slower and slower it runs.

**Describe the solution you'd like**
I had an idea (would be default off of course) where you could set like walletprune=X to whatever number you want and any spent entries in the wallet would be deleted after getting that many confirms. In theory this should greatly speed up wallet activity. This would be completely separate from blockchain pruning which could be on or off.

**Describe alternatives you've considered**
The main alternative here is rolling your own wallet system or using a service like BitGo for anything more than small projects.
Repository: create-react-app
Issue: Let developers explicitly specify Dart Sass implementation through USE_DART_SASS environment variable
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Currently react-scripts uses `sass-loader@8.0.2` which, [according to the README](https://github.com/webpack-contrib/sass-loader/blob/e74b5aa8e4c836d243df8826128073a1ee2d83d7/README.md) will:
 * use Dart Sass if `sass` is installed
 * use Node Sass if `node-sass` is installed
 * will prefer `node-sass` if both are installed

We have our projects on a monorepo setup, and we have both dependencies through projects. We use `pnpm` to manage dependencies, and the end result is that since sass-loader finds `node-sass`, it uses it. There's no way to force Dart Sass

### Describe the solution you'd like

Have an environment variable `USE_DART_SASS=true` to let consumers specify the want to use Dart Sass

```javascript
// webpack.config.js

const implementationOptions = process.env.USE_DART_SASS === 'true'
  ? { implementation: require.resolve('sass') }
  : {}

// ...

{
  loader: require.resolve(preProcessor),
  options: {
    sourceMap: true,
    ...implementationOptions,
  },
}
```

### Describe alternatives you've considered

I've considered remove node-sass from all of the projects, but that's not only too much work, but it also makes my project health dependent on making sure nobody in the future ever adds a `node-sass` installation, or my app will break.

I've also considered forking and using custom react-scripts, however keeping it in sync with the public one and such seems like a lot of work for this one single option.

I've pushed #9629 to show you how it'd look like.
Repository: rust
Issue: rustdoc: layout-relevant private fields can not be documented
Labels: T-rustdoc

Some structs with, e.g. with `repr(C)`, are intended be layout stable. This makes every field relevant to a user particularly for ffi purposes. The names and types of additional alignment fields introduces to avoid uninitialized padding are not meant to be part of the SemVer relevant interface and should not be `pub`. However, this completely elides the documentation so that it becomes guesswork which alignment was done.

```rust
#[repr(C)]
struct Duck {
    pub kind: u32,
    _reserved_flags: u32,
    pub quak: u64,
}
```

The generated documentation looks like so:
```
pub struct Duck {
    pub kind: u32,
    pub quak: u64,
    // some fields omitted
}
```

The order is painfully confusing in that it suggests that there _is_ padding. I'd suggest a `#[doc(pub)]` attribute that explicitly shows the field in right order but marked as not being accessible. A workaround is to conditionally make the field public for rustdoc:

```rust
#[repr(C)]
struct Duck {
    pub kind: u32,
    #[cfg(not(rustdoc))] _reserved_flags: u32,
    #[cfg(rustdoc)] pub _reserved_flags: u32,
    pub quak: u64,
}
```

## Context

`#[doc(hidden)]` can be applied to fields and functions to _not_ list them in the documentation even if they would otherwise be publicly documented.
Repository: neovim
Issue: Floating window will not be deleted when no listed buffers exist
Labels: bug

NVIM v0.5.0-948e625e1
macosx 10.15.6
kitty terminal

### Steps to reproduce using `nvim -u NORC`

launch neovim with no listed buffers
create a floating window with buffer that is not listed
call "bwipeout <floating buffer id>" on the buffer with the floating window

### Actual behaviour
the floating window/buffer would remain visible

### Expected behaviour
the floating window/buffer should close