sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: autocmds in an augroup nondeterministically execute repeatedly when defined from Lua
Labels: bug,api,lua

### Neovim Version

0.5.0

### Operating system/version:

macOS 11.4

### Terminal name/version:

iTerm 3.4.8

### TERM environment variable

xterm-256color

### Installation

homebrew

### Steps to reproduce

##  In `nvim -u NORC`:

###  Step 1: Define the following autogroup **using Lua**:

```
:lua vim.api.nvim_command("augroup testgroup\nautocmd BufEnter * :echo 'one'\nautocmd BufEnter * :echo 'two'\nautocmd BufEnter * :echo 'three'\naugroup end")
```

### Step 2: Repeatedly open files — observe the exploding output each time

```
:enew
:enew
:enew
:enew
:enew
```

##  In `nvim -u NONE`:

Same as above.

### Vim

Does not apply

### Expected behavior

After each call to `:enew`, Neovim should print

```
one
two
three
```

### Actual behavior

After the first call to `:enew`, Neovim prints:

```
one
```

After the second call to `:enew`, Neovim prints:

```
one
two
```

After the third call to `:enew`, Neovim prints:

```
one
two
two
three
```

After the fourth call to `:enew`, Neovim prints:

```
one
two
two
three
one
two
two
three
two
three
three
```

After the fifth call to `:enew`, Neovim prints:

```
one
two
two
three
two
three
three
two
three
three
three
two
three
three
three
```

And so on. The above is nondeterministic, so the output will be different each time.

**Notably, this behavior does not happen when the augroup is defined via vanilla VimL**
Repository: rust
Issue: x.py tidy forces `use path::{...}` to come after `use path::m::{...}`; makes commits noisy.
Labels: A-rustfmt

(This may be a rustfmt bug, rather than a rustc bootstrap issue. But I just wanted to file it somewhere before I forgot about it.)


Today, if you have:

```rust
use rustc_middle::middle::cstore::CrateDepKind;
use rustc_middle::middle::cstore::LinkagePreference::{self, RequireDynamic, RequireStatic};
```

and you want to import `rustc_middle::middle::cstore::CStore`, you could write 

```rust
use rustc_middle::middle::cstore::CrateDepKind;
use rustc_middle::middle::cstore::CStore; // <--- new line
use rustc_middle::middle::cstore::LinkagePreference::{self, RequireDynamic, RequireStatic};
```

But one might rightly think that's overly verbose; why not use a `{...}` block on the first `use`?

But if you try that, and write:

```rust
use rustc_middle::middle::cstore::{CrateDepKind, CStore}; // <--- changed line
use rustc_middle::middle::cstore::LinkagePreference::{self, RequireDynamic, RequireStatic};
```

then x.py tidy complains, and says it wants you to rewrite it as:

```rust
use rustc_middle::middle::cstore::LinkagePreference::{self, RequireDynamic, RequireStatic};
use rustc_middle::middle::cstore::{CrateDepKind, CStore}; // <--- changed and *moved* line
```

This seems wrong to me.

if I had to guess, I'd infer that the `rustfmt` algorithm is using a naive alphabetical ordering on the lines, rather than considering the higher level module tree structure. Looking at it from the view point of putting nodes closer to the tree's root first, everything for `use path::{...}` should come before `use path::m::{...}`, right?
Repository: go
Issue: gerrit: support "mergeable" queries
Labels: NeedsInvestigation

From https://gerrit-review.googlesource.com/Documentation/user-search.html, I can see:

> is:mergeable
>
> True if the change has no merge conflicts and could be merged into its destination branch.
>
> Mergeability of abandoned changes is not computed. This operator will not find any abandoned but mergeable changes.
>
> This operator only works if Gerrit indexes 'mergeable'. See indexMergeable for details.

If I try to use it on go-review.googlesource.com, I get an error:

> Error 400 (Bad Request): 'is:mergeable' operator is not supported by server

Could we enable this index? It would be very useful when filtering/searching CLs. For example, if I'm looking for CLs of mine which need updating due to merge conflicts, or when I'm looking through CLs for packages I maintain and which don't have merge conflicts - and could thus be tested and merged if they look good.
Repository: pytorch
Issue: Serialising `torch.bool` generates a warning about `np.bool` being deprecated. 
Labels: module: error checking,module: serialization,triaged,module: numpy

## 🐛 Bug

Serialising `torch.bool` generates a warning about `np.bool` being deprecated. 

## To Reproduce
Running
```
python -c "import torch; import pickle; pickle.dumps(torch.bool)"
```

should generate a 
```
<string>:1: DeprecationWarning: `np.bool` is a deprecated alias for the builtin `bool`. To silence this warning, use `bool` by itself. Doing this will not modify any behavior and is safe. If you specifically wanted the numpy scalar type, use `np.bool_` here.
Deprecated in NumPy 1.20; for more details and guidance: https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations
```
warning. 

