sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Provide const generics hints when a token is forgotten
Labels: A-diagnostics,A-parser,T-compiler,A-const-generics,D-newcomer-roadblock,const-generics-bad-diagnostics

Ideally, `rustc` should guide the user towards producing const generics code, even if they forget the `const`, the type, or both.

Given the following code:

```rust
// forgot type
impl<T, const N> From<[T; N]> for VecWrapper<T>
where
    T: Clone,
{
    fn from(slice: [T; N]) -> Self {
        VecWrapper(slice.to_vec())
    }
}
```

(All examples are in https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4a11f9dad9f8069e70f2aea6cb4084ad )

The current output is:

```
error: expected `:`, found `>`
  --> src/lib.rs:25:16
   |
25 | impl<T, const N> From<[T; N]> for VecWrapper<T>
   |                ^ expected `:`
```

Ideally the output should look like:
- expected `: Type`
- maybe a hint for the `usize` type, because that's the type of `N` in `[T; N]`

Similarly:
```rust
// Forgot const 
impl<T, N: usize> From<[T; N]> for VecWrapper<T>
where
    T: Clone,
{
    fn from(slice: [T; N]) -> Self {
        VecWrapper(slice.to_vec())
    }
}
```

Produces:
```
error[E0423]: expected value, found type parameter `N`
  --> src/lib.rs:15:28
   |
15 | impl<T, N: usize> From<[T; N]> for VecWrapper<T>
   |                            ^ not a value

error[E0404]: expected trait, found builtin type `usize`
  --> src/lib.rs:15:12
   |
15 | impl<T, N: usize> From<[T; N]> for VecWrapper<T>
   |            ^^^^^ not a trait

error[E0423]: expected value, found type parameter `N`
  --> src/lib.rs:19:24
   |
19 |     fn from(slice: [T; N]) -> Self {
   |                        ^ not a value
```

Ideally the output should look like:
- expected `const` with a hint

And:
```rust
// forgot const and type
impl<T, N> From<[T; N]> for VecWrapper<T>
where
    T: Clone,
{
    fn from(slice: [T; N]) -> Self {
        VecWrapper(slice.to_vec())
    }
}
```

Produces:
```
error[E0423]: expected value, found type parameter `N`
  --> src/lib.rs:25:21
   |
25 | impl<T, N> From<[T; N]> for VecWrapper<T>
   |                     ^ not a value

error[E0423]: expected value, found type parameter `N`
  --> src/lib.rs:29:24
   |
29 |     fn from(slice: [T; N]) -> Self {
   |                        ^ not a value
```

Ideally the output should look like:
- expected `const N: Type`
- maybe a hint for the `usize` type, because that's the type of `N` in `[T; N]`

```sh
$ rustc --version
rustc 1.53.0-nightly (392ba2ba1 2021-04-17)
```
Repository: godot
Issue: PanoramaSkyMaterial has artifacts at top and bottom due to the texture repeating
Labels: bug,topic:rendering,confirmed,topic:3d

**Godot version:**
4.0.dev 837b5da6a

**OS/device including version:**
Windows 10

