sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: SyntaxError: Unexpected token 'function' when using a Big.js type
Labels: question / support,compatibility with other tools,inactive

**Describe the bug**
I've isolated the issue as far as I can. The issue seems to be that Storybook is crashing when instantiating a component who has a type `Big` (https://mikemcl.github.io/big.js/).

**To Reproduce**
Steps to reproduce the behavior:

#### Component (BugTest.tsx)
```typescript
import React from 'react';
import { Big } from 'big.js';

export interface BugTestProps {
  bigNumber: Big;
}

export default function BugTest({ bigNumber }: BugTestProps) {
  return <div>{bigNumber.toNumber()}</div>;
}
```

#### Story (BugTest.stories.tsx)
```typescript
import React from 'react';
import { Story } from '@storybook/react/types-6-0';
import { Big } from 'big.js';
import BugTest, { BugTestProps } from './BugTest';

export default {
  title: 'BugTest',
  component: BugTest,
};

const bigNumber = new Big(123);

// This approach works
export const Works = () => <BugTest bigNumber={bigNumber} />;

// This approach breaks it (comment it out to see)
const Template: Story<BugTestProps> = args => <BugTest {...args} />;
export const Bugged = Template.bind({});
Bugged.args = {
  bigNumber,
};
```

**Expected behavior**
Storybook should render both approaches the same.

**Screenshots**
![image](https://user-images.githubusercontent.com/66535998/99573380-0cbcb080-29a4-11eb-8c38-9c349ed87b91.png)

**Code snippets**
If applicable, add code samples to help explain your problem.

**System**
Environment Info:

  System:
    OS: macOS 10.15.6
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 12.18.3 - ~/.nvm/versions/node/v12.18.3/bin/node
    Yarn: 1.18.0 - /usr/local/bin/yarn
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.3/bin/npm
  Browsers:
    Chrome: 86.0.4240.198
    Edge: 86.0.622.69
    Firefox: 77.0.1
    Safari: 14.0
  npmPackages:
    @storybook/addon-actions: 6.0.5 => 6.0.5 
    @storybook/addon-links: 6.0.5 => 6.0.5 
    @storybook/addon-storyshots: 6.0.5 => 6.0.5 
    @storybook/addons: 6.0.5 => 6.0.5 
    @storybook/core: 6.0.5 => 6.0.5 
    @storybook/react: 6.0.5 => 6.0.5 

**Additional context**
I suspect that the way the Big.js object is formatted is clashing with how Storybook is creating its stories in the templated approach. Specifically, the `Big` object has a `constructor` attribute that may be the culprit, but I haven't had time to really dig into the Storybook internal code to understand it.
Repository: godot
Issue: DualShock 4 controller not properly supported on macOS / Apple M1
Labels: bug,discussion,platform:macos,confirmed,topic:input

**Godot version:**
Godot Engine 3.2.3.stable.official

**OS/device including version:**
Mac OS Big Sur 11.0.0 & 11.0.1
Apple M1 Chip
PS4 Dualshock controller (wired or wireless)

**Issue description:**
Controller input is not detected after the first few frames of starting the game in both the editor and the exported Mac OS build.

**Steps to reproduce:**
1) Open attached reproduction project on a Mac OS Big Sur device
2) With controller plugged in, hold down the playstation "X"/"cross" button and play the project
3) "Hello world" should be printed in the console. If you press "X"/"cross" button again, it will not print
4) Unplug and re-plug the controller. If you re-plug the controller while holding "X"/"cross", the console will print "Hello world" once again.

