sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Conda install from pytorch-nightly channel does not install the expected version on macOS
Labels: module: binaries,triaged,module: macos

### 🐛 Describe the bug

A similar error occurred before https://github.com/pytorch/pytorch/issues/33103
Another related issue about pytorch nightly on macOS https://github.com/pytorch/pytorch/issues/78681

* Platform: macOS 12.4, Apple M1 Max
* Conde version 4.13
* Conda config: channel_priority: disabled

1. When installing pytorch only the expected nightly build version (1.13) is installed 

```
conda install -c pytorch-nightly pytorch
```

2. When installing pytorch together with torchvision, ```conda-forge``` channel is used and the stable versions are installed, which do not have Apple M chip support

```
conda install -c pytorch-nightly pytorch torchvision
```

3. When installing pytorch first then torchvision, pytorch version is forced to fall back to 1.11

```
The following packages will be SUPERSEDED by a higher-priority channel:

  pytorch            pytorch-nightly::pytorch-1.13.0.dev20~ --> conda-forge::pytorch-1.11.0-cpu_py39h03f923b_1
```

### Versions

```
Collecting environment information...
PyTorch version: 1.13.0.dev20220610
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.4 (arm64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.5)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.13 | packaged by conda-forge | (main, May 27 2022, 17:00:33)  [Clang 13.0.1 ] (64-bit runtime)
Python platform: macOS-12.4-arm64-arm-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
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.4
[pip3] torch==1.13.0.dev20220610
[conda] numpy                     1.22.4           py39h7df2422_0    conda-forge
[conda] pytorch                   1.13.0.dev20220610         py3.9_0    pytorch-nightly
```

cc @ezyang @seemethere @malfet @albanD
Repository: godot
Issue: Error spam when setting invalid child in `ShapeCast2D`
Labels: bug,topic:2d

### Godot version

4.0 alpha 9

### System information

Ubuntu 22.04

### Issue description

When running simple scene with ShapeCast2D which is parent of CanvasGroup I see error spam 
```
ERROR: Invalid shape.
   at: _update_shapecast_state (scene/2d/shape_cast_2d.cpp:271)
```
in almost each frame.
I think that this message should be printed only once at start, to not pollute output

