sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: quantize_per_tensor not symbolically traceable with FX if scale+zp are proxied
Labels: triaged,module: fx

## 🐛 Bug

Unable to symbolically trace a `torch.quantize_per_tensor` method call with FX if scale and zero_point are proxied.

## To Reproduce

```
# code
import torch                                                       
from torch.quantization.quantize_fx import prepare_fx, convert_fx  
from torch.fx.experimental import normalize                        
                                                                   
                                                                   
class M(nn.Module):                                                
    def __init__(self):                                            
        super().__init__()                                         
        self.dtype = torch.quint8                                  
                                                                   
    def forward(self, x, scale, zp):                               
        return torch.quantize_per_tensor(x, scale, zp, self.dtype) 
                                                                   
mp = torch.fx.symbolic_trace(M())                                  

# error

Traceback (most recent call last):
  File "/home/vasiliy/local/tmp/test.py", line 28, in <module>
    mp = torch.fx.symbolic_trace(M())
  File "/data/users/vasiliy/pytorch/torch/fx/symbolic_trace.py", line 771, in symbolic_trace
    graph = tracer.trace(root, concrete_args)
  File "/data/users/vasiliy/pytorch/torch/fx/symbolic_trace.py", line 483, in trace
    self.create_node('output', 'output', (self.create_arg(fn(*args)),), {},
  File "/home/vasiliy/local/tmp/test.py", line 26, in forward
    return torch.quantize_per_tensor(x, scale, zp, self.dtype)
TypeError: quantize_per_tensor() received an invalid combination of arguments - got (Proxy, P
roxy, Proxy, torch.dtype), but expected one of:
 * (Tensor input, float scale, int zero_point, torch.dtype dtype)
      didn't match because some of the arguments have invalid types: (Proxy, Proxy, Proxy, to
rch.dtype)
 * (tuple of Tensors tensors, Tensor scales, Tensor zero_points, torch.dtype dtype)
      didn't match because some of the arguments have invalid types: (Proxy, Proxy, Proxy, to
rch.dtype)

```


cc @ezyang @SherlockNoMad
Repository: TypeScript
Issue: lib.dom.d.ts should escape html elements in jsdoc comments
Labels: Suggestion,Help Wanted,Experience Enhancement

# lib Update Request

<!--
  Please fill in each section completely. Thank you!

  Are you here for one of these commonly-requested lib changes?
    * Object.keys - see https://stackoverflow.com/questions/55012174/
    * Array methods - see https://github.com/microsoft/TypeScript/issues/36554
    * parseInt, parseFloat, isFinite, isNaN, etc. - see https://github.com/microsoft/TypeScript/issues/4002

  The DOM lib is maintained elsewhere and you can skip a step by filing issues/PRs for the DOM at that repo.
  See https://github.com/microsoft/TypeScript-DOM-lib-generator
-->

## Configuration Check

<!--
  If you're missing common new methods like Array.includes, you may have a misconfigured project.
  Try setting `lib: "es2020"` and checking whether the type you want is present.
  You can diagnose further by running `tsc` with `--listFilesOnly` or `--showConfig`.

  Conversely, if you are seeing built-in methods you expect to *not* see, check your 'lib' setting
  or review your dependencies for lib/reference directives that might be polluting
  your global scope. This is common when using the 'node' type library. See https://github.com/microsoft/TypeScript/issues/40184

  Replace the text below:
-->
My compilation *target* is `ES2020` and my *lib* is `the default`.

## Missing / Incorrect Definition
For html elements such as `HTMLScriptElement`, the JSDoc includes `<script>`. This causes VS Code to drop the entire body of the comment

## Sample Code

```js
const a: HTMLScriptElement // hover over HTMLScriptElement
```

 
<img width="577" alt="Screen Shot 2021-05-11 at 9 32 36 AM" src="https://user-images.githubusercontent.com/12821956/117852381-1c72ce80-b23c-11eb-963b-2baed48f7bf5.png">


## Proposal

These JSDoc comments should escape any html in the comments. I suggest using markdown inline code instead:

```ts
/** HTML `<script>` elements expose the HTMLScriptElement interface ... */
interface HTMLScriptElement extends HTMLElement {
```
Repository: transformers
Issue: Routing Transformers / Add Google PG-19 Models
Labels: New model

# 🌟 New model addition - Google PG-19 Models

