sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: dependencies in go.mod of older versions of modules in require cycles affect the current version's build
Labels: NeedsInvestigation,GoCommand,modules

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.5 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes. 1.13.5 is the latest release at this date.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOOS="linux"
</pre></details>

### What did you do?

I have three modules, a, b and c. All use go modules. a/go.mod requires b and c, and (due to history) b/go.mod requires a. One (or both) of those cyclic requires refers to an older version than the newest, but it's new enough for both a and b to build.

Now I wanted to downgrade module c to an older version. So I edited a/go.mod, and rebuild a. The c line in a/go.mod was edited to the newer version of c, which I had been using before, and which I did not want to use anymore.

Investigating with go mod graph showed that the newer c was required by an older a, which was required by the current b, which was required by the current a. In other words

  a@now -> b@now -> a@older -> c@newer

### What did you expect to see?

I did not expect the a@older/go.mod to be of any consequence to the go modules choice of version of c, since in the end it was going to use a@now to build, not a@older.


### What did you see instead?

go mod graph showed that because of the cycling in the module dependency graph, a@older/go.mod was consulted, as if a@older wasn't an older version of a module already in the graph, but rather some other independent module.

As a consequence a@older's dependencies changed a@now's build.
Repository: youtube-dl
Issue: HUYA SUPPORT 
Labels: site-support-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 2020.01.01. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support 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 new site support request
- [X] I've verified that I'm running youtube-dl version **2020.01.01**
- [X] I've checked that all provided URLs are alive and playable in a browser
- [X] I've checked that none of provided URLs violate any copyrights
- [X] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single video: https://v.huya.com/play/247298790.html
- Single video: https://v.huya.com/play/242184662.html
- Playlist: http://v.huya.com/u/2487318471

## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

WRITE DESCRIPTION HERE
Repository: godot
Issue: "visible_characters" property of Label and RichTextLabel behave differently; discrepancy between whether they acknowledge spaces or not.
Labels: enhancement,confirmed,topic:gui

**Godot version:**
3.1.1
**OS/device including version:**
Ubuntu 16.04 LTS ...I've been too lazy to upgrade :flushed: 
**Issue description:**
The visible_characters property in the node type Label ignores spaces, though the same property on the node type RichTextLabel acknowledges spaces as characters. This is a discrepancy in behavior that can be frustrating.
**Steps to reproduce:**
Just play with the aforementioned properties. See attached example project.

