sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Expanding collapsed NavigationView results in transparent flash
Labels: Help Wanted,Issue-Bug,Product-Terminal,Priority-3,Area-SettingsUI

### Windows Terminal version

1.14.2282.0

### Windows build number

10.0.22000.832

### Other Software

_No response_

### Steps to reproduce

Open Terminal at a size at which the NavigationView is collapsed.
Open settings
Expand NavigationView

### Expected Behavior

_No response_

### Actual Behavior

see below

https://user-images.githubusercontent.com/51363864/170275376-c5ab0c81-f360-4855-ba7f-b381ca8d7df7.mp4
Repository: ant-design
Issue: segmented : allow title as tooltip component
Labels: help wanted,💡 Feature Request,Inactive

### What problem does this feature solve?

we can add title to segmented item but you want to add antd Tooltip component, it display object.

### What does the proposed API look like?

allow to add Tooltip in place of title

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: go
Issue: proposal: archive/zip: return clearer errors
Labels: Proposal

Currently, the errors returned in archive/zip are often not very clear due to the following issues:
- They lack documentation (e.g. ErrAlgorithm in reader.go on lines 25 and 190).
- They are too generic to provide an actionable error message to the end user (e.g. ErrFormat in reader.go on lines 24 and 238).
- They are not stored in a variable (e.g. the error in writer.go on line 512).
- One return in particular seems to violate the documentation of io.Reader: on line 245 of reader.go we return 0, io.ErrUnexpectedEOF. But the documentation of io.Reader states "When Read encounters an error or end-of-file condition after successfully reading n > 0 bytes, it returns the number of bytes read." So we should return n instead of 0.

I would like to replace the current errors in archive/zip with actionable, clearly documented variables, like the ones we see in io/io.go. If you accept the general outline of the proposal, I can make a detailed design doc containing every error I would like to create. A design doc seems important given the number of public-facing changes that are needed.
Repository: go
Issue: debug/buildinfo: build info not found in PE binaries
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
1.18

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?
PE go binary, any host OS

### What did you do?
The go buildinfo tool fails to locate the build info because the bit test here is wrong https://github.com/golang/go/blob/119da6358bf8cc01bb8bc7556d616bd0fe723ad4/src/debug/buildinfo/buildinfo.go#L317. When the `.data` section characteristics flags are value `0xC0500040`. 

![image](https://user-images.githubusercontent.com/6619205/170285236-1c6553c0-72a1-4345-8c33-c8720e896dae.png)


### What did you expect to see?
The `.data` section to be found.


### What did you see instead?
The `.data` section is not found and the PE is seen as malformed by the buildinfo command, and information extraction fails.
Repository: pytorch
Issue: Floating point exception in _conv_depthwise2d
Labels: triaged,module: edge cases

### 🐛 Describe the bug

Floating point exception in `_conv_depthwise2d`.

### Example to reproduce

```python
import torch

torch.cuda.init()

gpu_dev = torch.device('cuda')

tensor_0 = torch.full((4, 1, 3, 3,), 1, dtype=torch.float64, requires_grad=False, device=gpu_dev)
tensor_1 = torch.full((4, 1, 3, 3,), 0.5, dtype=torch.float64, requires_grad=False, device=gpu_dev)
intarrayref_2 = [1, 1]
tensor_3 = torch.full((4,), 1, dtype=torch.float64, requires_grad=False, device=gpu_dev)
intarrayref_4 = [0, 0]
intarrayref_5 = [0, 0]
intarrayref_6 = [0, 0]
torch._C._nn._conv_depthwise2d(tensor_0, tensor_1, intarrayref_2, tensor_3, intarrayref_4, intarrayref_5, intarrayref_6)
```

### Result
```floating point exception```

### Expected behavior
Graceful termination or a RuntimeError to be thrown.

### Note
This bug was discovered using IvySyn, a fuzz testing tool which is currently being developed at Secure Systems Labs at Brown University.

### Versions

PyTorch version: 1.11.0a0+git1efeb37
Is debug build: False
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: 4.3.21300-5bbc51d8

OS: Debian GNU/Linux 11 (bullseye) (x86_64)
GCC version: (Debian 10.2.1-6) 10.2.1 20210110
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.31

Python version: 3.9.12 (main, Apr  5 2022, 06:56:58)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.10.0-14-amd64-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: Lexa XT [Radeon PRO WX 3100]
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: 40321.30
MIOpen runtime version: 2.12.0
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.3
[pip3] torch==1.11.0a0+gitfdec0bf
[conda] mkl                       2022.0.1           h06a4308_117
[conda] mkl-include               2022.0.1           h06a4308_117
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] torch                     1.11.0a0+gitcb6fe03          pypi_0    pypi
Repository: opencv
Issue: imdecode should also have a vector<uchar> API
Labels: feature,category: imgcodecs

