sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: testing: report GC/op when b.ReportAllocs is called
Labels: Proposal,Proposal-Accepted

Currently benchmarks defined in the testing package only show `ns/op` by default, while optionally reporting average allocation count and rate (`allocs/op`, `bytes/op`). Users may also export a custom metric, via `testing.(*B).ReportMetric`.

A common issue with benchmarks defined by the testing package, especially microbenchmarks, is that they might execute only a handful of GC cycles. If, due to internal or external noise, like scheduling, an extra GC cycle gets executed, it could cause a significant shift in the results (typically `ns/op`). As a result, it's more difficult to trust the results from such benchmarks; they need either more iterations to be useful, or a change in how they're defined (say, with a bigger GOGC value).

I propose exposing the ~_total number of GC cycles_~ _average number of GC cycles_ that passed during a given benchmark run to help expose such issues. One issue with making the total a benchmark metric is that it depends on the benchmark time, or the number of benchmark iterations, so this number is not comparable if those are different between runs. I think this is OK, because this metric is just supposed to flag an issue, not to be used in actual performance comparisons. Tooling such as `benchstat` could simply understand this, or we could export some benchmark unit metadata that makes this explicit.

I don't have strong feelings about the details, such as the metric name (maybe ~`total-GC-cycles`~ `GCs/op`?). While this metric potentially adds noise to benchmark output, I believe that cost is outweighed by the value of being able to identify this kind of noise early.

Alternatively, we could make it the job of the testing package to flag issues around such performance cliffs, but I suspect it's cleaner to just export the raw data and have it be interpreted by downstream tooling.

One might think that the testing package could just add iterations to adjust for these cliffs, but this is very difficult to do in the general case. It would involve a lot of heuristics that will generally be fragile and depend on the GC implementation. On the other hand, it's straightforward for tools to find issues after the fact, by identifying outliers and correlating those outliers with relatively large (by %) differences in GC cycle count.

~Note that the average number of GC cycles per op would not work, because in many scenarios where this matters, it wouldn't properly flag an issue (the average would just be zero, or very, very close to zero).~

EDIT: Switched to average number of GC cycles.

CC @aclements @prattmic @dr2chase
Repository: pytorch
Issue: Allow `torch.fx` tracing on TorchScript models
Labels: oncall: jit,module: fx

### 🚀 The feature, motivation and pitch

It would be really nice if we could use `torch.fx.symbolic_trace` on a TorchScript model. We use TorchScript extensively to save models since it's a hermetically sealed artifact that no longer requires a Python dependency. We'd like to be able to then `torch.fx.symbolic_trace` these TorchScript models so we can use the Graph FX quantization API on pre-trained models -- right now, if you try to trace a TorchScript model you get an error like:

```python
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Input In [47], in <module>
      1 original = nn.Linear(1, 1)
      2 scripted = torch.jit.script(original)
----> 3 torch.fx.symbolic_trace(scripted)

File /opt/conda/envs/ctrldev/lib/python3.8/site-packages/torch/fx/_symbolic_trace.py:907, in symbolic_trace(root, concrete_args, enable_cpatching)
    858 """
    859 Symbolic tracing API
    860 
   (...)
    904     GraphModule: a Module created from the recorded operations from ``root``.
    905 """
    906 tracer = Tracer(enable_cpatching=enable_cpatching)
--> 907 graph = tracer.trace(root, concrete_args)
    908 name = root.__class__.__name__ if isinstance(root, torch.nn.Module) else root.__name__
    909 return GraphModule(tracer.root, graph, name)

File /opt/conda/envs/ctrldev/lib/python3.8/site-packages/torch/fx/_symbolic_trace.py:559, in Tracer.trace(self, root, concrete_args)
    557 if isinstance(root, torch.nn.Module):
    558     self.root = root
--> 559     fn = type(root).forward
    560     self.submodule_paths = {mod: name for name, mod in root.named_modules()}
    561 else:

File /opt/conda/envs/ctrldev/lib/python3.8/site-packages/torch/jit/_script.py:298, in _CachedForward.__get__(self, obj, cls)
    297 def __get__(self, obj, cls):
--> 298     return self.__getattr__("forward")

AttributeError: '_CachedForward' object has no attribute '__getattr__'
```

This would be super convenient because it would decouple the code that produced the original pre-trained model and the code used for quantization.