**Minimal reproduction project:**
[Controller-bug.zip](https://github.com/godotengine/godot/files/5562435/Controller-bug.zip)
Repository: terminal
Issue: Evaluate different regular expressions we can use for URL detection
Labels: Issue-Bug,Area-UserInterface,Area-TerminalControl,Product-Terminal,Issue-Task,Priority-2

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment

```none
Windows build number: 10.0.20180.1000
Windows Terminal version (if applicable): 1.5.3142.0

Any other software? experienced in weechat running in screen on remote server connected by mosh running in WSL2 Ubuntu, though it shouldn't matter
```

# Steps to reproduce
1. Encounter `https://www.x-kom.pl/g-5/c/158-zasilacze-do-komputera.html?f[1775][52858]=1` string
2. Hold `ctrl` key while pointing it

Another example would be `https://en.wikipedia.org/wiki/Tibia_(video_game)`


# Expected behavior

Whole link should be detected, underlined and followed

# Actual behavior

`https://www.x-kom.pl/g-5/c/158-zasilacze-do-komputera.html?f` is detected, underlined and followed

for the second example `https://en.wikipedia.org/wiki/Tibia` gets detected
Repository: pytorch
Issue: "Found no NVIDIA driver" produces too much log
Labels: module: cuda,triaged

## 🐛 Bug
I am using libtorch cuda binaries in a project that can be run on a machine with/without GPU. When running in cpu-only machine, it throws a warning:

[W CUDAFunctions.cpp:100] Warning: CUDA initialization: Found no NVIDIA driver on your system. Please check that you have an NVIDIA GPU and installed a driver from http://www.nvidia.com/Download/index.aspx (function operator())

This warning is informative, but populates the server log as it prints a line for every single job. Right now, this warning arises from torch::manual_seed and some other functions. Can you disable this warning? 


## To Reproduce

Steps to reproduce the behavior:

1. Build a C++ program using libtroch-CUDA on a GPU-enabled machine
2. Run the executable on a CPU-only machine


## Environment
 - libtorch Version : 1.7
 - OS : Linux
 - How you installed libtorch : source
 - CUDA/cuDNN version: 10.2, 8.0.4



cc @ngimel
Repository: rust
Issue: HashMap reports zero capacity without freeing memory
Labels: A-collections,C-bug,T-libs

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

It's generally expected that when std collections return a capacity of zero, that they are not backed by any allocation. I believe this was also true for the HashMap prior to hashbrown, although I could be wrong.

In any case, whilst `HashMap::capacity()` is documented as a *lower bound* I still find it extremely surprising that it reports a capacity of zero without freeing its memory.

You can reproduce the issue with the following program (using mockalloc to detect the leaked memory):

```rust
use std::alloc::System;
use std::collections::hash_map::{DefaultHasher, HashMap};
use std::hash::BuildHasherDefault;

use mockalloc::Mockalloc;

#[global_allocator]
static ALLOCATOR: Mockalloc<System> = Mockalloc(System);

const NUMBERS: &[usize] = &[
    25, 38, 41, 42, 89, 115, 184, 237, 273, 286, 300, 326, 377, 413, 482, 536, 602, 650, 702, 746,
    750, 807, 810, 836, 960, 979, 982, 1007,
];

fn main() {
    let mut guard =
        HashMap::<String, (), _>::with_hasher(BuildHasherDefault::<DefaultHasher>::default());
    mockalloc::assert_allocs(|| {
        for &n in NUMBERS {
            let k = n.to_string();
            guard.insert(k, ());
        }
        for &n in NUMBERS {
            let k = n.to_string();
            guard.remove(&k);
            if guard.len() * 3 < guard.capacity() {
                guard.shrink_to_fit();
            }
        }
        eprintln!("Capacity: {}", guard.capacity());
        //guard.shrink_to_fit();
    });
}
```

Given these lines: 
```rust
if guard.len() * 3 < guard.capacity() {
    guard.shrink_to_fit();
}
```

I expected all the memory to be reclaimed by the end of the loop. However, this is not the case: the memory is only reclaimed if `shrink_to_fit()` is called an additional time.

IMO, the fix should be two-fold:
1) When the last element of a HashMap is removed, it should automatically clear out any tombstones so that the `capacity()` method is accurate again.