##### System information (version)

- OpenCV => 4.x

##### Detailed description

`imdecode` only has a `cv::InputArray` API. If you have an input buffer `std::vector<uchar>` that is bigger than 2GB, a `cv::Mat` will be created to wrap it but its size `[1,length]` will not fit in an int. In practice, we are still safe up to 4GB because of wrap around (the dimensions are negative but total() is cast to size_t).
`imencode` does have a `std::vector<uchar>` API so I believe it also makes sense to expose one for imdecode.

 - [x] I report the issue, it's not a question
 - [x] I checked the problem with documentation, FAQ, open issues,
       forum.opencv.org, Stack Overflow, etc and have not found any solution
 - [x] I updated to the latest OpenCV version and the issue is still there
Repository: material-ui
Issue: Typography variantMapping should merge with the default value
Labels: docs,component: Typography

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Current behavior 😯

variantMapping es sobreescrito por defaultVariantMapping estropeando la variantMapping propiedad.

https://github.com/mui/material-ui/blob/92a4866ce9a06769592cddc06cfa7455b4644544/packages/mui-material/src/Typography/Typography.js#L102

Se podría cambiar esta linea por 
 variantMapping["defaultVariantMapping"] = defaultVariantMapping,

![image](https://user-images.githubusercontent.com/69035383/170290650-0532537c-3631-4a61-8674-a3488ec4e171.png)

En esta linea variantMapping[variant] no se lee nunca porque las propiedades quedan sobre escritas.
https://github.com/mui/material-ui/blob/92a4866ce9a06769592cddc06cfa7455b4644544/packages/mui-material/src/Typography/Typography.js#L121



### Expected behavior 🤔

Que variantMapping funcione de manera correcta, sin tener que usar la api de componentes.

### Steps to reproduce 🕹

 Crear un tema y probar las opciones de typography con diferentes api
typography: {

    fontFamily: "libre franklin",
    "em":styleText(400 ,{name: "backgroundColor", value:"lawngreen"}),
    /*
    variantMapping: {
      "em": 'em',
    },*/
    defaultProps: {
      variantMapping: {
        "em": 'em',
      },
    },

  },

  components: {
    MuiTypography: {

      variants: [
        {
            props: { variant: 'mark' },
            style: {
              backgroundColor:"lightskyblue",
            },
        },
      ],
/*    Nofunciona
      variantMapping: {
        "mark": 'mark',
      },
*/
      defaultProps: {
        variantMapping: {
          subtitle1: 'header',
          subtitle2: 'header',
          "mark": 'mark',
          "em": 'em',
        },
      },
    },
  },

### Context 🔦

Al ver porque usabais defaultProps me di cuenta de este error.

### Your environment 🌎

_No response_
Repository: pytorch
Issue: [CI] Detect when tests are no longer running from CI
Labels: module: ci,triaged

### 🐛 Describe the bug

A few days ago (as of 5/25), the mac CI tests stopped running as a result of a yml change that broke GHA parsing (see https://github.com/pytorch/pytorch/pull/78000). 

The scary part is that we only noticed it days later, and there was no automatic mechanism warning us that the test was missing. We should have such a mechanism.

How we can detect when this happens next time:
1. We could warn when the number of test cases run for a commit has dropped significantly even when there are no pending jobs 
2. We could warn when the number of workflow jobs run for a commit has dropped from the previous workflow run

How should we warn?
- Send an email to OSS CI oncall
- Auto create an issue and tag module: ci and high-priority
- Configure an alert that looks different from our other alerts

### Versions

CI

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: pytorch
Issue: pytorch-android-lite use its own libfbjni.so, which is not compatible with any other version at all..
Labels: module: binaries,triaged,module: android

### 🐛 Describe the bug

Wanted to have react-native and pytorch lite together in one project.

Already wasted 2 full working days on that, only to find out the root problem (well, there are 2).

The first problem is that strange "0.0.3" version of fbjni, which NEVER existed (and should never). If you go to the fbjni page, you will also see, there was NEVER a release of 0.0.3. Yet, someone uploaded to maven and enough are referencing to it.

0.2.2 should be the version, where react-native >=0.65 and pytorch(lite) should work together, if pytorch lite didnt change the library itself and then break everything else, as you cannot say which .so it should use. Just "pickFirst (woow at android gradle for that)".

Just make a small demo pytorch android lite project and then change your implementation to that (in build.gradle) :

    implementation 'com.facebook.fbjni:fbjni:0.2.2' //(not java-only, really that one)
    implementation ('org.pytorch:pytorch_android_lite:1.12'){
        exclude module:'fbjni'
        exclude module:'fbjni-java-only'
        exclude module:'soloader'
        exclude module:'nativeloader'
    }
Also dont forget to say "which" .so it should pick
android {
     packagingOptions {
        pickFirst "**/*.so"
    }
}

Try to start your demo project now and it will just crash with that:
cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.planradar.demoML-IK4F5CYrCuaaR7Csu8YHzQ==/lib/arm64/libpytorch_jni_lite.so"

Then just REMOVE the exclude parts and also remove the import of fbjni0.2.2. Then build your app again and it works again..

Basically your dependency says, it needs fbjni:0.2.2 (which is true), but you somehow change the library itself, resulting in a bigger .so file.

The problem is, that when using react-native together, it always picks the "wrong" one. So the one with 170kb. React-native starts fine, but pytorch just crashes.

I replaced the .so file manually (apktool and signing) and then react-native and pytorch are starting fine.

### Versions

Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.5 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.23.1
Libc version: glibc-2.26

Python version: 3.7.5 (default, Feb 23 2021, 13:22:40)  [GCC 8.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-74-generic-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: N/A
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.20.3
[conda] Could not collect



PS.: I tested with pytorch android lite 1.11 and 1.12

cc @ezyang @seemethere @malfet
Repository: pytorch
Issue: Request for adding the possibility for training on sparse tensors
Labels: module: sparse,triaged

### 🚀 The feature, motivation and pitch

I'm working on tensors that most of the cells are 0's and some cells are 1's, say `100` 1's out of `50^3` 0's.
I tried to use [turn tensor into sparse tensor](https://pytorch.org/docs/stable/generated/torch.Tensor.to_sparse.html#torch-tensor-to-sparse) in order to turn my tensors into sparse ones.
The problem is that I can't use them in order to propagate inside a neural network for training and I'm getting the error message: `RuntimeError: Input type (torch.cuda.sparse.FloatTensor) and weight type (torch.cuda.FloatTensor) should be the same`.
It would be great if there be a possibility for training on sparse tensors too.

Thank you

### Alternatives

_No response_

### Additional context

_No response_

cc @nikitaved @pearu @cpuhrsch @amjames
Repository: storybook
Issue: Uncaught TypeError: dispatcher.useInsertionEffect is not a function
Labels: bug,needs triage

**Describe the bug**
I'm created a project using rollup the project is basically a library out of which I'm exporting some reusable componnents.
I tried installing storybook, did npx story book init after that I did npm run story book, It opened the browser with a blank white page when I opened console to check for errors I spot different types of errors coming up on console and the most repetitive one was Uncaught TypeError: dispatcher.useInsertionEffect is not a function.
Apart from that few other errors were : 
vendors~main.manager.bundle.js:97153 The above error occurred in the <EmotionGlobal> component:
vendors~main.manager.bundle.js:97153 The above error occurred in the <Insertion> component:

My rollup.config.js
`import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
import typescript from "@rollup/plugin-typescript";
import dts from "rollup-plugin-dts";
import postcss from "rollup-plugin-postcss";
const packageJson = require("./package.json");

export default [
  {
    input: "src/index.ts",
    output: [
      {
        file: packageJson.main,
        format: "cjs",
        sourcemap: true,
      },
      {
        file: packageJson.module,
        format: "esm",
        sourcemap: true,
      },
    ],
    plugins: [
      resolve(),
      postcss({
        minimize: true,
        modules: true,
        use: {
          sass: null,
          stylus: null,
          less: { javascriptEnabled: true },
        },
        extract: true,
      }),
      commonjs(),
      typescript({ tsconfig: "./tsconfig.json" })
    ],
  },
  {
    input: "dist/esm/types/index.d.ts",
    output: [{ file: "dist/index.d.ts", format: "esm" }],
    plugins: [dts()],
    external: [/\.css$/],
  },
];
`
Repository: vscode
Issue: Push users to file issues on extensions
Labels: feature-request,issue-reporter

Feels like I’ve had so many notifications for new caused-by-extension issues lately, usually from the issue reporter. I wonder if we could include one more hint here, like in the “Please enter details” placeholder. “If this is an issue with an extension, please select ‘File on: An extension’ above”

![image](https://user-images.githubusercontent.com/323878/170325017-7f072a01-6ccb-48da-8e81-aee2493aa4d5.png)
Repository: godot
Issue: Can't drag and drop image with capitalized extension.
Labels: bug,topic:editor,needs testing,topic:import

### Godot version

v4.0.alpha8.official [cc3ed63af]

### System information

Linux Mint 20

### Issue description

I used Krita's Export Layers option, which uses capitalized letters in extension name, and couldn't drag and drop images into scene.
Adding Sprite2D and setting texture manually works fine.

### Steps to reproduce

-Import a file with capitalized PNG extension
-Try to drag and drop an image into scene

### Minimal reproduction project

_No response_
Repository: rust
Issue: "error[E0119]: conflicting implementations of trait" resolves same trait in different ways?
Labels: A-diagnostics,T-compiler


```rust
#[derive(Debug, PartialEq, PartialEq)]
struct A;
```

The current output is:

```
error[E0119]: conflicting implementations of trait `std::marker::StructuralPartialEq` for type `A`
 --> src/main.rs:1:28
  |
1 | #[derive(Debug, PartialEq, PartialEq)]
  |                 ---------  ^^^^^^^^^ conflicting implementation for `A`
  |                 |
  |                 first implementation here
  |
  = note: this error originates in the derive macro `PartialEq` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0119]: conflicting implementations of trait `std::cmp::PartialEq` for type `A`
 --> src/main.rs:1:28
  |
1 | #[derive(Debug, PartialEq, PartialEq)]
  |                 ---------  ^^^^^^^^^ conflicting implementation for `A`
  |                 |
  |                 first implementation here
  |
  = note: this error originates in the derive macro `PartialEq` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0119`.
error: could not compile `c` due to 2 previous errors
```
I would expect "PartialEq` and `PartialEq` to actually refer to the same trait :upside_down_face:  but for the diagnostic, rustc seems to search for other/similarly named traits...?
Does this make sense here?

Would it make sense to warn "you already derived this trait here <span>" or something like that?
Repository: neovim
Issue: normal commands structured map ("introspection" / "meta")
Labels: enhancement,documentation,api,vimscript

## Feature description

I need a structured version of `index.txt` which lists the available mappings, by mode, plus documentation, to support [a plugin I'm working on](https://github.com/linty-org/key-menu.nvim).

I've done a first pass JSONifying `index.txt`, the JSON is [here](https://github.com/linty-org/key-menu.nvim/blob/fe5ab88f21c14088476d3dd855d9fbd6b60f30a2/index.json). I can/will just include this in my plugin source for now, but:

I'm wondering, is this something we want to upstream? The structured version of this data could be used to generate the `:help` file, and programmatic access to this data would be useful for plugin authors. For example, it could be used to implement a clone of Emacs's `<C-h>k`. If so, does the core team have thoughts about where it should go?
Repository: flutter
Issue: Building a new_gallery with a local profile or release engine fails
Labels: platform-android,tool,engine,t: gradle,P2,team-android,triaged-android

But it succeeds if you remove the deferred components.

Seems like there's something wrong with deferred component logic when using a local engine.

This makes it harder to test performance experiments in local engine builds on Android.
Repository: deno
Issue: deno fmt issue
Labels: bug,deno fmt

Hi,

I got an error trying to format a js file that is seemingly valid (generated by babel and webpack, loads in the browser fine). Is there a way to fix this and format my code properly?
I am very concerned about the line that says "_Formatting not stable. Bailed after 5 tries. This indicates a bug in the formatter where **it formats the file differently each time**_".

Does that mean the formatter is not deterministic?

## Backtrace

`RUST_BACKTRACE=1 deno fmt main.js`
```
============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: linux x86_64
Version: 1.22.0
Args: ["deno", "fmt", "main.js"]

thread 'tokio-runtime-worker' panicked at 'Formatting not stable. Bailed after 5 tries. This indicates a bug in the formatter where it formats the file differently each time. As a temporary workaround you can ignore this file.', cli/tools/fmt.rs:458:11
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/core/src/panicking.rs:143:14
   2: tokio::runtime::task::raw::poll
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```
<hr>

I really like the deno formatter and I use it for all my JS projects, deno or not because it uses sane settings (two spaces, splits a line if it's too long, etc...). It's literally the first time it's failed me.

Thanks for your help.

**EDIT:** forgot to say that the error **is** in fact reproducible. It's not just a one-time bug.
Repository: pytorch
Issue: TRACK: integral + floating inputs to an op with floating requiring grad result in INTERNAL_ASSERT
Labels: module: autograd,triaged,actionable

### 🐛 Describe the bug

This is the tracking of the issues that "integral + floating inputs to an op with floating requiring grad result in INTERNAL_ASSERT"

- tensordot #77517
- addmv #77814 
- mv #77814 
- bilinear #78087 
- matmul #78141 
- mm #78141 
- baddmm #78143 
- index_fill #78443
- layer_norm #78444

### Versions

pytorch: 1.11.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7