sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Increased memory usage in repetitive torch.jit.trace calls
Labels: high priority,oncall: jit,triaged

## 🐛 Bug

Tracing a model multiple times seems to increase the memory usage.
Reported by [alepack](https://discuss.pytorch.org/u/alepack) in [this post](https://discuss.pytorch.org/t/possible-memory-leak-in-torch-jit-trace/74455).

## To Reproduce

```python
#Utilities 
import os
import psutil

#JIT trace test
import torch
import torchvision.models as model_zoo

with torch.no_grad():

  #Create a simple resnet 
  model = model_zoo.resnet18()
  model.eval

  #Create sample input
  sample_input = torch.randn(size=[2, 3, 480, 640], requires_grad=False)

  #Get process id
  process = psutil.Process(os.getpid())

  #Repeat tracing 
  for i in range(0, 1000):
    tr_model = torch.jit.trace(model, sample_input, check_trace=False)
    print("Iter: {} = {}".format(i, process.memory_full_info()))

# output:
Iter: 0 = pfullmem(rss=415825920, vms=8240693248, shared=123785216, text=2215936, lib=0, data=6408441856, dirty=0, uss=419287040, pss=420155392, swap=0)
Iter: 1 = pfullmem(rss=456716288, vms=8292564992, shared=125976576, text=2215936, lib=0, data=6460313600, dirty=0, uss=461049856, pss=461918208, swap=0)
Iter: 2 = pfullmem(rss=493195264, vms=8331886592, shared=125976576, text=2215936, lib=0, data=6499635200, dirty=0, uss=495702016, pss=496570368, swap=0)
Iter: 3 = pfullmem(rss=547762176, vms=8391135232, shared=125976576, text=2215936, lib=0, data=6558883840, dirty=0, uss=550371328, pss=551239680, swap=0)
Iter: 4 = pfullmem(rss=577015808, vms=8420626432, shared=125976576, text=2215936, lib=0, data=6588375040, dirty=0, uss=579932160, pss=580800512, swap=0)
Iter: 5 = pfullmem(rss=630874112, vms=8469778432, shared=125976576, text=2215936, lib=0, data=6637527040, dirty=0, uss=629145600, pss=630013952, swap=0)
Iter: 6 = pfullmem(rss=659718144, vms=8499269632, shared=125976576, text=2215936, lib=0, data=6667018240, dirty=0, uss=662802432, pss=663670784, swap=0)
Iter: 7 = pfullmem(rss=698855424, vms=8538853376, shared=125976576, text=2215936, lib=0, data=6706601984, dirty=0, uss=702468096, pss=703336448, swap=0)
Iter: 8 = pfullmem(rss=728879104, vms=8568344576, shared=125976576, text=2215936, lib=0, data=6736093184, dirty=0, uss=732028928, pss=732897280, swap=0)
Iter: 9 = pfullmem(rss=773472256, vms=8617496576, shared=125976576, text=2215936, lib=0, data=6785245184, dirty=0, uss=776867840, pss=777736192, swap=0)
Iter: 10 = pfullmem(rss=802549760, vms=8646987776, shared=125976576, text=2215936, lib=0, data=6814736384, dirty=0, uss=806092800, pss=806961152, swap=0)
```

## Environment

alepack's setup based on the forum post:
* PyToch `1.4.0` installed via conda

I verified it with `1.5.0a0+5b3492df18`.


cc @ezyang @gchanan @zou3519 @suo
Repository: rust
Issue: Should `TryFrom` get mentioned in AsRef/AsMut?
Labels: C-enhancement,T-libs-api

Both `AsMut` as well as `AsRef`'s documentation contain the following note:

> **Note: This trait must not fail.** If the conversion can fail, use a dedicated method which returns an `Option<T>` or a `Result<T, E>`.

This wording was added in 58d2c7909f9 and 6cda8e4eaac back in 2016/01. It was also very similar in `From` and `Into` up to 71bdeb022a9, where the explicit mention of dedicated methods was replaced by a link to the `Try*` variants. 

Since `TryFrom` is now stabilized, one could go ahead and write `AsRef` variants via `try_from`:

```rust
struct Example {
    dont_panic: bool,
}
struct Panic;

impl TryFrom<&Example> for &u8 {
    type Error = Panic;

    fn try_from(e: &Example) -> Result<Self, Self::Error> {
        if e.dont_panic {
            Ok(&42)
        } else {
            Err(Panic)
        }
    }
}
// full example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8446972919a4ab31222800395accb434
```
However, I'm not sure whether that breaks the original spirit of `AsRef` and `AsMut`, being *cheap* conversions and all. I'm also not sure whether it is intended to use `TryFrom` for references. 

If possible failing (and costly?) *reference* conversions are indeed a use case for `TryFrom`, should this alternative to an `Option<T>` or `Result<T,E>` get added to `AsRef`'s documentation? Or is this a misuse case and reference conversion should get mentioned on `TryFrom`'s documentation as a non-goal?

(Note that I don't have a use case for a `TryAsRef` or similar; I just read a lot of Rust's documentation lately and came across the symmetry between `From` and `TryFrom` and the missing counterpart in `AsRef`)
Repository: react
Issue: Devtools: Allow editing context
Labels: Type: Feature Request,Component: Developer Tools

React version: 16.13 and `0.0.0-experimental-aae83a4b9

## Steps To Reproduce

1. Goto https://codesandbox.io/s/xenodochial-field-rfdjz
2. Try editing value of `MessageListContext.Provider`

Link to code example: https://codesandbox.io/s/xenodochial-field-rfdjz

## The current behavior

Context from `createContext` can't be edited in the current devtools (provider, consumer, hooks)

## The expected behavior

Context value should be editable. I already proposed an implementation for [Provider](https://github.com/facebook/react/pull/18255) and [Consumer](https://github.com/facebook/react/pull/18257).
Repository: godot
Issue: dialog window title bar are visible in Windows(os)
Labels: enhancement,discussion,topic:editor,topic:porting,usability

**Godot version:** 307b1b3a5

**OS/device including version:** windows10

**Issue description:**
title bar is visible in dialog windows in Windows(os). also dragging them around makes the window lagging
![windows-title-bar](https://user-images.githubusercontent.com/41085900/77822296-66235700-7117-11ea-8d82-bc319cd1513f.JPG)
![windows-title-bar4](https://user-images.githubusercontent.com/41085900/77822323-a256b780-7117-11ea-8fbf-20c8ad4beb01.png)
![windows-title-bar3](https://user-images.githubusercontent.com/41085900/77822325-a4b91180-7117-11ea-8686-7df93ece37c0.png)
![windows-title-bar2](https://user-images.githubusercontent.com/41085900/77822326-a5ea3e80-7117-11ea-9375-9ae55929cd83.png)
Repository: godot
Issue: GDScript: Strange const scoping with classes
Labels: bug,topic:gdscript

**Godot version:** 3.2.1

**OS/device including version:** `Ubuntu 18.04.3 LTS (bionic) - Linux 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux`

**Issue description:** `const` scoping seems to be very restrictive, with child classes being unable to use constants from their parent or from the top level of the script in constant expressions. This results in having to use `var` instead (as in #20354), or copy consts/enums to each child (maintenance nightmare).

**Steps to reproduce:** See gdscript samples below.

**Minimal reproduction project:**
```
# Singleton named Note
extends Node

enum {NOTE_TAP, NOTE_HOLD}
enum Named {NOTE_TAP, NOTE_HOLD}
const NOTE_TAP1 := 0

class NoteBase:
    ...

class NoteTap extends NoteBase:
    var type = NOTE_TAP  # legal, seems like the fix for #20354 was targeted at this case
    const type1 = NOTE_TAP  # illegal: "Expected a constant expression."
    const type2 = Named.NOTE_TAP  # illegal
    const type3 = Note.NOTE_TAP  # illegal: "invalid index 'NOTE_TAP' in constant expression"
    const type4 = Note.Named.NOTE_TAP  # illegal
    const type5 = NOTE_TAP1  # illegal
    const type6 = Note.NOTE_TAP1  # illegal
```

```
class NoteBase:
    enum {NOTE_TAP, NOTE_HOLD}
    const NOTE_TAP1 := 0
    ...

class NoteTap extends NoteBase:
    const type = NOTE_TAP  # still illegal
    const type1 = NoteBase.NOTE_TAP  # still illegal
    const type2 = NOTE_TAP1  # also illegal
```

```

class NoteBase:
    ...

class NoteTap extends NoteBase:
    enum {NOTE_TAP, NOTE_HOLD}
    const type = NOTE_TAP  # legal!
```
Repository: TypeScript
Issue: T | (() => T) 
Labels: Bug

**TypeScript Version:**  3.9.0 (Nightly)

**Search Terms:** `T | (() => T)`, `T & Function`

**Code**

```ts
type Initializer<T> = T | (() => T)
// type Initializer<T> = T extends any ? (T | (() => T)) : never

function correct<T>(arg: Initializer<T>) {
    return typeof arg === 'function' ? arg() : arg // error
}
```

Line 2 provides a workaround for this.
More info on [stackoverflow](https://stackoverflow.com/questions/60898079/typescript-type-t-or-function-t-usage).

**Expected behavior:** no errors

**Actual behavior:** `This expression is not callable.
  Not all constituents of type '(() => T) | (T & Function)' are callable.
    Type 'T & Function' has no call signatures.`

**Playground Link:** [here](https://www.typescriptlang.org/play/?ts=3.9.0-dev.20200327&ssl=1&ssc=1&pln=6&pc=2#code/C4TwDgpgBAkgdgS2AghgGwQLwgJwDwAqAfFALxQFQA+UAFLQJRkkEMBQA9B1KJLIsnRZchEuUoQAHsAhwAJgGcoKOCCgB+OpRr0mpFgyYAuKHAgA3XGzYAzAK5wAxsgD2cKI5c4cEZ6NooOADmJvBIqBjY+MRMAN5sUIlQPsB2OO68EC42ysFkpOQA5PZOrnCFGrlBjFAmgUFQXFC4OF5sAL5AA).

**Related Issues:** none
Repository: godot
Issue: Unable to inherit from ProjectSettings
Labels: discussion,topic:core

**Godot version:**
3.2.1

**OS/device including version:**
Arch Linux

**Issue description:**
If I trying to extend `ProjectSettings` I have parsing error:
```
modules/gdscript/gdscript_compiler.cpp:1864 - Condition "native.is_null()" is true. Returned: ERR_BUG
```
Extending `ProjectSettings` can be very useful to add helper methods such as `add_gravity()` instead of using `get_setting("physics/3d/default_gravity")` every time.

**Steps to reproduce:**
1. Create a script.
2. Extend it from `ProjectSettings`.
3. Add any method or variable.
4. Try to use it in code.

**Minimal reproduction project:**
[PrjectSettings.zip](https://github.com/godotengine/godot/files/4397236/PrjectSettings.zip)
In this project I created `MySettingsNode` class that inherits from Node and works as expected. Also I created `MySettingsProjectSettings` class that have the same code, but will not work (just try to instantiate it from code to see the error.

**Temporary workaround:**
For now it is possible to create a class and with static functions and just access to all settings via `ProjectsSettings` because this is a singleton. This is useful to the error looks like a bug.
Repository: scrcpy
Issue: scrcpy on Asus TF101 running Android 6.0.1
Labels: device


Hi there!

I am trying to get my old Asus EeePC (TF101) to work with scrcpy on Ubuntu 18.04. The tablet is currently running [KatKiss Marshmallow 6.0.1 ROM](https://forum.xda-developers.com/eee-pad-transformer/development/rom-t3318496) with USB Debugging on:
$ adb devices
List of devices attached
037001494120f517	device

When I run scrcpy I get:
$ scrcpy
INFO: scrcpy 1.12 <https://github.com/Genymobile/scrcpy>
/usr/local/share/scrcpy/scrcpy-server: 1 file pushed. 1.1 MB/s (26196 bytes in 0.022s)
INFO: Initial texture: 1280x800
but no windows open. My scrcpy installation is working perfectly with my Samsung S9, so I guess the problem is elsewhere. The output of "adb logcat -d" (attached [logcat.txt](https://github.com/Genymobile/scrcpy/files/4397849/logcat.txt)) has some weird outputs related to the Nvidia.h264.encoder:
03-28 15:17:40.792  3848  3865 I OMXClient: Using client-side OMX mux.
03-28 15:17:40.797   111  1270 E OMXNodeInstance: setParameter(2b:Nvidia.h264.encoder, OMX.google.android.index.storeMetaDataInBuffers(0x7fc00007): Output:1 en=0 type=1) ERROR: BadParameter(0x80001005)
03-28 15:17:40.797  3848  3865 E ACodec  : [OMX.Nvidia.h264.encoder] storeMetaDataInBuffers (output) failed w/ err -2147483648
03-28 15:17:40.798  3848  3865 W ACodec  : do not know color format 0x7f000789 = 2130708361
03-28 15:17:40.799  3848  3865 I ACodec  : setupVideoEncoder succeeded
03-28 15:17:40.799   111  1270 E OMXNodeInstance: setParameter(2b:Nvidia.h264.encoder, OMX.google.android.index.enableAndroidNativeBuffers(0x7fc00004): Output:1 en=0) ERROR: BadParameter(0x80001005)
03-28 15:17:40.800  3848  3865 W ACodec  : do not know color format 0x7f000789 = 2130708361
03-28 15:17:40.801   111  2380 E OMXNodeInstance: getParameter(2b:Nvidia.h264.encoder, ParamConsumerUsageBits(0x6f800004)) ERROR: NotImplemented(0x80001006)

Any ideas on how to circumvent this?

Thanks in advance,

Marcelo
Repository: rust
Issue: assert_eq(x, y) is not the same as assert_eq(y, x) because of type inferrence
Labels: T-lang,A-inference,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8c06ef8af87645f50695bdba65f8a723)):

```rust
fn main() {
    assert_eq!(0_i64, S::zero());
    assert_eq!(S::zero(), 0_i64);
}

struct S;

trait Zeroed<T> {
    fn zero() -> T;
}

impl Zeroed<i16> for S {
    fn zero() -> i16 {
        0
    }
}

impl Zeroed<i64> for S {
    fn zero() -> i64 {
        0
    }
}
```

I expected to see this happen: The program compiles and runs successfully.

Instead, this happened:

```
error[E0282]: type annotations needed
 --> src/main.rs:3:16
  |
3 |     assert_eq!(S::zero(), 0_i64);
  |                ^^^^^^^ cannot infer type for type parameter `T` declared on the trait `Zeroed`
```

Note that the `assert_eq!(0_i64, S::zero());` works as expected.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.42.0 (b8cedc004 2020-03-09)
binary: rustc
commit-hash: b8cedc00407a4c56a3bda1ed605c6fc166655447
commit-date: 2020-03-09
host: x86_64-unknown-linux-gnu
release: 1.42.0
LLVM version: 9.0
```

The same error is present on nightly:

```
rustc 1.44.0-nightly (2fbb07525 2020-03-26)
binary: rustc
commit-hash: 2fbb07525e2f07a815e780a4268b11916248b5a9
commit-date: 2020-03-26
host: x86_64-unknown-linux-gnu
release: 1.44.0-nightly
LLVM version: 9.0
```
Repository: opencv
Issue: No checks if CV_CN_MAX is exceded at Mat constructor
Labels: feature,priority: low,category: core

##### System information (version)
<!-- Example
- OpenCV => 4.2
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2017
-->

- OpenCV => 3.4.8 (+)
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2017

##### Detailed description

When creating a map, types with ch > CV_CN_MAX are accepted.
I guess it's realted to the CV_MAKETYPE macro.

##### Steps to reproduce

for example this runs without any errors, but the result is incorrect 

```
cv::Mat  test = cv::Mat(200, 200, CV_MAKETYPE(CV_64F, 1200));
std::cout << test.channels(); // 176
```
or
```
cv::Mat  test = cv::Mat(200, 200, CV_64F(1200));
std::cout << test.channels(); //176
```

##### Issue submission checklist
 - [ ] I updated to latest OpenCV version and the issue is still there
   <!--
   master branch for OpenCV 4.x and 3.4 branch for OpenCV 3.x releases.
   OpenCV team supports only latest release for each branch.
   The ticket is closed, if the problem is not reproduced with modern version.
   -->
Repository: rust
Issue: Incorrect/confusing error message with multiple bounds of a single associated-type parametrized trait
Labels: A-diagnostics,T-compiler,C-bug,D-confusing,D-invalid-suggestion

```rust
#![allow(unreachable_code)]

pub trait Super<P> {
    type Assoc;
}

pub trait A<P>: Super<P> {}

pub trait B<P>: Super<P> {
    fn join(&mut self, handle: Self::Assoc) -> ();
}

pub trait Trait<T> {
    type Assoc;
}

// Removing B<<C as Trait<T>>::Assoc> bound allows this to infer and resolve
fn bug<T, U, C: Trait<T> + Trait<U> + B<<C as Trait<T>>::Assoc> + A<<C as Trait<T>>::Assoc> + B<<C as Trait<U>>::Assoc> + A<<C as Trait<U>>::Assoc>>() {
    let ctx: &mut C = panic!();
    let a: <C as Super<<C as Trait<U>>::Assoc>>::Assoc = panic!();
    
    // Removing this line allows it to resolve
    ctx.join(a);
}
```

I expect that this would compile given that the type of `a` is fully specified and only one implementation of `B` can satisfy the requirement imposed. Aside from that, the error message produced here is on `let ctx`, specifically "consider giving `ctx` the explicit type `&mut C`, where the type parameter `C` is specified". An error is in fact reported on `join`, 
```
cannot infer type for type parameter `C`

note: cannot resolve <C as Super<_>>::Assoc == <C as Super<<C as Trait<U>>::Assoc>>::Assoc
```
but in the real-world codebase from which this originated the error was reported in an earlier use of `ctx` in the function, not the one which caused the issue, and it would be reported on the first occurrence of a use of `C` by receiver in the function regardless of the nature of that use.

Fully qualifying the call i.e.
```rust
B::<<C as Trait<U>>::Assoc>::join(ctx, a);
```
also resolves and the program compiles successfully, my concern here is around the exceedingly confusing misplaced error message which sometimes has a span in unrelated source.

[playground reproduction](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a0fb72d5443c71262f275bc54b199f9e)
Repository: flutter
Issue: FloatingActionButtonThemeData disabled color
Labels: framework,f: material design,c: proposal,P2,team-design,triaged-design

FloatingActionButtonThemeData does not have disabled color. It would be a easy if it had, so dimming the floating action button when data fields are not filled could be done with one line of code.

```
gintas-mac:lifetrens gintas$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel master, v1.16.3-pre.64, on Mac OS X 10.15.3 19D76, locale
    en-GB)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 11.4)
[✓] Chrome - develop for the web
[✓] Android Studio (version 3.6)
[!] VS Code (version 1.43.2)
    ✗ Flutter extension not installed; install from
      https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
[✓] Connected device (3 available)

! Doctor found issues in 1 category.
```
Repository: excalidraw
Issue: Excalidraw is a bit broken with Oculus hand tracking
Labels: bug

When using Excalidraw in the Oculus Browser (on Quest w/ hand tracking enabled), pinch-to-click results in a click event *and* the context menu pops up. Desired behavior would be to just register the click event and suppress the context menu (I think)
Repository: excalidraw
Issue: Synchronize cursor type
Labels: collaboration

Right now all the collaborations only have a single cursor, but when you edit the scene locally you have many cursor types. Would be nice to synchronize cursor type.
Repository: rust
Issue: rustc_mir::shim misuses `ParamEnv`s.
Labels: T-compiler,A-MIR,C-bug

(This example is about `CloneShim`, but `DropGlue` has a similar issue)

In this snippet, `param_env` is obtained from `tcx.param_env(def_id)` and used twice with `self_ty`:
1. for `is_copy_modulo_regions`
    * if `self_ty` doesn't involve type parameters, `param_env` doesn't matter, but if it does, they could be from anywhere (e.g. caller of `clone`, via MIR inliner), so the `param_env` being that of `Clone::clone` itself is not useful at all (all it contains is `Self: Clone`)
    * to get the right `ParamEnv`, the `mir_shims` query would need to take `ParamEnvAnd<InstanceDef>` instead of just `InstanceDef` (but we might not need this)
    * however it's a waste to generate one shim for every `Copy` type, we should instead do what `DropShim` does and have `Option<Ty>` in `CloneShim`, or split out of a `CloneByCopyShim`
2. for evaluating an array length
    * the length (a `ty::Const`) is converted to `u64` only to be converted back to `ty::Const`, which is unnecessary and we could skip it entirely

https://github.com/rust-lang/rust/blob/77621317d643cc5d13da60b26ab68b057668e688/src/librustc_mir/shim.rs#L330-L343
Repository: TypeScript
Issue: [P in keyof T]: T[P] not accepting inferred base type via extends
Labels: Suggestion,Help Wanted,Effort: Difficult,Experience Enhancement

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
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.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
* `[P in keyof T]?: T[P]`
* `typescript generic extends in keyof`
* `typescript generic extends T[P]`
* `typescript mongo collection generic`

**Code**

```ts
interface IModel {
	id: string;
}

type Query<T> = {
	[P in keyof T]?: T[P]
}

export class Base<T extends IModel> {
	public find(query: Query<T>): void {
		// Forward the query to database
		console.log(query);
	}

	public findOneById(id: string): void {
		this.find({ id });
	}
}
```

**Expected behavior:**

It's expected to allow to execute the find with the properties defined on `IModel` as base of any other model;

**Actual behavior:**

It shows an error:
```
Argument of type '{ id: string; }' is not assignable to parameter of type 'Query<T>'.ts(2345)
```

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

https://typescript-play.js.org/#code/JYOwLgpgTgZghgYwgAgJIFkD2ATCAbZAbwCgBIYbALmQGcwpQBzAbmIF9jiwBPABxQCKAV2jcAPABUAfMgC8RMgG0ACslDIA1hG6YYyCQF0A-NQkqD7ThAAevTFDDIEeODRrIAQq4iTkNyCDY7hg4+DIkpLxCAEZ4wAjIMKDYABQAjiJQ3NTCopJSAJTUAG6YFAqkpAD0VcgAYvYA7nBQ2MhgABYoGaLtmMjYcGBw0d5kpAiYIDSYeBAAdHiYjOmZ3AWspBxkUbHxickA8iAQHtyoqRTUdAwgjEXIpeURpJ3ANPNJgSmEam1sGzIHA4QA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->

Didn't find any related issue
Repository: pytorch
Issue: Caffe2 generate_proposals_op_gpu_test crashes on Windows
Labels: module: tests,triaged

See https://app.circleci.com/pipelines/github/pytorch/pytorch/148057/workflows/df15651f-11ba-4459-8687-cd11a2a13b15/jobs/4987650 
```
unning "C:\Users\circleci\project\build\win_tmp\build\torch\test\generate_proposals_op_gpu_test.exe"
Running main() from ..\third_party\googletest\googletest\src\gtest_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from GenerateProposalsTest
[ RUN      ] GenerateProposalsTest.TestRealDownSampledGPU
+ cleanup
```
Repository: pytorch
Issue: How do you change Adam learning rate since the latest commits ?
Labels: module: cpp,triaged

## 🐛 Bug

Since this commit : https://github.com/pytorch/pytorch/commit/76035f050b215d0606fe786901dcd07b5c9544fe#diff-b8c53e7a2010d3dae3200c9911950551
It's no longer possible to directly access the options variable of Adam in libtorch, making it impossible to change the learning rate on the fly with libtorch.
How can I change the learning rate ?

## To Reproduce

Steps to reproduce the behavior:

1. Install the latest nightly of libtorch
2. Create an Adam optimizer
3. Try to access its .options variable to change the learning rate : options does not exist anymore


cc @yf225