[ABCD2105835423.tscn.zip](https://github.com/godotengine/godot/files/8883388/ABCD2105835423.tscn.zip)
Repository: rust
Issue: weird "private trait" errors around ptr::metadata for public struct wrapping private trait object
Labels: A-diagnostics,A-trait-system,A-visibility,T-compiler,C-bug,requires-nightly,D-confusing,D-terse,T-libs,D-imprecise-spans

<!--
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: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=bf288d74a24e2a8d9f6c22d96d7e2f39

```rust
#![feature(ptr_metadata)]

mod foo {
    trait P<'a> {}
    pub struct S<'a>(dyn P<'a>);
}

fn f<'a>(a: &mut foo::S<'a>) {
    let mut b = None;
    b = Some(std::ptr::metadata(a));
}
```

I expected to see this happen: it'd just compile

Instead, this happened: 

```
error: trait `P` is private
 --> src/lib.rs:9:17
  |
9 |     let mut b = None;
  |                 ^^^^ private trait

error: trait `P` is private
  --> src/lib.rs:10:9
   |
10 |     b = Some(std::ptr::metadata(a));
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ private trait
```

I guess it doesn't like inferring `DynMetadata<dyn P<'a>>` since `P` is private, but I don't understand why that happens since I'm not naming `P` there, and even if I was, the error highlighting `None` is super confusing.

Not sure how to reduce it to not touch `ptr::metadata` since I'm not sure I understand how the metadata types work.

### 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.63.0-nightly (ec55c6130 2022-06-10)
binary: rustc
commit-hash: ec55c61305eaf385fc1b93ac9a78284b4d887fe5
commit-date: 2022-06-10
host: x86_64-unknown-linux-gnu
release: 1.63.0-nightly
LLVM version: 14.0.5
```
Repository: rust
Issue: Silence `trait objects must include the dyn keyword` error when a trait and a self type are misplaced
Labels: A-diagnostics,T-compiler,D-verbose,A-trait-objects

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
fn main() {}

struct Struct<T>;

trait Trait<'a, T> {}

impl<'a, T> Struct<T> for Trait<'a, T> {}
```

The current output is:

```
error[E0404]: expected trait, found struct `Struct`
 --> src/main.rs:7:13
  |
7 | impl<'a, T> Struct<T> for Trait<'a, T> {}
  |             ^^^^^^^^^ not a trait
  |
help: `impl` items mention the trait being implemented first and the type it is being implemented for second
  |
7 | impl<'a, T> Trait<'a, T> for Struct<T> {}
  |             ~~~~~~~~~~~~     ~~~~~~~~~

warning: trait objects without an explicit `dyn` are deprecated
 --> src/main.rs:7:27
  |
7 | impl<'a, T> Struct<T> for Trait<'a, T> {}
  |                           ^^^^^^^^^^^^
  |
  = note: `#[warn(bare_trait_objects)]` on by default
  = warning: this is accepted in the current edition (Rust 2018) but is a hard error in Rust 2021!
  = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2021/warnings-promoted-to-error.html>
help: use `dyn`
  |
7 - impl<'a, T> Struct<T> for Trait<'a, T> {}
7 + impl<'a, T> Struct<T> for dyn Trait<'a, T> {}
  |
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```diff
error[E0404]: expected trait, found struct `Struct`
  --> $DIR/suggest-swapping-self-ty-and-trait-edition-2021.rs:12:13
   |
LL | impl<'a, T> Struct<T> for Trait<'a, T> {}
   |             ^^^^^^^^^ not a trait
   |
help: `impl` items mention the trait being implemented first and the type it is being implemented for second
   |
LL | impl<'a, T> Trait<'a, T> for Struct<T> {}
   |             ~~~~~~~~~~~~     ~~~~~~~~~

- error[E0782]: trait objects must include the `dyn` keyword
-   --> $DIR/suggest-swapping-self-ty-and-trait-edition-2021.rs:12:27
-    |
- LL | impl<'a, T> Struct<T> for Trait<'a, T> {}
-    |                           ^^^^^^^^^^^^
-    |
- help: add `dyn` keyword before this trait
-    |
- LL - impl<'a, T> Struct<T> for Trait<'a, T> {}
- LL + impl<'a, T> Struct<T> for dyn Trait<'a, T> {}
-    | 
```

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->
Repository: godot
Issue: Deleting / detaching / moving large numbers of child nodes can be excessively slow
Labels: enhancement,topic:core,performance

### Godot version

3.5 current (3.5 RC 3), earlier versions presumably

### System information

N/A

### Issue description

While benchmarking something else, I noticed that the time taken to `queue_delete()` a large number of `MeshInstance` children seemed to grow exponentially with the number of siblings of the parent. This is unlikely to come up that often outside of benchmarks / extreme cases, but is still a concern.

On discussion with @akien-mga there were two suspect areas, the ordered remove and possibly notifications sent as a result of the moving of the children. Testing revealed that the slowdown didn't occur when removing children in back to front order, which confirmed the suspicions.

A very similar problem can also occur when detaching / attaching / moving nodes.

I've also profiled the slow situation:
![queue_delete_profile](https://user-images.githubusercontent.com/21999379/173183548-6d0f8f40-19f7-4418-94f8-e64fcd568820.png)


### Steps to reproduce

* Add a large number of children to a node (5000+)
* Call `queue_delete()` in the order of `get_child()`


### Minimal reproduction project
[QueueDeleteSlow.zip](https://github.com/godotengine/godot/files/8883695/QueueDeleteSlow.zip)
* Run the MRP, takes ~5 seconds to add 10,000 boxes and queue delete.
* Comment out the `queue_free()` line 14, takes 250ms.

If you queue free in reverse order:
```
	var num_children = $Boxes.get_child_count()
	for n in range (num_children):
		$Boxes.get_child(num_children - 1 - n).queue_free()
```
It takes 730ms - still curiously slower than adding, but a lot faster than before.

**Update**
Make the box invisible to eliminate the BVH from the bottlenecks, this shows the real difference from the PR linked.

### Discussion
It is possible we can modify the deletion code to prevent this situation occurring, perhaps by guaranteeing reverse ordering:
* sorting the deletion list
* searching in reverse order through children for `queued_for_deletion` flags when deleting nodes

Additionally, if there is a notification on re-ordering, perhaps it can be sent once (after all deletes) instead of after each deletion.
Repository: ant-design
Issue: Internationalization throws hydration error in Next.js
Labels: 🐛 Bug,help wanted,Inactive

### Reproduction link

[https://github.com/bwmirek/antd-nextjs-locale-bug](https://github.com/bwmirek/antd-nextjs-locale-bug)

### Steps to reproduce

#### Reproduction repo:
1. Install deps
```shell
yarn install
```
2. Run app
```shell
yarn dev
```

3. Open app in browser

#### New project
1. Create Next.js App
```shell
yarn create next-app --typescript
```

2. Install antd
```shell
yarn add antd
```

4. Add i18n component to the page:
```typescript
// file: pages/index.tsx
import type { NextPage } from 'next';
import { ConfigProvider, Calendar } from 'antd';

import plPL from 'antd/lib/locale/pl_PL';

import 'antd/dist/antd.css';

const Home: NextPage = () => {
  return (
    <ConfigProvider locale={plPL}>
      <Calendar/>
    </ConfigProvider>
  );
};

export default Home;
```

5. Run app
```shell
yarn dev
```

6. Open app in browser

### What is expected?

Component should be rendered the same way both on the server and the client.

### What is actually happening?

Component is rendered differently on the server than the client, causing hydration error: "Hydration failed because the initial UI does not match what was rendered on the server".

| Environment | Info |
| --- | --- |
| antd | 4.21.0 |
| React | 18.1.0 |
| System | Windows 10 |
| Browser | Google Chrome 102.0.5005.63 |

---
Next.js version: 12.1.6, may be related to SSR.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: go
Issue: doc: go_mem.html is unclear about io as synchronisation mechanism
Labels: Documentation,NeedsInvestigation

https://tip.golang.org/ref/mem does not speak about os operations.

Is a `syscall` a synchronization primitive if the underlying os says the corresponding syscall is ?

In other words:
```go
var shared int

func read(print, close *os.File) {
  print.Read() // wait EOF
  fmt.Println(shared)
  close.Close() // send EOF
} 

func main() {
  printr, printw, err := os.Pipe()
  c(err)
  closer, closew, err := os.Pipe()
  c(err)

  go read(printr, closew)
  shared = 42
  printw.Close() // send EOF
  closer.Read() // wait EOF
}
```
Legal code ? (*assuming posix*)
Please ignore the fact that this code is completely unrealistic, this could realistically come up in edge cases of real code.
Repository: pytorch
Issue: PyTorch get positive log_prob of a multivariate normal distribution 
Labels: triaged

### 🐛 Describe the bug

PyTorch get positive log_prob of a multivariate normal distribution 

version is 1.11.0
here is the code:
```
import torch
m = torch.Tensor([0.3512,  1.3149, -0.8541,  0.5619]).to(torch.double)
cov = torch.Tensor([[0.2304, 0.0000, 0.0000, 0.0000],
                    [0.0000, 0.1919, 0.0000, 0.0000],
                    [0.0000, 0.0000, 0.0785, 0.0000],
                    [0.0000, 0.0000, 0.0000, 0.1838]]).to(torch.double)

a = torch.Tensor([0.3278,  1.3005, -0.8631,  0.5571]).to(torch.double)
print(torch.distributions.MultivariateNormal(m, cov).log_prob(a))
```
And I get result 0.0006

### Versions

version is 1.11.0
here is the code:
```
import torch
m = torch.Tensor([0.3512,  1.3149, -0.8541,  0.5619]).to(torch.double)
cov = torch.Tensor([[0.2304, 0.0000, 0.0000, 0.0000],
                    [0.0000, 0.1919, 0.0000, 0.0000],
                    [0.0000, 0.0000, 0.0785, 0.0000],
                    [0.0000, 0.0000, 0.0000, 0.1838]]).to(torch.double)

a = torch.Tensor([0.3278,  1.3005, -0.8631,  0.5571]).to(torch.double)
print(torch.distributions.MultivariateNormal(m, cov).log_prob(a))
```
And I get result 0.0006
Repository: PowerToys
Issue: FancyZones Quick Layout Switch
Labels: Idea-Enhancement,Product-FancyZones

### Microsoft PowerToys version

0.59.0

### Running as admin

- [X] Yes

### Area(s) with issue?

FancyZones, FancyZones Editor

### Steps to reproduce

FancyZones
Running PowerToys v0.59.0 on a dual monitor setup.

FancyZones Settings:
- Enabled: On
- Launch editor on the display: With active focus
- Enable quick layout switch: On
- Layouts configured in editor: True
- Layout-shortcuts: Designated in editor

**Case:** 
> Working on a document with mouse on one monitor - active focus on monitor where cursor is positioned.
> alt-tab to window on a different monitor and input something (but leave cursor on original screen) - active focus on different monitor.
> Change FancyZones layout using layout-shortcut.
-> Bug occurs.



### ✔️ Expected Behavior

Expected _focused monitor_ to switch FancyZones layout honoring appropriate layout-shortcut

### ❌ Actual Behavior

Monitor _where mouse pointer is_ switches it's FancyZones layout honoring appropriate layout-shortcut.

### Other Software

_No response_
Repository: terminal
Issue: Command-line to toggle visibility
Labels: Product-Terminal,Issue-Task,Area-Commandline,Area-Remoting

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement

<!-- 
-->
I'm proposing a command-line option to toggle the visibility of the terminal window. It should do exactly that: if I run (for instance) "wt --toggle" it should create a new window with default profile and show it (if no window exists) or show the current window (if one already exists). If the window is currently being displayed, running "wt --toggle" should hide the window and focus the previously selected application. This can be complemented with an option to make it that if "wt --toggle" creates the window, then it won't make it visible (useful on startup of terminal). A second run of "wt --toggle" will make the window visible.

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
Not sure about how to do this. Maybe a switch that will run the same "toggle visibility" internal command of terminal, or something? however that does not seem to be exactly what I described above.
Repository: pytorch
Issue: [bazel] ability to run gpu tests on gpu machines in RBE
Labels: triaged,module: bazel

### 🚀 The feature, motivation and pitch

As a user who builds pytorch using bazel and Remote Build Execution, I need a way to tell the remote build to use GPU machines for tests that require GPU. In order to achieve this, it's beneficial to consolidate all tests usage through the common macros definition.

### Alternatives

Build and test everything on GPU machines. Very expensive.

### Additional context

This is quality of life improvement for bazel builds.
Repository: pytorch
Issue: Adam not optimally implemented: unnecessary torch.div
Labels: module: performance,module: optimizer,triaged,actionable

### 🚀 The feature, motivation and pitch

Adam is implemented in https://github.com/pytorch/pytorch/blob/master/torch/optim/adam.py#L259 using the following effective formula (terminology from the [paper](https://arxiv.org/abs/1412.6980) and the code with light abbreviations): 
```
theta = lr / bias1 * m / (sqrt(v) / bias2 + eps)
```
This formulation requires an additional division of the full-sized tensor `sqrt(v)` by `bias2`. Presumably it was done this way to have `eps` not be implicitly affected by `bias2`. However, we can still achieve this without the costly `sqrt(v)/bias2` op - multiply & divide `eps` by `bias2` and then factor out `1/bias2` in the denominator and you get: 
```
theta = lr * bias2 / bias1 * m / (sqrt(v) + bias2 * eps)
```
which should be incrementally faster to compute. 

Note: the current formulation permeates the Adam and Adam-esque implementations, so any update should presumably be propagated across them. 




### Alternatives

N/a

### Additional context

I've confirmed that the current formulation does indeed induce an extra `div` op in the Adam step: 

![image](https://user-images.githubusercontent.com/90846/173192526-34c07c06-e6f9-4d49-8d56-2dc92bdc5466.png)

This was done on pytorch v1.10, and the code has been reorganized since so the precise file & line reference is no longer accurate, but the relevant piece of code hasn't actually changed, it's still there on https://github.com/pytorch/pytorch/blob/master/torch/optim/adam.py#L259 as of this writing. 

cc @VitalyFedyunin @ngimel @vincentqb @jbschlosser @albanD
Repository: TypeScript
Issue: [refactoring] Refactor private class members to use hash names instead
Labels: Suggestion,Awaiting More Feedback

# Refactoring Suggestion

## 🔍 Search Terms

- `Refactor private`
- `Private member`
- `Private refactor`
- `private label:"Domain: Refactorings"`

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

It would be nice if there was another refactoring option to class members. 
Sometimes you might want to refactor classes using TypeScript private modifiers to the newer JS hash name private fields.
Currently if you want to do this, you have to manually delete "private" and rename the member.

So I propose to add a new refactor: "Refactor member to use hash names", which will do the following:

- Delete the `private` modifier (still preserving `static` and `readonly`)
- Rename the member (prefix it with `#`)

There should also be an option for the class declaration to refactor all private members, maybe under the name `Refactor class to use hash names`.

## 📃 Motivating Example and 💻 Use Cases

I have a class (many, in fact) with many numerous private members:

```ts
class Scanner {
    private start = 0;
    private current = 0;
    private line = 0;
    private col = 0;

    private next() {
        // ...
    }

   // ...
}
```

Currently, to change this class to use the hash name private fields, I have to delete "private", and then rename the member to `#<member>`.
Now, because there are many of these members, I currently have to manually (in VSCode) do these two steps for each member.

This gets repetitive and counter-productive really fast, so if I could simply do (MacOS):

- `Command ⌘` + `.` (refactoring panel)
- Select `Refactor member to use hash names`

And it would do the two steps above for me.
Even further you could also open the refactoring panel on the class declaration itself and add an option to refactor all private fields to hash names.
Repository: godot
Issue: custom class instance can't access members after being loaded from PackedScene
Labels: topic:gdscript

### Godot version

3.4.3 stable

### System information

Linux Debian 11

### Issue description

When a custom class instance whose `_init()` expects a parameter, and is stored on disk in a `PackedScene`, to then load it and access the members of such instance, it isn't recognized as custom class, only as `Node`, even if extends from another built-in type (in this case `Node2D`), so can't access its members.

When try it, the compiler complains.



Play with the exported `bool` property in the main scene.

### Steps to reproduce

The adjunct project has all to reproduce it and has comments for guidance.

Press `F5` to reproduce the issue.

### Minimal reproduction project

[custom_class_instance_cant_access_members.zip](https://github.com/godotengine/godot/files/8884797/custom_class_instance_cant_access_members.zip)
Repository: pytorch
Issue: [bazel] build spams warnings
Labels: triaged,module: bazel

### 🐛 Describe the bug

Minor annoyance about bazel build:
it doesn't use the same COPTs as the CMake build for the warning ignores, which leads to a lot of spam during the build.
It would be useful to do something like "build_variables.bzl" but for the COPTs.

### Versions

master 164029f783ba52d206862925e9341e6b851179ff