## Expected behavior
There shouldn't be a warning.

## Environment

```
PyTorch version: 1.9.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 11.5.1 (x86_64)
GCC version: Could not collect
Clang version: 12.0.5 (clang-1205.0.22.9)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.6 | packaged by conda-forge | (default, Jul 11 2021, 03:36:15)  [Clang 11.1.0 ] (64-bit runtime)
Python platform: macOS-11.5.1-x86_64-i386-64bit
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

Versions of relevant libraries:
[pip3] numpy==1.21.1
[pip3] torch==1.9.0
[conda] numpy                     1.21.1                   pypi_0    pypi
[conda] torch                     1.9.0                    pypi_0    pypi
```
## Additional context
For anyone who comes across this before it gets fixed in Pytorch, you can silence the warning with 
```
with warnings.catch_warnings():
    warnings.filterwarnings('ignore', '.*`np.bool_`.*')
    pickle.dumps(torch.bool)
```

cc @mruberry @rgommers @heitorschueroff
Repository: pytorch
Issue: DistributedDataParallel documentation
Labels: oncall: distributed,triaged,better-engineering,module: ddp

Guys,
This probably isn't my business, but I want to point out that you are building up technical debt by not putting effort into internal documentation at the C++ level.  Class Reducer, for example, doesn't have good documentation either from the higher-level or the detailed level; and this isn't the kind of code where you can credibly claim that it's self-documenting.

By higher-level I mean a many-paragraph comment block describing what is the basic design approach: a description of the algorithm that's being implemented, with special cases and so on stripped out, to give a high-level understanding, then what are some details of the design that might not be obvious, what are the pitfalls, and so on, starting from the more important to the less important.

By detailed level I mean documentation of the individual functions: what does the function do, what are the individual arguments (their format and purpose, and preconditions they must satisfy), what does the function return, when is it called, and so on.  Only maybe 10% of this is done.  For example, in the comment for the constructor, only one of the 10 arguments is mentioned by name, and the name is wrong.

https://github.com/pytorch/pytorch/blob/38c185189c4e7b11f9bd9b60afed75b367ee00e2/torch/csrc/distributed/c10d/reducer.hpp#L109

I get it, move fast and break things, and PyTorch is great of course, but I feel like you'd get a lot of benefit from a little work here, and you'd even save time within your own team and be less f*cked if one of your key guys gets a deadly virus or something.

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd @cbalioglu @gcramer23
Repository: pytorch
Issue: [typing] new_ones has wrong signature
Labels: module: bootcamp,module: typing,triaged

## 🐛 Bug
`tensor.new_ones` accepts a size with each dim as an individual argument (similar to all other ctors we have). But the type stub doesn't think so 

![image](https://user-images.githubusercontent.com/5674597/129469616-4cbb9800-70e8-43e4-b791-2013bf1aabd1.png)



cc @ezyang @malfet @rgommers @xuzhao9 @gramster
Repository: rust
Issue: where bounds not properly inherited?
Labels: regression-from-stable-to-stable,C-bug,T-types

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
pub trait Kind where for<'a> &'a Self::Values: IntoIterator<Item=&'a Self> {
    type Values;
}
pub trait DataSource<T: Kind> {
    fn get_values(&self) -> &T::Values;
}

struct Foo;

impl Kind for Foo {
    type Values = Vec<Foo>;
}

struct Bar {
    foo: Vec<Foo>
}

impl DataSource<Foo> for Bar {
    fn get_values(&self) -> &Vec<Foo> {
        &self.foo
    }
}

fn main() {

}
```

I expected to see this happen: We thought it would just... work.

Instead, this happened: It causes this very confusing error:

```
   Compiling playground v0.0.1 (/playground)
error[E0277]: `&'a <T as Kind>::Values` is not an iterator
 --> src/main.rs:4:25
  |
1 | pub trait Kind where for<'a> &'a Self::Values: IntoIterator<Item=&'a Self> {
  |                                                --------------------------- required by this bound in `Kind`
