sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: PEP-585 type annotations not supported for class-level annotations
Labels: oncall: jit,triaged

## 🐛 Bug

Pytorch 1.9 supports PEP-585 type annotations, but JIT fails when annotations are used outside functions. The same works with `List[torch.Tensor]`.

## To Reproduce

```py
import torch

class Test(torch.nn.Module):
    ys: list[torch.Tensor]

    def __init__(self):
        super().__init__()
        self.ys = []

torch.jit.script(Test())
```
```sh
$ python jit2.py
Traceback (most recent call last):
  File "/pool01/home/twoertwe/git/python-tools/jit2.py", line 14, in <module>
    torch.jit.script(Test())
  File "/pool01/home/twoertwe/.cache/pypoetry/virtualenvs/python-tools-XWCSm5JO-py3.9/lib/python3.9/site-packages/torch/jit/_script.py", line 1096, in script
    return torch.jit._recursive.create_script_module(
  File "/pool01/home/twoertwe/.cache/pypoetry/virtualenvs/python-tools-XWCSm5JO-py3.9/lib/python3.9/site-packages/torch/jit/_recursive.py", line 410, in create_script_module
    concrete_type = get_module_concrete_type(nn_module, share_types)
  File "/pool01/home/twoertwe/.cache/pypoetry/virtualenvs/python-tools-XWCSm5JO-py3.9/lib/python3.9/site-packages/torch/jit/_recursive.py", line 386, in get_module_concrete_type
    concrete_type = concrete_type_store.get_or_create_concrete_type(nn_module)
  File "/pool01/home/twoertwe/.cache/pypoetry/virtualenvs/python-tools-XWCSm5JO-py3.9/lib/python3.9/site-packages/torch/jit/_recursive.py", line 327, in get_or_create_concrete_type
    concrete_type_builder = infer_concrete_type_builder(nn_module)
  File "/pool01/home/twoertwe/.cache/pypoetry/virtualenvs/python-tools-XWCSm5JO-py3.9/lib/python3.9/site-packages/torch/jit/_recursive.py", line 291, in infer_concrete_type_builder
    attr_type, inferred = infer_type(name, value)
  File "/pool01/home/twoertwe/.cache/pypoetry/virtualenvs/python-tools-XWCSm5JO-py3.9/lib/python3.9/site-packages/torch/jit/_recursive.py", line 139, in infer_type
    ann_to_type = torch.jit.annotations.ann_to_type(class_annotations[name], _jit_internal.fake_range())
  File "/pool01/home/twoertwe/.cache/pypoetry/virtualenvs/python-tools-XWCSm5JO-py3.9/lib/python3.9/site-packages/torch/jit/annotations.py", line 376, in ann_to_type
    raise ValueError(f"Unknown type annotation: '{ann}' at {loc.highlight()}")
ValueError: Unknown type annotation: 'list[torch.Tensor]' at
```

cc @gmagogsfm
Repository: pytorch
Issue: Some ops throw runtime errors when called with complex tensors that require_grad but work when requires_grad=False
Labels: module: autograd,triaged,module: complex,complex_autograd

The following ops will throw an error when called with complex inputs that require grad:

- cholesky_inverse
- linalg.det
- var_mean
- std_mean
- to_sparse
- sigmoid

However, an error should only be thrown if a user actually tries to compute the gradient through these ops.

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @anjali411 @dylanbespalko @mruberry
Repository: storybook
Issue: [V6.2.9] Control type OBJECT's value is not set on initial load
Labels: bug,addon: controls

