sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: C++ standard library confusion
Labels: module: build,triaged

## 🐛 Bug

After building py-torch from source with a newer version of gcc (and libstdc++), we get the following error on import:

```shell
[aweits@localhost ~]$ python
Python 3.8.7 (default, Jan  6 2021, 14:20:25) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/aweits/GIT/UPSTREAMSPACK/spack/opt/spack/linux-centos8-skylake_avx512/gcc-9.3.0/py-torch-1.7.1-gja66kub643ix7sevlid27wcsdimbxgx/lib/python3.8/site-packages/torch/__init__.py", line 190, in <module>
    from torch._C import *
ImportError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /home/aweits/GIT/UPSTREAMSPACK/spack/opt/spack/linux-centos8-skylake_avx512/gcc-9.3.0/py-torch-1.7.1-gja66kub643ix7sevlid27wcsdimbxgx/lib/python3.8/site-packages/torch/lib/libtorch_python.so)

```
# To Reproduce

1. Build from source with a newer-than-system gcc/libstdc++, and newer cuda libraries that depend on libstdc++

## Expected behavior
Should cleanly import. The issue is that the "empty" library introduced in commit ddff4ef pulls in the Nvidia libraries, which *then* pull in the system libstdc++. This is incorrect in this case as the libstdc++ that was included/built with the compiler should be used instead. This can be avoided/fixed by changing the following:

```shell
'torch_global_deps PROPERTIES LINKER_LANGUAGE C'
```
to
```shell
'torch_global_deps PROPERTIES LINKER_LANGUAGE CXX'
```
in caffe2/CMakeLists.txt

## Environment

 - PyTorch Version (e.g., 1.0): 1.7.1
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): from source, using spack
 - Build command you used (if compiling from source): 
 - Python version:
 - CUDA/cuDNN version: 11.1.1/8.0.4.30-11.1
 - GPU models and configuration: Nvidia Quadro P4000
 - Any other relevant information:

## Additional context

https://github.com/spack/spack/issues/18867

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @malfet @seemethere @walterddr
Repository: go
Issue: x/tools/gopls: multiple failures on windows-arm-zx2c4
Labels: OS-Windows,NeedsInvestigation,gopls,Tools

Looking at our build dashboard for first-class ports, windows-arm-zx2c4 stands out as failing for a long time.

Some of the failures might be due to resource constraints (gopls tests can be very IO and memory heavy), but some are failures related to the filesystem that should be investigated, for example:
https://build.golang.org/log/477a5faf3f4383900706c4b25940a706322b6362

```
--- FAIL: TestLSP (23.64s)
    --- FAIL: TestLSP/Modules (8.57s)
        lsp_test.go:57: invalid workspace configuration: case mismatch in path "C:\\Users\\GOPHER~1.DES\\AppData\\Local\\Temp\\TestLSP_Modules233674203\\lsp": component "GOPHER~1.DES" should be "Gopher.DESKTOP-6IM5GCA"
        
--- FAIL: TestCaseInsensitiveFilesystem (0.02s)
    view_test.go:50: checkPathCase("C:\\Users\\GOPHER~1.DES\\AppData\\Local\\Temp\\TestCaseInsensitiveFilesystem086638055\\a\\B\\c\\DEFgh\\f.go") = case mismatch in path "C:\\Users\\GOPHER~1.DES\\AppData\\Local\\Temp\\TestCaseInsensitiveFilesystem086638055\\a\\B\\c\\DEFgh\\f.go": component "GOPHER~1.DES" should be "Gopher.DESKTOP-6IM5GCA", wanted error: false
```

Opening this issue to track getting this builder out of failure, either by deciding to skip these tests or by fixing them.

CC @stamblerre @heschik @pjweinbgo
Repository: flutter
Issue: Add the equivalent of Center() for the remaining alignments
Labels: c: new feature,framework,f: material design,c: proposal,team-design,triaged-design

Typing `Align` `alignment`, `Alignment` over and over is pretty annoying after a while.