### Alternatives

Ultimately, what we want is to be able to quantize a model without having access to the original code that generated the model (so no `pickle`, for instance). AFAICT, TorchScript is the best way to serialize a model without needing the original Python dependency, but if there's an alternative serialization format that plays nice with `torch.fx` then I think we'd be happy to use that instead (e.g. is there a way to serialize a `torch.fx.Graph` in such a hermetically sealed way?).

### Additional context

_No response_
Repository: pytorch
Issue: Ensure custom Function are correct in double backward setting
Labels: module: autograd,triaged,enhancement,actionable

### Problem statement
Today, if intermediary Tensors are saved during the forward and used during the backward, the double backward will be silently wrong because their contribution will be ignored.

A small repro is:
```python
import torch
from torch.autograd import Function, gradcheck, gradgradcheck


class MyFn(Function):
    @staticmethod
    def forward(ctx, inp):
        temp = inp * 2
        out = temp * 3
        ctx.temp = temp
        ctx.inp = inp
        return out

    @staticmethod
    def backward(ctx, gO):
        return gO * torch.full_like(gO, 3) * ctx.temp / ctx.inp


inp = torch.rand(10, dtype=torch.float64, requires_grad=True)

gradcheck(MyFn.apply, inp)
gradgradcheck(MyFn.apply, inp)
```

### Proposed solution
Note that I am not sure this is the best way to go about this, we might want to do something else in practice?

Option 1) Add a `ErrorNode` as the grad_fn for everything that gets saved on the ctx and via save_for_backward if it does not already have a grad_fn.
Since the backward runs in no grad_mode when you're not doing double backward, it will just be ignored for most users. But in the double backward case, it will be attached to the created graph. And so if the user tries to backward through that particular Tensor, we can provide a nice error message.
If this is a false positive for some users (they want to ignore that intermediary from the double backward computation), then they can just "detach()" it to recover the previous behavior.

Option 2) Add these error nodes on the fly during the backward function only if grad_mode is enabled. This avoid mutating the object when the user does `ctx.foo = foo` which is better? And only the accessed one is changed? Unfortunately, we cannot do this out of place as some users rely on the fact that `ctx.foo is foo`.

Option 3) ??



cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: angular
Issue: Reactive Forms require both [name] and [attr.name] for radio buttons to work correctly with [formControl]
Labels: area: forms,P3,bug

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

No

### Description

I have three minimal example variations of two sets of radio buttons on one page, with each set having its own `[formControl]` provided. In this scenario both sets of radios have the same values.

_Unideal Working Example:_

https://stackblitz.com/edit/angular-ivy-qf7yke?file=src%2Fapp%2Fapp.component.html
In this example it works as intended, but both `[name]` and `[attr.name]` are required.

_Failing Example 1:_

https://stackblitz.com/edit/angular-ivy-f16c7a?file=src%2Fapp%2Fapp.component.html
If only `[attr.name]` is provided, both radio buttons end up mirroring each other's control. The underlying form model is correct, but the "template model" is displayed incorrectly due to this mirroring.

_Failing Example 2:_

https://stackblitz.com/edit/angular-ivy-oyycqj?file=src%2Fapp%2Fapp.component.html
If only `[name]` is provided, it seems to work as intended, but because no attribute is attached to the HTML, the browser can't group the radio buttons, and keyboard controls work incorrectly. Tabbing only goes to the first group, skipping the second group, and arrow keys scroll through all the radio buttons on the page instead of being restricted to the correct group.

### Please provide a link to a minimal reproduction of the bug

_No response_

### Please provide the exception or error you saw

_No response_

### Please provide the environment you discovered this bug in (run `ng version`)

```true
@angular/animations
12.2.5
@angular/common
12.2.5
@angular/compiler
12.2.5
@angular/core
12.2.5
@angular/forms
12.2.5
@angular/platform-browser
12.2.5
@angular/platform-browser-dynamic
12.2.5
@angular/router
12.2.5
rxjs
7.3.0
tslib
2.3.1
zone.js
0.11.4
```


### Anything else?

It seems like the easy solution here would be that `[name]` should be inserting an attribute into the HTML similar to `[id]`.

`formControlName` appears to avoid these issues for some reason, but I can't use `formControlName` in my real-life scenario - I need to be able to pass the `formControl` itself through component layers.
Repository: electron
Issue: [Feature Request]: Detect crashes due to GPU issues
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