### BUG DESCRIPTION
* Controls of object type is not set on initial load of story:
  * ![image](https://user-images.githubusercontent.com/43020293/122341123-77f45280-cf86-11eb-8b23-08694861fad2.png)
* _**But**_ it will be set once you click on **Reset controls** button.
  * ![control object gets set on reset only](https://user-images.githubusercontent.com/43020293/122341317-b12cc280-cf86-11eb-9f4b-0ebc47f994a6.gif)

### System
`npx sb@next info` output:


```bash
Environment Info:

  System:
    OS: macOS 11.2.2
    CPU: (8) x64 Intel(R) Core(TM) i7-1068NG7 CPU @ 2.30GHz
  Binaries:
    Node: 12.22.1 - ~/.nvm/versions/node/v12.22.1/bin/node
    npm: 6.14.12 - ~/.nvm/versions/node/v12.22.1/bin/npm
  Browsers:
    Chrome: 91.0.4472.106
    Firefox: 89.0
    Safari: 14.0.3
  npmPackages:
    @storybook/addon-a11y: ^6.2.1 => 6.2.9 
    @storybook/addon-actions: ^6.2.1 => 6.2.9 
    @storybook/addon-essentials: ^6.2.1 => 6.2.9 
    @storybook/addon-knobs: ^6.2.1 => 6.2.9 
    @storybook/addon-links: ^6.2.1 => 6.2.9 
    @storybook/addon-options: ^5.3.21 => 5.3.21 
    @storybook/react: ^6.2.1 => 6.2.9 
    @storybook/theming: ^6.2.1 => 6.2.9 
```

**Additional context**
:information_source: : Last time this worked for us was in `version 6.2.1` ❗
Repository: pytorch
Issue: torch.load non backwards compatible on Transformer between 1.8.1 and 1.9.0
Labels: module: serialization,triaged

## 🐛 Bug

A Transformer that I used `torch.save` on with Pytorch 1.8.1 cannot load on Pytorch 1.9.0.

## To Reproduce

Steps to reproduce the behavior:

On Pytorch 1.8.1:
```python
import torch
from torch.nn import Transformer
torch.save(Transformer(), 'transformer.pt')
```
Then update Pytorch to 1.9.0
```python
import torch
torch.load('transformer.pt')
```
The following stacktrace will show:
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File ".../python3.8/site-packages/torch/serialization.py", line 607, in load
    return _load(opened_zipfile, map_location, pickle_module, **pickle_load_args)
  File ".../python3.8/site-packages/torch/serialization.py", line 882, in _load
    result = unpickler.load()
  File ".../python3.8/site-packages/torch/serialization.py", line 875, in find_class
    return super().find_class(mod_name, name)
AttributeError: Can't get attribute '_LinearWithBias' on <module 'torch.nn.modules.linear' from '.../python3.8/site-packages/torch/nn/modules/linear.py'>
```

## Expected behavior

`torch.save()` on Pytorch X should be able to load modules that are saved on previous versions (https://github.com/pytorch/pytorch/issues/6801#issuecomment-383178266 says that torch.load is supposed to be backwards-compatible)

In this specific case, redefining the `_LinearWithBias` module in torch.nn.modules.linear would solve the issue.

## Environment

 - PyTorch Version (e.g., 1.0): 1.9.0
 - OS (e.g., Linux): macOS (but it also happens on Linux with a model loaded & saved there)
 - How you installed PyTorch (`conda`, `pip`, source): `pip`
 - Python version: 3.8.7
 - CUDA/cuDNN version: None
 - GPU models and configuration: No



cc @mruberry
Repository: flutter
Issue: [flutter_driver]: Proposal to add properties for drop down values
Labels: c: new feature,framework,t: flutter driver,c: proposal,P3,team-framework,triaged-framework

After tap the drop down/list using flutter driver and how we are getting this list, if we have the this features then it will good for all !

and i believe nothing is impossible so can we add this features where we target all the input field like we used find for finding something can we have **finds**  

Thank you !! 🙂
Repository: pytorch
Issue: [Android] Upgrading to 1.9.0 causes NNAPI model loading to fail
Labels: module: android,oncall: mobile

## 🐛 Bug

After upgrading to Pytorch 1.9.0 and using the suggested dependency imports and model loading function, the model fails to load. 
Before, I was creating the NNAPI model with 1.9.0 nightly-build and importing the dependency as 
`implementation 'org.pytorch:pytorch_android:1.9.0-SNAPSHOT'` and it worked.

## To Reproduce

Steps to reproduce the behavior:

**1. Convert to NNAPI & CPU**

```
# Convert to NNAPI
nnapi_model = torch.backends._nnapi.prepare.convert_model_to_nnapi(torchscript_model, input_tensor)
nnapi_model._save_for_lite_interpreter("model-nnapi.torchscript.pt")

# Convert to CPU
cpu_model = optimize_for_mobile(torchscript_model)
cpu_model._save_for_lite_interpreter("model-cpu.torchscript.pt")
```

**2. Add dependency in Android App**

I've tried both
```
repositories {
    maven {
        url "https://oss.sonatype.org/content/repositories/snapshots"
    }
}
implementation 'org.pytorch:pytorch_android_lite:1.9.0'
implementation 'org.pytorch:pytorch_android_torchvision:1.9.0'
```
and 
```
repositories {
    jcenter()
}
implementation 'org.pytorch:pytorch_android_lite:1.9.0'
implementation 'org.pytorch:pytorch_android_torchvision:1.9.0'
```

**3. Load both models**

```
mModuleCPU = LiteModuleLoader.load(MainActivity.assetFilePath(getApplicationContext(), "model-cpu.torchscript.pt"));
mModuleNNAPI = LiteModuleLoader.load(MainActivity.assetFilePath(getApplicationContext(), "model-nnapi.torchscript.pt"));
```

**4. CPU model loads, NNPI model fails**

```
com.facebook.jni.CppException: The implementation of class __torch__.torch.classes._nnapi.Compilation cannot be found. ()
Exception raised from parseMethods at ../torch/csrc/jit/mobile/import.cpp:426 (most recent call first):
(no backtrace available)
```


## Expected behavior

I expect the NNAPI model to load as well.

## Environment
I am using the following libraries for converting the model to NNAPI(I was using the 1.9.0 nightly build before)

```
pytorch                   1.9.0           py3.8_cuda10.2_cudnn7.6.5_0    pytorch
torchvision               0.10.0               py38_cu102    pytorch
```
Repository: storybook
Issue: @storybook/web-components lit v1 compat requires lit-html dependency
Labels: bug,dependencies,web-components

**Describe the bug**

Introduced by #14898.

The peer dependency configuration means that we're forced to have `lit-html` as a dependency to make storybook pull in the right peer.

We have something like this inside storybook now:

```json
  "lit-html": "1.4.1 | 2.0.0"
```

however, going forward the best practice is to pull from `lit`, _not_ `lit-html`. Which means all lit v2 projects will have to install lit-html as a dependency to force storybook into resolving the right one.

Not having the right version means we then have the wrong `TemplateResult` in the types, causing build errors in typescript projects.

you can see this also mentioned here:

https://github.com/storybookjs/storybook/pull/14898#issuecomment-847694008

I also understand we're making `@storybook/lit` but web-components should still work correctly, without having to add an unnecessary dependency.
Repository: flutter
Issue: [Webview_flutter][Android]: Url not showing up in full screen.
Labels: platform-android,p: webview,package,has reproducible steps,P2,found in release: 2.2,team-android,triaged-android

![1](https://user-images.githubusercontent.com/78532352/122406811-c31a5f80-cf9e-11eb-9ed3-a5b2a906f2a1.jpg)

![2](https://user-images.githubusercontent.com/78532352/122406831-c6ade680-cf9e-11eb-92f3-5a3060b5d63c.jpg)

![3](https://user-images.githubusercontent.com/78532352/122406842-c9104080-cf9e-11eb-9ca6-fdcfd8846a08.jpg)

<h2>In My project webview is not show in full screen</h2>
<h3> Device Samsung<h3>
<h3> OS Version: 11<h3>

<details>
<summary>Code</summary>
<p>import 'dart:io';

import 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';

class WebviewFlutterTest extends StatefulWidget {
  @override
  State<StatefulWidget> createState() => _WebviewFlutterTest();
}

class _WebviewFlutterTest extends State<WebviewFlutterTest> {
  @override
  void initState() {
    if (Platform.isAndroid) WebView.platform = SurfaceAndroidWebView();
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: WebView(
          initialUrl:
              "https://github.com/"),
    );
  }
}
</p>
Repository: deno
Issue: New File System API
Labels: web,suggestion,runtime

This API would live in parallel with the existing low-level file system API provided by `Deno.open`, `Deno.write`, `Deno.read`, `Deno.readDir`, ...

Writing to a file:
```js
const fileHandle = await Deno.getFileHandle("/tmp/foo.txt"); // Returns FileSystemFileHandle 
const writable = await fileHandle.createWritable();
const writer = writable.getWriter();
await writer.write(new TextEncoder().encode("Hello World"));
await writer.close();
```

Also directory listing
```js
const directoryHandle = await Deno.getDirectoryHandle("/etc"); // Returns FileSystemDirectoryHandle 
for await (let [name, handle] of directoryHandle) {
  // ...
}
```

https://wicg.github.io/file-system-access/




Or maybe we have a Deno name-spaced directoryHandle corresponding to the cwd.
```js
const fileHandle = await Deno.currentDirectory.getFileHandle("README.md");

// maybe root directory too?
const passwdHandle = await Deno.rootDirectory.getFileHandle("etc/passwd");
```
Repository: flutter
Issue: Make the enabled FeatureFlags more visible to developers
Labels: tool,a: quality,P3,team-tool,triaged-tool


## Use case


First, a little background on a recent issue that I ran into. (for reference: #84347 )

Many flutter devs, and also me, use [fvm](https://fvm.app/) for managing the flutter versions and to quickly switch between flutter versions without downloading them over and over again.
Flutter versions installed through fvm had an issue where they would not be on a valid channel.
Since the channel was unknown, the flutter tool set the enabled feature flags to the feature flags from master. (https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/features.dart#L367 )

This caused fvm users who installed a stable version to be running features that were not intended for stable versions.

Since fvm is a rather popular package on pub and nobody noticed this until recently, I think it's a reasonable claim that a lot of flutter developers are not aware of the behavior, that features get enabled based on the current channel, which is derived from the git history.

Also, when I opened an issue because of a bug that occurred due to the feature flags that were enabled when they should not have been, I misunderstood the suggestion that the cause of this is that I am not on a valid channel -
I assumed that the person reviewing the issue thought that I am running some custom version of flutter with custom commits, and not that the fact that the channel is unknown caused a difference in behavior, even if you are on the same commit.

This is not only a potential issue for fvm users (fvm will fix this in a future release), but also for users who are running a custom version of flutter, for example, because they need to include a few commits who are not yet on an official release.
At least I did this in the past when I was waiting for PRs to get merged but still needed to get a new release out.

They might not be aware that by just switching to a new branch and adding a small commit, they might change the behavior of the flutter tool.


## Proposal

I would like the flutter tool to display the enabled feature flags more prominently, for example when running `flutter doctor --verbose`.

Also, when running flutter on an unknown branch, maybe there should be a warning/info that lists all the enabled features or at least the ones that are not yet stable.

I think if there was an info message that I am running flutter with "isSingleWidgetReloadEnabled", I would have found the source of the issue with hot reload much much earlier.
Repository: godot
Issue: get_wordwrap_string_size wrong calculation with japanese text without any space charaters
Labels: bug,topic:gui

### Godot version

3.3.2-stable

### System information

MacOS Bir Sur 11.4 - Radeon Pro 580X 8 GB

### Issue description

get_wordwrap_string_size result divided by font.get_height gives not correct line count if the text has no whitespace.
Text is shown correctly in RichTextLabel

### Steps to reproduce

I made a small project where you can see, that the line count should be 3 but the output is just 2.

this is the whole code, you can see that it grabs the size for the width from the RichTextLabel, so it should be 3 as well.

```
func _ready():
	var font:Font = $RichTextLabel.get_font("normal_font")
	var max_width = $RichTextLabel.rect_size.x
	calc_line_count(font, $RichTextLabel.bbcode_text, max_width)

func calc_line_count(font: Font, text: String, max_width: float):
	var text_dim: Vector2 = font.get_wordwrap_string_size(text, max_width)
	var line_count = text_dim.y / font.get_height()
	prints("Text", text)
	prints("max_wdith", max_width)
	prints("rect", text_dim)
	prints("line count", text_dim.y / font.get_height())
```

### Minimal reproduction project

[JapaneseLinecount.zip](https://github.com/godotengine/godot/files/6671199/JapaneseLinecount.zip)
Repository: go
Issue: cmd/go: suggest 'go get' for packages in the main module instead of missing external package paths
Labels: NeedsInvestigation,GoCommand,modules,BadErrorMessage

In https://github.com/golang/go/issues/45979#issuecomment-862744748, I noted that `go get` in a `go 1.17` module adds its arguments as `// indirect`.

As an intentional consequence of #45965, we place the `// indirect` dependencies in a separate section of the `go.mod` file from the direct dependencies. That potentially makes these new actually-direct dependencies more difficult to spot.

If we saw the import of the missing package from within the main module to begin with, we would add it without the erroneous `// indirect` marking, and avoid the churn of moving it between sections. So I think we should suggest a command that does that, instead of suggesting `go get` on the specific missing package(s).

That would also help to eliminate some of the redundancy in the `go get` hints (#43653).

CC @jayconrod @matloob @stevetraut
Repository: deno
Issue: Stabilising UDP/Datagram
Labels: public API,suggestion

I couldn't find any issue tracking the progress on stabilising UDP in Deno, so I wanted to ask the current status of it was. Is it close or is there work to be done?
Repository: create-react-app
Issue: document SKIP_PREFLIGHT_CHECK, improve err messaging
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Unclear that `PREFLIGHT_CHECK` consists only of `verifyPackageTree`. CRA users in non-traditional environments (_e.g.;_ <tt>git submodules</tt>, <tt>lerna</tt>, <tt>yarn workspaces</tt>) encountering this can get a false positive because normal node module resolution indeed works just fine. 

refs:
* #1333
* #6756
* #1795

### Describe the solution you'd like

1. Wordsmith the [error messaging in `verifyPackageTree.js`](https://github.com/facebook/create-react-app/blob/0ee4765c39f820e5f4820abf4bf2e47b3324da7f/packages/react-scripts/scripts/utils/verifyPackageTree.js#L83-L158) to indicate this is only a footgun check
2. Add something to the docs site about this flag. AFAIK, there is no mention of `SKIP_PREFLIGHT_CHECK` _anywhere_ in the docs site, but adding to `/docusaurus/docs/advanced-configuration.md` at minimum would be a good idea.

### Describe alternatives you've considered

Would be nice if the `SKIP_PREFLIGHT_CHECK` had a more descriptive name, but not worth changing IMO.
Repository: PowerToys
Issue: Image Resizer - Size Grouping Categories for different scenarios
Labels: Idea-Enhancement,Product-Image Resizer

### Provide a description of the new feature / enhancement

Currently, the image resizer allows you to create preset sizes for images.

Many web developers have multiple different components that require images be in different aspect ratios than other components. So, each of these components may have a different definition for what a small, medium, large, and extra large image would be.

I propose categories be added to the image resizer, where the user may add/edit/remove categories, and add/edit/remove image sizes within each category. When resizing, these categories would appear as a context menu group, and when expanded, options exist for each image size in the category, as well as an option to make a copy of the image in all sizes in the category.

For example, if I needed to resize a single image to fit a jumbotron component on multiple viewports, I could right click the image, Choose resize, select the category, and then select the size(s) I want. The output will appear in a new folder and the images would have their new dimensions in the filename, or the size label in their place.
Repository: vscode
Issue: More obvious UI for output mimetype selector
Labels: ux,polish,notebook-output

This selector isn't the most obvious for changing output type. Especially since an ellipses isn't an icon I'd think about clicking often; I assume it contains secondary actions that aren't everyday actions and not something I'd use often which I would for changing output types.

![image](https://user-images.githubusercontent.com/12758612/122435028-7c037e80-cf4c-11eb-864d-0efa556894d8.png)

Previously we had an icon that looked like: `</>` but I've seen some feedback where that icon is non-intuitive and doesn't make sense to click. 

I think this is also compounded by the fact that changing output isn't common in other notebook platforms so most people aren't expecting to use that icon but are expecting a different outputs mentioned here: https://github.com/tanhakabir/rest-book/issues/85#issuecomment-828896165

There's also no UI indication that a cell has more than 1 output type available.

Ideas:
1. Language picker style output picker? Like this: 
![image](https://user-images.githubusercontent.com/12758612/122446951-14ebc700-cf58-11eb-84c6-b5babe28ae79.png)
Repository: pytorch
Issue: [package] Tutorial not accessible
Labels: oncall: package/deploy,imported

## 📚 Documentation

The [tutorial included in the documentation](https://pytorch.org/docs/stable/package.html#packaging-your-first-model) for `torch.package` leads to document that is not publicly accessible.
Repository: PowerToys
Issue: FancyZones editor to allow custom zones for Win11 snapping
Labels: Idea-Enhancement,FancyZones-Editor,FancyZones-Layouts,Product-FancyZones

### Description of the new feature / enhancement

I know leaks wont be discussed, so this can wait until after June 24th but is there a chance that Fancy Zone layouts could be bubbled up into the new Hover on Maximise/Restore button UI to integrate Fancy Zone interaction with the OS?

![image](https://user-images.githubusercontent.com/7389110/122454777-a16fa700-cfa3-11eb-9fc8-deb1512875b6.png)

### Scenario when this would be used?

Whilst the OS code and Fancy Zones should be separate, maybe the OS could add support for reading from a user's App Data folder - and the PowerToy could be the Fancy Zone editor, for creating the layouts?

### Supporting information

Just sharing a thought, but there is no Discussion section here :)