It would be nice if the core had the equivalent of center for all the alignments:
```
import 'package:flutter/material.dart';
​
Widget _build(Alignment value, Widget child) => Align(alignment: value, child: child);
​
/// TOPS
class TopLeft extends StatelessWidget {
  const TopLeft({Key key, this.child}) : super(key: key);
  final Widget child;
​
  @override
  Widget build(BuildContext context) => _build(Alignment.topLeft, child);
}
​
class TopRight extends StatelessWidget {
  const TopRight({Key key, this.child}) : super(key: key);
  final Widget child;
​
  @override
  Widget build(BuildContext context) => _build(Alignment.topRight, child);
}
​
class TopCenter extends StatelessWidget {
  const TopCenter({Key key, this.child}) : super(key: key);
  final Widget child;
​
  @override
  Widget build(BuildContext context) => _build(Alignment.topCenter, child);
}
​
/// CENTERS
class CenterLeft extends StatelessWidget {
  const CenterLeft({Key key, this.child}) : super(key: key);
  final Widget child;
​
  @override
  Widget build(BuildContext context) => _build(Alignment.centerLeft, child);
}
​
class CenterRight extends StatelessWidget {
  const CenterRight({Key key, this.child}) : super(key: key);
  final Widget child;
​
  @override
  Widget build(BuildContext context) => _build(Alignment.centerRight, child);
}
​
/// BOTTOMS
class BottomLeft extends StatelessWidget {
  const BottomLeft({Key key, this.child}) : super(key: key);
  final Widget child;
​
  @override
  Widget build(BuildContext context) => _build(Alignment.bottomLeft, child);
}
​
class BottomRight extends StatelessWidget {
  const BottomRight({Key key, this.child}) : super(key: key);
  final Widget child;
​
  @override
  Widget build(BuildContext context) => _build(Alignment.bottomRight, child);
}
​
class BottomCenter extends StatelessWidget {
  const BottomCenter({Key key, this.child}) : super(key: key);
  final Widget child;
​
  @override
  Widget build(BuildContext context) => _build(Alignment.bottomCenter, child);
}
```
Repository: TypeScript
Issue: Documentation on Supported Version(s)
Labels: Docs

# Bug Report
I was unable to find any documentation on what versions of TypeScript are "supported." I realize that is a loosely defined term, what I mean is this: If a security vulnarability was found in TypeScript, which versions would be patched?

Right now, it's impossible to know what the minimum version of TypeScript we should be using in order to be ready for any security patches that could be issued.

### 🔎 Search Terms
 - supported versions
 - security support
 - version support
Repository: pytorch
Issue: `hasattr` check not supported on objects other than `self`
Labels: oncall: jit,weeks

## 🐛 Bug

The following examples work in Python, but not in TorchScript. It seems like we only support `hasattr(self, <ATTRIBUTE>)` inside nn.Modules.

```python
class M(torch.nn.Module):
    def __init__(self, x: torch.Tensor):
        super(M, self).__init__()
        self.x = x

    def forward(self):
        if hasattr(self.x, "is_cuda"):
            return "foo"
        else:
            return "bar"

m = M(torch.rand(2, 3))
scripted = torch.jit.script(m)

"""
RuntimeError: hasattr's first argument must be an object, got Tensor 
instead
"""
```

```python
@torch.jit.script
def fn(x: torch.Tensor):
    if hasattr(x, "is_cuda"):
        return "foo"
    return "bar"

print(fn(torch.rand(2, 3)))

"""
RuntimeError: hasattr's first argument must be an object, got Tensor 
instead
"""
```

cc @gmagogsfm
Repository: youtube-dl
Issue: Command-line option to pause at the end
Labels: request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.02.10. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar feature requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [X] I'm reporting a feature request
- [X] I've verified that I'm running youtube-dl version **2021.02.10**
- [X] I've searched the bugtracker for similar feature requests including closed ones


## Description

<!--
Provide an explanation of your issue in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->

