sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Suggest comparison with binary char when comparing u8 with char literal
Labels: C-enhancement,T-compiler,A-suggestion-diagnostics

Currently attempting to compare a `u8` with a literal `char` gives a generic error about missing trait implementations:

```rust
let mut next: u8;
...
while next != ']' {
```

> can't compare `u8` with `char`    no implementation for `u8 == char`   
> help: the trait `std::cmp::PartialEq<char>` is not implemented for `u8`

As the comparison is being made between a single, literal char (vs a runtime value or multiple characters), I believe it is safe for a help message suggesting comparing against `b'…'` instead.

e.g. something along the lines of

> can't compare `u8` with `char`    no implementation for `u8 == char`    
> help: did you mean to compare with b'X' instead?

Ideally `X` would be substituted with the actual value that was in the code.
Repository: go
Issue: time: NewTimer firing later if computer sleeps, how to use wall clock?
Labels: help wanted,OS-Darwin,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
go version go1.11.4 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>
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/gabriel/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/gabriel/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=""
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/gj/lr5vqgfn7jj_431xw83k37qc0000gn/T/go-build372524712=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?
```
go func() {
	timer := time.NewTimer(timeUntilAlarm)
	select {
	case <-timer.C:
		log.WithField("event", event.Summary).Info("Firing alarm for event")
		alarmFired <- event
	case <-ctx.Done():
		// alarm cancelled
		timer.Stop()
	}
}()
```

### What did you expect to see?

This works until my macbook goes to sleep (macOS) I'm guessing that it's because of the monotonic clock stopping. Is there a way to create a Timer that fires using the wall clock?

I need the alarm to fire at the right time (after x amount of minutes/hours have passed) regardless of whether the computer went into sleep mode in between the time when the timer was created and when it was supposed to fire.

### What did you see instead?
If macbook goes to sleep, timer clock stops and it fires way later than it was supposed to (depending on how long the computer slept)
Repository: node
Issue: --use-strict flag doesn't apply strict mode to script
Labels: confirmed-bug,v8 engine

* Node 12.*:
* Windows 64bit, Debian 64bit:

The `--use-strict` flag doesn't apply strict mode to script.
reproduction:
```
echo a = 1 > test.js && node --use-strict test
```
expected behavior:
    `ReferenceError: a is not defined` is thrown.
behavior:
    script executes without any issue.

however it works as expected when node is started first and script is called from repl.
<12 versions aren't affected. 

```
node --use-strict
Welcome to Node.js v12.12.0.
Type ".help" for more information.
> a = 1
Thrown:
ReferenceError: a is not defined
>
```
Repository: rust
Issue: `dylib` shared libraries will not make public symbols that may be necessary to link inlined code
Labels: A-linkage,P-medium,T-compiler,regression-from-stable-to-stable,C-bug

When a `dylib` crate has a public `inline(always)` functions in it that use, as an implementation, other, private functions, using these public functions from other crates will fail with linkage errors because we fail to "export" the private functions.