2) A new method should be introduced to obtain the upper bound on the capacity. At the moment code which attempts to shrink under-utilized hashmaps is broken, and it's not possible to fix this code without a new method.
Repository: pytorch
Issue: [FX] Write an inference optimization pass
Labels: triaged,module: fx

We should have a pass `prepare_for_gpu_inference(m : nn.Module) -> nn.Module` (or something similar) that will do things that will make a given model run faster on GPU in the inference scenario. The stages of this pipeline should include:

* FP16 conversion of the model
* Convert the model (and input) to NHWC layout
  * https://docs.nvidia.com/deeplearning/cudnn/api/index.html#cudnnConvolutionBiasActivationForward
  * https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/cudnn/Conv.cpp
* Fuse patterns like Conv-BN and Conv-BN-ReLU

And we should have documentation for this pass, particularly pointing out that the datatype change may change accuracy, so users should re-eval their model after they run it.

With this pass, we estimate there should be a ~2x latency improvement on small batches on V100 and A100 GPUs

cc @ezyang @SherlockNoMad @ngimel @Chillee
Repository: rust
Issue: Closure seemingly both implements and doesn't implement a trait
Labels: A-closures,C-bug

This is a bit of an odd issue that I ran into today, and one that I think is a bug in rustc but I'm not 100% certain. Given [this code](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a11f940ef5416e8f6ac664d98cf1d5c5):

```rust
trait Foo {}

impl<F> Foo for F where F: Fn(&i32) -> &i32 {}

fn take_foo(_: impl Foo) {}

fn main() {
    // Does not compile
    // take_foo(|a| a);
    // take_foo(|a: &i32| a);
    take_foo(|a: &i32| -> &i32 { a });

    // Does compile
    take_foo(identity(|a| a));
    take_foo(identity(|a: &i32| a));
    take_foo(identity(|a: &i32| -> &i32 { a }));

    fn identity<F>(t: F) -> F
    where
        F: Fn(&i32) -> &i32,
    {
        t
    }
}
```

this fails to compile with:

```
error[E0308]: mismatched types
  --> src/main.rs:11:5
   |
11 |     take_foo(|a: &i32| -> &i32 { a });
   |     ^^^^^^^^ one type is more general than the other
   |
   = note: expected reference `&i32`
              found reference `&i32`

error: aborting due to previous error
```

The perplexing part to me is that both calls to `take_foo` seem pretty equivalent, but the second compiles while the first does not. I've managed to get a variety of error messages trying to reduce this, the original project had a much more opaque "the trait bound is not satisfied" error. It may be the case though that the fix for the above snippet is the fix for the original snippet too though.
Repository: vscode
Issue: Emmet extension still partially relies on core functionality
Labels: bug,debt,emmet

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->

After #58600 is fixed, there is still the issue that part of the Emmet codebase relies on core functionality, rather than only on what is available within the VS Code API.

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: N/A
Repository: godot
Issue: Some Exported Fields/Properties Get Reset Periodically
Labels: bug,topic:editor,needs testing

I just started encountering this issue, but it's been reported previously (and never resolved):
https://www.reddit.com/r/godot/comments/7ehygb/just_me_or_are_exported_variables_really/
https://www.reddit.com/r/godot/comments/8rm3ta/exported_variables_tend_to_reset/
https://www.reddit.com/r/godot/comments/fc1yaz/problems_with_c_and_export_properties_resetting/

**Godot version:**
Reported in versions ranging from 2.1.x to 3.2.1

**OS/device including version:**
I've encountered this issue on windows. I don't know about the other people who've had the issue.

**Issue description:**
Sometimes exported fields will get reset upon running the scene (While it is open, I think). This is inconsistent! For me, it only happens about 1/3rd of the time I run the project with this particular scene open. I will set the exported properties (A string and a Vector2) to some values, build the project, and see them reset to their default values in the editor. The built project has the original values, but once I close and run the project again, it uses the reset values.