When youtube-dl is executed directly by other applications it automatically close at the end.
There is `--exec pause` to pause at the end but I have verified that it doesn't work in case of errors (for example this: `ERROR: requested format not available.`)
So it would like to have an option that run `pause` at the end in all cases, please.
Repository: godot
Issue: Primitives types shares the same color than keyword color.
Labels: enhancement,topic:editor

<!-- 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 3.2

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Manjaro. Godot set on GLES2

**Issue description:**
<!-- What happened, and what was expected. -->
There is a specific color for built in types, engine types, etc... but not for the primitive type. The primitive types shares the keyword color hurting readability.
https://github.com/godotengine/godot/issues/44922 Was closed but his inital topic is still a thing.

**Steps to reproduce:**
Open a GDScript in Godot editor and declare variables using static typing,  change the keyword colors using the editor settings.
Repository: godot
Issue: Changing the text editor theme to "Adaptative" erase the custom theme.
Labels: discussion,topic:editor

<!-- 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 3.2

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Manjaro. GLES2

**Issue description:**
<!-- What happened, and what was expected. -->
When I changed the text editor theme from "custom" to "adaptative" and change back to the custom, the theme remains as "adaptative". I expected the custom theme to go back.

**Steps to reproduce:**
Go to editor settings and follow the issue above.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: transformers
Issue: Multiple Mask support in Pipeline
Labels: Feature request

# 🚀 Feature request

The [fill mask](https://huggingface.co/bert-base-uncased?text=Paris+is+the+capital+of+%5BMASK%5D+%3F) feature as a part of the pipeline currently only supports a single mask for the inputs. It could be expanded to predict and return the results for multiple masks in the same sentence too.

## Motivation

There are use cases where one would ideally have more than just a single mask where they would need a prediction from the model. For example, smarter template filling in outputs returned to users etc. Could also be used in better study of the implicit knowledge that BERT models have accumulated during pre-training.

## Your contribution

I should be able to raise a PR for the same. The output JSON schema would have to be slightly modified, but I can go ahead and complete the same if there is no other obvious issue that slipped my mind as to why only a single [MASK] token needs to be supported.
Repository: pytorch
Issue: Removing mutation on block input should print any meaning message.
Labels: module: onnx,triaged,onnx-triaged

## 🚀 Feature

JIT ONNX converter prints message during processing:

```
Warning: ONNX Preprocess - Removing mutation on block inputs. This changes graph semantics.
```

This message is generated here:
https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/onnx/remove_inplace_ops_for_onnx.cpp#L765

It would be very helpful to see more meaningful message with node name and some context, where this node was created in PyTorch

## Motivation

The conversion from PyTorch to ONNX is quite hard so any helpful message will make it easier.


cc @houseroad @spandantiwari @lara-hdr @BowenBao @neginraoof @SplitInfinity
Repository: PowerToys
Issue: [Feature Request] Spawn Tabtip (Touch Keyboard) to secondary screen
Labels: Idea-Enhancement,FancyZones-Dragging&UI,Product-FancyZones

## 📝 Provide a description of the new feature
My second screen is a pen display and don't have touch support, whenever I spawn tabtip with shortcut (also with pen of course because mouse can't spawn it), it always appear in main screen, so is that possible to move it automatically while I spawn that

`c:\program files\common files\microsoft shared\ink\tabtip.exe
`

> What is the expected behavior of the proposed feature?  What is the scenario this would be used?


showing tabtip (touch keyboard to second display)
___
If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: three.js
Issue: MaterialLoader support custom materials
Labels: Enhancement

The MaterialLoader as it is now isn't very extensible.  I would like to be able to more easily create loaders for custom materials without duplicating the material loader.

The main problem is that while there's inversion of control for the textures, there isn't for Materials.

https://github.com/mrdoob/three.js/blob/d5bb724770de4bb384340139c52cbf1304cd5e5f/src/loaders/MaterialLoader.js#L70