## Model description

Model checkpoints finally released as discussed in "Efficient Content-Based Sparse Attention with Routing Transformers'
Aurko Roy, Mohammad Saffar, Ashish Vaswani, David Grangier (https://arxiv.org/abs/2003.05997)

## Open source status

* [X ] the model implementation is available: (same link as below)
* [ X] the model weights are available: ( https://github.com/google-research/google-research/tree/master/routing_transformer)
* [X ] who are the authors: (see above)

Note: These tf2 models require proper conversion to pytorch versions and modifications to scripts to enable training and inference.
Repository: go
Issue: all: replace x.Type().Kind() to x.Kind()
Labels: Performance,NeedsInvestigation

If `x` is a `reflect.Value` value and it is not the zero `Value`, `x.Kind()` can be used instead of `x.Type().Kind()`.

There are many places in the standard library where this replacement can be done

```
% grep -r ".Type().Kind()" src
src/cmd/fix/cftype.go:			if v.Type().Kind() != reflect.Ptr {
src/cmd/fix/cftype.go:			if v.Type().Kind() != reflect.Struct {
src/net/http/transport.go:	if rv := reflect.ValueOf(altProto["https"]); rv.IsValid() && rv.Type().Kind() == reflect.Struct && rv.Type().NumField() == 1 {
src/reflect/value.go:	if v.Type().Kind() == Float32 && t.Kind() == Float32 {
src/internal/fmtsort/sort.go:	if mapValue.Type().Kind() != reflect.Map {
src/encoding/xml/read.go:	if val.Type().Kind() == reflect.Slice && val.Type().Elem().Kind() != reflect.Uint8 {
src/encoding/binary/binary.go:		switch v.Type().Kind() {
src/encoding/binary/binary.go:		switch v.Type().Kind() {
src/encoding/binary/binary.go:		switch v.Type().Kind() {
src/encoding/binary/binary.go:		switch v.Type().Kind() {
src/encoding/gob/encode.go:	if ut.externalEnc == 0 && value.Type().Kind() == reflect.Struct {
src/encoding/gob/decoder.go:	if value.Type().Kind() != reflect.Ptr {
src/time/tzdata_test.go:	switch f1.Type().Kind() {
src/time/tzdata_test.go:		t.Errorf("test internal error: unsupported kind %v", f1.Type().Kind())
```

Replacing occurrences in the `encoding/binary` package results in improvements in the `WriteStruct` benchmark

```
name                      old time/op    new time/op    delta
ReadStruct-4                 412ns ± 3%     415ns ± 7%     ~     (p=0.548 n=5+5)
WriteStruct-4                404ns ± 1%     325ns ± 0%  -19.43%  (p=0.008 n=5+5)
```
Repository: vscode
Issue: Render right or left bracket border thicker depending on the cursor position relative to initial bracket
Labels: feature-request,editor-bracket-matching

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

# Discussion

Sometimes when you are writing code you need to find the other end of parenthesis to be sure you have just the right amount. The other end of the parentheses is shown, this is helpful.

But this can be ambiguous for the outermost matched pair because your cursor is inside or outside that last pair and the corresponding highlight only matches the character as a whole.

This can be shown visibly.

# Current

![old](https://user-images.githubusercontent.com/382183/117869951-6d4cec00-b269-11eb-9696-8768ae112b84.gif)

# Proposed

![new](https://user-images.githubusercontent.com/382183/117870160-bdc44980-b269-11eb-837e-dc1424088206.gif)
Repository: TypeScript
Issue: TS intellisense getting tripped on const object indexes
Labels: Bug,Help Wanted,Domain: Completion Lists

*TS Template added by @mjbvz*

**TypeScript Version**: 4.4.0-dev.20210511

**Search Terms**
- suggest / suggestions
- Bracket accessor 

---

Issue Type: <b>Bug</b>

```ts
const a = {
    foo: 'foo',
} as const;

const c = {
    [a.foo]: 'foo',
} as const;

c.
```
Suggests:
![Screenshot from 2021-05-11 17-49-16](https://user-images.githubusercontent.com/6131515/117846104-6c27b900-b281-11eb-9b14-78f8213a216b.png)
![Screenshot from 2021-05-11 17-49-33](https://user-images.githubusercontent.com/6131515/117846114-6df17c80-b281-11eb-9d53-eeabce18b065.png)
Yet type of `c` seems to be perfectly fine when hovered.


VS Code version: Code 1.55.2 (3c4e3df9e89829dce27b7b5c24508306b151f30d, 2021-04-13T09:37:02.931Z)
OS version: Linux x64 5.11.16-arch1-1

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz (8 x 2100)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: disabled_off<br>opengl: enabled_on<br>protected_video_decode: unavailable_off<br>rasterization: disabled_software<br>skia_renderer: enabled_on<br>video_decode: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|1, 1, 1|
|Memory (System)|31.02GB (12.29GB free)|
|Process Argv|. --no-sandbox|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|undefined|
|XDG_CURRENT_DESKTOP|GNOME|
|XDG_SESSION_DESKTOP|undefined|
|XDG_SESSION_TYPE|tty|
</details><details><summary>Extensions (19)</summary>

Extension|Author (truncated)|Version
---|---|---
terraform|4op|0.2.2
lit-html|bie|1.11.1
better-toml|bun|0.3.2
mustache|daw|1.1.1
vscode-eslint|dba|2.1.20
gitlens|eam|11.4.1
EditorConfig|Edi|0.16.4
RunOnSave|eme|0.2.0
plantuml|jeb|2.14.5
better-shellscript-syntax|jef|1.1.0
vscode-phpfmt|kok|1.0.30
theme-monokai-pro-vscode|mon|1.1.19
gitlink|qez|0.6.1
rust|rus|0.7.8
vscode-fileutils|sle|3.4.5
code-spell-checker|str|1.10.2
vcl|tho|0.1.2
shellcheck|tim|0.14.1
vscode-lldb|vad|1.6.3


</details>
<!-- generated by issue reporter -->
Repository: PowerToys
Issue: [Feature-Request] PT Run: custom order for Plugins
Labels: Idea-Enhancement,Run-Plugin Manager

![image](https://user-images.githubusercontent.com/32982430/117877399-cb4af500-b2a4-11eb-9241-3d9b392147bd.png)
The new Plugin list with the ability to disable single elements is awesome. Thanks for this great implementation!

The feature would be even better if users could re-order the plugins to their own liking. Just like the color formats in color picker.

usecase: 
Because I like the Windows Search, I use PT Run only for enhanced features, like executing shell commands. The most important thing is window walker, because you want to multi task in a fast way. Sadly it has a less important prioritization. As soon as you have cmd-commands enabled, window walker is always at the bottom. Typing the activation phrase is a great idea, but not always convinient. Maybe a custom order could make users more happy.

But I can also understand, if the activation phrase is already enough for this.
Repository: flutter
Issue: RenderWrap.computeMaxIntrinsicWidth does not calculate spacing, resulting in improper line feeds.
Labels: framework,a: layout,has reproducible steps,P2,found in release: 3.7,found in release: 3.11,team-framework,triaged-framework

code: 

```dart
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  static const String _title = 'Flutter Code Sample';

  @override
  Widget build(BuildContext context) {
    var data = 'test test test test test test test test test test';
    return MaterialApp(
        title: _title,
        home: Scaffold(
          body: IntrinsicWidth(
            child: Column(
              mainAxisSize: MainAxisSize.min,
              crossAxisAlignment: CrossAxisAlignment.stretch,
              children: [
                Container(
                  color: Colors.blue,
                  padding: const EdgeInsets.all(8.0),
                  width: 245,
                ),
                Wrap(
                  alignment: WrapAlignment.spaceBetween,
                  runAlignment: WrapAlignment.end,
                  spacing: 8,
                  children: [
                    Text(data),
                    Text('date time')
                  ],
                ),
              ],
            ),
          ),
        ),
      );
  }
}
```

![image](https://user-images.githubusercontent.com/11473691/117879113-2696da80-b2d9-11eb-817a-d4cb2e170022.png)


RenderWrap.computeMaxIntrinsicWidth does not calculate spacing, resulting in improper line feeds.
Repository: pytorch
Issue: TensorList upfront checks parameter types in argument parsing and throws an error unexpectedly
Labels: triaged,module: codegen

It has been discussed in the following PR https://github.com/pytorch/pytorch/pull/57529#discussion_r627059296 that in the process of argument parsing, unlike other lists (IntList, ScalarList etc) type checking wants to handle TensorLists parameters upfront whether TensorList is the correct parameter of signature or not.

Specifically, in the following line we can see 
https://github.com/pytorch/pytorch/blob/20430932177725efdc9bff53500e2f2397e4d20b/torch/csrc/utils/python_arg_parser.cpp#L406

that error has been thrown here. It would be nice to investigate if it can be possible to adjust this check similar to other lists and just return false.

Simple observation tells us, just deleting this Throw  and returning false would cause following test to be broken
```
======================================================================
FAIL [0.010s]: test_cat2_cpu_float16 (__main__.TestTensorCreationCPU)
----------------------------------------------------------------------
TypeError: cat(): argument 'tensors' (position 1) must be tuple of Tensors, not list
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/conda/lib/python3.6/site-packages/torch/testing/_internal/common_device_type.py", line 292, in instantiated_test
    result = test_fn(self, *args)
  File "/opt/conda/lib/python3.6/site-packages/torch/testing/_internal/common_device_type.py", line 729, in only_fn
    return fn(slf, device, *args, **kwargs)
  File "test_tensor_creation_ops.py", line 1158, in test_cat2
    self.assertRaisesRegex(TypeError, 'got None', lambda: torch.cat([x, None]))
  File "/opt/conda/lib/python3.6/site-packages/torch/testing/_internal/common_utils.py", line 1452, in assertRaisesRegex
    return super().assertRaisesRegex(expected_exception, expected_regex, *args, **kwargs)
AssertionError: "got None" does not match "cat(): argument 'tensors' (position 1) must be tuple of Tensors, not list"
```
Repository: godot
Issue: Editor tooltips should be constrained inside the editor window even at the bottom of the UI
Labels: discussion,topic:editor,usability

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.3.stable
<!-- Specify commit hash if using non-official build. -->


**OS/device including version:** Windows 10
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->


**Issue description:** As I move my mouse down, the editor tooltips are drawn incorrectly at the bottom of the main window. While their `x` position is adjusted to keep the tooltip inside the editor, such adjustment isn't applied for the `y` position, and at the bottom part of the UI the tooltips may only be partially visible, as my short video demonstrates.
<!-- What happened, and what was expected. -->
https://user-images.githubusercontent.com/2530086/117885488-33520900-b2ae-11eb-9427-9751e39b2440.mp4

A better UX would be to adjust the `y` position to keep the entire tooltip inside the main window. Perhaps the tooltip could be dismissed with `Shift + Esc` or a similar shortcut if it becomes "too helpful".


**Steps to reproduce:** Open the Godot Editor, find a Label in the Inspector near the bottom of the main editor window, and observe how the tooltips are drawn.


**Minimal reproduction project:** None, it's a bug in the editor itself.
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: TypeScript
Issue: Idea: Can we cache the result of `typeToTypeNode`?
Labels: Domain: Performance,Rescheduled

A large percentage of declaration emit time (and a small percentage of check time) is spent in `typeToTypeNode` and tracing indicates that it is called on some types many times (hundreds or thousands in a sufficiently large project).  I suspect, but have been able to demonstrate, that those requiring a `import()` qualification are particularly expensive.  Could we cache the result?  Two clear obstacles:

1. Nodes are mutated during emit, so we'd need to clone anything retrieved from the cache.  I'm reasonably confident that cloning will be cheaper than recomputing.
2. `typeToTypeNode` takes a complex context argument.  Possible workarounds include including the context hash in the cache key and storing the cached value _on_ the context.
Repository: pytorch
Issue: Follow-up updates to inference mode python bindings
Labels: triaged,inference mode

Issue tracks some things to do to follow up on #58045
 - Move tests to separate file from `test_autograd`
 - Move `inference_mode` context manager to its own file (from `grad_mode.py`
 - Python bindings for `is_inference_tensor`
 - Improved short description and example
 - Link to tutorial
Repository: TypeScript
Issue: Idea: Can declaration emit synthesize imports?
Labels: Domain: Performance,Fix Available,Rescheduled

If an unimported type is referenced repeatedly, each reference will be qualified with the same `import("path")` expression.  Cumulatively, these can significantly enlarge a declaration file.

Probably, this will be the first time we need to make non-local edits to a declaration file, which may substantially increase the code complexity.  It should not, however, take much more time to execute (unless I'm missing something).
Repository: TypeScript
Issue: Idea: Can declaration emit synthesize type aliases?
Labels: Suggestion,Domain: Performance,Experimentation Needed

Object types can be very large and in (e.g.) a react project that makes heavy use of type inference, it's not uncommon to have to refer to a type that is either not imported or is simply anonymous (e.g. a props type).  When these appear in multiple places in a declaration file, they tend to expand it considerably.  Perhaps we could just synthesize type aliases for them?

- We'd have to be careful not to change the exported API shape
- We could use a heuristic to skip the work for small types (e.g. < 20 characters)
- Even if we didn't wait until the second use of a type to decide to extract it, we'd be adding ~4 tokens per type (`type id =` and `id` at the use site)
Repository: TypeScript
Issue: Idea: Distinguish between build-signature declarations and for-publication declarations
Labels: Domain: Performance

Some declaration files are intended for publication and they need to be readable and "work" (e.g. no imports from node_modules).  Others are, from a user's perspective, basically temporary files produced by the build to make subsequent builds more incremental (i.e. faster).  Right now, we produce both sets of declaration files in the same way, but maybe we don't need to?  As far as I can tell, the characteristics we require from "build" declarations are:

1) They change if-and-only-if the API of the underlying code changes
2) A source map can get you back from the declaration file to the input file

We can satisfy these requirements without, e.g.

1) Pretty-printing
2) Adding imports (as in #44044)
3) Confirming that referenced types are actually accessible (simplifying #44045) 
4) Complaining about `node_modules` imports

One likely snag is how users will opt in to this behavior (Is it enough to be `composite`/`incremental` without having `declarations`?  Is yet another switch required?).
Repository: vscode
Issue: [api][commands] Open new window and a file
Labels: feature-request,api

The `vscode.newWindow` command takes a `remoteAuthority` argument and opens a window on that authority. The Azure ML extension needs to open a window on a certain remote, then open a file on that remote. They do this by adding extra data to the remoteAuthority. This works but a downside is that you end up with extra entries in recently opened, since these windows have different remote authorities and are considered distinct. A better way to do this would be to allow passing in extra arguments that go to the resolver. Maybe they would be a fragment or query on the opened workspace folder URI, I don't know whether we ever do that.
Repository: go
Issue: cmd/compile: allocate slices lazily
Labels: Performance,NeedsInvestigation

This is an alternative to #15735.

When a slice is constructed (`make([]foo, N)`), the Go runtime could avoid allocating the backing array until something actually tries to read or write to the slice.  In most cases, the slice is used immediately, so this has little effect, but when used with a blocking implemention of `io.Readable.Read`, the internal call to `pollDesc.waitRead()` delays the first use of the slice until after the wait.  This would improve the memory efficiency of Go socket servers with many blocked sockets (if they are written in a particular style and the garbage collector is working well).

This is not a language change, although it might influence coders to use different slice creation strategies.
Repository: pytorch
Issue: Static graph training fails if forward is called multiple times before backward
Labels: high priority,triage review,oncall: distributed,triaged,module: ddp

## 🐛 Bug

The accounting for how many times a grad will have its hook called is done in the backwards pass, namely in the autograd hook for the variable. However we only do this if `num_iterations_ == 1` so we implicitly have the assumption that every forward pass will do a backwards pass before calling the next forward.

However, this assumption breaks if the user does a forward, no backward, and then a forward again, followed by backward. The reducer thinks that num_iterations_ == 2 and thus it has never populated `numGradHooksTriggeredMap_`, leading to an error.

## To Reproduce
Patch https://github.com/pytorch/pytorch/pull/57073, and just duplicate the line `out_static = model_static_graph(inp, output_type=output_type)` right on the next line. It will fail with:

```
    Variable._execution_engine.run_backward(
RuntimeError: Your training graph has changed in this iteration, e.g., one parameter is unused in first iteration, but then got used in the second iteration. this is not compatible with static_graph set to True.
```

cc @ezyang @gchanan @zou3519 @bdhirsh @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @agolynski @mrzzd @cbalioglu @gcramer23
Repository: pytorch
Issue: [FX] Revise PyTree support in FX to move pytree logic out of `self.code`
Labels: triaged,module: fx

The idea is to move pytree-ification of a module into a separate pass, and have that pass return a tuple of `(flat_graph, reinstall_pytree_fn)`.

cc @ezyang @SherlockNoMad