An example project can be seen [here](https://gitlab.com/nagisa/sample-example-for-rust-bernacle/tree/master). In this example the `driver` dylib crate privately `extern`s a symbol from a static C library and uses it to implement an `inline(always)` interface/wrapper. The `user` crate then attempts to use the `inline(always)` wrapper, but linking fails with an error such as this:

```
/tmp/user/driver/src/lib.rs:8: undefined reference to `private_extern_symbol'
```

When inspecting the `libdriver.so` we can see that the extern symbol does indeed exist but is "private":

```
0000000000001100 t private_extern_symbol
```

I think we might be un-exporting items too aggressively here. cc @michaelwoerister @oli-obk 

Blocks https://github.com/rust-lang/rust/pull/55617

Regression from 1.36.0 (example builds successfully) to 1.37 (example fails to build).
Repository: go
Issue: cmd/go: unclear error when server does not provide 'go-import' metadata for a module in a subdirectory
Labels: Documentation,NeedsInvestigation,modules

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.1 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/wolf/.cache/go-build"
GOENV="/home/wolf/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/wolf/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/wolf/tmp/golang_test/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build652827916=/tmp/go-build -gno-record-gcc-switches"
</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.
-->

Created go module:

```
+$ tree .
.
└── bar
    ├── bar.go
    └── go.mod

1 directory, 2 files
+$ find . -name .git -prune -o -type f -print -exec cat {} \;
./bar/bar.go
package bar

func Bar() string {
        return "bar"
}
./bar/go.mod
module git.sr.ht/~graywolf/foo/bar

go 1.13
```

pushed it to the repository (`https://git.sr.ht/~graywolf/foo`) and tried to use it in following program:

```
package main

import (
        "fmt"
        "git.sr.ht/~graywolf/foo/bar"
)

func main() {
        fmt.Println(bar.Bar())
}
```

### What did you expect to see?

```
+$ go run sr.go
bar
```

### What did you see instead?

```
+$ go run sr.go
go: finding git.sr.ht/~graywolf/foo latest
build command-line-arguments: cannot load git.sr.ht/~graywolf/foo/bar: module git.sr.ht/~graywolf/foo@latest (v0.0.0-20191019153505-33a4721605aa) found, but does not contain package git.sr.ht/~graywolf/foo/bar
```
Repository: godot
Issue: Bad performance using AnimationTree when multithreaded
Labels: bug,topic:core,needs testing

Sorry for weird bug report in here, but I do not have time to dig deeper now.
This is for master branch of Friday, October 18 2019.
I have a character scene with AnimationTree (25K poly/160 bones per character), I add 30 characters to main scene playing the same idle animation (random waving mainly) which is set up using AnimationTree. If I enable thread model as "multiple threads" I get 20 FPS and if I set threading model "single safe" I get 60 FPS, no other changes are there.
If I disable AnimationTree I get 60FPS in both cases. Do anybody had the same observation?
I had to disable threads because of this and now performance is normal, so the issue is not in anyway urgent for me, but I just want to let people know.
Repository: vue
Issue: Symbol-keyed properties non-reactive
Labels: feature request

### Version
2.6.10

### Reproduction link
[https://jsfiddle.net/dansebcar/b75n0uw6/16/](https://jsfiddle.net/dansebcar/b75n0uw6/16/)







### Steps to reproduce
- Press update to change each item's name to "b"

### What is expected?
The list re-renders with the new name

### What is actually happening?
The list does not change

---
If we instead define "symbol" as any non-empty string, the expected re-render is observed, so I think the cause is just the parent list (items) is accessed through a symbol.

Nesting the symbol property an additional level (IE in config, rather than directly on data) is necessary to render the list at all; I guess symbols from data aren't directly transferred?

I noticed in the devtools when I pressed "refresh" after mutating the items that I could see the new name, so I assumed something about the way I was setting the property didn't trigger the update, but even Vue.set did not help.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: godot
Issue: Updating MeshLib may result in incorrect cell items, unless .import folder is cleaned
Labels: bug,topic:editor,confirmed

**Godot version:** 3.1, 3.1.1, 3.2

**OS/device including version:** Windows 10 64-bit

**Issue description:**
- When you update your existing Mesh Library, by adding / deleting / changing / renaming items; your new MeshLib may have missing / incorrect meshes as well as missing / incorrect texture previews
- A consistent solution to such bugs is to delete .import folder and reimport your 3D file / scene and meshlib
- This seems to affect all versions starting from 3.1 at least 

**Steps to reproduce:**
1) Add your working meshlib to a gridmap, test your tiles
2) Update your meshlib, by adding / deleting meshes or by renaming them
3) Test your gridmap again - you may observe missing / incorrect items
4) Delete your .import folder and (maybe) re-create your meshlib - now everything is working as expected
Repository: go
Issue: cmd/compile: expected "not used" error
Labels: NeedsInvestigation,compiler/runtime

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.1 linux/amd64
</pre>

### Does this issue reproduce with the latest release?


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/me/.cache/go-build"
GOENV="/home/me/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/me/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build399130454=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.13.1 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.13.1
uname -sr: Linux 5.0.0-31-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.3 LTS
Release:	18.04
Codename:	bionic
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.27-3ubuntu1) stable release version 2.27.
gdb --version: GNU gdb (Ubuntu 8.1-0ubuntu3.1) 8.1.0.20180409-git
</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://play.golang.org/p/O_76qweGQ0g