**Issue description:**
I assigned a gradient as a texture for panorama (from an image, because GradientTexture still doesn't support vertical gradients)

You can see here there is a dot at the bottom of the skybox (at the top, there is an inverse dot for the same reason.

![image](https://user-images.githubusercontent.com/39946030/115172008-2c522500-a079-11eb-92ca-97efb434e40e.png)

Here is the image: ![bwgrad](https://user-images.githubusercontent.com/39946030/115172114-615e7780-a079-11eb-9bd7-b881ef0649ed.png)

Godot 3 renders this correctly.

I think the correct behavior is Y-repeat should be turned off, and X-repeat should be enabled...

Also, I suspect the panorama was not imported with the correct sRGB settings. it looks different compared to Godot 3.

**Steps to reproduce:**
1. From a new project, create a new WorldEnvironment. Make an Environment. Make a Sky. Make a PanoramaSkyMaetrial. Make a Panorama and assign the [https://user-images.githubusercontent.com/39946030/115172114-615e7780-a079-11eb-9bd7-b881ef0649ed.png](above sky gradient texture) to it.
2. Look straight up or down.
3. Godot 4 shows dots at top and bottom.

**Minimal reproduction project:**
Repository: transformers
Issue: Getting time offsets of beginning and end of each word in Wav2Vec2
Labels: Good First Issue,Good Second Issue

# 🚀 Feature request

Hello I was thinking it would be of great help if I can get the time offsets of start and end of each word .

## Motivation
I was going through Google Speech to text documentation and found this  [feature](https://cloud.google.com/speech-to-text/docs/async-time-offsets) and thought will be really amazing if i can have something similar here. 

<!-- Please outline the motivation for the proposal. Is your feature request
     related to a problem? e.g., I'm always frustrated when [...]. If this is related
     to another GitHub issue, please link here too. -->

## Your contribution

I can really use some help in this task and would love to implement something similar. 

<!-- Is there any way that you could help, e.g. by submitting a PR?
     Make sure to read the CONTRIBUTING.MD readme:
     https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md -->
Repository: pytorch
Issue: logcumsumexp (and maybe other cum* ops) has divergent CUDA and CPU out= behavior
Labels: module: cuda,triaged,module: safe resize

It has been observed that cum* ops behaving different on CPU and CUDA. 

https://github.com/pytorch/pytorch/blob/ffdecc1ac48baf6aea3848e9f530256342a7046b/torch/testing/_internal/common_methods_invocations.py#L4602

The operator logcumsumexp fails to warn when resizing out= on CUDA. Analysis of the code shows logcumsum calls https://github.com/pytorch/pytorch/blob/158cdece65a9599656f788f926e7b835845e9f77/aten/src/ATen/native/cpu/ReduceOpsKernel.cpp#L23  on CPU, which is calling resize_output() function. However, the operator calls https://github.com/pytorch/pytorch/blob/d2784c233bfc57a1d836d961694bcc8ec4ed45e4/aten/src/ATen/native/cuda/ScanKernels.cu#L546 on CUDA that is not calling the function resize_output().

This can suggest an opportunity to refactor the code so that both the CPU and CUDA use more code in common to prevent issues like this in the future.

cc @ngimel
Repository: pytorch
Issue: [NNC] All NNC APIs should return bool flag
Labels: NNC

Most of the APIs in NNC throw exceptions. This is not ideal for using these transformations. 

Instead, all the APIs should be returning a boolean flag to indicate if the transformation was successful and not throw exceptions. They could throw exceptions when given an IR that is invalid. Also, the APIs could return true even if the transformation is not necessary for the given input.

The following guarantees should hold for all APIs:
* Given a valid IR, the APIs should never throw exceptions.
* When an API returns true, the resulting IR will always conform to the transformed output.
   - This could happen in 2 ways. 1) The transformation was applied successfully. OR 2) The transformation was not needed since the input IR already conforms to the result form.
Repository: pytorch
Issue: Support for stereo audio data in from torch.utils.tensorboard.SummaryWriter
Labels: feature,triaged,module: tensorboard,module: data

## 🚀 Feature
Accept stereo data for the SummeryWriter.add_audio() method in pytorch, which only accepts mono audio for now.

## Motivation

Feature compatibility with tensorboard.


cc @VitalyFedyunin @ejguan
Repository: flutter
Issue: Scroll Down/Up not working with iOS Voice Control
Labels: platform-ios,framework,engine,a: accessibility,customer: money (g3),has reproducible steps,P2,found in release: 2.0,found in release: 2.2,team-ios,triaged-ios

b/226078425

When using Voice Control on iOS it is not possible to scroll a ListView by saying "scroll down" or "scroll up". When saying the commands the bubble with the info scroll down/up indicates that the command was received and understood. However no scrolling happens. When saying "swipe down" or "swipe up" the list is scrolling. Scrolling works fine with Android Voice Access.

Steps to reproduce :
```
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatelessWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('scroll demo'),
      ),
      body: ListView(
        children: getList(),
      ),
    );
  }

  List<Widget> getList() {
    List<Widget> _list = [];
    for (int i = 0; i < 20; i++) {
      _list.add(DemoTile(i + 1));
    }
    return _list;
  }
}

class DemoTile extends StatelessWidget {
  final int number;
  DemoTile(this.number);
  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: const EdgeInsets.all(36.0),
      child: TextButton(
        child: Text('This is Tile number $number'),
        onPressed: () {
          print('pressed : $number');
        },
      ),
    );
  }
}
```

https://user-images.githubusercontent.com/25162677/115225172-0fb3fc80-a10e-11eb-9a40-f2b502fc2375.mov


Turn on Voice Control on iOS, verify that "Scroll down" and "Scroll up" are enabled in Settings/Accessibility/Voice Control/Customise Commands/Basic Gestures and try to say the commands "scroll down" or "scroll up".
Repository: pytorch
Issue: Acquiring "is_grad_enabled()" inside an autograd function 
Labels: feature,module: autograd,triaged,module: custom-operators,actionable

## 🚀 Feature
Acquiring whether gradient is enabled in a custom autograd function would be very useful. Currently such information can not be obtained.

## Motivation
Custom autograd functions (i.e. by inheriting `torch.autograd.Function`) is frequently used in Pytorch. To write a custom autograd function, we will implement two static methods: `forward` and `backward`. Currently in the `forward` function, the gradient is automatically disabled and `is_grad_enabled()` always returns false. So we can not know whether `backward` will be called later.

In some situations such information would be very useful, especially for speeding up the calculation. For example, consider the `max` function in Pytorch. If we need to calulate the gradient of `max`, we must save the index that achieves maximum, since the gradient is non-zero only at the saved index. On the other hand, if we know in advance that we do not need to calculate gradient, then the implementation can be significantly simplified so that only a max-reduction is needed. This can be much faster than calculating the maximum and the index that achieves maximum.

Another situation is the `sort` function that sorts an array. If we know in advance that we do not need to calculate the gradient, then we do not need to save the rank of each element. This again speeds up the running time significantly.

## Pitch

It would be very nice if Pytorch can provide a function to acquire whether gradient is enabled inside the `forward` method of a custom autograd function.

## Alternatives

Currently I has no idea how to achieve above goal. So the forward implementation is slow even if I know I do not need to calcualte gradient.

## Additional context

Here is the pseudo-code about the feature metioned above (using the `max` example):

```
class Max(torch.autograd.Function):
    @staticmethod
    def forward(ctx, x):
        if not torch.is_grad_enabled(): # Currently it always returns false.
            return x.max() # only calculate the maximum, which is fast
        y, index = x.max(dim=0) # calculate both the maximum and the index, which is slow
        ctx.save_for_backward(x, index)
        return y

    @staticmethod
    def backward(ctx, grad):
        x, index = ctx.saved_tensors
        res = torch.zeros_like(x)
        res[index] = grad
        return res

```

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer
Repository: go
Issue: x/tools: please add heap dump viewer
Labels: NeedsInvestigation,FeatureRequest

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.2 linux/amd64
</pre>



### What did you do?

My go program consume large memory. I want to know which type of object consumes a lot of memory.

I have tried pprof to analyze heap, it shows which method consumes a lot of memory.  But a lot of goroutines have the same traceback that contains this method, each of these goroutines process different type object, I couldn't find which type of object consumes a lot of memory.

### What did you expect to see?

A tool can be used to analyze heap dump

#16410
Repository: godot
Issue: `JavaClass.new().get_class()` returns `null` instead `JavaClass`
Labels: bug,topic:core

**Godot version:**
3.3.rc.custom_build. 8dd6fd058


**OS**
Ubuntu 20.04 - Ubuntu 3.36 X11

**Issue description:**
Executing
```
print(Node2D.new().get_class())
print(JavaClass.new().get_class())
```
prints
```
Node2D
Null
```
but every object should print properly name of its class
Repository: neovim
Issue: TUI: kitty's keyboard protocol support
Labels: enhancement,tui,input

<https://sw.kovidgoyal.net/kitty/keyboard-protocol/>

- [x] Enable kitty's keyboard protocol #18181
- [x] Recognize keys in private use area #19180
- [x] Recognize <kbd>Super</kbd> modifier #24357
- [ ] Add notations for keys and modifiers not yet present in Nvim?
- [ ] Enable higher progressive enhancement levels?
Repository: godot
Issue: [Bullet] Concave collision shapes not working with areas 
Labels: bug,topic:physics,topic:3d

**Godot version:**
3.2.3 and 3.3 rc9

**OS/device including version:**
Windows 10, Nvidia GeForce RTX 2060/PCIe/SSE2

**Issue description:**
Areas with concave collision shapes (generated in Godot via the editor) don't detect collisions. If you use the same shape for a StaticBody it works however. I also tested this with GodotPhysics and it works there, so it's a Bullet-only related issue. 

**Concave** collsion shape (created with "Create Trimesh collision sibling" in the editor):
![concave](https://user-images.githubusercontent.com/8750135/115267109-186df800-a139-11eb-8fde-b0c71231bd71.gif)

**Convex** collsion shape (created with "Create Single Convex collision sibling" in the editor):
![convex](https://user-images.githubusercontent.com/8750135/115267286-4b17f080-a139-11eb-92fa-4660ac6f5f3f.gif)

**Steps to reproduce:**
- Create a bunch of cubes in Blender and export as obj
- Generate convex and concave collision shapes
- Add both shapes to an area and disable one while keeping the other enabled
- Concave shape detects bodies, convex shape does not

**Minimal reproduction project:**
Same MRP as in gifs: [AreaConcaveCollisionBug.zip](https://github.com/godotengine/godot/files/6337488/AreaConcaveCollisionBug.zip)

![mrp](https://user-images.githubusercontent.com/8750135/115268093-2bcd9300-a13a-11eb-8023-a3c62ebcb024.png)
Repository: storybook
Issue: Custom control type matchers should support all control types
Labels: feature request,addon: controls

**Is your feature request related to a problem? Please describe**

[Custom control type matchers](https://storybook.js.org/docs/react/essentials/controls#custom-control-type-matchers) are a useful feature, but would be much more useful if they supported _all_ control types, instead of just "color" and "date".

For example, our component library uses lots of props named `*Props` (e.g. `InputProps`), as it is built on [material-ui](https://material-ui.com/api/text-field/#props). All of those should use the "object" control type, but the inferred type is the default "JSON string".

**Describe the solution you'd like**

Something like `type Matchers = Record<keyof SupportedControlTypes, Regex>`, and supporting code.

**Describe alternatives you've considered**

This is a convenience feature, as consumers can define the control type for each individual prop, currently.

**Are you able to assist to bring the feature to reality?**

Yep. Happy to submit a PR. Looks like [this might be a good starting point](https://github.com/storybookjs/storybook/blob/next/lib/client-api/src/inferControls.ts#L19-L26), and would consider changes to tests/docs, as well.

**Additional context**
Add any other context or screenshots about the feature request here.
Repository: create-react-app
Issue: react-scripts start unhandled rejection handling makes missing dependencies painful to debug
Labels: needs triage,issue: bug report

```js
// react-scripts/scripts/start.js
//L15
// Makes the script crash on unhandled rejections instead of silently
// ignoring them. In the future, promise rejections that are not handled will
// terminate the Node.js process with a non-zero exit code.
process.on('unhandledRejection', err => {
  throw err;
});
```

when you're missing a dependency you get an error and a crash

```bash
/node_modules/react-scripts/scripts/start.js:19
  throw err;
  ^

[Error: ENOENT: no such file or directory, stat '/initrd.img'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'stat',
  path: '/initrd.img'
}
npm ERR! code ELIFECYCLE
npm ERR! errno 1
```

when you remove `process.on('unhandledRejection', err => {  throw err; });` it gives you a much more useful error and doesn't crash

```js
Failed to compile.

./node_modules/[redacted]/dist/index.modern.js
Module not found: Can't resolve 'framer-motion' in '/home/[redacted]/node_modules/[redacted]/dist'
```

that small addition of code makes things much harder to debug when simply missing a peer dependency or something similar and could stop people dead in their tracks.  maybe it should be removed until a better way of handling it can be thought of?
Repository: pytorch
Issue: Tests in CI are run from the test/ directory
Labels: module: docs,module: tests,triaged

Currently, [the "Python Unit Testing" section of `CONTRIBUTING.md`](https://github.com/pytorch/pytorch/blob/ca6e5c7fc9244ace874bb99aacb12eddef5d4f8a/CONTRIBUTING.md#python-unit-testing) suggests running test files from the repo root directory:

> ```bash
> python test/test_jit.py
> ```

> ```bash
> python test/test_jit.py TestJit.test_Sequential
> ```

> ```bash
> pytest test/test_nn.py -k Loss -v
> ```

However, as noted in #56388, this is (surprisingly) not what `test/run_test.py` does: that script sets the working directory to `test/` before running the test file. This discrepancy between CI and developer testing practices can and has caused subtle bugs to crop up (for example, #56388).

The goal of this GitHub issue is to

1. document why exactly we don't run tests from the repo root directory, and
2. hopefully come up with a solution to bring `test/run_test.py` back in line with `CONTRIBUTING.md`.

cc @brianjo @mruberry @VitalyFedyunin @walterddr @pytorch/pytorch-dev-infra @ansley
Repository: pytorch
Issue: Figure out what mojo FB common/process/StackTrace.h has that we don't
Labels: module: internals,triaged,better-engineering

I have observed that in FB-internal builds, the implementation of stack trace printing in common/process/StackTrace.h is superior to the native implementation in c10/util/Backtrace.cpp in that it is able to symbolize more symbols than we are able to.

For now, I'm going to stem the bleeding by making sure fbcode builds use this better implementation, but ultimately we should figure out what's going on (it's probably related to DWARF) and apply it to our implementation.

cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh @ailzhang @driazati
Repository: flutter
Issue: Allow recording a "profile" of what widgets are built and regions of the screen are repainted
Labels: c: new feature,tool,c: performance,P3,team-tool,triaged-tool

Today we may provide some high level build stats of what widgets are being rebuilt, and we also allow taking profiles with debug widget builds. I'm less familiar with the former, but the latter has the problem that widget `self` time is not particularly interesting, but has the unfortunate side effect of slowing down the build.

We could create a toggleable "profile" mode which only recorded _which_ widgets are rebuilt, along with information about which regions of the screen are re-pained. In combination with some post processing, this could help users understand what parts of an animation are expensive and could be simplified.

This would be exposed via a service extension toggle and then potentially a devtools UI
Repository: TypeScript
Issue: inferred generic incorrectly widened
Labels: Suggestion,In Discussion

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms
inferred generic widened
<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

### 🕗 Version & Regression Information
4.3.0-beta

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.3.0-beta&ssl=1&ssc=1&pln=3&pc=35#code/C4TwDgpgBAYg9nAPAFShAHsCA7AJgZymwFcBbAIwgCcA+KAXilQyz0IEtsAzaqAJQD8UAEIBDKoj40AXEQgA3XgHolAYzikw7ADbRqVOFVnJw0AOR8zUXHAiFscYFHyjg7fFxBRgAC2jrsfGAqUU4nMxIKajMAKBjQSBFxFDRMHAIiMkpaBjlFKiA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
type Foo<T extends number> = T extends infer R? Bar<R>: never //compile error: Type 'R' does not satisfy the constraint 'number'

type Bar<T extends number> = never
```

### 🙁 Actual behavior
`R` was incorrectly widened to no longer be a `number`, even though it was inferred from `T` which is a `number`
<!-- What happened, and why it was wrong -->

### 🙂 Expected behavior
no error, as `R` is a number
<!-- What you expected to happen instead, and why -->
Repository: rust
Issue: Incremental compilation ICE with `predicates_of`
Labels: I-ICE,E-needs-test,T-compiler,A-incr-comp,C-bug,E-needs-mcve

Anyone encountering this issue (or an issue linked here) can run either `cargo clean` or `cargo clean -p <your_package_name>` as a temporary workaround.

Since https://github.com/rust-lang/rust/pull/83007 was merged, we now ICE during incremental compilation when the hash of a re-computed query result does not match the hash from a previous session.

There have been a very large number of bug reports, all involving `predicates_of`:
* https://github.com/rust-lang/rust/issues/84336
* https://github.com/rust-lang/rust/issues/84237
* https://github.com/rust-lang/rust/issues/84116

There are several common characteristics across these issues
* All of them involve calling `predicate_of` on a trait from *the standard library*, not user code.
* All of them involve remapped paths pointing into the local standard library source code.

I've been able to reproduce similar crashes to these by adding or removing the `rust-src` component between  compilation sessions