sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: `unique` will reverse the input when `sort=False` on cpu (not sorting)
Labels: module: cpu,triaged,intel

### 🐛 Describe the bug

`unique` will reverse the input when sort=False on cpu (not sorting). By contrast, the cuda will keep the order.

```py
import torch

input = torch.FloatTensor([1, 3])
torch.unique(input, sorted=False)
# tensor([3., 1.])
torch.unique(input.cuda(), sorted=False)
# tensor([1., 3.], device='cuda:0')
```

You can see the input is in the ascending order. Even `sort=True` it should return the `[1, 3]`. But cpu will reverse the input to a descending order

### Versions

torch: 1.13.0
cuda: 11.6

cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
Repository: go
Issue: x/crypto/ssh: make it possible to disable SHA-1 algorithms
Labels: NeedsFix

#49952 tracked adding support for the SHA-2 variants of `ssh-rsa`. This issue is about exposing the settings necessary to turn off the original SHA-1 algorithm, both on the signer and on the verifier side, both for client and host authentication.

For example, this will require something akin to `ServerConfig.PublicKeyAuthAlgorithms` from #49269 and `MultiAlgorithmSigner` from #52132, as well as others.

Eventually, we'll want to make SHA-1 disabled by default, and these settings will be how applications can turn it back on.
Repository: vscode
Issue: Wrong codelens position in merge editor
Labels: bug,merge-editor

<img width="1273" alt="image" src="https://user-images.githubusercontent.com/876920/199838730-90b5ce23-c3c3-468d-b166-15f6ee61594c.png">

In the result editor, the codelens is not rendered at the right position.
Repository: next.js
Issue: Fast Refresh breaks with ESI tags
Labels: bug,Output (export/standalone)

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP Wed Apr 27 21:16:35 UTC 2022
    Binaries:
      Node: 16.15.1
      npm: 8.13.2
      Yarn: 3.2.1
      pnpm: N/A
    Relevant packages:
      next: 13.0.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0

### What browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

next dev

### Describe the Bug

This is utilizing the new app/ directory layout.
When defining a root layout, and adding in <esi:include> tags, which are replaced by an intermediary proxy (Varnish, Cloudflare worker, Lambda@Edge, etc), fast-refresh/hydration breaks on the page.

This is because the output does not match, as it was dynamically replaced before it hit the browser.

### Expected Behavior

Refresh should work with <esi:include /> tags. 
This could be an option in the config to disable refresh for the root layout.

Essentially if you have any process in-between the nextjs dev server, and the user's browser, which alters the HTML, the fast-refresh breaks as it tries to hydrate. There should be a way to mark an area as completely static, and disable the fast-refresh from that area, while keeping it for the main body of the application.

### Link to reproduction

https://github.com/siosphere/nextjs-esi-refresh

### To Reproduce

Reproducing requires running a proxy in-between the nextjs server and the browser, which can understand <esi:include> tags.

In the repo i provided, you can run:
```
yarn dev
```
in one terminal window, which starts the normal nextjs service on localhost:3000, and fast-refresh and everything works as expected. In another terminal window, you can run:
```
node proxy.js
```
Which spins up a very simple proxy that just does a replace on the esi:include tag, to mimic what an esi capable proxy would do. Visiting `localhost:3001` will then give you the hydration error, since client-side it is trying to hydrate the esi:include tag, but the server has differing html.
Repository: flutter
Issue: [Linux] Support semantics custom actions
Labels: a: accessibility,platform-linux,a: desktop,P2,team-linux,triaged-linux

Flutter represents accessibility information using semantics nodes and custom actions. The Linux embedder does not support semantics custom actions. This likely results in incorrect accessibility for things that use custom actions, like a `ReorderableListView`.
Repository: pytorch
Issue: MaxPool1D output shapes can be negative when ceil_mode=True
Labels: module: nn,triaged,module: pooling

### 🐛 Describe the bug

When ceil_mode=True, output shape can potentially be negative, which is nonsensical. I think the calcuation of output shape for that case is wrong.

This seems related to issue https://github.com/pytorch/pytorch/issues/88144