What's especially bizarre is how it works with my inheritance structure:
DamageArea<T> (Base) -> DamageShape -> OffsetDamageShape

DamageArea and OffsetDamageShape both have exported properties (Including a Vector2, in both cases). The properties of DamageArea always get reset together, but the properties of OffsetDamageShape never reset. They persist, as they are supposed to. Some nodes just use DamageShape script directly, while others use OffsetDamageShape.

I'm having this problem in C#, and of the three other reports I found, 1 is in C# and 2 are in GDScript.

I'm have tried:
-Abstract/non-abstract base class (Where the exported properties are)
-Moving exported properties to DamageShape class
-Making base class concrete type (i.e. DamageArea<T> -> DamageArea)
-Making properties into fields

None of it works. The exported properties on DamageArea<T> always reset after a few runs of the project while the scene is open. And I never have a problem with any other properties.

**Minimal reproduction project:**
My project I'm getting this on is not available for public use, but one person shared their project with the issue here (I haven't tried this one myself): https://github.com/mnemo88/godottesting
Repository: pytorch
Issue: Modifying values() tensor of COO tensor requiring grad throws an odd error message
Labels: module: sparse,module: autograd,triaged

```
a = torch.randn((2, 2)).to_sparse()
a.requires_grad_(True)
a.values()[0] = 0
: RuntimeError: sparse tensors do not have strides
```

While the error's statement is true it's not related to the issue. For example, this works fine when the tensor doesn't require grad:

```
a = torch.randn((2, 2)).to_sparse()
a.values()[0] = 0
a
: tensor(indices=tensor([[0, 0, 1, 1], [0, 1, 0, 1]]),
       values=tensor([ 0.0000,  0.8869, -0.3072, -0.9301]),
       size=(2, 2), nnz=4, layout=torch.sparse_coo)
```

Note that the error is kind of consistent with strided tensors:

```
a = torch.randn((2, 2), requires_grad=True)
a[0][0] = 0
a.sum().backward()
: RuntimeError: leaf variable has been moved into the graph interior
```

Although the error message in this case is, at best, hard to parse for non-experts. Note also that this error message appears when attempting to backward, not when making the assignment like in the sparse snippet. 

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @aocsa @mruberry
Repository: pytorch
Issue: Softplus differs depending on number of elements in tensor
Labels: module: nn,triaged

## 🐛 Bug

The output of `F.softplus` is different depending on the number of elements in the input tensor.

## To Reproduce
```
import torch
import torch.nn.functional as F
problem_value = -1.1052913665771484
A = torch.zeros(15)
A[0] = problem_value
assert F.softplus(A)[0] == F.softplus(A[0])
A = torch.zeros(16)
A[0] = problem_value
assert F.softplus(A)[0] == F.softplus(A[0]) # Error!
```
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

The value of softplus should not depend on the number of elements in the tensor.
In particular, the last line in the code sample above should not throw an error.

## Environment

PyTorch version: 1.7.0
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Mac OSX 10.15.7 (x86_64)
GCC version: Could not collect
Clang version: 12.0.0 (clang-1200.0.32.21)
CMake version: Could not collect

Python version: 3.8 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.2
[pip3] torch==1.7.0
[conda] blas                      1.0                         mkl
[conda] mkl                       2019.4                      233
[conda] mkl-service               2.3.0            py38hfbe908c_0
[conda] mkl_fft                   1.2.0            py38hc64f4ea_0
[conda] mkl_random                1.1.1            py38h959d312_0
[conda] numpy                     1.19.2           py38h456fd55_0
[conda] numpy-base                1.19.2           py38hcfb5961_0
[conda] pytorch                   1.7.0                   py3.8_0    pytorch


## Additional context

This was originally observed where the split between the number of elements in the tensor was much higher, say ~ 1000 and 20,000. It seems to depend both on the particular value (`problem_value` in my example) and the number of elements.