```
package main

func main() {
	var x int
	x = 7 - x
}
```
### What did you expect to see?

Although x is used in assignment over itself, there is no usage of x, it is nice to get "not used" error for preventing unnecessary computations.

### What did you see instead?

Nothing, run successfully
Repository: go
Issue: x/crypto/ssh: Unable to start subsystem without an exec or shell message 
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.3 openbsd/amd64
</pre>

### Does this issue reproduce with the latest release?
It does.


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/stuart/.cache/go-build"
GOENV="/home/stuart/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="openbsd"
GONOPROXY=""
GONOSUMDB=""
GOOS="openbsd"
GOPATH="/home/stuart/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/stuart/.go/1.13.3"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/stuart/.go/1.13.3/pkg/tool/openbsd_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="0"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -fmessage-length=0"
</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.
-->
Wrote a little server which implemented an SSH subsystem and tried to write a client to use that subsystem.
A minimal server: http://play.golang.org/p/HtAmPnyMpDl
A minimal client: http://play.golang.org/p/VqSuWARBHJT

### What did you expect to see?
Output from the subsystem


### What did you see instead?
That the session hadn't been started.


When starting a subsystem, a channel is opened and a `subsystem` request is sent with the name of the subsystem.  According to [RFC4254](https://tools.ietf.org/html/rfc4254#section-6.5) exactly one of `shell`, `exec`, or `subsystem` requests can succeed per channel, though it doesn't say that only one may be sent.  Currently, the subsystem request is sent with session.RequestSubsystem, but there is no way to call the non-exported session.start without calling session.Start (which sends an `exec` request) or session.Shell (which sends a `shell` request).  This means that to start subsystem, the server will first receive a `subsystem` request and then an `exec` or `shell` request.  Changing session.RequestSubsystem to call session.start (i.e. to parallel session.Shell and session.Start) causes the server to start the subsystem and delivers output to the client.

The OpenSSH client only sends a `subsystem` message.  The OpenSSH server replies with false `exec` request following a `subsystem` request.
Repository: flutter
Issue: Write test for FlutterFragmentActivity in framework devicelab test suite
Labels: a: tests,team,framework,engine,a: existing-apps,P2,team-engine,triaged-engine

Write test for FlutterFragmentActivity in framework devicelab test suite

For example, to cover things like this:
https://github.com/flutter/engine/pull/13214
Repository: neovim
Issue: TUI thread / environment hygiene
Labels: needs:design,environment,tui,has:plan

@erw7:

> Related to #11259: `gettext()` calls `getenv()` internally, so I think we need the same exclusive control as #11259. However, the TUI thread does not include a `gettext()` call, so only os_getenv() can be called during a `gettext()` call. ISO/IEC 9899:1999 has the following description of `getenv()`.
>
> ```
> The string pointed to shall not be modified by the program, but may
> be overwritten by a subsequent call to the getenv function.
> ```
>
> Therefore, strictly speaking, exclusive control is necessary. I'm wondering if there are any implementations that actually need exclusive control, but should `gettext` be controlled exclusively?


@justinmk:

> wouldn't this problem exist even if we were using gettext + getenv (not
> the os_getenv wrapper) ?

@erw7:

> Regardless of whether or not `os_getenv()` is used, it is necessary to call
> `getenv()`, `setenv()`, and unsetenv() exclusively.


I think we shouldn't worry about this. neovim/neovim#10071 will reduce the need for an extra thread.

Plan:

- we should focus on eliminating the extra thread .
- we should avoid using env vars in the TUI thread.
- we definitely should not use gettext there.
- E.g. `$TERM` could be passed from the main thread, to the TUI thread, from `ui_builtin_start()`.
- We could add `unibi_from_params` which takes parameters instead of checking the environment itself.
Repository: go
Issue: x/mobile: gomobile +6d0d39b incompatible with NDK 20.0.x
Labels: NeedsInvestigation,mobile

### What version of Go are you using (`go version`)?

