sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Waker::will_wake() gets mostly defeated by executor optimizations
Labels: C-enhancement,T-libs-api,A-async-await,AsyncAwait-Triaged,C-optimization

The Futures `Waker` API provides a [Waker::will_wake()](https://doc.rust-lang.org/beta/std/task/struct.Waker.html#method.will_wake) method which tries to determine whether the 2 `Waker`s are equivalent. It intends to allow `Future`s so determine whether they have to swap a `Waker` or have to can keep an already stored one which is equivalent. That can avoid some churn on atomic refcounts on those `Waker`s.

The `will_wake` method [is implemented by a `PartialEq` derive on `RawWaker`](https://doc.rust-lang.org/beta/src/core/task/wake.rs.html#279-281) - which means `will_wake()` will return `true` only if the pointer as well as the vtable in `RawWaker` are equivalent.

However futures executors are moving more and more towards a design where they lazily create the "real" storeable `Waker`, and only provide a `Waker` reference to tasks they poll.  E.g. `futures-rs` uses [WakerRef](https://github.com/rust-lang-nursery/futures-rs/blob/master/futures-task/src/waker_ref.rs) [tokio does the same](https://github.com/tokio-rs/tokio/blob/d5c1119c881c9a8b511aa9000fd26b9bda014256/tokio/src/runtime/task/waker.rs#L9-L28). This avoids an atomic increment and decrement cycle for each task that an executor polls.

However this means the `RawWaker` that the executor passes through the `Context` parameter will now always be different to the one stored inside a `Future` and `will_wake()` will return false. Which causes the `Future` to update the `Waker` reference (2 atomic ops). If the executor polls a couple of sub-tasks which now all swap out their `Waker`s the original executor optimization could now even lead to de-optimization - since the result is more atomic ops in other places.

Using the `will_wake()` method makes most sense exactly inside the `.poll()` method of a `Future` in order to determine whether a stored `Waker` needs to get updated. This is now the exact same point where the `WakerRef`  would return the false negative. Therefore using `.will_wake()` is not that helpful given the state of the executor ecosystem.

So far for the description of the issue. The next question is whether this can be improved or solved. I don't think changing `PartialEq for RawWaker` - e.g. to conly compare the data pointer - makes sense. It will likely only lead to false positives (`waker.will_wake(other) == true`). Which then leads to missing wakeups aka live-locks.

The original design of `RawWaker` plus `Vtable` contained a vtable entry for `will_wake()`. This would have definitely helped to solve the issue, since the executors would have been able to overwrite the check and to be able to associate `Waker`s  and their `WakerRef`s.  However this was removed for simplification purposes.

I think one possible outcome could be to keep this issue as a tracking issue for the deficit. And if there is ever a change to the vtable for other reasons to also add a `will_wake` method back. Up to then it's probably not worth an update.
Repository: neovim
Issue: API: listen only for cursor state without grid_lines
Labels: enhancement,performance,api,ui

From: #11367 

> 3\. Don't need `lines` / `grid_lines` event at all if there will be API to get HL states. So toggle/ui-option to get only cursor updates will be very good to save rpc bandwidth

Allow to listen for only for the cursor state, without ```lines/grid_lines``` events. May be ui-option like ```ext_cursor``` which will send updates for both screen line/col positions and buffer line/col positions
Repository: rust
Issue: Missing object files when linking with LTO
Labels: A-linkage,O-macos,A-cross,T-compiler,C-bug

### Situation

I'm trying to add a dependency to [SPIRV-Cross](https://github.com/KhronosGroup/SPIRV-Cross) for Gecko, and I'm seeing [linking errors](https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=274841436&repo=try&lineNumber=37327) (with undefined symbols) *only* in the "OS X Cross Compiled asan" job (cross-compiled macosx with address sanitizer and fuzziness. Non-fuzzy (non-asan) cross-compiled builds are fine.

This has been blocking a very [large and important change](https://phabricator.services.mozilla.com/D49458) to Gecko for about a week. I would appreciate any hints on how to approach this!

### Problem

The objects of SPIRV-Cross are supposed to reach the linker by the following path:
  1. The C++ project is built into `libspirv-cross-rust-wrapper.a` by "cc-rs" that is invoked from the `build.rs` of [spirv_cross](https://github.com/kvark/spirv_cross/tree/wgpu) crate
  2. That crates produces a regular Rust library that is statically linked with this `.a` file
  3. It is a dependency of other crates, eventually making its way to the `gkrust` crate, which is the root.
  4. `libgkrust.a` is a static C library build by Gecko
  5. Gecko static libraries are linked into XUL dynamic library

I can inspect `libspirv-cross-rust-wrapper.a` with `llvm-objdump` and I see everything is in place as expected: [objdump-local.txt](https://github.com/rust-lang/rust/files/3829870/objdump-local.txt). I don't know how to properly inspect the `rlib` or `rmeta` of the Rust library products. I can, however, inspect `libgkrust.a` and see that some of the SPIRV-Cross objects didn't make it: [libgkrust-objdump.txt](https://github.com/rust-lang/rust/files/3829874/libgkrust-objdump.txt) (e.g. it has `spirv_cfg.o` but no `spirv_cross.o`). The selection appears to be arbitrary but consistent between compilations. From that, I conclude that the metadata about statically linked objects is not propagated through steps 2-3, which is what Cargo/Rustc are responsible for (!).

I'm able to reproduce the linking errors locally on linux, by downloading the artifacts and enabling both ASAN and fuzziness options in [mozconfig-cross.txt](https://github.com/rust-lang/rust/files/3829841/mozconfig-cross.txt). I confirmed that removing the "--enable-fuzzing" option makes it link fine.

I understand that this is a very big project, and it's not trivial to replicate the setup. However, so far, attempts to reproduce this on a reduced test case were not fruitful.

### Further observations

It appears that Gecko has only handful of dependencies on C/C++ code by the vendored Rust crates, and all of them are either C or Obj-C, using `clang` for compiling (via "cc-rs" crate). SPIRV-Cross dependency is the only one in C++ using `clang++`, which makes it rather unique.

I'm also attaching the reduced verbose build log that only rebuilds spirv-cross related pieces: 
[detailed-build.log](https://github.com/rust-lang/rust/files/3829865/detailed-build.log).


cc @jrmuizel @alexcrichton
Repository: rust
Issue: Stabilize `#[bench]` and `Bencher`?
Labels: T-lang,T-libs-api,B-unstable,A-libtest

I’ll take the liberty of copying a section of @hsivonen’s [Rust 2020 blog post](https://hsivonen.fi/rust2020/):

> ## Non-Nightly Benchmarking
>
> The library support for the `cargo bench` feature has been in the state “[basically, the design is problematic, but we haven’t had anyone work through those issues yet](https://users.rust-lang.org/t/timeline-for-libtest-stability/3123/3)” since 2015. It’s a useful feature nonetheless. Like I said a year ago and the year before, it’s time to let go of the possibility of tweaking it for elegance and just let users use it on non-nighly Rust. 

Indeed the existing benchmarking support has basically not changed in years, and I’m not aware of anyone planning to work on it. To keep reserving the right to make breaking changes is not useful at this point. [Custom test frameworks](https://github.com/rust-lang/rust/issues/50297) offer another way forward for when someone does want to work on better benchmarking.

So I’d like to propose a plan:

* Move `test::Bencher` to `std::bench::Bencher`. <del>I have a PR coming soon that</del> <ins>https://github.com/rust-lang/rust/pull/66290</ins> demonstrates that this is possible. This move avoids the need to stabilize the `test` crate.
* Optionally, make some surface-only API tweaks to `Bencher`. For example, the public `bytes` field could become a parameter to some method.
  * Although not strictly necessary for changes to an unstable type, we can keep the existing `bytes` field and `iter` method unchanged as unstable + deprecated for a while.
* **Stabilize** the `#[bench]` attribute and just enough of `Bencher` to make it usable with `#[bench]`. (For example, no stable constructor.)

@rust-lang/libs, @rust-lang/lang, do you feel this needs an RFC?
Repository: flutter
Issue: [in_app_purchase] Not receiving receipt in the purchase process
Labels: p: in_app_purchase,package,team-ecosystem,P2,triaged-ecosystem

We have implemented subscriptions using the in_app_purchase plugin and we detected that our  users are experiencing problems activating the subscription. Our flow is the following:

When user subscribe to our service we save the first receipt to our backend and then we use server-to-server notifications to get the renewals and bind the renewal to the user and extend the access to the service.

The problem we have detected is that a high percentage of users are not receiving the receipt during the purchase flow. It seems that the purchaseUpdatedStream is not receiving the receipt. That happens with a percentage of our Android users and most of users in IOS. Why do that usually happens?
Repository: pytorch
Issue: Tensorboard GPU Problems
Labels: module: cuda,triaged,module: tensorboard

## 🐛 Bug

When I train a model without importing tensorboard everything works fine. when I import it I get the following warning:

> lib/python3.7/site-packages/torch/nn/parallel/data_parallel.py:26: UserWarning: 
>     There is an imbalance between your GPUs. You may want to exclude GPU 2 which
>     has less than 75% of the memory or cores of GPU 0. You can do so by setting
>     the device_ids argument to DataParallel, or by setting the CUDA_VISIBLE_DEVICES
>     environment variable.
>   warnings.warn(imbalance_warn.format(device_ids[min_pos], 

Without importing tensorboard, the training is on one gpu. With importing tensorboard the training is on all four gpus, which I don't want.
`print("torch.cuda.device_count() with tensorboard ",torch.cuda.device_count())`
torch.cuda.device_count() with tensorboard  4
`print("torch.cuda.device_count() without tensorboard ",torch.cuda.device_count())`
torch.cuda.device_count() without tensorboard  1

## Environment
PyTorch version: 1.1.0
Is debug build: No
CUDA used to build PyTorch: 9.0.176

OS: Debian GNU/Linux 9.9 (stretch)
GCC version: (GCC) 5.4.0
CMake version: Could not collect

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 9.0.176
GPU models and configuration: 
GPU 0: Quadro P6000
GPU 1: TITAN X (Pascal)
GPU 2: GeForce GTX 1080 Ti
GPU 3: TITAN X (Pascal)

Nvidia driver version: 390.87
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] numpy==1.16.4
[pip] pytorch-ignite==0.1.2
[pip] torch==1.1.0
[pip] torchvision==0.3.0
[conda] blas                      1.0                         mkl  
[conda] ignite                    0.1.2                    py37_0    pytorch
[conda] mkl                       2019.4                      243  
[conda] mkl-service               2.0.2            py37h7b6447c_0  
[conda] mkl_fft                   1.0.14           py37ha843d7b_0  
[conda] mkl_random                1.0.2            py37hd81dba3_0  
[conda] pytorch                   1.1.0           py3.7_cuda9.0.176_cudnn7.5.1_0    pytorch
[conda] torchvision               0.3.0           py37_cu9.0.176_1    pytorch
tensorboard.__version__ 2.0.0

How can I import Tensorboard without changing anything?

Tried:
```
os.environ['CUDA_VISIBLE_DEVICES'] = 0
torch.cuda.set_device(0)
```
Did't work
Repository: flutter
Issue: `CupertinoContextMenuAction` should have a `trailing` widget rather than just an `IconData trailingIcon`
Labels: c: new feature,framework,c: API break,f: cupertino,c: proposal,P3,team-design,triaged-design,fyi-text-input

## Use case

Now we can't change the icon color or use others widget for trailing

## Proposal

https://github.com/flutter/flutter/blob/9e0df259df9c521d0ffbdf5ba664f6ab30143884/packages/flutter/lib/src/cupertino/context_menu_action.dart#L46

`IconData trailingIcon` -> `Widget trailing`
Repository: flutter
Issue: Dialog maxWidth is not configurable
Labels: framework,f: material design,c: proposal,P3,workaround available,team-design,triaged-design

The `Dialog` class uses a `ConstrainedBox` widget with `constraints: const BoxConstraints(minWidth: 280.0)`.

It would be useful to add `maxWidth` as a constructor parameter since currently all dialogs appear very wide on large screens (e.g. tablet or web).
Repository: vscode
Issue: [themes] provide command to change theme
Labels: feature-request,themes

There is a command to open the theme prompt (`workbench.action.selectTheme`), however, I would like a command to change the theme (the name of which would be provided as an argument).

The reason I would like this is that I frequently switch between a dark and a light theme, depending on my mood, time of day, etc. Currently, I am forced to use the theme picker, but I would really like to create keyboard shortcuts to switch themes immediately.
Repository: terminal
Issue: Feature request: 'age' output visually 
Labels: Issue-Feature,Area-Rendering,Area-Extensibility,Product-Terminal

Similar to #3519, when watching logs, or build processes, similar lines being shown repeatedly can often make it hard to determine if anythings happening (as each new page of data looks the same as the previous one)

#3519 mentions smooth scrolling, but it would also be useful to apply some visual effect to old output. **This is a bit unusual, I don't know of any other terminal that does this, but it would also be very useful**

Eg, remove brightness by X percent for output older than 5 minutes, y% for output older than 15 minutes.
Repository: go
Issue: encoding/json: tag `json:"-"` doesn't hide an embedded field
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 linux/amd64
$ gotip version
go version devel +696c41488a Mon Nov 11 15:37:55 2019 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes, see `gotip` version.

### 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/ainar/.cache/go-build"
GOENV="/home/ainar/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ainar/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/ainar/go/go1.13"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/ainar/go/go1.13/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/ainar/dev/tmp/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-build199093238=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

``` go
type A struct {
	Name string `json:"name"`
}

type B struct {
	A
	Name string `json:"-"`
}
```

https://play.golang.org/p/uKY3umGYEp3

### What did you expect to see?

Either:

``` none
<nil> {}
```

Or:

``` none
some error about tag conflict
```

### What did you see instead?

``` none
<nil> {"name":"1234"}
```
Repository: go
Issue: image/gif: decode fails with "gif: too much image data"
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.4 windows/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
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\User\AppData\Local\go-build
set GOENV=C:\Users\User\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=E:\vagrant\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\User\AppData\Local\Temp\go-build365934466=/tmp/go-build -gno-record-gcc-switches
</pre></details>

### What did you do?

I have attached a zip file with three gif images that image/gif can't open (I get the message "gif: too much image data") but that other viewers can open fine. I assume they are actually invalid but perhaps image/gif could be changed to be more forgiving?

[unknown.zip](https://github.com/golang/go/files/3832483/unknown.zip)
Repository: go
Issue: crypto/tls: improve default performance of SupportsCertificate
Labels: Performance,NeedsDecision

As discussed in https://golang.org/cl/205059, SupportsCertificate requires c.Leaf to be set not to be extremely slow (because it needs to re-parse the leaf every time). This also impacts automatic selection from multiple Certificates candidates.

There are multiple solutions suggested on the CL, I will pick one and turn this into a proposal for further discussion.
Repository: pytorch
Issue: `print` uses lots of GPU memory
Labels: module: printing,module: cuda,triaged,enhancement

## 🐛 Bug

I'm not totally certain if this is a bug or just an oddity I don't understand, but calling Python's `print` function on a GPU tensor uses a lot of GPU memory.

That's probably a reasonably low priority bug by itself, but it's also kind of a strange one, so I thought I'd raise it in case it's indicative of something else going wrong somewhere.

## To Reproduce

Consider the following three code snippets.

```python
# Snippet 1
import torch
torch.cuda.reset_max_memory_allocated()
x = torch.rand(10000, device='cuda')
print(torch.cuda.max_memory_allocated())
```
```python
# Snippet 2
import torch
torch.cuda.reset_max_memory_allocated()
x = torch.rand(10000, device='cuda')
print(x.cpu())
print(torch.cuda.max_memory_allocated())
```
```python
# Snippet 3
import torch
torch.cuda.reset_max_memory_allocated()
x = torch.rand(10000, device='cuda')
print(x)
print(torch.cuda.max_memory_allocated())
```
On my machine the first two both print out `40448`, but the third prints out `173568`. Several times as much, just to print out a few numbers!

## Expected behavior

It's not clear to me why this should use so much memory. The second example demonstrates that this information can clearly be printed out without incurring any extra memory cost.

## Environment

 - PyTorch Version (e.g., 1.0): tested with both 1.2.0 and 1.3.0
 - OS (e.g., Linux): Linux
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source): N?A
 - Python version: 3.7.5
 - CUDA/cuDNN version: 10.1
 - GPU models and configuration: GeForce RTX 2080 Ti
 - Any other relevant information: -
Repository: pytorch
Issue: [feature request] Print some measure of fragmentation at CUDA out-of-memory
Labels: module: cuda,triaged,enhancement

It would be nice to include by default some information about memory fragmentation into the default CUDA OOM exception message (and not just amount of allocated / cached memory). It may help to understand OOM's coming from variable batch size.
Repository: rust
Issue: Add `RUST_BACKTRACE=full` to CI Docker images
Labels: C-enhancement,T-infra

Currently, none of the CI docker builders have backtraces enabled. This can make debugging a failed PR very time consuming - since the panic message itself is often useless, it can be necessary to run the entire CI script locally to generate a proper backtrace.

If all of the CI images had backtraces enabled, it would be possible to get a backtrace directly from the logs, saving PR authors a significant amount of time.

I wasn't sure the best way to go about this - I didn't want to duplicate `RUST_BACKTRACE` across ever single `Dockerfile`, but there doesn't seem to be any infrastructure in place for sharing common thigns between the various `Dockerfile`s.

This came up in https://github.com/rust-lang/rust/pull/60026#issuecomment-552238786
Repository: kubernetes
Issue: Add Container Storage Interface integration to conformance
Labels: sig/storage,kind/feature,lifecycle/frozen

<!-- Please only use this template for submitting enhancement requests -->

**What would you like to be added**:
Continuing the discussion in https://github.com/kubernetes/kubernetes/issues/65155#issuecomment-510247066, while we can't test provider-specific CSI drivers in conformance, we can test provider-agnostic drivers like CSI hostpath, and make sure that K8s distributions are properly supporting the CSI interface.

There are some challenges that need to be solved before we can test CSI in conformance:
* sig-storage has refactored some 30+ [tests](https://github.com/kubernetes/kubernetes/tree/master/test/e2e/storage/testsuites) to be driver-agnostic (can run against any driver, in-tree or CSI). However, that currently makes it difficult to promote those tests to conformance using the current conformance tooling because the tests case definitions are now a library shared by many drivers.  We either need to: 1) enhance the current conformance tooling to handle conditional test cases based off of other inputs (such as the driver being tested) or 2) duplicate all of the test cases to a conformance-specific suite.
* CSI drivers need to be privileged in order to do mount propagation on kubelet. I forget if conformance tests allow privileged containers?
* CSI hostpath needs "/dev" access on the host to support raw block (filesystem PVC is fine, the driver just writes to the container fs). It may be that we can't test raw block in conformance.
* In addition, we have some test cases outside of our driver suite that uses the [mock driver](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/storage/csi_mock_volume.go), and checks various CSI calls toggled by different settings (via K8s objects like CSIDriver, as well as CSI driver config options). Most of the tests validate that the right CSI calls are made by grepping mock driver logs for specific msgs since the mock driver isn't actually very functional (compared to the hostpath driver).  Right now most of these test cases are testing beta features, but it would be a good idea to write a very basic test testing all the GA features. These test cases may be less functional than the generic driver suite since the mock driver doesn't actually write any data and most of our functional tests check for data persistence.


**Why is this needed**:
It is important to make sure that all K8s distributions support the CSI spec.

@kubernetes/sig-storage-feature-requests 
cc @johnbelamaric