**Minimal reproduction project:**
[visible-characters-bug.zip](https://github.com/godotengine/godot/files/4018364/visible-characters-bug.zip)
Repository: flutter
Issue: [web] Error loading fonts icons are not shown
Labels: tool,platform-web,P2,team-web,triaged-web

When I run the flutter run -d web-server there is a font loading error, icons are not visible after this. 

Launching lib\main.dart on Web Server in profile mode...
Error: unable to locate asset entry in pubspec.yaml: "packages/flutter_gallery_assets/fonts/raleway/Raleway-Regular.ttf".
Error: unable to locate asset entry in pubspec.yaml: "packages/flutter_gallery_assets/fonts/raleway/Raleway-Regular.ttf".
Building application for the web...                               176.3s
lib\main.dart is being served at http://localhost:8080/

Warning: Flutter's support for web development is not stable yet and hasn't
been thoroughly tested in production environments.
For more information see https://flutter.dev/web

🔥  To hot restart changes while running, press "r". To hot restart (and refresh the browser), press "R".
For a more detailed help message, press "h". To quit, press "q".

![image](https://user-images.githubusercontent.com/50856934/71713999-e9573a00-2dc0-11ea-871b-0b7fe3a6b6e0.png)

Note: tested on Chrome on Windows
Repository: pytorch
Issue: Libtorch's files conflict with glog's file?
Labels: module: build,triaged

Hi,guys, i am use libtorch and glog in the same codes in c++,but there are indices some files conflict between each other. The libtorch's logging_is_not_google_glog.h(#define LOG(n)) is conflict with glog's logging.h(#define LOG(severity) COMPACT_GOOGLE_LOG_ ## severity.stream()).The details problem is:
In file included from libtorch/include/c10/util/Logging.h:28:0,
                 from /libtorch/include/c10/core/TensorImpl.h:17,
                 from /libtorch/include/ATen/core/TensorBody.h:11,
                 from /libtorch/include/ATen/Tensor.h:11,
                 from //libtorch/include/ATen/Context.h:4,
                 from /libtorch/include/ATen/ATen.h:5,
                 from /libtorch/include/torch/csrc/api/include/torch/types.h:3,
                 from /libtorch/include/torch/script.h:3,
/libtorch/include/c10/util/logging_is_not_google_glog.h:96:0: warning: "LOG" redefined
 #define LOG(n)                   \
 ^
In file included from /glog/linux/include/glog/logging.h:483:0: note: this is the location of the previous definition
 #define LOG(severity) COMPACT_GOOGLE_LOG_ ## severity.stream()
 ^
In file included from /libtorch/include/c10/util/Logging.h:28:0,
                 from /libtorch/include/c10/core/TensorImpl.h:17,
                 from /libtorch/include/ATen/core/TensorBody.h:11,
                 from /libtorch/include/ATen/Tensor.h:11,
                 from /libtorch/include/ATen/Context.h:4,
                 from /libtorch/include/ATen/ATen.h:5,
                 from /libtorch/include/torch/csrc/api/include/torch/types.h:3,
                 from /libtorch/include/torch/script.h:3,
/libtorch/include/c10/util/logging_is_not_google_glog.h:99:0: warning: "VLOG" redefined
 #define VLOG(n) LOG((-n))
 ^
In file included from /glog/linux/include/glog/logging.h:1068:0: note: this is the location of the previous definition
 #define VLOG(verboselevel) LOG_IF(INFO, VLOG_IS_ON(verboselevel))
Does anyone can tell me how to deal with it?My environment is ubuntu16.04 pytorch1.3 libtorch libtorch-cxx11-abi-shared-with-deps-1.3.1.zip,qt5.5. tkx.
Repository: excalidraw
Issue: Investigate Cypress for UI tests
Labels: test

Preliminary tests show promise. I'll try to write a few tests and make a PR if it feels good.
Repository: go
Issue: x/tools/gopls: respect staticcheck config file
Labels: FeatureRequest,gopls,Tools

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

govim is using commit `f13409bb`, which is pretty new, and it reproduces

### 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="/Users/llimllib/go/bin"
GOCACHE="/Users/llimllib/Library/Caches/go-build"
GOENV="/Users/llimllib/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/llimllib/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/llimllib/code/tools-golang/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/r4/mc760j7j6xjdgr5p5hxk_xrw0000gq/T/go-build877572449=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

I don't know how to use `gopls` directly, so here's how to reproduce through `govim`

1. Create a directory
2. Create a `staticcheck.conf` file with these contents:
```toml
checks = ["all", "-ST1005"]
```
3. Create a main.go file:
```go
package main

import "fmt"

func main() error {
	return fmt.Errorf("This capitalized error should be ignored but isn't")
}
```
4. Note that running `staticcheck .` or `staticcheck main.go` do not raise any errors
5. Turn on vim, with govim installed and staticcheck enabled via `call govim#config#Set("Staticcheck", 1)`
6. Note that govim flags error `ST1005` on line 6

Reading the gopls logs from govim shows:

```
[Trace - 10:10:46.572 AM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///private/tmp/govim-bug/main.go","version":1,"diagnostics":[{"range":{"start":{"line":5,"character":18},"end":{"line":5,"character":18}},"severity":2,"source":"ST1005","message":"error strings should not be capitalized","tags":[1]}]}
```

As you can see from the config, `ST1005` ought to be ignored for this file.

(I feel pretty certain that `govim` isn't doing anything wrong in how it launches or communicates with `gopls`? But if I've got this error filed on the wrong side of that divide, I apologize)

### What did you expect to see?

No ST1005 errors flagged on main.go

### What did you see instead?

An ST1005 error flagged on main.go
Repository: godot
Issue: Image texture is not displayed in exported project untile window is resized
Labels: bug,topic:rendering

**Godot version:** 3.1.2

**OS/device including version:** Linux

**Issue description:** 
I am working with color splatter effect in godot and found some wierd bug. It works fine while game is launched from IDE but in exported project it doest show the overlay image untile window is resized. See gif
![ezgif com-video-to-gif(1)](https://user-images.githubusercontent.com/29702428/71736703-c76cbe80-2e77-11ea-9a5e-b4899a9aa7fc.gif)
 
It might be a project releated bug but I didnt find any workaround so I am posting it here. 

**Steps to reproduce:**
1. Download the exported project (linux) [color-splatter-effect.zip](https://github.com/godotengine/godot/files/4020013/color-splatter-effect.zip)

**Minimal reproduction project:**
https://github.com/Janglee123/godot-color-splatter-effect
Repository: TypeScript
Issue: Mapped types shouldn't transform any type
Labels: Suggestion,In Discussion

@ahejlsberg Can you remember #29793 and this?

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.7.x-dev.20200101

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
type M<T> = { [P in keyof T]: T[P] };
type a = M<any>;
```

**Expected behavior:**
Type a is `any`.
**Actual behavior:**
Type a is `{ [x: string]: any; }`.
**Playground Link:** https://www.typescriptlang.org/play/index.html?ts=3.8.0-dev.20200101&ssl=1&ssc=1&pln=30&pc=1#code/C4TwDgpgBAsgPAFQHxQLxQN5QNoAUoCWAdlANYQgD2AZlAgLoBcde9UAvgNwBQokUAQzSw4AoiCScgA

**Related Issues:** #29793
Repository: pytorch
Issue: logsumexp: two little-impact perf suggestions
Labels: module: performance,module: cpu,triaged,module: reductions

https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/ReduceOps.cpp#L372

1. Could probably do exp in-place?
2. Hopefully `torch.isinf` could be made to not allocate a full copy with abs call (currently [same](https://github.com/pytorch/pytorch/blob/bcb0bb7e0e03b386ad837015faba6b4b16e3bfb9/torch/functional.py#L284) happens in Python impl of `torch.isinf`)

cc @VitalyFedyunin @ngimel @mruberry
Repository: pytorch
Issue: Support rpc/remote torch script call with script class/module name and class/module method name
Labels: oncall: jit,triaged,module: rpc

Current rpc torch script call only supports annotated global torch script function defined by users, ideally we should support torch script call with script class/module name and class/module method name as well. This is follow up on PR #30063


cc @suo @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @xush6528 @jjlilley
Repository: TypeScript
Issue: Allow accessors to support inline generics for this
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

getter, accessor, this, generic

## Suggestion
Currently accessor declarations do not support generics at the declaration site. The error returned is `An accessor cannot have type parameters.ts(1094)`.  Currently the accessor can implement generic declaration via the enclosing class.  The goal would be to allow for the accessor to support a generic `this` at the declaration site.

## Use Cases

The use case is to allow for more expressive setter/getter declarations, in line with how method declarations currently work.  

## Examples

### Suggested Pattern
Below is an example of defining the constraints of `this` at the accessor site, to determine if an inherited accessor method is valid by the shape of the subclass.

```typescript
class Base {
   get left<T extends { _left: string}>(this: T) {
       return this._left;
   } 
   get right<T extends { _right: string}>(this: T) {
       return this._right;
   } 
}

...
class Left extends Base {
    _left: string = '';
}
new Left().left; // OK
new Left().right;  // Errors

...
class Right extends Base {
   _right: string = '';
}
new Right().right; // OK
new Right().left; // Errors

...
class Both extends Base {
   _right: string = '';
   _left: string = '';
}
new Both().right; // OK
new Both().left; // OK
```

This pattern can currently be emulated by converting the accessors into standard methods
```typescript
class Base {
  getLeft<T extends { _left: string}>(this: T) {
      return this._left;
  } 
  getRight<T extends { _right: string}>(this: T) {
      return this._right;
  } 
}

...
class Left extends Base {
   _left: string = '';
}
new Left().getLeft(); // OK
new Left().getRight(); // Errors

...
class Right extends Base {
  _right: string = '';
}
new Right().getRight(); // OK
new Right().getLeft(); // Errors

...
class Both extends Base {
  _right: string = '';
  _left: string = '';
}
new Both().getRight(); // OK
new Both().getLeft(); // OK
```

## Checklist

My suggestion meets these guidelines:

* [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [X] This wouldn't change the runtime behavior of existing JavaScript code
* [X] This could be implemented without emitting different JS based on the types of the expressions
* [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: TypeScript
Issue: Insert semicolon on typing fails after typing function block
Labels: Bug

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.8.0-20200.103

Observed in Visual Studio and VSCode

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
semicolon 

After typing out a function block, semicolon insertion on new line stops working inside of and before the function block, but not after. Explicitly formatting by sending the format command *does* insert the semicolons as expected.

**Code**

Typed in alphabetical order:

**Expected behavior:**
```ts
var a;
var d;

function b(){
    var c;
}

var e;
```

**Actual behavior:**
```ts
var a;
var d

function b(){
    var c
}

var e;
```
Repository: rust
Issue: const simd_extract/insert are no longer usable in latest nightly (2020-01-02)
Labels: T-compiler,B-unstable,A-SIMD,A-const-eval,requires-nightly

A few months ago #64738 introduced `const` `simd_insert`/`simd_extract`, which I then integrated into my application via a fork of `packed_simd`.

However, upon upgrading to the latest nightly (`rustc 1.42.0-nightly (0a58f5864 2020-01-02)`), it was suddenly non-const. 

Furthermore, It seems the ability to make it `const` via `rustc_const_unstable` is not possible in user applications, making the `const` versions of this effectively rustc internal-only now, breaking my fork of `packed_simd` and my application.
Repository: TypeScript
Issue: Updating Windows contributor requirements to run Windows 10
Labels: Discussion,Infrastructure

We recently ran into a situation where git errored during a `checkout` due to a file path that was too long.

https://github.com/microsoft/TypeScript/pull/35711#issuecomment-570730960

To get around this, we can run

```
git config core.longpaths true
```

However, it seems that this option requires Windows users to run Windows 10. It doesn't affect other users.

Everyone on the core team who's on Windows is basically on the latest version, and we don't have reason to believe at the moment that this affects many external contributors. As a result, we will likely turn on the flag and adjust appropriately if this becomes an issue.
Repository: flutter
Issue: Allow Embedder API to pass ICU data as buffer
Labels: engine,e: embedder,c: proposal,P2,team-engine,triaged-engine

As an embedder of the flutter engine it seems to be a recurring error to crash because of missing ICU data. Typically this is the embedder's own fault, maybe the path was wrong, or maybe s/he passed the wrong version of it.

There is however another way to pass this data to the engine, embedded in an object file. This approach seems better, eliminating the need to pass around files and getting their paths correct. This approach is now used for the Android target.

There is however a drawback: it seems there is no platform independent way to embed the data into an object file.

**The proposal is therefore to allow the embedder an alternative way of passing the data, via a buffer and a size.**

More concretely, add:
```
struct FlutterProjectArgs 
{
...
  /// ICU data to use. Allows the embedder to provide ICU data anyway they seem fit.
  const uint8_t* icu_data;
  /// The size of the ICU data buffer. 0 if not used.
  size_t icu_data_size;
...
}
```

Internally, this data can be wrapped in `settings.icu_mapper`- the code is already in place.

This is analog to how a number of user provided binaries are passed to the engine, such as dart vm blobs/snapshots.
Repository: rust
Issue: rustdoc: provide more context for parse errors in code blocks
Labels: T-rustdoc,C-enhancement,A-diagnostics,A-parser

Split from #67563.

Currently, the bad_codeblock_syntax_pass in rustdoc provides error messages like the following:

```
warning: could not parse code block as Rust code
  --> $DIR/invalid-syntax.rs:3:5
   |
LL |   /// ```
   |  _____^
LL | | /// \__________pkt->size___________/          \_result->size_/ \__pkt->size__/
LL | | /// ```
   | |_______^
   |
   = note: error from rustc: unknown start of token: \
   = note: error from rustc: unknown start of token: \
   = note: error from rustc: unknown start of token: \
```

Ideally, we could display the error spans inline (but downgrade them to warnings).
Repository: godot
Issue: Text exceeds item boundary with custom font
Labels: bug,topic:editor,confirmed,topic:gui

**Godot version:** v3.2.beta.custom_build.34c71157f

**OS/device including version:** macOS Catalina 10.15.2 / MacBook Pro (Retina, 13-inch, Early 2015)

**Issue description:**
When using [NotoSansCJKsc-Regular.otf](https://noto-website-2.storage.googleapis.com/pkgs/NotoSansCJKsc-hinted.zip) ([Site](https://www.google.com/get/noto/help/cjk/)) as the main editor font, a long filename in the Open Scene dialog exceeds the item (cell) boundary.

![comparison](https://user-images.githubusercontent.com/372476/71760096-f4aa8280-2ef2-11ea-8296-328483629a1b.gif)

The complete filename is quite long: new-years-eve-2019-4659144240922624-l.png

I can confirm that this behavior starts from 3.2 alpha0, and using the default font do not have this issue.

**Steps to reproduce:**
1. Download the NotoSansCJKsc-Regular.otf mentioned above
2. Open the Editor menu and choose Editor Settings
3. For the Interface / Editor / Main Font property, choose the font file
4. Prepare a long named file in your project directory
5. Find the file in the Open Scene dialog
Repository: godot
Issue: Selecting and edit tilemap issues
Labels: bug,topic:editor,topic:2d

**Godot version:**
3.2 beta 5

**OS/device including version:**
windows 10, 64

**Issue description:**
Issues when selecting a tilemap:
- mode is always changed to "Select Mode" 
- right click to delete tile triggers panning instead
Repository: pytorch
Issue: Fix softplus clampling issues using logsigmoid
Labels: module: nn,triaged

Softplus (torch.nn.functional.softplus) requires a threshold for numerical reasons. However this threshold can be removed by using the Logsigmoid (torch.nn.functional.logsigmoid) implementation.

Softplus is a non-linear activation function, with parameter beta, defined by

`softplus(x) = (1/beta) log(1+exp(beta * x))`

Some mathematical manipulations let you rewrite this as the Logsigmoid function

`softplus(x)`
`= (1/beta) log(1 + exp(beta * x))`
`= - (1/beta) log(1 / (1 + exp(beta * x)))`
`= - (1/beta) log(1 / (1 + exp( -(-beta * x))))`
`= - (1/beta) logsigmoid(-beta * x)`

Implementing this should be fairly easy, and solves any issues arising from clamping/numerical stability.