GPU acceleration shouldn't be disabled by default, though sometimes renderer processes can crash because of GPU issues in some computers, in which case IMO the app should restart itself with GPU acceleration disabled. Though it doesn't seem possible to detect when such crash occurs.

### Proposed Solution

There's already an "render-process-gone" event, it'd be awesome to have a "gpu-failure" reason or something like that.

### Alternatives Considered

Exposing a setting for disabling GPU acceleration, which I already implemented, though it would be much nicer if the app could restart itself with GPU acceleration disabled, like people don't even know what the GPU is, chances are some users would just switch app rather than successfully fix this via a setting.

### Additional Information

_No response_
Repository: pytorch
Issue: fx: cannot find module <built-in method matmul> when using apex.amp
Labels: triaged,module: fx

### 🐛 Describe the bug

I camp up with the following issue when using `torch.fx` and [apex.amp](https://nvidia.github.io/apex/amp.html) together.
If a model has `torch.matul` operations and uses `apex.amp (opt_level=O1)` for mixed precision optimization, then fx will fail to recompile the model graph and will report the following error:
```text
File "/xxxxxxxxxxxxx/dist-packages/torch/fx/node.py", line 40, in _find_module_of_method
    raise RuntimeError(f'cannot find module for {orig_method}, {name}')
RuntimeError: cannot find module for <built-in method matmul of type object at 0x7f6c5fd9fe40>
```

A simple toy module with `torch.matmul` can reproduce the error.
```python
import torch
from torch import fx

class ToyMod(torch.nn.Module):
    def __init__(self, in_features=768, out_features=768):
        super().__init__()
        self.linear = torch.nn.Linear(in_features=in_features, out_features=out_features)

    def forward(self, X, other):
        result = torch.matmul(self.linear(input=X), other)
        return result

def test():
    from apex import amp
    mod = ToyMod().cuda()
    optimizer = torch.optim.SGD(mod.parameters(), lr=1e-3)

    # Allow Amp to perform casts as required by the opt_level
    model, optimizer = amp.initialize(mod, optimizer, opt_level="O1")
    graph : fx.Graph = fx.Tracer().trace(model)
    for node in graph.nodes:
        # do something
        pass
    graph.lint()
    return fx.GraphModule(model, graph)
```

By checking [fx/node.py](https://github.com/pytorch/pytorch/blob/v1.10.0/torch/fx/node.py), it seems `torch.matmul` is missing in `torch`. I added `print(torch.matmul)` at https://github.com/pytorch/pytorch/blob/v1.10.0/torch/fx/node.py#L37, and got 
```text
torch.matmul: <function _VariableFunctionsClass.matmul at 0x7f377820cb70>
```
The object address of matmul in `torch` has been changed. 

Any suggestions about this issue are appreciated.


### Versions

PyTorch version: 1.10.0
CUDA used to build PyTorch: 11.3

OS: Debian GNU/Linux 10 (buster) (x86_64)
GCC version: (Debian 8.3.0-6) 8.3.0

Python version: 3.7.3
Is CUDA available: True
CUDA runtime version: 11.3.109

[pip3] numpy==1.21.5
[pip3] torch==1.10.0
[pip3] torchaudio==0.10.0+cu113
[pip3] torchvision==0.11.1+cu113

apex: Version 0.1



cc @ezyang @SherlockNoMad
Repository: neovim
Issue: Autocommand event for mapping creation/deletion
Labels: enhancement,needs:vim-patch,mappings,events

### Feature already in Vim?

No

### Feature description

It would be useful for some plugin authors to have the ability to register callbacks which fire when mappings are created and deleted (including buffer-local mappings).
Repository: kubernetes
Issue: prevent the "Expect(err).NotTo(HaveOccurred())" and "ExpectNoError(err)" anti-pattern in e2e tests
Labels: kind/feature,sig/testing,lifecycle/frozen,area/e2e-test-framework,needs-triage

### What would you like to be added?

This was previously tracked in https://github.com/kubernetes/kubernetes/issues/34059 (created in 2016, closed in 2020 after several tests were enhanced).

I'm starting to wonder whether the problem is getting worse again because we still don't catch new tests that use this anti-pattern (for example, https://github.com/kubernetes/kubernetes/pull/107763).

Is it time to start another spring clean which removes occurrences of this anti-pattern? Or perhaps add some mechanism that prevents it in new code?

/sig testing
/area e2e-test-framework

### Why is this needed?

I'm getting tired of seeing failures where the only output is
```
Expected error:
    <*errors.errorString | 0xc820412c10>: {
        s: "timed out waiting for the condition",
    }
    timed out waiting for the condition
not to have occurred
```

This is the result of
```
Expect(err).NotTo(HaveOccurred())
```

or more recently
```
ExpectNoError(err)
```

An explanation string would help, but even better solutions would be possible (https://github.com/kubernetes/kubernetes/issues/106575).
Repository: flutter
Issue: Change the Desktop window template to initially place the window in the usable screen area.
Labels: tool,platform-windows,a: desktop,P2,team-windows,triaged-windows

Sorry, I'm not an expert in flutter and desktop applications, but I was just wondering if it's possible to change the hardcoded start position of the window in the interim while validating the full implementation of this feature into the framework. I know that the issue is being worked on (https://github.com/flutter/flutter/issues/30736); however, all sources I've looked at state that the integration has an indefinite time frame. 

Right now, if I have my taskbar at the top of the screen in Windows, the window is set to open underneath the bar and the title bar is inaccessible by the typical means (mouse interaction). I was wondering if it would be difficult to have the default position center the window instead to ensure that important title bar features are not inaccessible under that taskbar. It could also just be offset to maybe 20% down from the top.

If this is asking too much, I apologize. I understand that maybe people wouldn't want this behavior and know that I probably am gravely misunderstanding the problem. So, thank you for reading this, if this has already been considered.

I have discovered the ability to change `main.cpp` in the Windows runner, but I wasn't sure if this is the intended place to put such a change from my naive understanding of what is generated and expected to change as part of the framework or is allowed to be edited by the end developer.

For anyone else that is a novice like me with this issue; this is what I changed in the runner as a workaround. Obviously, it could probably be more elegant, but I am still learning, so it is passable enough for me at the moment: 

from
`Win32Window::Point origin(10, 10);` 
to
`Win32Window::Point origin(100, 100);`

_Originally posted by @whitemagehealing in https://github.com/flutter/flutter/issues/30736#issuecomment-1105636064_
Repository: rust
Issue: Wrong trait in "use the fully qualified path for the potential candidates" suggestion
Labels: A-diagnostics,T-compiler,A-suggestion-diagnostics,D-papercut

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ee16c31890addb9bd9e64b3d393a2de3

```rust
struct A<T>(T);
struct B;

trait I<T> {}
impl I<i32> for B {}
impl I<u32> for B {}

trait V<U> {
    fn method(self) -> U;
}

impl<T, U> V<U> for A<T>
where
    T: I<U>,
{
    fn method(self) -> U { unimplemented!() }
}

fn main() {
    let a = A(B);
    a.method();
}
```

The current output is:

```console
error[E0283]: type annotations needed
  --> src/main.rs:21:7
   |
21 |     a.method();
   |     --^^^^^^--
   |     | |
   |     | cannot infer type for type parameter `U`
   |     this method call resolves to `U`
   |
note: multiple `impl`s satisfying `B: I<_>` found
  --> src/main.rs:5:1
   |
5  | impl I<i32> for B {}
   | ^^^^^^^^^^^^^^^^^
6  | impl I<u32> for B {}
   | ^^^^^^^^^^^^^^^^^
note: required because of the requirements on the impl of `V<_>` for `A<B>`
  --> src/main.rs:12:12
   |
12 | impl<T, U> V<U> for A<T>
   |            ^^^^     ^^^^
help: use the fully qualified path for the potential candidates
   |
21 |     <B as I<i32>>::method(a);
   |     ~~~~~~~~~~~~~~~~~~~~~~~~
21 |     <B as I<u32>>::method(a);
   |     ~~~~~~~~~~~~~~~~~~~~~~~~
```

The two suggestions `<B as I<i32>>::method(a)` and `<B as I<u32>>::method(a)` are nonsensical because `a` is not of type `B` and the trait `I<T>` does not have a method called `method`. This is not how the ambiguous type would need to be disambiguated.

```console
error[E0576]: cannot find method or associated constant `method` in trait `I`
  --> src/main.rs:21:20
   |
21 |     <B as I<i32>>::method(a);
   |                    ^^^^^^ not found in `I`
```

Instead a correct suggestion would look like one of the following:

- `<A<B> as V<i32>>::method(a)`
- `<A<_> as V<i32>>::method(a)`
- `<_ as V<i32>>::method(a)`
- `<V<i32>>::method(a)`
- `V::<i32>::method(a)`

Exactly which one of the above 5 correct possibilities is chosen is related to #96292, but this issue focuses on the fact that the current suggestion's **trait** is wrong (`I` vs `V`).
Repository: pytorch
Issue: [Feature request] Exclusive prefix sum, `torch.cumsum(input, dim=0, exclusive=True)`
Labels: high priority,module: cuda,triaged,enhancement,module: nestedtensor,module: reductions

### 🚀 The feature, motivation and pitch

Currently `torch.cumsum` only supports inclusive prefix sum. However, the exclusive prefix sum is also needed in some cases.

Proposed to add a `exclusive` parameter to the `torch.cumsum` function
```py
input = torch.tensor([1, 1, 1])
torch.cumsum(input, dim=0, exclusive=True)   # [1, 2, 3]
torch.cumsum(input, dim=0, exclusive=False)  # [0, 1, 2]
```

Related issue from PyTorch Forums:
- [PyTorch equivalent of exclusive cumsum? - PyTorch Forums](https://discuss.pytorch.org/t/pytorch-equivalent-of-exclusive-cumsum/107259)

CUDA implementation from CUB:
- [CUB: cub::DeviceScan Struct Reference](https://nvlabs.github.io/cub/structcub_1_1_device_scan.html#a02b2d2e98f89f80813460f6a6ea1692b)

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @gchanan @zou3519 @kadeng @msaroufim @ptrblck @cpuhrsch @jbschlosser @bhosmer @drisspg @soulitzer @ngimel
Repository: electron
Issue: [Bug]: Presentation API doesn't find any presentation displays
Labels: bug :beetle:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

v18.1.0

### What operating system are you using?

Windows

### Operating System Version

Windows 10 21H2

### What arch are you using?

x64

### Last Known Working Electron version

-

### Expected Behavior

Presentation API should find presentation displays, if the user is using multiple monitors, their other screen should be one of those displays.


### Actual Behavior

Presentation API doesn't find any valid presentation displays:
![image](https://user-images.githubusercontent.com/6506529/164550610-04463bc6-42e5-43d4-9de4-6903fbea6180.png)


### Testcase Gist URL

https://gist.github.com/ThaUnknown/b749beed37325615b9a697fa139dd299

### Additional Information

This is an electron-related issue, not chromium.
Compiling a custom build of chromium retains the functionality of the presentation API [as shown in the screenshot above].
Build electron with the same custom build of chromium breaks this functionality. Is this because of chrome-sandbox?
Repository: pytorch
Issue: Update NCCL to 2.12
Labels: oncall: distributed,module: build,triaged

### 🐛 Describe the bug

The current PyTorch links NCCL v2.10.3-1 by default, which includes a critical bug that breaks the `CollNet` algorithm in distributed training: https://github.com/NVIDIA/nccl/issues/556. This bug has been fixed since v2.12.7-1: https://github.com/NVIDIA/nccl/commit/4ec992fab7d90691ad43bee6f7f6c34aa219934c.

Is there any timeline to update the NCCL version that PyTorch links to? If not I'd be happy to submit a PR.

### Versions

N/A

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @malfet @seemethere
Repository: vscode
Issue: Prevent the blue warning strip at the top that keeps popping up
Labels: feature-request,unicode-highlight

<!-- ⚠️⚠️ 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. -->

Steps to Reproduce:

1. Append `"editor.unicodeHighlight.nonBasicASCII": true,` to the settings json.
1. Open a document w/ many non-ascii chars

![image](https://user-images.githubusercontent.com/5728319/164579544-594bb146-1594-4435-afbf-928cd75ca6f9.png)

I realize non-ascii chars are highlighted and no I don't want to disable it - after all I was the one who enabled that option.
Why does it feel the need to keep reminding me of that?
Accomplishes nothing but look out of place and take up screen space.
Maybe in addition to the "Disable highlights" button there should be a "Don't show again" one.