<pre>
$ go version
gomobile version +6d0d39b Wed Oct 2 17:59:09 2019 +0000 (android); androidSDK=/opt/android-sdk/platforms/android-29
</pre>

### Does this issue reproduce with the latest release?
Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/arp/.cache/go-build"
GOENV="/home/arp/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/opt/go-packages"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build030033936=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
gomobile clean
gomobile init

### What did you expect to see?
Should not show following error!!

### What did you see instead?
```
gomobile: No compiler for 386 was found in the NDK (tried /opt/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/i686-linux-android16-clang). Make sure your NDK version is >= r19c. Use `sdkmanager --update` to update it.

gomobile bind
gomobile: No compiler for amd64 was found in the NDK (tried /opt/android-sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android21-clang). Make sure your NDK version is >= r19c. Use `sdkmanager --update` to update it.

```

### Android NDK version 
Android NDK r20.0.x
Repository: go
Issue: syscall: windows doesn't allow read-only directories
Labels: Documentation,OS-Windows,NeedsInvestigation,compiler/runtime

On Windows, right now we map the lack of the writable bit in Unix file permissions to FILE_ATTRIBUTES_READONLY.  This sort of works fine, but MSDN says that it's not honored for directories. This has implications for the Go module cache.

I'm not suggesting that we change this mapping to something else right now, but in case things pop up down the line related to this, here's a bug to track it.

cc @bcmills @alexbrainman
Repository: go
Issue: syscall: windows doesn't allow renames for read-only files
Labels: Documentation,OS-Windows,NeedsFix

On Windows, right now we map the lack of the writable bit in Unix file permissions to FILE_ATTRIBUTES_READONLY.  This sort of works fine, but this actually prohibits rename-in-place, whereas it's allowed on Unix.

I'm not suggesting that we change this mapping to something else right now, but in case things pop up down the line related to this, here's a bug to track it.

cc @bcmills @alexbrainman
Repository: TypeScript
Issue: Create a parser npm module
Labels: Suggestion,Awaiting More Feedback

## Search Terms

- parser
- parser module

## Suggestion

use the parser part of typescript and create a npm module from it to be used without the whole typescript (a few megabytes)

## Use Cases

parsing typescipt & javascript to AST

## 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: go
Issue: cmd/link: allow asking linker to *not* eliminate a "dead" function
Labels: NeedsInvestigation,compiler/runtime

We have some assembly code in our Go binary that is never directly called by any Go code in userspace. (It's intended to be handed to the kernel to execute during a `kexec` in ring 0. Kernel hands execution to this piece of Go assembly, Go assembly hands it to a kernel we're booting.)

Normally, this code would be optimized out of the final binary by the linker. So far, we can get around that with this: https://github.com/u-root/u-root/blob/ac7ae682c648c26a7c90ac73a2a8b4597bdbeb78/pkg/multiboot/internal/trampoline/trampoline_linux_amd64.go#L39

Arguably a hack that will eventually be optimized away by the compiler.

Can we have a directive to not optimize away a piece of code? "//go:nodelete"? This is the assembly in question that shouldn't be optimized away: https://github.com/u-root/u-root/blob/ac7ae682c648c26a7c90ac73a2a8b4597bdbeb78/pkg/multiboot/internal/trampoline/trampoline_linux_amd64.s#L29
Repository: pytorch
Issue: torch.multinominal ignores elements from cumulative distribution
Labels: module: cpu,triaged,module: random

## 🐛 Bug

torch.multinominal for CPU calculates cumulative distribution internally to generate samples. If the exponents of the probabilities in one row have significantly different values (e.g. half < 1e-15 and others > 1e+15) the optimized local cumulative sum does not work as expected. The issue exists because we lose mantissa when calculating cumulative distribution, summarizing large and small numbers, and is not longer monotonically increasing. 

Example:
input = [1e+15, 1e-15, 1e-15, 1e-15]
cumsum = [1e+15, 1e+15, 1e+15, 1e+15] //lost of mantissa
random = sum * rand(0, 1) = 1e+15 * rand(0, 1) => always a zero index

so function will never return values in the tail.

cc @VitalyFedyunin