sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: [Feature Request] Add `to`, `cpu`, and `cuda` method to optimizer
Labels: feature,module: optimizer,triaged

## 🚀 Feature

```python
model =     # initialize
optimizer = # initialize

model.cuda()

optimizer.load_state_dict(optimizer_checkpoint)  # if checkpoint is not on gpu memory
optimizer.cuda()                                 # <<<<<< this code can be helpful

# and training codes...
loss.backward()
optimizer.step()
```

I think there is no appropriate way to send optimizer states to gpu memory currently.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->

When training should be saved and resumed, I packed all state dict to one dictionary object like `{"model": model.module.state_dict(), "optimizer": optimizer.state_dict(), "lr_scheduler": scheduler.state_dict()}` and save it. Due to the limit of GPU memory, when resuming training, I always load state dict using `map_location=torch.device('cpu')`.

At that situation, I have to cast all optimizer state to gpu manually like below code(From issue https://github.com/pytorch/pytorch/issues/2830).

```python
for state in optimizer.state.values():
    for k, v in state.items():
        if torch.is_tensor(v):
            state[k] = v.cuda()
```


## Pitch

Implement `to`, `cpu`, and `cuda` method to `optim.Optimizer` like `nn.Module`.

## Additional Context

Maybe related to #2830

cc @vincentqb
Repository: terminal
Issue: wpf: TerminalContainer consumes WM_MOUSEWHEEL and doesn't let the native HWND have it
Labels: Issue-Bug,Product-Terminal,Priority-2,Area-WPFControl

This makes VT mouse scrolling events not work.
Repository: ant-design
Issue: Can't override <Table/> "Select All" checkbox when paginated
Labels: 💡 Feature Request,Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/antd-table-selection-ikqym)

### Steps to reproduce
I have an Ant Design table with sorting, selection and pagination. By default (if I understand it correctly), Antd Table selection works on a per-page basis. If you click the 'Select All' checkbox in the selection column header, Antd will select all the rows on the current page but if you then change page, both the rows and header will revert to a unchecked state. The selection is not lost because if you then go back to the previous page, the rows and header are all checked.

So I wanted to change this so that 'Select All' really selects all the rows of the table regardless of pagination. I found a few github issues in which recommended simply managing the selectedRowKeys array onSelect and onSelectAll functions oneself. I did this and now my selection works as expected...

However...

The "select all" checkbox in the selection column header still functions in terms of the page rows. So for example if I'm on the first page and "Select all" then deselect one of the rows, the "select all" checkbox is in the intermediate/partial state as expected. However if I then go to the next page, all rows are checked as expected and so is the "select all" checkbox in the header. For this selection to make sense functionally it would need to remain in the intermediate/partial state. It needs to reflect the selection over the entire dataset and not just the current page.

### What is expected?
To be able to override the state of the "Select all" checkbox to find a "selection over entire paginated dataset" scenario.

### What is actually happening?
Nothing. Can't find any info on how to do this!

| Environment | Info |
|---|---|
| antd | 4.4.3 |
| React | 16.11.0 |
| System | Windows 10 |
| Browser | Google Chrome 83.0.4103.116 |

---
This is a bit of a deal-breaker for us...


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: test_bottleneck_cuda fails on Power
Labels: module: tests,triaged,module: POWER

## 🐛 Bug