...
4 | pub trait DataSource<T: Kind> {
  |                         ^^^^ `&'a <T as Kind>::Values` is not an iterator
  |
  = help: the trait `Iterator` is not implemented for `&'a <T as Kind>::Values`
  = note: required because of the requirements on the impl of `for<'a> IntoIterator` for `&'a <T as Kind>::Values`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground`

To learn more, run the command again with --verbose.
```

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3ec5006f8378c11861c1c24614814594

This legit feels like something that *should* be accepted, even if RFC 1214 says it shouldn't. It became a warning on rust 1.4.0 and a hard error on rust 1.7.0.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
<version>
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
<backtrace>
```

</p>
</details>
Repository: pytorch
Issue: Support `torch.linalg.outer`
Labels: feature,triaged,module: linear algebra,module: python array api

## 🚀 Feature
Support `torch.linalg.outer`.

cc @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @walterddr @IvanYashchuk @xwang233 @Lezcano @rgommers @pmeier @asmeurer @leofang @AnirudhDagar @asi1024 @emcastillo @kmaehashi

## Motivation & Pitch

Python Array API proposes the use of `linalg.outer` among other linear algebra functions. Currently, PyTorch supports the same functionality with `torch.outer`. `torch.ger` (to be deprecated in 1.10) is also an alias to `torch.outer` at the moment. 

We can either make `torch.linalg.outer` the main function with `torch.outer` and `torch.ger` as aliases to that. Or we can keep `torch.outer` as is and just alias `torch.linalg.outer` to that.

The only difference is that Array API doesn't define a keyword-only `out=` argument which should be fine since PyTorch's API will just be a superset of Array API here.

## Additional context

* [Python Array API linalg.outer](https://data-apis.org/array-api/latest/extensions/linear_algebra_functions.html#linalg-outer-x1-x2)
Repository: PowerToys
Issue: Allow for Naming Zones in Fancy Zones
Labels: Idea-Enhancement,FancyZones-Editor,Product-FancyZones,Cost-Medium

### Description of the new feature / enhancement

Allow for naming of Zones in addition to or in replace of numbers.

### Scenario when this would be used?

Organize zones by name. I have several layouts for zones and the main layout has 11 overlapping zones. When dragging windows to zones it's would be nice to have the zone named instead of just a number. For example, I have a zone, let's say it's zone 5, and I always snap Word files to this zone. It would be helpful to have this zone labeled "WORD" instead of "5" when dragging the window to that zone.

### Supporting information

_No response_
Repository: youtube-dl
Issue: [Request Support] Flixtor Download Support
Labels: request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2021.06.06. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar feature requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a feature request
- [x] I've verified that I'm running youtube-dl version **2021.06.06**
- [x] I've searched the bugtracker for similar feature requests including closed ones


## Description

<!--
Provide an explanation of your issue in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->

hello i want to ask for support for Flixtor
i have tryed to download but its not working i dont know if its possible to add support for it to download movies / series from there but still

`https://flixtor.video/`
Repository: rust
Issue: Semantically equal `Ordering` matches generate different assembly
Labels: I-slow,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

https://rust.godbolt.org/z/orxr8sffq

I tried this code:

```rust
use std::cmp::Ordering;

pub fn a(x: i32, y: i32) -> i32 {
    match x.cmp(&y) {
        Ordering::Greater => 3,
        Ordering::Equal => 2,
        Ordering::Less => 1,
    }
}

pub fn b(x: i32, y: i32) -> i32 {
    match x.cmp(&y) {
        Ordering::Greater => 3,
        Ordering::Equal => 2,
        _ => 1,
    }
}
```

I expected to see this happen: They both run at the exact same speed and both emit the exact same assembly.

Instead, this happened:
```
example::a:
        xor     ecx, ecx
        cmp     edi, esi
        sete    cl
        xor     ecx, 3
        cmp     edi, esi
        mov     eax, 1
        cmovge  eax, ecx
        ret

example::b:
        xor     eax, eax
        cmp     edi, esi
        setne   al
        mov     rcx, -1
        cmovge  rcx, rax
        xor     eax, eax
        cmp     rcx, 1
        sete    al
        lea     edx, [rax + rax]
        add     edx, 1
        test    rcx, rcx
        mov     eax, 2
        cmovne  eax, edx
        ret
```

It appears `b` has far more assembly generated for it which doesn't make sense because semantically `a` and `b` are the same.
`b` is probably slower. Either way, it shouldn't generate this much instructions.
I believe this doesn't just apply to `Ordering` but possibly to many more similar cases.

@rustbot label: +I-slow


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"hkratz"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: multicast_dns add support for advertising/broadcasting selected name
Labels: c: new feature,package,p: multicast_dns,team-ecosystem,P3,triaged-ecosystem

I would like to advertise/broadcast new mDns name of my choosing from my dart program.

The [example page of multicast_dns](https://pub.dev/packages/multicast_dns/example) and the [Readme](https://pub.dev/packages/multicast_dns) does not say anything about it.

My program runs on Linux and Windows.

Will multicast_dns add support for advertising/broadcasting a selected name?.
Repository: TypeScript
Issue: The right-hand side of an arithmetic operation must be of type 'any', 'number', 'bigint' or an enum type.ts(2363)
Labels: Suggestion,Experience Enhancement

# Suggestion

The following code errors:

```
      const x: Number = 5;
      const y = 5 - x;
```

With this:

>The right-hand side of an arithmetic operation must be of type 'any', 'number', 'bigint' or an enum type.ts(2363)

Which is super confusing because it is a number. But I didn't realize the problem was the first letter capitalization. `Number` vs `number`.

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

right-hand side of an arithmetic

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [v] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [v] This wouldn't change the runtime behavior of existing JavaScript code
* [v] This could be implemented without emitting different JS based on the types of the expressions
* [v] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [v] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->

Would be nice if there was an error during the assignment, is `Number` also a `number`? Another option is error 2363 could mention this potential issue. E.g.

>The right-hand side of an arithmetic operation must be of type 'any', 'number', 'bigint' or an enum type. Not 'Number' .ts(2363)

And replace 'Number' with whatever type was actually found.

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

```
      const x: Number = 5;
      const y = 5 - x;
```

Minor typos should have a clear error message.
Repository: rust
Issue: Recursive Closure Fixed-Point Support or Error Message
Labels: T-compiler,C-bug,-Zpolymorphize

I tried this code (reduced from something in real code):

```rust
fn bar<F: Fn()>(f: F) {
    bar(|| ());
}

fn main() {
    bar(|| ());
}
```

I expected this to work, but the compiler says: (note: line numbers are inaccurate)
```
error: reached the recursion limit while instantiating `bar::<[closure@src/main.rs:18:9: 18:14]>`
  --> src/main.rs:18:5
   |
18 |     bar(|| ());
   |     ^^^^^^^^^^
   |
note: `bar` defined here
  --> src/main.rs:17:1
   |
17 | fn bar<F: Fn()>(f: F) {
   | ^^^^^^^^^^^^^^^^^^^^^
```

After some reflection, I think I see the issue. When creating `bar::<main's closure>`, the complier "writes":

```rust 
struct MainClosure;

fn bar_MAIN_CLOSURE(f: MainClosure) {
    bar::<bar_MAIN_CLOSURE's closure>::(ClosureOfBarMainClosure);
}
```

Which then causes the compiler to instantiate this function, for which the closure is different again. So, it has to repeat this process, until it hits the recursion limit.

I'm wondering if it's possible to identify the "fixed point", and intervene with something like:

```rust
struct ClosureOfBarMainClosure;

fn bar_CLOSURE_OF_bar_MAIN_CLOSURE(f: ClosureOfBarMainClosure) {
    bar_CLOSURE_OF_bar_MAIN_CLOSURE(ClosureOfBarMainClosure);
}

struct MainClosure;

fn bar_MAIN_CLOSURE(f: MainClosure) {
    bar_CLOSURE_OF_bar_MAIN_CLOSURE(ClosureOfBarMainClosure);
}
```

Though I have no idea what would have to happen to get this to be implemented, so it might not be possible/pheasable/worth it. If not, I think it would make sense to have an error message with this, and a `rustc --explain` for it, as when I first encountered this I was quite confused.

In any case, the following (analogous to what I'm using now) replacement worked:

```rust
fn bar_fixed_point() -> impl Fn() {
    || ()
}

fn bar<F: Fn()>(f: F) {
    bar(bar_fixed_point());
}

fn main() {
    bar(|| ());
}
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.56.0-nightly (5a19ffe1c 2021-08-13)
binary: rustc
commit-hash: 5a19ffe1c2b99d9e09706cc286aad1ec0868eddb
commit-date: 2021-08-13
host: x86_64-unknown-linux-gnu
release: 1.56.0-nightly
LLVM version: 12.0.1
```
Repository: PowerToys
Issue: Separate shortcut for opening editor (when in color picker only mode).
Labels: Idea-Enhancement,Product-Color Picker

### Description of the new feature / enhancement

I would like to be able to optionally activate the editor with a shortcut after using the color picker. I use the "color picker only" mode as this is all I need 90% the time. However, sometimes I need to adjust the selected color. Rather than switching between modes, it would be nice to use "color picker only" mode, and simply use an additional shortcut to edit the selected color when needed.

### Scenario when this would be used?

When "color picker only" mode is the best mode for majority of use cases, but color adjustments are sometimes required.

The alternative solution is to always use "Color picker with editor mode enabled", but it is not ideal to have the editor open every time when it is only needed 10% of the time.

### Supporting information

_No response_
Repository: deno
Issue: WebIDL API class constructor's incorrectly construct superclasses
Labels: bug,web

Many ES builtins, and nearly all WebIDL APIs do not construct a class's parent class by looking up a dynamic prototype. The problem is... ECMAScript's `super` keyword does exactly that.

Reproduction code:
```js
Reflect.setPrototypeOf(AbortSignal, null);
console.log(AbortSignal.abort());
```
Tested in Firefox and Deno, Firefox's constructor is unaffected, whereas Deno's crashes because `super` no longer works.

(Furthermore, this can be used to steal the internal `illegalConstructorKey` symbol, by using a user-defined constructor, allowing code to go willy-nilly, constructing everything, e.g. `Window` 😉)