cc @ezyang @gchanan @zou3519 @bdhirsh @albanD @mruberry
Repository: node
Issue: patching Module.wrapper et al. breaks shebang stripping
Labels: module

* **Version**: v14.10.1
* **Platform**: Darwin Kernel Version 18.7.0: Mon Aug 31 20:53:32 PDT 2020; root:xnu-4903.278.44~1/RELEASE_X86_64 x86_64
* **Subsystem**: internal/modules/cjs

### What steps will reproduce the bug?

in file `test.js`:
```
#! /foo/bar/baz
console.log('ok')
```

then
```
$ node
> const Module = require('module')
> Module.wrapper = Module.wrapper
> require('./test')
/Users/jake/test.js:1
(function (exports, require, module, __filename, __dirname) { #! /foo/bar/baz
                                                              ^

Uncaught SyntaxError: Invalid or unexpected token
```

### How often does it reproduce? Is there a required condition?

always

### What is the expected behavior?

shebang line is stripped, no syntax error

### What do you see instead?

syntax error

### Additional information

Shebang lines are supposed to be stripped when loading modules. This was moved from `internal/modules/cjs` to V8, see https://github.com/nodejs/node/commit/702331be90

Also, loaded modules are wrapped in an IIFE to provide context; this originally used `Module.wrapper`, but was changed to use an internal `contextify` module, with a fallback to the old implementation if `Module.wrapper` is monkey-patched, see https://github.com/nodejs/node/commit/5f8ccecaa2

(I'm using Electron, which monkey-patches `Module.wrapper`, see https://github.com/electron/electron/commit/a4fcc32799)

However, the shebang change seems to have broken the monkey-patching support. In this case, the shebang line is not stripped in `internal/modules/cjs`, but the module is wrapped in an IIFE, so the shebang is now inside the IIFE.
Repository: flutter
Issue: bouncing physics with scrollview cause jank when scoll ends on 120hz screen
Labels: e: device-specific,platform-android,c: performance,f: scrolling,P2,team-engine,triaged-engine

use bouncing physics in scrollview on android high refresh rate devices
smooth when finger still on the screen, after i release my finger it jank at the last couple of fames, raster delay up to 32ms.
smooth when use scrollphysics.
![Screenshot_20201119-131613](https://user-images.githubusercontent.com/20534594/99624795-dea1a400-2a69-11eb-919d-38640ce91251.png)

```dart
import 'package:flutter/material.dart';

void main() {
  runApp(
    MaterialApp(
        debugShowCheckedModeBanner: false, home: Scaffold(body: MyApp())),
  );
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    int count = 30;

    return Scaffold(
      appBar: AppBar(),
      body: ListView.builder(
        itemCount: count,
        physics: BouncingScrollPhysics(),
        itemBuilder: (context, index) => ListTile(
          title: Text(index.toString()),
        ),
      ),
    );
  }
}

```
Repository: go
Issue: cmd/go: misleading "malformed module path" error with -m flag for wildcard patterns with versions
Labels: NeedsInvestigation,GoCommand,modules

`go list -m` supports module wildcards, and supports version queries. However, if you try to combine a wildcard with a version query, you currently get a misleading `malformed module path` error rather than the result of applying the query to each module in the build list that matches the wildcard.

```
example.com$ go version
go version devel +a14e7bf6d Wed Nov 18 06:29:09 2020 +0000 linux/amd64

example.com$ go mod init example.com
go: creating new go.mod: module example.com

example.com$ go get -d golang.org/x/text
go: downloading golang.org/x/text v0.3.4

example.com$ go list -m golang.org/x/...
golang.org/x/text v0.3.4
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e

example.com$ go list -m golang.org/x/text@latest
golang.org/x/text v0.3.4

example.com$ go list -m golang.org/x/...@latest
go list -m: golang.org/x/...@latest: malformed module path "golang.org/x/...": invalid path element "..."
```

CC @matloob @jayconrod