When running the test suite on Power (with lot's of tests already excluded to make it to this point) I get a failed test_bottleneck_cuda.

## To Reproduce

Steps to reproduce the behavior:

1. `python run_test.py --verbose -x test_cpp_extensions_jit test_torch test_autograd test_cpp_extensions_aot_no_ninja test_cpp_extensions_aot_ninja test_jit test_nn`

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

The message isn't helpful:

```
FAIL: test_bottleneck_cuda (__main__.TestBottleneck)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_utils.py", line 422, in test_bottleneck_cuda
    self.assertEqual(rc, 0, msg='Run failed with\n{}'.format(err))
  File "/tmp/easybuild-tmp/eb-iBDAhF/tmp7gvyPW/lib/python3.7/site-packages/torch/testing/_internal/common_utils.py", line 1122, in assertEqual
    self.assertTrue(result, msg=msg)
AssertionError: False is not true : Run failed with


----------------------------------------------------------------------
```


## Environment

PyTorch version: 1.6.0-rc3
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: Red Hat Enterprise Linux Server release 7.6 (Maipo)
GCC version: (GCC) 8.3.0
CMake version: Could not collect

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.1.243
GPU models and configuration:
GPU 0: Tesla V100-SXM2-32GB
GPU 1: Tesla V100-SXM2-32GB
GPU 2: Tesla V100-SXM2-32GB
GPU 3: Tesla V100-SXM2-32GB
GPU 4: Tesla V100-SXM2-32GB
GPU 5: Tesla V100-SXM2-32GB

Nvidia driver version: 440.64.00
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy==1.17.3
[pip3] torch==1.6.0

cc @mruberry @VitalyFedyunin
Repository: go
Issue: testing: Document that T.Log and friends should not be invoked after the end of the test 
Labels: Documentation,help wanted,NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.14.3 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/slinkydeveloper/.cache/go-build"
GOENV="/home/slinkydeveloper/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/slinkydeveloper/go"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/lib/golang"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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-build310442572=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

I learnt, while using testing tools, that you cannot invoke `t.Logf` and similar after `t` is done: https://golang.org/src/testing/testing.go?s=25276:25317#L1025

### What did you expect to see?
Some doc in **all** logging methods of `T`, like https://golang.org/pkg/testing/#T.Log, explaining this behaviour:

> Be aware that you cannot invoke this method after `t` is done, otherwise the race detector will detect a race inside the `t` code.

### What did you see instead?
Nothing documented so far
Repository: vue
Issue: Vue SSR v-html on dynamic-component hydration warning
Labels: bug,has workaround,feat:ssr

### Version
2.6.11

### Reproduction link
The reproduction is updated to use Vue SSR without NUXT
[https://github.com/privatenumber/vue-ssr-vhtml-dyncomp-bug](https://github.com/privatenumber/vue-ssr-vhtml-dyncomp-bug)

### Steps to reproduce
_Dynamic.vue_
```vue
<template>
  <component is="div">
    content necessary
  </component>
</template>
```

_App.vue_
```vue
<template>
  <dynamic v-html="'<div>trigger hydration warning</div>'" />
</template>
```

### What is expected?
The expected behavior is for there to be no hydration warning when the SSR and client markup are identical.


### What is actually happening?
Although there isn't a discrepancy in rendered HTML between client and SSR, it gives warnings that there is.

![warningD](https://user-images.githubusercontent.com/1075694/88136132-a28f2d00-cbb6-11ea-84db-f38d0bf3adf3.png)
![warningE](https://user-images.githubusercontent.com/1075694/88136136-a327c380-cbb6-11ea-81e6-b3830645de60.png)

### Work around
I used a [render function](https://vuejs.org/v2/guide/render-function.html) instead of a dynamic-component:
```
render(h) {
    return h(this.component, this.$slots.default);
}
```

### Other info
Previous issue: https://github.com/vuejs/vue/issues/11532


<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: terminal
Issue: Productize the WPF, UWP Terminal Controls
Labels: Area-TerminalControl,Product-Terminal,Issue-Scenario,Area-WPFControl

This scenario tracks the remaining work to productize the UWP and WPF versions of the Terminal Control. These will allow 3rd-party developers to embed terminal instances in their applications. That way, external developers won't need to write their own terminals, they can just re-use the one we build in this repo. 

Currently, the Windows Terminal uses the UWP version of the control. Similarly, Visual Studio embeds the WPF version. 

## Pre-Requisites
These tasks aren't immediately related, but will need to get done first to unblock this work

* [x] #5000 / #1256: I'm planning on tearing up the TermControl as a part of the window/content process model refactor. Undoubtably, this will affect the API boundary that will be exposed
* [x] #381: Before we ask anyone else to use us, we should probably be a better terminal emulator. The Alt buffer is an important part of that story.
* [ ] Should we perhaps also finish the VT implementation for the `TerminalCore` as well? Currently the Terminal Core only implements the VT sequences that ConPTY will emit. Hypothetically, someone might be using this in a scenario where conpty _isn't_ on the other end.

## Tasks

```[tasklist]
## Tasks
- [x] Introduce abstraction layer between TermControl and TerminalCore (aka Interactivity) #6842
- [ ] Tear out the `SearchBoxControl` from the `TermControl`, so it can be its own control
- [ ] Remove the SharedShadow thing in SearchBoxControl, noted in #12913
- [ ] Finalize API boundary - Where is the real line between `TermControl` / `ControlInteractivity` / `ControlCore`?
- [ ] Re-base the WPF control on the shared `TerminalContent`.
- [ ] Package as a nuget
- [ ] Deploy to some nuget feed somewhere?
- [ ] #4572
- [x] #3337
- [ ] #13408
- [ ] https://github.com/microsoft/terminal/issues/15404
- [ ] https://github.com/microsoft/terminal/issues/6967
- [ ] https://github.com/microsoft/terminal/issues/6996
- [ ] https://github.com/microsoft/terminal/issues/5094
- [ ] Pasting is super wacky. The control shouldn't ask the app to paste to it.
- [ ] https://github.com/microsoft/terminal/issues/1304
- [ ] https://github.com/microsoft/terminal/issues/14407
- [ ] https://github.com/microsoft/terminal/issues/13681
- [ ] https://github.com/microsoft/terminal/issues/16404
```


## related
* Scenario: TerminalControl Interactivity Improvements #6106
* starting Terminal with wt no longer returns the main window handle of the resulting window #7084 
  - This is the "reparent the terminal to another HWND thread"
Repository: terminal
Issue: [Epic] Shared UI Automation Improvements
Labels: Area-Accessibility,Product-Terminal,Priority-1,Issue-Scenario

_created and maintained by @carlos-zamora_

A number of screen readers still don't use the UIA framework we've exposed in ConHost and Windows Terminal. After speaking with @codeofdusk, there's a number of suggested improvements we can do to convince screen reader manufacturers to switch over from the legacy framework.

- #5406: Standard and alt buffer distinction
- #2161: Expose text attributes
- #6986: Better "end of buffer" handling (trim whitespace)
- #7960: Word navigation bug

With this changes, we can...
- build a case for NVDA to use UIA by default (see https://github.com/nvaccess/nvda/pull/10964)
- help NVDA ~remove~ reduce their use of all of their workarounds from pre-#4018
- improve performance, stability, and accessibility for ConHost and Windows Terminal when using screen readers (i.e. password detection)

see also:
- #11253
Repository: rust
Issue: Better slices array type inference
Labels: T-compiler,A-inference,C-feature-request

This code:
```rust
#[allow(unused_variables)]
fn main() {
    let foos1: [&[u32]; 3] = [&[1_u32, 2, 3], &[1, 2], &[]];
    let foos2 = [&[1_u32, 2, 3], &[1, 2], &[]];
}
```
Currently (rustc 1.47.0-nightly 8ad7bc3f4 2020-07-21) this gives:
```rust
error[E0308]: mismatched types
 --> ...\test.rs:4:34
  |
4 |     let foos2 = [&[1_u32, 2, 3], &[1, 2], &[]];
  |                                  ^^^^^^^ expected an array with a fixed size of 3 elements, found one with 2 elements
  |
  = note:   expected type `&[u32; 3]`
          found reference `&[u32; 2]`
```
Is it possible to improve the type system so foo2 too compiles?
Repository: flutter
Issue: "mounted" state should be automatically checked by flutter instead of forcing code to "fix" it
Labels: framework,c: proposal,P3,team-framework,triaged-framework

The following message was presented when an async call took longer than expected to get a version.txt file for the web build of a flutter app. The app has a custom splash screen which presents the version and build number from a txt file since PackageInfo do not work on the web.

"The preferred solution is to cancel the timer or stop listening to the animation in the dispose() callback. Another solution is
to check the "mounted" property of this object before calling setState() to ensure the object is still in the tree."

Shouldn't setState automatically check this to avoid the error? Instead we have to code things like

        if (mounted) {
          setState(() {

Not cool
Repository: flutter
Issue: Implement native platform resolved locales on desktop embedders
Labels: engine,platform-mac,a: internationalization,a: desktop,P3,team-macos,triaged-macos

Continuation from https://github.com/flutter/flutter/issues/47087

We currently expose a `ComputePlatformResolvedLocale` callback in the embedder API (flutter/engine#19597), and, as appropriate, should implement this for each embedder. This is already done for Android and iOS.
Repository: storybook
Issue: Failing to parse TypeScript files outside the src directory
Labels: question / support,react,typescript,cra

**Describe the bug**
I am utilizing TypeScript path aliases with CRA along with Yarn workspaces in a mono repo situation.

Importing files from the aliased path that contains type declaration fails to parse that file when compiling Storybook. The CRA itself has no trouble with that.

Upon removing type declaration the import is working correctly.

**To Reproduce**
I did set up a whole repo to reproduce a problem. Instructions are pretty straightforward, but I've outlined in README the most notable differences from the regular setup.

https://github.com/FredyC/storybook-cra-workspaces

**Expected behavior**
Files with Typescript declaration should be imported without an issue.

**Screenshots**
![image](https://user-images.githubusercontent.com/1096340/88175563-5085f000-cc26-11ea-9ca0-744b22c552b8.png)

**System:**
![image](https://user-images.githubusercontent.com/1096340/88175689-80cd8e80-cc26-11ea-95e9-bd6f664df7ae.png)
Repository: realworld
Issue: Use of hashtag fragments in routes
Labels: Status: Triage

Hi,

I want to create a fullstack implementation of Realworld for an MVC we use at our company, but I noticed the spec seems to dictate the use of hashtag routes (`/#/`) instead of fully qualified pathnames. I've never been a fan of those, are they really required for **fullstack** implementations?
Repository: create-react-app
Issue: Proposal: enforce immutability for hook dependencies instead of exhaustive deps
Labels: issue: proposal,needs triage

Hi, so there is a long discussion for and against CRA's `react-hooks/exhaustive-deps` lint rules in the issue #6880.

Without going to further analyze that, it's safe to assume that the exhaustive-deps rule causes some unwanted busywork and even introduction of undesired side-effects which the developers might have not intended.

To illustrate what I mean: if I have a regular functional component with a `getTodos()` API call in the useEffect hook, as of now exhaustive-deps requires me to add the `getTodos()` to the dependency array. Yet me, as the developer, have no intention ever changing the function thus it should be immutable during the whole execution of the component. Moreover, it would be a _bug_ if it ever did so which would make adding it as a dependency contradictory to my original aim of only running the hook once per mount. The correct behavior in such cases would be to throw an error, not doing a very strange recomputation of the useEffect hook. And this is notwithstanding the annoying overhead of having to add every single thing imaginable to the dependency array. 

I hope my argumentation makes sense and the participants of the original thread, including @gaearon, can attest that this is an issue worth debating about.

The solution to this matter, the enforcement of immutability of the props/variables, is another issue entirely and I do not have any idea how such thing could be implemented or even checked with a linter. Perhaps this problem can only be solved with adding additional immutable functionality or error checking to React, which seems a bit of a long-shot.

In the meantime, I'll try to figure my own approach of dealing with the issue. Perhaps I'll just disable the rule and trust that I remember to add only the variables that can and should change during the lifecycle of a component. But for the sake of my sanity I won't be bothering to waste my time on adding every variable possible to the dependency array, when they should never change in the first place. If React could throw errors when those values did change unnecessarily, that would already be a pretty big improvement.
Repository: TypeScript
Issue: String union types in props inside generic types
Labels: Bug

**TypeScript Version:**  3.9.2 & 4.0.0-beta

**Code**

```ts
type A = {
    foo: number
}

type B<T extends string> = {
    [key in T]?: number
}

type C<T extends string> = A & B<T>

const f = <T extends string>(prop: T, value: number): C<T> => {
    const c: C<T> = {
        foo: 6
    }

    c[prop] = value

    return c
}

type Props = 'bar' | 'baz'

const o = f<Props>('bar', 6)
```

**Expected behavior:**
It should work :)

**Actual behavior:**
line 16: Type 'number' is not assignable to type 'C<T>[T]'.

**Playground Link:** [click](https://www.typescriptlang.org/play/index.html?ssl=23&ssc=29&pln=1&pc=1#code/C4TwDgpgBAglC8UDeBYAUFTUBmB7XAXFAHYCuAtgEYQBO6AvuuqJFAEIA8AKlBAB7AIxACYBnKKOA0AlsQDmAPgTJ0WKAG0A1hBBRZULgF0A-ETJVaDJmhbQAwt14ChYiVNmLlcAGTtuC6wBjXGJJHGVHfkERcUkZeQUACjAaXDAiLgAaKAA3AEMAG1IIMwpqGgBKIgcuJXglVAwsYNDgKEDq-2VGtTU8QigANlUsRjQRzED1FLTDZXyiiGs1GghgUhpidqtxm3BoAAVUsHFEAHJKPJozqAAfKAu8gC8zoJCw3GVsDiO00STHtdsoMKkA)
Repository: rust
Issue: macOS x86_64 requires frame pointers to unwind functions with huge stack frames
Labels: A-LLVM,O-macos,O-x86_64,T-compiler,C-bug

[Upstream LLVM bug](https://bugs.llvm.org/show_bug.cgi?id=46813)

Currently macOS x86_64 forcibly has frame pointers enabled, but this is an unfortunate performance loss relative to other platforms. There's no fundamental need to use frame pointers on macOS and it'd be a nice perf boost if we could stop requiring them. https://github.com/rust-lang/rust/pull/74575 was a recent attempt to disable frame pointers on macOS but it ran into a lot of segfaults in the compiler. Some debugging showed that this program will also segfault:

```rust
fn main() {
    let _huge_stack = [0u64; 1024];
    panic!("x");
}
```

run with:

```sh
$ rustc main.rs -C force-frame-pointers=no
$ ./main
thread 'main' panicked at 'x', main.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
zsh: segmentation fault  ./main
```

The issue appears to be with how the unwind information for the `main` function is encoded. macOS uses "compact unwind information" which basically means "not dwarf". I believe that this is an LLVM bug where the compact unwind information for `main` is incorrect when stack probes are also used. The `main` function requires a stack probe, and its unwind information is encoded in the `UNWIND_X86_64_MODE_STACK_IND` mode which is [documented as](https://gist.github.com/alexcrichton/42a2d7bc175d408a2a9682629425f7ef):

```
// UNWIND_X86_64_MODE_STACK_IND:
//    A "frameless" (RBP not used as frame pointer) function large constant 
//    stack size.  This case is like the previous, except the stack size is too
//    large to encode in the compact unwind encoding.  Instead it requires that 
//    the function contains "subq $nnnnnnnn,RSP" in its prolog.  The compact 
//    encoding contains the offset to the nnnnnnnn value in the function in
//    UNWIND_X86_64_FRAMELESS_STACK_SIZE.  
```

That all matches the description of `main` (doesn't use RBP, big stack that it probably can't fit in an otherwise compact encoding), but the `main` function doesn't have a subtraction to set the stack pointer. Instead the main function calls `__rust_probestack` and then executes `subq $rax, $rsp` where `$rax` has the stack size.

Basically I think this boils down to the unwind information generated by LLVM being incorrect for functions which trigger usage of `__rust_probestack` (stack probe guards). I don't think there's much we can do to fix this in rust-lang/rust but I wanted to file an issue to track this.
Repository: vscode
Issue: [theming] token type hierarchy to the 'Developer: Inspect Editor Tokens and Scopes' command
Labels: feature-request,editor-theming

Issue Type: <b>Feature Request</b>

This would be really useful for theme authors who want to find out the available supertypes of a token, without looking in the `semanticTokenTypes` contribution point. It could just be another line between `semantic token type` and `modifiers`:
![inspectTokens](https://user-images.githubusercontent.com/52179873/88200196-20e6e000-cc46-11ea-8d02-6c103165a121.png)

The right side of the line could say `token type hierarchy`, and the left side could say something like `member function`, to describe that `member` is the declared supertype of `function`. It is important to show **a hierarchy**, not just the immediate supertype of the token. For example, a token with a more complex type hierarchy could say something like:
`token type hierarchy <-- space in-between, like in the picture --> member property enumMember`