sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: html/template: escape unquoted attributes by first quoting them
Labels: Proposal

# Current behavior

We allow actions to appear in "[Unquoted Attribute](https://html.spec.whatwg.org/multipage/parsing.html#attribute-value-(unquoted)-state)" contexts.

This means this template is valid:
```html
<img src={{.}}>
```

To support this when we escape we have to take some extra care to escape **all whitespace** (which would break the token) and we rely on some **niche behaviors of the spec**.

For example if we render the template above with "da ta/" we get
```html
<img src=da&#32;ta/>
```
Which looks an awful lot like an ambiguous syntax. ([Playground link](https://play.golang.org/p/Fi80uovuhRk))

It turns out that if you follow the spec this should parse as
```html
<img src="data/">
```

But I find this behavior very brittle, especially considering that the escaping character set that we use currently was retrieved by using a bit of the spec and a custom script we **never re-run**:
https://github.com/golang/go/blob/75e16f5127eb6affb4b473c93565a8d29a802e51/src/html/template/html.go#L81-L93

# Proposal
Change this escaping to run two passes:
* First, escape the attribute as if it was double-quoted
* Then emit the value inside a pair of quotes

This would remove the need for `htmlNospace(Norm)ReplacementTable` and would make the logic more robust and simple.

# Notes

I found this while looking into https://github.com/golang/go/issues/42506

/cc @katiehockman @FiloSottile @rolandshoemaker @rsc
Repository: rust
Issue: Impl Trait forces unnecessary lifetime bounds
Labels: A-lifetimes,A-impl-trait,A-variance

It seems like impl Trait forces its own lifetime bound onto anything that it touches, even if that doesn't make sense.

```rust
struct Never<T>(fn() -> T);

impl<T> Iterator for Never<T> {
    type Item = T;
    fn next(&mut self) -> Option<T> {
        None
    }
}

fn actual_type<T>(f: fn() -> T) -> Never<T> {
    Never(f)
}

fn impl_trait<T>(f: fn() -> T) -> impl Iterator<Item = T> + 'static {
    Never(f)
}
```

Here I create an iterator like type that takes a function that produces T values. The implementation of the iterator doesn't really matter here. If I now create a function constructing that type, returning the actual type lets the borrow checker correctly understand that T doesn't require any lifetimes. However if I return impl Iterator instead, the compiler is apparently seeing that T is part of the impl Trait and therefore forces me to apply the same lifetime as the iterator itself to the elements T, even if that makes no sense. I'm guessing impl Trait is not properly respecting variance.

```
error[E0310]: the parameter type `T` may not live long enough
  --> src/lib.rs:14:35
   |
14 | fn impl_trait<T>(f: fn() -> T) -> impl Iterator<Item = T> + 'static {
   |               -                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `Never<T>` will meet its required lifetime bounds
   |               |
   |               help: consider adding an explicit lifetime bound...: `T: 'static`

error: aborting due to previous error
```

[Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8308bd1be7f75ae2aec884397801b4b1)

@HeroicKatora mentioned that a similar problem happens with trait objects as well: [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ce945e7487378ec680045fca77d0176e)
Repository: pytorch
Issue: Pytorch 1.5+: Kernel dies / Segmentation Fault with torch.cuda.mermory_allocated() and torch.cuda.mermory_reserved()
Labels: module: cuda,triaged,module: regression

## Issue description
When using pytorch > 1.4 calls for torch.cuda.mermory_allocated() or torch.cuda.mermory_reserved() lead to instantaneous dying of Jupyter Notebook Kernels without any exception trace. If run as python script from shell, the exception is: 

"Segmentation fault (core dumped)"

The same runs perfectly fine under pytorch 1.4 (w cuda 10.2 and cuda 11, 2080tis...).
I had the weird issue already like half a year ago when I tried updating to pytorch 1.5. As I did not need any of the new features I reverted the update instead of investigating the issue. Now, after updating to pytorch 1.7 the problem reappeared.

Other torch.cuda methods like is_available(), device_count() or empty_cache() work fine. I can also use my code as expected without problems by simply commenting out the problematic methods. 

## Code example

import torch
torch.cuda.mermory_allocated()

## System Info
Installed and updated pytorch via conda.

Output of collect_env.py:

Collecting environment information...
PyTorch version: 1.7.0
Is debug build: Yes
CUDA used to build PyTorch: 11.0

OS: Ubuntu 18.04.4 LTS
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
CMake version: version 3.10.2

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: GeForce RTX 2080 Ti
GPU 1: GeForce RTX 2080 Ti
GPU 2: GeForce RTX 2080 Ti
GPU 3: GeForce RTX 2080 Ti
GPU 4: GeForce RTX 2080 Ti
GPU 5: GeForce RTX 2080 Ti
GPU 6: GeForce RTX 2080 Ti
GPU 7: GeForce RTX 2080 Ti

Nvidia driver version: 455.45.01
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] efficientnet-pytorch==0.6.3
[pip3] numpy==1.19.2
[pip3] pytorchcv==0.0.58
[pip3] torch==1.7.0
[pip3] torchaudio==0.7.0a0+ac17b64
[pip3] torchvision==0.8.1
[conda] blas                      1.0                         mkl  
[conda] efficientnet-pytorch      0.6.3                    pypi_0    pypi
[conda] mkl                       2020.2                      256  
[conda] mkl-service               2.3.0            py37he8ac12f_0  
[conda] mkl_fft                   1.2.0            py37h23d657b_0  
[conda] mkl_random                1.1.1            py37h0573a6f_0  
[conda] pytorch                   1.7.0           py3.7_cuda11.0.221_cudnn8.0.3_0    pytorch
[conda] pytorchcv                 0.0.58                   pypi_0    pypi
[conda] torchaudio                0.7.0                      py37    pytorch
[conda] torchvision               0.8.1                py37_cu110    pytorch


cc @ngimel
Repository: flutter
Issue: [60Fps] is not reaching when calling the setState on every 200 milliseconds in simple application
Labels: platform-android,engine,c: performance,perf: speed,P2,team-android,triaged-android

## Details

I have tested the fps with simple sample by calling the setState on every 200ms to update the count in StatefullWidget. I expect that it will reach 60fps on every call but so disappointed that it reach only 15 to 30 up and down gradually.

- I delpoyed the application in profile mode
- Please look into the attached video 
[Screen Recording 2020-12-16 at 11.23.07 PM.zip](https://github.com/flutter/flutter/files/5704559/Screen.Recording.2020-12-16.at.11.23.07.PM.zip)
- Please get the sample form below attached zip.
[main.dart.zip](https://github.com/flutter/flutter/files/5704569/main.dart.zip)
- Please refer the reproducing steps

Reproducing step: 
1) Run the attached sample
2) In timer i have already set the 200ms to refresh the view

**Target Platform:** Android 
**Target OS version/browser:**
**Devices:** Samsung Galaxy S6 

## Logs
syncmac15136@syncmac15136s-MacBook-Air flutter_app_performance % flutter analyze  
Analyzing flutter_app_performance...                                    
No issues found! (ran in 8.0s)

```
```
syncmac15136@syncmac15136s-MacBook-Air flutter_app_performance % flutter doctor -v
[✓] Flutter (Channel stable, 1.22.5, on macOS 11.0.1 20B29 darwin-x64, locale en-US)
    • Flutter version 1.22.5 at /Users/syncmacn15136/flutter
    • Framework revision 7891006299 (6 days ago), 2020-12-10 11:54:40 -0800
    • Engine revision ae90085a84
    • Dart version 2.10.4

 
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /Users/syncmacn15136/Library/Android/sdk
    • Platform android-30, build-tools 30.0.2
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.2, Build version 12B45b
    • CocoaPods version 1.10.0

[!] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.51.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.17.0

[✓] Connected device (2 available)
    • SM G920I (mobile)           • 1215fc0d0e003303 • android-arm64 • Android 7.0 (API 24)
    • sdk gphone x86 arm (mobile) • emulator-5554    • android-x86   • Android 11 (API 30) (emulator)

! Doctor found issues in 1 category.
syncmac15136@syncmac15136s-MacBook-Air flutter_app_performance % 
```
```
Repository: pytorch
Issue: Write link in README.md
Labels: module: docs,triaged

## 🐛 Bug

The link in the file `README.md` on the main directory:
```
![PyTorch Logo](https://github.com/pytorch/pytorch/blob/master/docs/source/_static/img/pytorch-logo-dark.png)
```
is not correct, it points to a non-image file (in fact a HTML file), but GitHub is able to correctly this information. In programs like doxygen and pandoc the above link is converted to:
```
<img src="https://github.com/pytorch/pytorch/blob/master/docs/source/_static/img/pytorch-logo-dark.png" alt="PyTorch Logo" class="inline"/>
```
and when trying to display this image this results in the alternative text "PyTorch Logo".

## To Reproduce

Steps to reproduce the behavior:

1. take the README.md
1. create an empty Doxyfile (for doxygen)
1. run doxygen
1. view the result in a browser

## Expected behavior

Correct link so the image is rendered properly.

## Environment

 - PyTorch Version (e.g., 1.0): current master 
 - OS (e.g., Linux): independent

## Additional context

Possible solutions, change the link in:
```
![PyTorch Logo](https://github.com/pytorch/pytorch/raw/master/docs/source/_static/img/pytorch-logo-dark.png)
```
or
```
![PyTorch Logo](https://github.com/pytorch/pytorch/blob/master/docs/source/_static/img/pytorch-logo-dark.png?raw=true)
```
where the first solution is the preferred one.

cc @jlin27 @mruberry
Repository: pytorch
Issue: Use METH_FASTCALL protocol in Python bindings
Labels: feature,triaged,module: pybind

## 🚀 Feature
Move python bindings to use `FASTCALL` methods.

## Motivation

Python 3.7 introduced the `METH_FASTCALL` and `METH_FASTCALL | METH_KEYWORDS` binding methods. ([API](https://docs.python.org/3/c-api/structures.html#METH_FASTCALL)) They skip tuple/dict construction and simply pass C arrays, and based on my testing in https://github.com/pytorch/pytorch/pull/48965 can save ~15ns compared to `METH_VARARGS`. (I have not tested the kwargs version, but I would expect skipping a dictionary to be even better.)

## Pitch

https://github.com/pytorch/pytorch/pull/48965 adds a wrapper in `python_compat.h` so that we can rewrite endpoints to use `_PyCFunctionFast` but fall back to tuple wrapping for 3.6. This would need to be applied to all varargs functions and an analog would need to be written for functions that take kwargs. Given that most binding comes from the torch python arg parser, that will likely need to be converted as well. (I'm not sure how much work that would be.)
Repository: pytorch
Issue: Callbacks may not be automatically synchronized in a single NCCL future chain
Labels: oncall: distributed,triaged

## 🐛 Bug

I implemented PowerSGD gradient compression as a communication hook, and it is essentially a single future chain. Ideally, since NCCL won't kick off a callback until the precursor callback in the same future chain is completed, the user shouldn't need any explicit synchronization in this case.

However, I find that I do need an explicit synchronization `torch.cuda.synchronize()` at least in the last callback of the future chain. Otherwise, it will lead to illegal memory access (or sometimes the output tensor has NaN).
See #49435, which is my workaround.

## Error Message
```
[trainer0]:W1214 22:04:22.827462  1145 ExceptionTracer.cpp:187] Invalid trace stack for exception of type: c10::Error
[trainer0]:terminate called after throwing an instance of 'c10::Error'
[trainer0]:  what():  CUDA error: an illegal memory access was encountered
[trainer0]:Exception raised from create_event_internal at caffe2/c10/cuda/CUDACachingAllocator.cpp:716 (most recent call first):
[trainer0]:
[trainer0]:# 2  c10::detail::torchCheckFail(char const*, char const*, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
[trainer0]:# 3  c10::cuda::CUDACachingAllocator::DeviceCachingAllocator::create_event_internal()
[trainer0]:# 4  c10::cuda::CUDACachingAllocator::THCCachingAllocator::free(void*)
[trainer0]:# 5  c10::TensorImpl::release_resources()
[trainer0]:# 6  THPVariable_clear(THPVariable*)
[trainer0]:# 7  THPVariable_dealloc(THPVariable*)
[trainer0]:# 8  subtype_dealloc
[trainer0]:# 9  dict_dealloc
[trainer0]:# 10 subtype_dealloc
[trainer0]:# 11 dict_dealloc
[trainer0]:# 12 subtype_dealloc
[trainer0]:# 13 dict_dealloc
[trainer0]:# 14 subtype_dealloc
[trainer0]:# 15 torch::autograd::PyNode::~PyNode()
```

## To Reproduce
Comment out the explicit `torch.cuda.synchronize()` and try some complex models using multiple GPUs.

Facebook:
1. Comment out the explicit `torch.cuda.synchronize()`;
2. Run `scripts/wayi/mast_prof_gradient_compression.sh POWER_SGD 8`
In step 2, may need to replace the value of `launcher.data_project` in the script with your own secure group.

## Environment
 - PyTorch Version (e.g., 1.0): 1.7
 - OS (e.g., Linux): CentOS Linux 7 (Core) (x86_64)
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Python version: 3.7
 - CUDA/cuDNN version: 9.2
 - GPU models and configuration:
 GPU 0: Tesla M40
 GPU 1: Tesla M40

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd
Repository: pytorch
Issue: Internal symbols are leaking from torch.nn.functional
Labels: triaged

## 🐛 Bug

Currently symbols which are imported by `torch/nn/functional.py` are accessible through the namespace. 

## To Reproduce

```
>>> import torch
>>> print(torch.nn.functional.has_torch_function)
<built-in function _has_torch_function>
```

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

```
# has_torch_function lives in overrides, and is not part of the public API
AttributeError: module 'torch.nn.functional' has no attribute has_torch_function
```

## Environment

N/A
Repository: pytorch
Issue: rank-0 gpu consume too high memory
Labels: oncall: distributed,triaged

Hi,

I am running distributed PyTorch on multi nodes with  8-GPUs per node.
Nvidia-smi shows that rank-0 GPU consumes extra 870*7 MiB memory
compared with other GPUs. See below.

Is there a way to reduce the extra memory size ? And they are for communication ?

    0   N/A  N/A   2695172      C   [xarexec] ./dlrm_hack2.par      26167MiB |
|    0   N/A  N/A   2695173      C   [xarexec] ./dlrm_hack2.par        871MiB |
|    0   N/A  N/A   2695174      C   [xarexec] ./dlrm_hack2.par        871MiB |
|    0   N/A  N/A   2695178      C   [xarexec] ./dlrm_hack2.par        871MiB |
|    0   N/A  N/A   2695181      C   [xarexec] ./dlrm_hack2.par        871MiB |
|    0   N/A  N/A   2695186      C   [xarexec] ./dlrm_hack2.par        871MiB |
|    0   N/A  N/A   2695189      C   [xarexec] ./dlrm_hack2.par        871MiB |
|    0   N/A  N/A   2695194      C   [xarexec] ./dlrm_hack2.par        871MiB |



cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu
Repository: rust
Issue: Confusing error message given for incorrectly-scoped invocation
Labels: C-enhancement,A-diagnostics,A-trait-system,A-associated-items,T-compiler,A-suggestion-diagnostics,D-confusing

This code, which is obviously bogus, unfortunately causes Rust to give an error message pertaining to associated types, even though it uses none:

````
struct A {}

impl A {
    pub fn new() -> Self {
        A {}
    }
}

struct B {}

fn main() {
    B::A::new(); // should be A::new()
}
````

Error:
````
error[E0223]: ambiguous associated type
  --> src/main.rs:13:5
   |
13 |     B::A::new();
   |     ^^^^^^^^^ help: use fully-qualified syntax: `<B as Trait>::A`
````

The error message is particularly confusing because it suggests specifying a trait, but there are no traits in the above code. Of course, the actual code I was debugging (as opposed to the minimal example above) DID use traits, so it took me a little while to figure out what was going on.
Repository: electron
Issue: Remove `--headless` command line argument from Electron
Labels: enhancement :sparkles:

From discussion with @jkleinsc (and indirectly @nornagon), it looks like if you want to run a headless Electron e.g. for CI testing, in Docker, etc. the approach is to use a virtual framebuffer e.g. xvfb and run it that way. That we allow the `--headless` argument seems to confuse users, as it implies that we support it.

xref https://github.com/electron/electron/issues/26974
Repository: godot
Issue: Using Make Floating while in single-window move can make docks unrecoverable until editor restart
Labels: bug,topic:editor,usability

**Godot version:** 4.0 Git https://github.com/godotengine/godot/commit/9c39b51c5306333ba210c0a323f4198a258b51bd

**OS/device including version:** Fedora 33, GeForce GTX 1080 (NVIDIA 455.45.01)

**Issue description:**

It's possible to make editor docks floating in single-window mode, which can lead to an unusable editor if the user moves the docks outside the editor window. Restoring the editor layout to **Default** won't recover the docks.

Possible fixes would be:

- Don't show **Make Floating** when single-window mode is used.
- Clamp dock positions to be confined within the window when single-window mode is used. This could be used to make specific docks display even when distraction-free mode is enabled.

**Steps to reproduce:**

- Click the three dots on the right of the left or right docks.
- Choose **Make Floating**.
- The dock may have appeared outside the editor window, making it impossible to drag back inside the window. If it did appear inside the window, then you can drag it out and release the mouse button. This will make it impossible to recover the dock until you restart the editor.

**Minimal reproduction project:** N/A
Repository: pytorch
Issue: Bug report: INTERNAL ASSERT FAILED
Labels: needs reproduction,triaged

## Issue description
Bug report: INTERNAL ASSERT FAILED

## Code example
Minimal example which triggers the INTERNAL ASSERT FAILED:
	n, m = 4, 6
	x = torch.rand(n, m, 3)
	y = torch.zeros(*x.shape, 3)
	y.as_strided(x.shape, [y.stride(0), y.shape[-1] + 1]).copy_(x)
Traceback:
	  File ".../bug_report.py", line 4, in minimal_example
		y.as_strided(x.shape, [y.stride(0), y.shape[-1] + 1]).copy_(x)
	RuntimeError: size.size() == stride.size() INTERNAL ASSERT FAILED at C:\w\1\s\tmp_conda_3.7_100118\conda\conda-bld\pytorch_1579082551706\work\aten\src\ATen/native/Resize.h:96, please report a bug to PyTorch.

## System Info
PyTorch version: 1.4.0
Is debug build: False
CUDA used to build PyTorch: 10.1
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 10 Enterprise
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect

Python version: 3.7 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: GeForce RTX 2060
Nvidia driver version: 441.14
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip] numpy==1.18.1
[pip] torch==1.4.0
[pip] torchvision==0.5.0
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               10.1.243             h74a9793_0    anaconda
[conda] mkl                       2020.0                      166    anaconda
[conda] mkl-service               2.3.0            py37hb782905_0
[conda] mkl_fft                   1.0.15           py37h14836fe_0
[conda] mkl_random                1.1.0            py37h675688f_0
[conda] numpy                     1.18.1           py37h93ca92e_0
[conda] numpy-base                1.18.1           py37hc3f5095_1
[conda] pytorch                   1.4.0           py3.7_cuda101_cudnn7_0    pytorch
[conda] torchvision               0.5.0                py37_cu101    pytorch
Repository: PowerToys
Issue: [Color Picker Editor] alternate feedback method for copy event
Labels: Idea-Enhancement,Area-User Interface,Product-Color Picker

When copying a color (in a specific format) it is good to have visual confirmation, but it would be nice if the "Copied to clipboard" message did not overlap with the list of formats. My ideas, in order:

1. Show a checkmark icon `E73E` in the copy button, for one second, **just like Snip & Sketch app**
2. Flash the control/icon (by either disabling or hiding it and then showing it)
3. Show the text inside the control (replacing the normal text) for a short time.

We can also use an `<Infobar>`.

Really a small thing though. No priority.
Repository: pytorch
Issue: Segfault in torch.bincount
Labels: module: crash,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce
~~~python
import torch
torch.bincount(input =torch.tensor([9223372036854775807]))
~~~

The code snippet gives 
~~~
Segmentation fault (core dumped)
~~~

## Expected behavior
expect no crash

## Environment

PyTorch version: 1.5.0
Is debug build: False
CUDA used to build PyTorch: 10.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.4 LTS (x86_64)
GCC version: Could not collect
Clang version: Could not collect
CMake version: version 3.14.0

Python version: 3.7 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A