sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Inconsistent implementation of quant_utils:: ChooseQuantizationParams compared with fbgemm:: ChooseQuantizationParams
Labels: oncall: quantization,triaged

### 🐛 Describe the bug

The documentation says it should use sum

https://github.com/pytorch/pytorch/blob/d576a7dc97d222ca8db5f8b876ce391866018a9c/aten/src/ATen/native/quantized/cpu/QuantUtils.h#L135-L137

> sum of absolute values of terms

However, the implementation uses `difference`:
https://github.com/pytorch/pytorch/blob/d576a7dc97d222ca8db5f8b876ce391866018a9c/aten/src/ATen/native/quantized/cpu/QuantUtils.h#L140-L143

---

Also, the comment says
https://github.com/pytorch/pytorch/blob/d576a7dc97d222ca8db5f8b876ce391866018a9c/aten/src/ATen/native/quantized/cpu/QuantUtils.h#L58

But `fbgemm` is using `sum`, not difference. See
https://github.com/pytorch/FBGEMM/blob/49061a284744423bad17162d45a9bdc56adb4739/src/QuantUtils.cc#L100-L103
```cpp
  double zero_point_from_min_error =
      std::abs(qmin) + std::abs(min / static_cast<double>(scale));
  double zero_point_from_max_error =
      std::abs(qmax) + std::abs(max / static_cast<double>(scale));
```

### Versions

The latest master.

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
Repository: PowerToys
Issue: Some expected applications do not appear in search results
Labels: Issue-Bug,Product-PowerToys Run,Priority-3

### Microsoft PowerToys version

0.60.1

### Running as admin

- [x] Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

Install Visual Studio Code and Node.js Runtime, then search "VSC" in PowerToys Run.