This is a factory pattern that isn't provided to the loader, nor is there a way to add a new material constructor / material type.
Repository: pytorch
Issue: CosineAnnealingWarmRestarts LR scheduler fails when lash_epoch != -1
Labels: module: optimizer,triaged

## 🐛 Bug

`torch.optim.lr_scheduler.CosineAnnealingWarmRestarts` construction fails, when `last_epoch` parameter isn't equal to `-1` (i.e., the user wants to continue scheduling from the specified epoch).

## To Reproduce

```python
import torch

l = torch.nn.Linear(20, 30)
op = torch.optim.SGD([{"params": l.parameters(), "initial_lr": 0.01}], lr=0.01)
sch = torch.optim.lr_scheduler.CosineAnnealingWarmRestarts(op, 1, last_epoch=1)
```

The output as of current `master` is something like that:
```bash
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/site-packages/torch/optim/lr_scheduler.py", line 965, in __init__
    super(CosineAnnealingWarmRestarts, self).__init__(optimizer, last_epoch, verbose)
  File "/usr/lib/python3.8/site-packages/torch/optim/lr_scheduler.py", line 79, in __init__
    self.step()
  File "/usr/lib/python3.8/site-packages/torch/optim/lr_scheduler.py", line 1008, in step
    self.T_cur = self.T_cur + 1
AttributeError: 'CosineAnnealingWarmRestarts' object has no attribute 'T_cur'
```

## Expected behavior

No output meaning the construction succeeded.

## Environment

PyTorch version: 1.7.0a0+57bffc3
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Gentoo/Linux (x86_64)
GCC version: (Gentoo 9.3.0-r2 p4) 9.3.0
Clang version: 11.0.0
CMake version: version 3.18.5

Python version: 3.8 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.4
[pip3] pytorch-sphinx-theme==0.0.24
[pip3] torch==1.7.0a0
[pip3] torchvision==0.8.0a0
[conda] Could not collect

cc @vincentqb
Repository: pytorch
Issue: CTCLoss gradient is incorrect
Labels: module: docs,module: autograd,module: loss,triaged

## 🐛 Bug
Hi,

While working on some CTC extensions, I noticed that torch's CTCLoss was computing incorrect gradient. At least when using CPU (I have not tested on GPU yet). I observed this problem on both pytorch 1.3 and pytorch 1.7.1 , using MacOS/anaconda distribution.

## To Reproduce
Torch's own gradcheck tool detect this problem. Here is a minimal example of gradient computation going wrong (for the record, it is not a problem of precision with gradcheck. The computed gradient is really wrong.

```python
import torch
import torch.nn as nn

# For this minimal example, let us use a mninbatch of size 1, 3 time steps and a label vocabulary size of 2
V = 2
T = 3

# Generate some random input parameters for CTC
params_ctc = nn.functional.log_softmax(torch.randn(T, 1, V+1)) 
params_ctc = params_ctc.double()  # convert to double so that gradcheck is more accurate
params_ctc.requires_grad = True

torch_ctc = nn.CTCLoss() 

labels = torch.tensor([[1]] )
labels_size = torch.tensor([1])
T_lengths = torch.tensor([T])

torch.autograd.gradcheck(torch_ctc, [params_ctc, 
        labels ,T_lengths, labels_size])

```

## Expected behavior

The gradcheck call above should pass without error.

## Environment

 - PyTorch Version (e.g., 1.0): 1.7.1
 - OS (e.g., Linux): MacOS
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source):
 - Python version: 3.8
 - CUDA/cuDNN version:   N/A (CPU)
 - GPU models and configuration: N/A
 - Any other relevant information:


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @brianjo @mruberry @jlin27
Repository: rust
Issue: Generic Mul Bound Error
Labels: A-diagnostics,A-trait-system,T-compiler,C-bug,D-invalid-suggestion

I tried this code:

```rust
use cgmath::{Vector3, Point3};
use std::ops::Mul;

#[derive(Debug)]
pub struct Ray<S> {
    pub origin: Point3<S>,
    pub direction: Vector3<S>,
}

impl <S> Ray<S> {
    pub fn new(origin: Point3<S>, direction: Vector3<S>) -> Self {
	Self { origin, direction }
    }

    pub fn at(&self, t: S) -> Self {
	let aaa = self.direction * t;
	Self { origin: self.origin, direction: aaa }
    }
}
```

I expected to see this happen: Compiler suggests the following bound
```rust
where
    Vector3<S>: Mul<S, Output = Vector3<S>>
```

Instead, this happened: Compiler suggests the following bound
```rust
where
    S: Mul<Output = Vector3<S>>
```

the above bound doesn't constrain the generic correctly and the compiler will keep requesting you add it despite it already being present.

### Meta

The bug also occurs when I use nightly.

`rustc --version --verbose`:
```
rustc 1.50.0 (cb75ad5db 2021-02-10)
binary: rustc
commit-hash: cb75ad5db02783e8b0222fee363c5f63f7e2cf5b
commit-date: 2021-02-10
host: aarch64-apple-darwin
release: 1.50.0
```
Repository: godot
Issue: Shaders do not work with Control nodes and their children
Labels: needs testing,topic:shaders

**Godot version:** v3.2.4.rc2.official
**OS/device including version:** Linux 5.10.13-2-MANJARO
**Issue description:** Shader does not work for the source node and his childrens being attached to Control.
**Steps to reproduce:**
* Create new scene witn Control root node;
* Add some childs like Texture, NinePatch, ColorRect, etc.;
* Add ShaderMaterial for root Control node;
* Create simple fade shader with gradient;

![editor_screenshot_2021-02-13T034459+0500](https://user-images.githubusercontent.com/5412322/107830550-e4c7c800-6dad-11eb-84b8-bf9542180bb5.png)

**Minimal reproduction project:** [debug.zip](https://github.com/godotengine/godot/files/5974586/debug.zip)
Repository: godot
Issue: Assigning a new scene node to the Visual Script's function call node causes the node to lose its original node type
Labels: bug,topic:visualscript

<!-- 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 3.2.4 rc2


**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->

- Windows 10 Home 64-bit, Version 20H2, OS build 19042.804
- Intel® UHD Graphics 620, Version 27.20.100.9168


**Issue description:**
<!-- What happened, and what was expected. -->

Assigning a new scene node to the Visual Script's function call node will cause the node to lose its original node type as it reverts back to the type of which belonged to **_self_** node. 

The example is shown below when I assigned a new scene node to it via the inspector. This will cause the script to crash as the node reverted back to the type of which belonged to **_self_** node (MeshInstance) which doesn't have the function of the Tween node type:

https://user-images.githubusercontent.com/1403194/107833881-7108c980-6d73-11eb-88f3-e73f501a9345.mp4

I expect the node to retain its type when assigning a new scene node to it.


**Steps to reproduce:**

1. Open the reproduction project.
2. Enter the script.
3. Try to assign a new scene node (tween node type) to the Tween's start node.
4. Test the project. It will crash as there's no tween function to be called under the MeshInstance node of which the script attached to.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[test2.zip](https://github.com/godotengine/godot/files/5974688/test2.zip)
Repository: create-react-app
Issue: Is it more technically correct to have the line “homepage”: “./” in a React App package.json created by create-react-app?
Labels: issue: proposal,needs triage

https://stackoverflow.com/questions/66175240/is-it-more-technically-correct-to-have-the-line-homepage-in-a-react-app

I tried a React App, and instead of running it off from http://localhost:3000 or 5000, I deployed it to my own website.  However, I found that the line

    "homepage": "./",

is needed in `package.json`, or else all the files needed would be stated as on `/`, so if the app is deployed on mysite.com/try01, then it'd fail, because the app is trying to load everything from `mysite.com/` instead of `mysite.com/try01/`.

So shouldn't the line above be there, so that it is *always relative*, and it works no matter on the root folder or subfolder. Since it is a more universal solution, wouldn't it be more technically correct to have that in every React app? Is there some reason that not having it, provides some advantage in some scenario?