```python
import torch

m = torch.nn.MaxPool1d(kernel_size=4, stride=1, padding=0, dilation=1, ceil_mode=True)
input = torch.randn(20, 16, 1)
output = m(input)
```

```
Traceback (most recent call last):
  File "/Users/mitch/***/avgpool.py", line 6, in <module>
    output = m(input)
  File "/opt/homebrew/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1190, in _call_impl
    return forward_call(*input, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/torch/nn/modules/pooling.py", line 92, in forward
    return F.max_pool1d(input, self.kernel_size, self.stride,
  File "/opt/homebrew/lib/python3.10/site-packages/torch/_jit_internal.py", line 485, in fn
    return if_false(*args, **kwargs)
  File "/opt/homebrew/lib/python3.10/site-packages/torch/nn/functional.py", line 696, in _max_pool1d
    return torch.max_pool1d(input, kernel_size, stride, padding, dilation, ceil_mode)
RuntimeError: max_pool1d() Invalid computed output size: -2
```

My experiments suggest that output shape for ceil_mode = True should be `ceiling((inputsize + padleft) / stride)`.


### Versions

```
Collecting environment information...
PyTorch version: 1.13.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.5 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.102)
CMake version: version 3.24.2
Libc version: N/A

Python version: 3.10.6 (main, Aug 30 2022, 04:58:14) [Clang 13.1.6 (clang-1316.0.21.2.5)] (64-bit runtime)
Python platform: macOS-12.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
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.23.3
[pip3] torch==1.13.0
[pip3] torchaudio==0.13.0
[pip3] torchvision==0.14.0
[conda] Could not collect
```

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
Repository: go
Issue: fmt: error verb rune 'w', overriding/breaking fmt.formatter implementation
Labels: NeedsInvestigation

https://go.dev/play/p/eM3d8y2L768

### What did you expect to see?

```
s
w
```
### What did you see instead?

```
s
%!w(main.T2={})
```
Repository: stable-diffusion-webui
Issue: [Feature Request]: Add clip studio paint plugin nekodraw plz
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Add clip studio paint plugin nekodraw plz, hope will in Extensions just like "auto-sd-paint-ext"
https://github.com/mika-f/nekodraw

### Proposed workflow

1. Go to .... 
2. Press ....
3. ...


### Additional information

_No response_
Repository: vscode
Issue: Context widgets are not aware of Window Controls Overlay (WCO)
Labels: bug,titlebar,menus

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: latest
- OS Version: windows11

Steps to Reproduce:

1. Set `window.experimental.windowControlsOverlay.enabled` to true.
2. 
![image](https://user-images.githubusercontent.com/99157764/199868324-020611b3-7879-4eae-a66e-830bc7d0ec8d.png)
![image](https://user-images.githubusercontent.com/99157764/199868361-87c9992d-9b31-4c88-a0ce-38924fb875e5.png)
Repository: kubernetes
Issue: [kubectl] server-side apply with --force-conflicts should warn about any conflicts it is forcing
Labels: sig/api-machinery,kind/feature,sig/cli,triage/accepted

### What would you like to be added?

`kubectl apply --server-side --force-conflicts` should provide a way to display any conflicts being overridden so that users--especially those migrating to SSA--can detect, investigate and address them without causing a disruption to their service (or need to revert to CSA). Perhaps this could even be the default behaviour. If it can't, I suggest `--force-conflicts=warn`

/sig api-machinery
/sig cli

### Why is this needed?

One of the biggest changes for end users migrating to server-side apply (SSA) from client-side apply (CSA) is the notion of field ownership conflicts. Indeed, the need to identify and resolve them may be a barrier to migrating to SSA, particularly when a central entity determines the apply strategy in CD pipelines they manage for an entire organization. Users can get around the problem to some extent by setting `--force-conflicts=true`, but then they don't even know whether or not conflicts are occurring. This functionality could be used to make the migration path smoother. It could also be a helpful tool in developing a strategy to automate opt-in to SSA in the long term.

Note: clients other than kubectl could likely also benefit from this information being exposed in the response
Repository: rust
Issue: riscv32imac-unknown-xous-elf: `rust-lld` gives `offset is outside the section` errors
Labels: A-LLVM,P-low,T-compiler,regression-from-stable-to-stable,C-bug,O-xous

### Version it worked on

It most recently worked on: Rust 1.64.0

### Version with regression

<!--
Provide the version you are using that has the regression.
-->

`rustc --version --verbose`:
```
rustc 1.65.0 (897e37553 2022-11-02)
binary: rustc
commit-hash: 897e37553bba8b42751c67658967889d11ecd120
commit-date: 2022-11-02
host: x86_64-pc-windows-msvc
release: 1.65.0
LLVM version: 15.0.0
```

### Description

Building crates for the `riscv32imac-unknown-xous-elf` target sometimes results in a link error. This began with Rust 1.65.0. For example:

```
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "C:\\Users\\Sean\\AppData\\Local\\Temp\\rustcR77RGd\\symbols.o" "E:\\Code\\Xous\\Core\\target\\riscv32imac-unknown-xous-elf\\release\\deps\\pddb-8aba67b084ba8fc1.pddb-b3f235aec8c95441.n927u1iqdxcieg4.rcgu.o.rcgu.o" "--as-needed" "-L" "E:\\Code\\Xous\\Core\\target\\riscv32imac-unknown-xous-elf\\release\\deps" "-L" "E:\\Code\\Xous\\Core\\target\\release\\deps" "-L" "E:\\Code\\Xous\\Core\\target\\riscv32imac-unknown-xous-elf\\release\\build\\xous-08f083a692e5c29b\\out" "-L" "C:\\Users\\Sean\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\riscv32imac-unknown-xous-elf\\lib" "-Bstatic" "C:\\Users\\Sean\\AppData\\Local\\Temp\\rustcR77RGd\\libxous-26655dcc7bb206b6.rlib" "C:\\Users\\Sean\\AppData\\Local\\Temp\\rustcR77RGd\\libxous-d175a8531300a7f7.rlib" "C:\\Users\\Sean\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\riscv32imac-unknown-xous-elf\\lib\\libcompiler_builtins-67716ddc427f4546.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "C:\\Users\\Sean\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\riscv32imac-unknown-xous-elf\\lib" "-o" "E:\\Code\\Xous\\Core\\target\\riscv32imac-unknown-xous-elf\\release\\deps\\pddb-8aba67b084ba8fc1" "--gc-sections" "-O1"
  = note: rust-lld: error: E:\Code\Xous\Core\target\riscv32imac-unknown-xous-elf\release\deps\pddb-8aba67b084ba8fc1.pddb-b3f235aec8c95441.n927u1iqdxcieg4.rcgu.o.rcgu.o:(.rodata.cst32): offset is outside the section


error: could not compile `pddb` due to previous error
```

### Background

We build a custom libstd for the `riscv32imac-unknown-xous-elf` target, which is a Tier-3 target. This repository is at https://github.com/betrusted-io/rust. We are working on preparing patches for upstream that do not add any external dependencies, but this work is taking time. As a result, we generally forward-port our patchset every six weeks once the stable build is released.

When building packages for the Betrusted platform, our build system compiles around 27 packages. Many of these packages succeed, but with Rust 1.65.0 we have three packages fail.

This target does not have a linker script, and instead relies on the default one provided by `rust-lld`.
Repository: PowerToys
Issue: keyboard shortcut
Labels: Idea-Enhancement

### Description of the new feature / enhancement

Set keyboard shortcuts that can quickly paste text or launch software. The function will be similar to software such as [clavier+](https://gryder.org/software/clavier-plus/)

### Scenario when this would be used?

It can be helpful in certain situations where repeated content is often posted

### Supporting information

_No response_
Repository: pytorch
Issue: Mixed precision training fails due to NaN in batch norm running_mean
Labels: triaged,module: amp (automated mixed precision)

### 🐛 Describe the bug

During mixed precision training, the NaN gradient is skipped by grad_scaler. However, the NaN output will destroy the batch norm running mean and variance. This is severe because:
1. It can only be observed during validation since during training the running_mean and running_variance are not used.
2. It will break the whole training process of AMP.

Can batch norm skip NaN samples while updating the running_mean and running_var? Is there any way to achieve such a purpose? Following is an MRE. 
```python
import torch 
data = torch.rand(2, 3, 10).cuda()
from torch import nn
from torch.cuda.amp import autocast as autocast

network = nn.Sequential(
    nn.Conv1d(3, 16, 3, padding=1),
    nn.ReLU(),
    nn.BatchNorm1d(16)).cuda()

with autocast():
    data = data.half() * 100000
    output = network[0](data)
    output = network[1](output)
    output = network[2](output)
    print(network[1].running_mean)
```
The output is :
```
tensor([nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan],
       device='cuda:0')
```

### Versions

PyTorch version: 1.10.1
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.3 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.7 (default, Sep 16 2021, 13:09:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.102.1-microsoft-standard-WSL2-x86_64-with-glibc2.31

cc @VitalyFedyunin @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @mcarilli @ptrblck @leslie-fang-intel
Repository: neovim
Issue: yarn 3.2.4 and :checkhealth
Labels: bug,provider

### Neovim version (nvim -v)

NVIM v0.8.0-1210-gd367ed9b2

### Vim (not Nvim) behaves the same?

I don't use vim.

### Operating system/version

Pop!_OS 22.04 LTS

### Terminal name/version

gnome terminal 3.44.0 for gnome 42

### $TERM environment variable

xterm-256color

### Installation

nvim.appimage

### How to reproduce the issue

```
nvm install node
corepack enable
corepack prepare yarn@v3.2.4 --activate
npm install -g neovim

nvim
:checkhealth
```

output:
```
## Node.js provider (optional)
  - INFO: Node.js: v19.0.0
  - INFO: Nvim node.js host: /home/user/.nvm/versions/node/v19.0.0/lib/node_modules/neovim/bin/cli.js
  - ERROR: Command error (job=19, exit code 1): `yarn info neovim --json` (in '/home/user')
    output: [31m[1mUsage Error[22m[39m: No project found in /home/user[1m$ [22myarn info [-A,--all] [-R,--recursive] [-X,--extra #0] [--cache] [--dependents] [--manifest] [--name-only] [--virtuals] [--json] ...
  - ERROR: Failed to run: yarn info neovim --json
    - ADVICE:
      - Make sure you're connected to the internet.
      - Are you behind a firewall or proxy?
```

The error generated:

```
"No project found"
```

Newer versions of yarn apparently do not have a concept of globally installing packages.  I am not sure what behavior would be best here.

### Expected behavior

Honestly I am not sure to what degree this is actually a problem but not having the health check pass does bother me.

### Actual behavior

That the health check pass using npm only perhaps?
Repository: three.js
Issue: FBXLoader.js should use the "min" function and not the "max" function when limiting the penumbra value.
Labels: Loaders

**Describe the bug**

`FBXLoader.js` should be use the "min" function instead of the "max" function for the _penumbra_ limiting statement.

***Code***

Here is the suspect code.  The code uses the "max" function when it should use "min" to limit the _penumbra_ to a value less than or equal 1. 

https://github.com/mrdoob/three.js/blob/f54eb5b0bf7baa7132acc26c799bbb16bda136a8/examples/jsm/loaders/FBXLoader.js#L1206-L1217

Also, wouldn't the first statement better as follows?:
```js
        penumbra = THREE.MathUtils.degToRad( lightAttribute.OuterAngle.value  / 360.0 );
	penumbra = Math.min( penumbra, 1 );
```
By dividing the FBX model angle value by 360 you rescale it to 0, 1.
Repository: node
Issue: Tweak security disclaimer regarding legacy `url.parse`
Labels: doc,url,security

### Affected URL(s)

https://nodejs.org/api/url.html#url_url_parse_urlstring_parsequerystring_slashesdenotehost

### Description of the problem

I know there is a bit of history regarding deprecating, undeprecating, legacy, doc deprecating, etc., which I'm not looking to rehash.  My question is specific to a small tweak or clarification on the last paragraph that mentions security.  The current docs have the following warning:

> It is prone to security issues such as [host name spoofing](https://hackerone.com/reports/678487) and incorrect handling of usernames and passwords. Do not use with untrusted input. CVEs are not issued for `url.parse()` vulnerabilities. Use the [WHATWG URL](https://nodejs.org/api/url.html#the-whatwg-url-api) API instead.

Is it possible to clarify there are no **active** security vulnerabilities with it.  Perhaps it's just me, but every time I read that paragraph (even though I know the specific vulnerability called out has indeed been fixed in https://github.com/nodejs/node/pull/38631), I always do a double take because it looks like the docs are saying there are active vulnerabilities that **won't** be fixed.

`new URL()` is still about 50% slower than `url.parse` in v19, and `url.parse` is still heavily used in the wild, so I think it'd be a value add in terms of clarity, but let me know your thoughts.  I'm not sure exactly what the wording should be, but just making it clearer that it's not an active security risk unless the current wording is intended to scare people away 😆
Repository: PowerToys
Issue: Fancy Spaces maintains fancyness after PC is in sleep mode
Labels: Idea-Enhancement,Needs-Triage

### Description of the new feature / enhancement

Hi.  PowerToys is awesome.  I love Fancy Spaces.  As a technical manager and someone who is probably on the "spectrum" a little, it is perfect.  If it is possible, it would be super awesome if my Fancy Spaces would be in the same place, after I leave my desk and lock my PC into sleep mode.  Now when I open my PC, I need to place them again.  *So great job! and just a suggestion, which I'm guessing you are probably aware of.

### Scenario when this would be used?

When reopening pc from sleep or hibernate mode, etc.

### Supporting information

I love that this is called 'Fancy Spaces'... rebranding "fancy" solutions as something that works and is to be excited about.
Repository: flutter
Issue: Add capability to deobfuscate dart code
Labels: c: new feature,tool,dependency: dart,d: api docs,P3,team-tool,triaged-tool

When I use the obfuscate command to build apk

"flutter build apk --obfuscate --split-debug-info=/<project-name>/<directory>"

When I run the apk , this is some logs: 
"Instance of 'Zs'"

The 'Zs' is obfuscated, It should be  class name

I want to how to find the class name depend the 'Zs'?

by the way，the below command can work to deobfuscate stack trace , but not work to deobfuscate class name 

flutter symbolize -i <stack trace file> -d out/android/app.android-arm64.symbols
Repository: godot
Issue: MeshInstance3D - Visibility Range has inconsistent behavior when doing manual LODs
Labels: bug,topic:rendering,confirmed,topic:3d

### Godot version

4.0 Beta 3, 4.0 Beta 4

### System information

Windows 10, Vulkan, Nvidia RTX 3060 Ti

### Issue description

When trying to use the Visibility Range setting for manual LOD control, _some_ models pop away temporarily when they switch between their different LODs. At the same time, other models don't have a problem and correctly toggle visibility as expected.
This is true regardless of if the margins are set to 0 or not. 
The issue happens regardless of if I import the LODs together in a single .GLB file, or if I import each LOD as seperate OBJ meshes.

Visibility settings for the 2 LOD meshes:
![LOD_settings](https://user-images.githubusercontent.com/2095704/199911432-53dd45ea-b4c8-426c-b4b7-6614e9c4a3b6.jpg)


Video showing the tree disappear, while at the same time the test model on the right does not disappear. Both have exactly the same Visibility Range settings:

https://user-images.githubusercontent.com/2095704/199912927-1ac54b00-1f16-42e3-a88c-1671a4ce2c22.mp4



### Steps to reproduce

- Load up the attached sample project
- Move the editor camera closer and further from the models 
- OR run the project and move the camera back and forth with the W and S keys

Result:
The tree object on the left disappears within a small distance threshold where it should switch between the two LODs,
At the same time the test object on the right correctly switches between its two LODs without disappearing. 
Both objects have their Visibility Ranges set exactly the same, to swap at 20m
Both objects scenes inherit from imported .glb files and have their automatic LODs turned off.


### Minimal reproduction project

[LOD_Bug.zip](https://github.com/godotengine/godot/files/9935845/LOD_Bug.zip)