The bug report log: [PowerToysReport_2022-07-23-17-28-35.zip](https://github.com/microsoft/PowerToys/files/9173464/PowerToysReport_2022-07-23-17-28-35.zip)

The screenshot: 

![image](https://user-images.githubusercontent.com/61044187/180599951-886175eb-529d-4d49-b2fd-66feb1bb593c.png)


### ✔️ Expected Behavior

The first result is Visual Studio Code. I can press enter to open it directly.

### ❌ Actual Behavior

Node.js instead and Visual Studio Code is disappeared in the results.

Once the bug produced when I search the abbreviation for another app name, but I forgot the name of that app. :(

### Other Software

- Visual Studio Code - 1.69.2 (system setup)

- Node.js Runtime - 16.16.0
Repository: godot
Issue: Editor <-> Debug window viewport inconsistency
Labels: topic:rendering,documentation,topic:2d

### Godot version

3.4.4.stable

### System information

MacOS Monterey, Intel Iris Plus Graphics 655 1536 MB, tested on GLES2/3

### Issue description

<img width="1440" alt="image" src="https://user-images.githubusercontent.com/16393543/180598957-02eb8613-0e52-45c2-acc9-3a294f0601d9.png">

In the editor the line and Node2D circle clearly shouldn't overlap. In the debug window the line renders as I'd expect, but the node does not. The circle I'm drawing to render the Node2D gets cut off by the end of the screen, but in the editor that's clearly impossible.

I'd expect that the marked viewport lines in the editor indicate the edge of the screen. The line2D shows that for it, that definitely is the edge of the screen, but the Node2D can only occupy the top left quarter of the viewport in order to render the way I'd expect it to. Note that this happens independent of having Hidpi mode on or off. Similarly stretch settings are not a factor. I've tried using those to fix this issue and got nowhere.

### Steps to reproduce

1. Create a Line2D element along the width and height of the marked viewport edge in the editor. We'll use this as a metric for the edge of the screen, since we can't trust the viewport lines in the editor.
2. Create a Node2D element. Attach a script that renders a circle over the position of the node.
3. Launch the debug window. Move the node towards the middle of the viewport (512, 300). Tab back to the window to see where it is.

### Minimal reproduction project

_No response_
Repository: rust
Issue: `alloc` methods are available in `#![no_std]` when running tests, despite not being imported.
Labels: A-libtest,C-bug,T-libs

I was messing around in a test in a `#[no_std]` crate and discovered that this code:

```rust
#![no_std]

#[test]
fn foo() {
    let b = b"hello";
    let _v = b.to_vec();
}
```
([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a2a27cb0adbe28cf8d4165ac364379ad))

compiles, which really surprised me, because `[T]::to_vec()` is defined in the `alloc` crate, and as you can see, I don't have any `extern alloc;` directive. It's even more surprising in that it *only* works in functions marked either `#[test]` or `#[cfg(test)]`. If you put it on a regular function (just remove `#[test]` from above), you get the expected error:
```
error[E0599]: no method named `to_vec` found for reference `&[u8; 5]` in the current scope
 --> src\lib.rs:5:16
  |
5 |     let _v = b.to_vec();
  |                ^^^^^^ method not found in `&[u8; 5]`
```

I expected this error to also happen in `#[cfg(test)]`, but it doesn't. This is unexpected and surprising.

What makes it even more surprising is that `alloc` isn't actually *in scope*, because if you change `let _v` to `let _v: alloc::Vec<_>` in the code above, you'll be told as much.
Repository: create-react-app
Issue: Failed to load plugin '@typescript-eslint',  Cannot find module 'eslint/use-at-your-own-risk'
Labels: needs triage,issue: bug report

`npm start` the following error is reported

ERROR in [eslint] Failed to load plugin '@typescript-eslint' declared in 'package.json » eslint-config-react-app#overrides[0]': Cannot find module 'eslint/use-at-your-own-risk'
Require stack:
- /Users/jasonli/web/专项训练营/datav/node_modules/@typescript-eslint/eslint-plugin/dist/util/getESLintCoreRule.js
- /Users/jasonli/web/专项训练营/datav/node_modules/@typescript-eslint/eslint-plugin/dist/rules/brace-style.js
- /Users/jasonli/web/专项训练营/datav/node_modules/@typescript-eslint/eslint-plugin/dist/rules/index.js
- /Users/jasonli/web/专项训练营/datav/node_modules/@typescript-eslint/eslint-plugin/dist/index.js
- /Users/jasonli/web/专项训练营/datav/node_modules/@eslint/eslintrc/dist/eslintrc.cjs

macOS 12.2.1
node v15.14.0
create-react-app v15.0.1
Repository: bitcoin
Issue: -proxy does not work for addresses like 10.x.y.z
Labels: Bug

Got unexpected behavior when trying to run bitcoind with -proxy setting.
-proxy is used to connect to SOCKS5 proxy which is able to access some internal network.
bitcoind is started with -noconnect option and network activity is absent (as it should be).

Then I command bitcoin-cli to connect to node with address 10.x.y.z with the command
`bitcoin-cli addnode 10.x.y.z add`

**Expected behavior** is for bitcoind to initiate connection through proxy.

**Actual behavior** is bitcoind trying to connect without using proxy.

In the code:
`CConnman::ConnectNode` calls GetProxy and GetProxy returns false because `CNetAddr::GetNetwork` returns NET_UNROUTABLE.

My take is this is unexpected behavior at minimum and should be documented.
Better way is to introduce another option just for the unroutable addresses:
- connect locally (for compatibility reasons, default);
- connect thru proxy;
- don't connect to unroutable addresses.
Repository: rust
Issue: Diag: closure with implied type lacks generic lifetime
Labels: A-diagnostics,A-lifetimes,T-compiler,D-confusing

Given the following code — [playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=99170e90a169ee5156ab147c918a7956):

```rust
struct A<'a>(&'a ());

trait Foo {}

impl<F: Fn(A)> Foo for F {}

fn main() {
    fn use_foo<F: Foo>(_: F) {}
    use_foo(|_| {});
}
```

The output on nightly is as follows. (Rust v1.62 only omits the second error + notes.)

```rust
Compiling playground v0.0.1 (/playground)
error: implementation of `FnOnce` is not general enough
 --> src/main.rs:9:5
  |
9 |     use_foo(|_| {});
  |     ^^^^^^^^^^^^^^^ implementation of `FnOnce` is not general enough
  |
  = note: closure with signature `fn(A<'2>)` must implement `FnOnce<(A<'1>,)>`, for any lifetime `'1`...
  = note: ...but it actually implements `FnOnce<(A<'2>,)>`, for some specific lifetime `'2`

error[[E0308]](https://doc.rust-lang.org/nightly/error-index.html#E0308): mismatched types
 --> src/main.rs:9:5
  |
9 |     use_foo(|_| {});
  |     ^^^^^^^^^^^^^^^ one type is more general than the other
  |
  = note: expected trait `for<'r> Fn<(A<'r>,)>`
             found trait `Fn<(A<'_>,)>`
note: this closure does not fulfill the lifetime requirements
 --> src/main.rs:9:13
  |
9 |     use_foo(|_| {});
  |             ^^^
note: the lifetime requirement is introduced here
 --> src/main.rs:8:19
  |
8 |     fn use_foo<F: Foo>(_: F) {}
  |                   ^^^
```

Ideally a hint like the following would be included:
```
help: consider adding a type annotation:
   |
 9 |     use_foo(|_: A<_>| {});
   |               ~~~+++
```

See also the [discussion on internals.rust-lang](https://internals.rust-lang.org/t/implied-lifetime-of-parameter-to-fnonce-trait/17068/13).

Note: the impl of `Foo for F` has an elided lifetime which expands as follows ([nomicon/HRTB](https://doc.rust-lang.org/nomicon/hrtb.html)):
```rust
impl<F> Foo for F
where
    for<'a> F: Fn(A<'a>),
{}
```

Note (@steffahn): "Closures with completely inferred types tend to not be generic over lifetimes, which is why |_| {} fails."
Repository: TypeScript
Issue: Colour coded error messages
Labels: Suggestion,Awaiting More Feedback

# Suggestion
Typescript error messages can be a bit verbose sometimes. Color coding them and formatting them better (in reference to [#45896](https://github.com/microsoft/TypeScript/issues/45896)) would greatly improve their readabillity.



## 🔍 Search Terms
Colour code, color code, syntax highlighting, formatter, error messages



## ✅ 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:

* [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [X] This wouldn't change the runtime behaviour 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
A plus:
Colour coded visual difference for type errors, for example when unions do not match or a required property is missing.



## 📃 Motivating Example
Images speak a thousand lines of code (I messed up the formatting a bit. I did this by hand in an online tool..)
![big output](https://user-images.githubusercontent.com/28539403/180614651-a07c5364-4ac7-49f3-abf1-ac39308324b3.png)
![difference](https://user-images.githubusercontent.com/28539403/180614762-4b96ae0e-82f9-4d31-9070-932dfbb0af41.png)

## 💻 Use Cases
Overall useful as current error messages are hard to read, especially with big complex types.
Repository: tauri
Issue: [bug] drag-region doesn't work correctly on windows touchscreen device
Labels: type: bug,status: upstream

### Describe the bug

I can drag with mouse, but not touchscreen

### Reproduction

1. npx create-tauri-app, choose react, and typescript
2. in tauri.conf.json, change the tauri.windows:
```
"windows": [
      {
        "decorations": false,
        "fullscreen": false,
        "height": 300,
        "resizable": true,
        "title": "",
        "width": 200,
        "alwaysOnTop": true
      }
    ]
```
3. App.tsx:
```
import React from 'react';

import './App.css';


function App() {

  return (
    <div className="App">
      <header className="App-header">
        <div data-tauri-drag-region style={{
          backgroundColor: "#111",
          padding: 20
        }}>
          Floating Hotkey
        </div>

      </header>
    </div>
  );
}

export default App;
```

4. App.css
```
.App {
  text-align: center;
}

.App-header {
  background-color: #282c34;
  min-height: 100vh;
  display: flex;
  flex-direction: column;
  align-items: stretch;
  justify-content: start;
  font-size: calc(10px + 2vmin);
  color: white;
}
```

should get something like this:


https://user-images.githubusercontent.com/36293056/180617696-e115d8dd-e7b6-493a-91e8-4cf81da61ac6.mp4



### Expected behavior

touchscreen should behave same as mouse drag

### Platform and versions

```shell
npm run tauri info

> floating-hotkey@0.1.0 tauri
> tauri "info"


Environment
  › OS: Windows 10.0.22000 X64
  › Webview2: 103.0.1264.62
  › MSVC:
      - Visual Studio Community 2019
  › Node.js: 16.6.0
  › npm: 7.19.1
  › pnpm: Not installed!
  › yarn: 1.22.17
  › rustup: 1.24.3
  › rustc: 1.61.0
  › cargo: 1.61.0
  › Rust toolchain: stable-x86_64-pc-windows-msvc

Packages
  › @tauri-apps/cli [NPM]: 1.0.5
  › @tauri-apps/api [NPM]: 1.0.2
  › tauri [RUST]: 1.0.5,
  › tauri-build [RUST]: 1.0.4,
  › tao [RUST]: 0.12.2,
  › wry [RUST]: 0.19.0,

App
  › build-type: bundle
  › CSP: unset
  › distDir: ../build
  › devPath: http://localhost:3000/
  › framework: React

App directory structure
  ├─ .git
  ├─ node_modules
  ├─ public
  ├─ src
  └─ src-tauri
```


### Stack trace

```shell
Compiling...
Compiled with warnings.

Warning
(11:3) autoprefixer: start value has mixed support, consider using flex-start instead

Search for the keywords to learn more about each warning.
To ignore, add // eslint-disable-next-line to the line before.

WARNING in ./src/App.css (./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[5].use[1]!./node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[1].oneOf[5].use[2]!./node_modules/source-map-loader/dist/cjs.js!./src/App.css)
Module Warning (from ./node_modules/postcss-loader/dist/cjs.js):
Warning

(11:3) autoprefixer: start value has mixed support, consider using flex-start instead

webpack compiled with 1 warning
No issues found.
```


### Additional context

_No response_
Repository: pytorch
Issue: Documentation for torch.cuda.Event(blocking=True) is wrong
Labels: module: docs,module: cuda,triaged

### 📚 The doc issue

https://pytorch.org/docs/stable/generated/torch.cuda.Event.html#torch.cuda.Event
doc states:
```
blocking (bool, optional): if ``True``, :meth:`wait` will be blocking (default: ``False``)
```

But cross referencing:
https://github.com/pytorch/pytorch/blob/30fb2c4abaaaa966999eab11674f25b18460e609/torch/csrc/cuda/Event.cpp#L48
and:
https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__EVENT.html#group__CUDART__EVENT_1g7b317e07ff385d85aa656204b971a042


[cudaEventBlockingSync](https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__TYPES.html#group__CUDART__TYPES_1g26509a522be9d449aa7c8c279612452d): Specifies that event should use blocking synchronization. A host thread that uses [cudaEventSynchronize()](https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__EVENT.html#group__CUDART__EVENT_1g949aa42b30ae9e622f6ba0787129ff22) to wait on an event created with this flag will block until the event actually completes.


### Suggest a potential alternative/fix

```
blocking (bool, optional): if ``True``, :meth:`synchronize` will be blocking. if ``False``,  :meth:`synchronize` will cause the CPU to busy-wait until the event has completed (default: ``False``).
```

cc @ezyang @gchanan @zou3519 @svekars @holly1238 @ngimel
Repository: godot
Issue: Editor popup menus do not follow main window when moved or resized (DisplayServer regression)
Labels: bug,topic:editor,topic:porting,needs testing,regression

### Godot version

v4.0.alpha12.official [2c11e6d9e]

### System information

Linux, Ubuntu 22.04 LTS, Vulkan API 1.2.0 - Using Vulkan Device #0: Intel - Intel(R) Graphics (ADL-S GT1)

### Issue description

Clicking on menu item produces a popup that does not stay with the window if the window is moved.

### Steps to reproduce

1. On a scene window, click "Scene" menu item 
- The popup appears with the Scene menu options
2. Move the mouse away toward the window header
3. Move the window
- The popup sticks where it was instead of following the window.


This does not occur in 3.4.4

### Minimal reproduction project

[godot4.zip](https://github.com/godotengine/godot/files/9174377/godot4.zip)
Repository: pytorch
Issue: optimize_for_mobile vulkan_prepack::conv2d_clamp_prepack
Labels: oncall: mobile,module: vulkan

### 🐛 Describe the bug

trying to convert a simple resnet18 model to mobile vulkan backend
i am being asked to report the bug `please report a bug to PyTorch. We don't have an op for vulkan_prepack::conv2d_clamp_prepack but it isn't a special case`

```python
import torch
from torch.utils.mobile_optimizer import optimize_for_mobile
print(torch.__version__)
m = torch.jit.load("ptl-models/resnet18_wd4_2_3_scripted.pt")
vm = optimize_for_mobile(m, backend='vulkan')
```

scripted.pt can be downloaded here https://drive.google.com/file/d/1crd0f-jq9GBAE0a7kKXAthgWcsHTNgYH/view?usp=sharing

```
1.12.0+cu102
Traceback (most recent call last):
  File "./pt_vulkan.py", line 5, in <module>
    vm = optimize_for_mobile(m, backend='vulkan')
  File "./venv/lib/python3.8/site-packages/torch/utils/mobile_optimizer.py", line 67, in optimize_for_mobile
    optimized_cpp_module = torch._C._jit_pass_vulkan_optimize_for_mobile(script_module._c, preserved_methods_str)
RuntimeError: 0 INTERNAL ASSERT FAILED at "../torch/csrc/jit/ir/alias_analysis.cpp":614, please report a bug to PyTorch. We don't have an op for vulkan_prepack::conv2d_clamp_prepack but it isn't a special case.  Argument types: Tensor, Tensor?, int[], int[], int[], int, NoneType, NoneType, 
```

### Versions

```
PyTorch version: 1.12.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 8.4.0-3ubuntu2) 8.4.0
Clang version: 10.0.0-4ubuntu1 
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.8.10 (default, Jun 22 2022, 20:18:18)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.15.0-41-generic-x86_64-with-glibc2.29
Is CUDA available: True
CUDA runtime version: 10.1.243
GPU models and configuration: GPU 0: Quadro RTX 5000 with Max-Q Design
Nvidia driver version: 515.48.07
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.4.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.4.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.0
[pip3] pytorchcv==0.0.67
[pip3] torch==1.12.0
[conda] Could not collect
```
Repository: flutter
Issue: Make "color" parameter values consistent throughout  material frame work.
Labels: c: new feature,framework,f: material design,c: proposal,team-design,triaged-design

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->
    There is an inconstant data type for "color" type parameters (or for parameters that require a color value!
    Some widgets have a material color (i.e MaterialColor) and others require a dart color ( Color) type.
    The "MaterialApp" widget uses a MaterialColor type widget and "Container" widget uses a dart Color widget.   
    I don't know if other widgets have this same problem. You might want to investigate. 

## Proposal

<!--
     Briefly but precisely describe what you would like Flutter to be able to dpeo.

     Consider attaching something showing what you are imagining:
      * images
      * videos
      * code samples

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->
    If I am writing a Material App, then all color parameters should refer to the MaterialColor type.
    Provide an override of any container that uses a Dart color so that a color parameter has
    a constituent MaterialColor type. If I do not import the Material package then let the pieces fall where
    they may.  

    You might also want to make a distinction for new developers of the differences. Don't let them learn
    by trial and error that there are two different color schemes. That information is hidden in your first 
    Material App.  How about adding a "color constant" in the example app where the color is defined
    as a class element and make it obvious that this element is not a dart color type.