sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: create-react-app
Issue: Error migrating to Yarn 2
Labels: needs triage,issue: bug report

### Describe the bug

**`yarn install` fails when trying to migrate a clean just-created CRA app to the version 2 (Berry)**

### Which terms did you search for in User Guide?

These are marked as closed but guys keep reporting the same issue:

* https://github.com/yarnpkg/berry/issues/719
* https://github.com/yarnpkg/berry/issues/886

### Environment

```
  current version of create-react-app: 4.0.0
  running from C:\Users\milic\AppData\Local\Yarn\Data\global\node_modules\create-react-app

  System:
    OS: Windows 10 10.0.19041
    CPU: (8) x64 Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
  Binaries:
    Node: 12.19.0 - C:\Temp\yarn--1604428991134-0.7984384358311725\node.CMD
    Yarn: 1.22.10 - C:\Temp\yarn--1604428991134-0.7984384358311725\yarn.CMD
    npm: 6.14.8 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 86.0.4240.111
    Edge: Spartan (44.19041.423.0), Chromium (86.0.622.58)
    Internet Explorer: 11.0.19041.1
  npmPackages:
    react: ^17.0.1 => 17.0.1
    react-dom: ^17.0.1 => 17.0.1
    react-scripts: 4.0.0 => 4.0.0
  npmGlobalPackages:
    create-react-app: Not Found
```

### Steps to reproduce

```shell
yarn create react-app just-app --template typescript
cd just-app
npm install -g yarn
yarn set version berry
git add .
git commit -m "yarn version set to berry"
# at this point I tried to remove node_modules and yarn.lock but in vain
yarn install
```

### Expected behavior

Yarn migrates to the version *berry*, node_modules go to `.yarn/cache`.

### Actual behavior

The last command (`yarn install`) fails with the following output:

```
➤ YN0000: ┌ Fetch step
➤ YN0013: │ iferr@npm:0.1.5 can't be found in the cache and will be fetched from the remote registry
...
➤ YN0066: │ fsevents@patch:fsevents@npm%3A2.2.0#builtin<compat/fsevents>::version=2.2.0&hash=127e8e: Cannot apply hunk #1 (set enableInlineHunks for details)
...
➤ YN0000: └ Completed in 17s 59ms
➤ YN0000: Failed with errors in 36s 813ms
```

### Possible workaround

I tried to create a _berry_ structure from the beginning:

```shell
# create a higher-level directory
cd test
yarn set version berry

# this way CRA creates a nested directory and inherits the yarn version collecting the dependencies in `.yarn`
yarn create react-app just-app --template typescript
cd just-app

# but created this way, CRA does not start due to https://github.com/facebook/create-react-app/issues/9446
yarn start

#  -- Module not found: Your application tried to access react-refresh

```
Repository: godot
Issue: In RichTextLabel indent tags break the placement of meta/url tags if the text is long enough (wraps multiple lines)
Labels: bug,topic:gui

**Godot version:**
3.2.2


**OS/device including version:**
Windows 10


**Issue description:**
If you use an indent tag and a url tag in the same RichTextLabel, the click/hover area of the url tag will gradually shift farther and father out until it no longer aligns with the text.


**Steps to reproduce:**
1. Download the attached project.
2. Run it and hover over the meta text. Try hovering in the line under it to find its actual click/hover position.
3. Try removing the indent tag from text under BB code.
4. Run again and see the meta text function as normal.
5. You can try subtracting and adding text to see that the issue scales with the amount of text in the indented paragraph.

**Minimal reproduction project:**
[IndentBugs.zip](https://github.com/godotengine/godot/files/5483459/IndentBugs.zip)
Repository: vscode
Issue: Render new lines in suggest widget details
Labels: ux,suggest,under-discussion

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

In reference to the refinement here: https://github.com/microsoft/vscode/issues/109717#issuecomment-719440817
The details view in the suggest widget no longer shows the line breaks that the text authors intended for us to see. I think it should work like the mouse over hover text where it breaks the line up if it gets too long but also shows the actual line breaks in the text. See this example:
![image](https://user-images.githubusercontent.com/42123497/98030836-e4fd1280-1e11-11eb-8c48-90f9b02e1316.png)
Repository: go
Issue: x/tools/gopls: reinitialize snapshot eagerly and asynchronously
Labels: gopls,Tools

Currently, reinitialization of a snapshot is done by the next request to need an initialized snapshot. We should probably do the reinitialization eagerly and asynchronously, while making sure that it is canceled whenever a new snapshot is created.
Repository: pytorch
Issue: [Feature request] Stochastic Frank-Wolfe optimizer
Labels: feature,module: optimizer,triaged

Recently, the Frank-Wolfe (FW) Algorithm is becoming more and more popular in Neural Network training due to its versatility and robustness (see e.g. [[1]](https://arxiv.org/abs/2010.07243) or [[2]](https://arxiv.org/abs/2010.05397)). While researching the algorithm in the context of Machine Learning, I implemented the algorithm (and several variants) and would like to contribute it to the Pytorch project to enable further research.

**The main difference of FW-like algorithms to e.g. vanilla SGD is that FW is a constrained optimizer.** While the parameter space of SGD is unconstrained (e.g. the entire R^n), Frank-Wolfe moves towards the optimum by convex combinations within any feasible region, that could e.g. be an L2-ball (leading to behaviour similar to SGD with weight-decay), the L1-Ball (for obtaining sparse network representations) or any other convex set (say a polytope). A way to do this with SGD would be to project to the feasible set after each iteration, which can be very inefficient, depending on the feasible set itself.

In its most basic version, a single iteration of the algorithm can be stated as follows (here C is a convex feasible region):
![FW](https://user-images.githubusercontent.com/66726489/98033846-5c34a580-1e16-11eb-88d4-ba6d7f5a0890.png)

Hence, in each iteration the linear optimization problem in Line 1 has to be solved. In practice, this is not done by an LP solver but by a so-called linear minimization oracle (LMO), that is a function/class which efficiently yields the optimal solution without applying the Simplex algorithm or anything of the like. Note that for many useful feasible regions (e.g. Lp-Balls for p >=1), closed form solutions exist and hence this is not a problem. After solving the problem in Line 1, Line 2 is just a convex step towards the optimum and the new parameters are still within the feasible region. Many known features as e.g. momentum can be easily added (and are already implemented in my version). For a more detailed explanation see [[1]](https://arxiv.org/abs/2010.07243).

**This brings me to the main implementation issue which I would like to discuss here: Assuming that there's interest in the community to add FW to Pytorch, how should the LMO be passed to the optimizer? Personally, I see three possibilities, which I have implemented already:**

1. Pass an LMO once when the optimizer is initialized. This LMO defines a feasible region which holds for each tensor that is part of the parameters passed to the optimizer.
2. Pass a list of LMOs to the optimizer when initialized. This allows to define different feasible regions for each layer of a neural network.
3. Attach the LMO to a tensor as an attribute (e.g. `p.constraint = L2_Ball(radius=5)`) and then just let the FW-optimizer get the LMO in each call of `step()`.

Clearly, it would be also possible to pass the LMOs to the optimizer's `step()`-function in every iteration of training.

Please let me know if you have any questions or comments.
Thanks!


cc @vincentqb
Repository: flutter
Issue: Suggestion - Adding Shadow box list to CupertinoTabBar Component
Labels: framework,f: cupertino,c: proposal,team-design,triaged-design


Hey Flutter dev team,

I have been developing an application using only Cupertino components and compared to its Material counterpart, I have noticed that it is not possible for me to add an elevation to CupertinoTabBar. Taking a look at the base code I could see that it is possible to add a Shadowbox component inside Boxdecoration when building the component.

Result:
![image](https://user-images.githubusercontent.com/30813101/98036356-a6a72980-1df8-11eb-850d-f773a32730ca.png)
Repository: pytorch
Issue: Quantized modules should properly implement __getstate__ and __setstate__ (copy.deepcopy doesn't work on quantized model)
Labels: oncall: quantization,triaged

## 🐛 Bug

There are various modules in the quantized namespace which inherit from `nn.Module` and override `__getstate__` and `__setstate__`.  In some cases, the `__getstate__` and `__setstate__` methods do not properly get/set state of the parent `nn.Module`.  This leads to subtle bugs when attempting to copy or inspect these modules.  

An additional complication is that inspecting `self.__dict__` doesn't seem to be `torch.jit.script`'able, and attempts to generically fix this such as https://github.com/pytorch/pytorch/pull/45341 have been challenging to land.

Known affected modules include `nn.quantized.modules.Conv{1|2|3}d` and `nn.quantized.modules.LinearPackedParams`.

Creating this issue to consolidate reports of these problems, and track the eventual resolution.

## To Reproduce (one example)

```
import torch
import torch.nn as nn
import copy
m = nn.Sequential(nn.Linear(4, 4))
m = torch.quantization.quantize_dynamic(m, {torch.nn.Linear}, dtype=torch.qint8)
m = copy.deepcopy(m)
# inspecting the packed params on a copy does not work, because the `_parameters` attribute was not
# properly carried through __getstate__/__setstate__
dir(m[0]._packed_params)

...

ModuleAttributeError                      Traceback (most recent call last)
<ipython-input-44-a953e4f9af1f> in <module>
      7 # inspecting the packed params on a copy does not work, because the `_parameters` attribute was not
      8 # properly carried through __getstate__/__setstate__
----> 9 dir(m[0]._packed_params)

/mnt/xarfuse/uid-5731/e4b45e64-seed-nspid4026531836-ns-4026531840/torch/nn/modules/module.py in __dir__(self)
   1402         module_attrs = dir(self.__class__)
   1403         attrs = list(self.__dict__.keys())
-> 1404         parameters = list(self._parameters.keys())
   1405         modules = list(self._modules.keys())
   1406         buffers = list(self._buffers.keys())

/mnt/xarfuse/uid-5731/e4b45e64-seed-nspid4026531836-ns-4026531840/torch/nn/modules/module.py in __getattr__(self, name)
    794                 return modules[name]
    795         raise ModuleAttributeError("'{}' object has no attribute '{}'".format(
--> 796             type(self).__name__, name))
    797 
    798     def __setattr__(self, name: str, value: Union[Tensor, 'Module']) -> None:

ModuleAttributeError: 'LinearPackedParams' object has no attribute '_parameters'
```

cc @jerryzh168 @jianyuh @dzhulgakov @raghuramank100 @jamesr66a @vkuzo
Repository: rust
Issue: regression: `panic!` and RUST_BACKTRACE=1 Show Wrong & Non-Informative Function Names when Unwinding
Labels: A-runtime,O-windows,A-debuginfo,P-medium,T-compiler,O-windows-msvc,E-help-wanted,C-bug,T-libs

<!--
Thank you for filing a regression report! 🐛 A regression is something that changed between versions of Rust but was not supposed to.

Please provide a short summary of the regression, along with any information you feel is relevant to replicate it.
-->
As I'm learning the language from a book ("_The Complete Rust Programming Reference Guide_" p. 229-230), and was executing the  `panic!` macro in a multi-thread environment, I've noticed the unwinding from the book is different from the one I've got where the one I've got is not informative or helpful, and seems wrong where the one in book seems to be OK.

### Code

I tried this code:

```rust
// panic_unwinding.rs

use std::thread;

fn alice() -> thread::JoinHandle<()> {
    thread::spawn(move || {
        bob();
    })
}

fn bob() {
    malice();
}

fn malice() {
    panic!("malice is panicking!");
}

fn main() {

    let child = alice();
    let _ = child.join();

    bob();
    println!("This is unreachable code");
    
}
```

I expected the backtrace to include the function names as they were called, all the way from the entry point of the threads.

Instead, all functions were named the same: 
(env: `RUST_BACKTRACE=1`)
```
thread '<unnamed>' panicked at 'malice is panicking!', .\panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'malice is panicking!', .\panic_unwinding.rs:16:5
stack backtrace:
   0: std::panicking::begin_panic
   1: panic_unwinding::alice::{{closure}}
   2: panic_unwinding::alice::{{closure}}
   3: panic_unwinding::alice::{{closure}}
   4: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
```

### Version it worked on
I don't know from when is the regression. The book is using an old version of Rust: 1.32.0
<!--
Provide the most recent version this worked on, for example:

It most recently worked on: Rust 1.47
-->
### Version with regression
I use the most current version: Rust 1.47.0
<!--
Provide the version you are using that has the regression.
-->

`rustc --version --verbose`:
```
rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-pc-windows-msvc
release: 1.47.0
LLVM version: 11.0
```
</p>
</details>

<!--
If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-stable-to-{channel} -regression-untriaged
-->
Repository: flutter
Issue: Eliminate remaining logic from flutter_windows.cc
Labels: team,engine,platform-windows,a: desktop,P3,team-windows,triaged-windows

Originally flutter_windows.cc had essentially everything in it; over time most of the code has been moved into classes that correspond to the conceptual classes implied by the C API (FlutterWindowsEngine, FlutterWindowsView, etc.). There is still some logic in flutter_windows.cc itself though, such as FlutterDesktopViewControllerCreate, which should be moved into the classes if at all possible. That would leave flutter_windows.cc as a very minimal C wrapper over a (hopefully) understandable set of well-factored C++ classes, existing solely to provide the DLL-safe API interface.

(There is almost certainly more refactoring that could happen in those classes as well, but that doesn't necessarily need to be in scope here.)

/cc @gw280
Repository: godot
Issue: Restarting Godot from Editor Settings might discard unsaved scenes
Labels: bug,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3

**Steps to reproduce:**
1. Create a new scene (don't save it)
2. Do some changes
3. Go do editor settings and change something that requires restart (e.g. display scale)
4. Click the Save and Restart prompt
5. The editor gets restarted, but the scene is not being saved
Repository: deno
Issue: Feature request: fetch/HttpClient additions for public key pinning
Labels: suggestion,ext/fetch

Public key pinning is important for IOT access and security in general. Having just got public key pinning working for accessing the Philips Hue API, here's a list of features that are missing from Deno's `fetch`/`HttpClient` API:

1. Being able to fetch an IP address (there's another bug on this already)
2. Being able to skip verifying the SSL certificate chain (vendors don't always provide all necessary certs and public key pinning and custom certificate verification is a suitable and safe replacement). This is equivalent to curl's `--insecure` command line argument.
3. Being able to supply a name-to-IP-address resolver: the certificate may not contain any host name or IP address that is directly addressable, so if there's any validation that compares the CN in the cert with the hostname of the URL, there has to be a way of overriding this. curl uses `--resolve` arguments to handle this: you supply a URL where the hostname matches the subject name in the cert then use --resolve to map that name to the IP address of the server. (Also curl's `--connect-to`)
4. Being able to provide a hash of the public key to `fetch` so that it can fail if the key hash doesn't match. This is public key pinning. curl uses `--pinnedpubkey`.
5. Being able to retrieve certificates and extract a hash of the public key that can be stored and passed to `fetch` later.

In my implementation I ended up with an HttpClient that looked like this:
```
export type HttpClient = {
    caFile?: string,
    skipVerifyingCertificateChain?: boolean,
    nameResolver?: NameResolver;
    publicKeyHashProvider?: { getPublicKeyHash(url: URL): Promise<PublicKeyHash> };
};
```
 I also validate when `skipVerifyingCertificateChain` is `true` that a `publicKeyHashProvider` is provided and that it returns a hash for the specific URL being fetched (as a runtime check even though the types already require the hash to be provided).
Repository: go
Issue: x/sys: sizeof st_rdev is 64bits on mips64
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.9 linux/mips64le
</pre>

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOHOSTARCH="mips64le"
GOHOSTOS="linux"
</pre></details>

when I compile docker on mips64 arch, there is a field Rdev comes from golang/sys must be convert to uint64 otherwise it doesn't compile, this field defined as uint32 on mips64, but we do some test which shows the sizeof st_rdev on mips64 should be 8bytes.

$ uname -a
Linux node001 4.19.90 #2 SMP PREEMPT Fri Sep 4 15:53:40 CST 2020 mips64 mips64 mips64 GNU/Linux
$ cat dev.c
#include <sys/stat.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
    printf("%lu\n", sizeof(dev_t));
    struct stat s;
    printf("%lu\n", sizeof(s.st_dev));
    printf("%lu\n", sizeof(s.st_rdev));
}
$ gcc --version
gcc (GCC) 7.3.1 20180303 (Loongson 7.3.1-5)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc dev.c -o dev && ./dev
8
8
8

So I think Rdev should be defined as unit64 on mips64:
https://github.com/golang/sys/blob/master/unix/ztypes_linux_mips64.go#L92

https://forum.golangbridge.org/t/the-argument-rdev-is-defined-as-type-uint32-in-mips-arch-and-uint64-in-others/21179

thanks.
Repository: rust
Issue: x.py test --stage 0 src/tools/clippy does not work
Labels: T-bootstrap,C-bug,A-contributor-roadblock,A-clippy

<!--
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.
-->

```
$ x.py test --stage 0 src/tools/clippy 
Updating only changed submodules
Submodules updated in 0.01 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.13s
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building stage0 tool clippy-driver (x86_64-unknown-linux-gnu)
   Compiling clippy v0.0.212 (/home/joshua/rustc/src/tools/clippy)
    Finished release [optimized] target(s) in 1.54s
   Compiling clippy v0.0.212 (/home/joshua/rustc/src/tools/clippy)
    Finished release [optimized] target(s) in 1.49s
     Running build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps/clippy_driver-c0ddca9b2ddf2dba

running 1 test
test test_arg_value ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps/compile_test-93629616c1644211

running 1 test
test compile_test ... FAILED

failures:

---- compile_test stdout ----
thread 'compile_test' panicked at 'Found multiple rlibs for crate `serde`: `"/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps/libserde-0cbb27a77c795012.rlib"` and `"/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0-tools/x86_64-unknown-linux-gnu/release/deps/libserde-d748cd52d3612bbb.rlib"', src/tools/clippy/tests/compile-test.rs:46:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

3478d7c3607ffbba629af2265c01002771e48c18
Repository: pytorch
Issue: [jit] support length inference for list comprehension
Labels: oncall: jit

## 🚀 Feature
```python
from typing import Dict

class A(nn.Module):
    def __init__(self):
        super().__init__()
        self.x = tuple([0, 1, 2])
        self.y = nn.ModuleList([nn.Linear(10, 10)] * 3)

    def forward(self, x: Dict[int, torch.Tensor]):
        z = tuple([x[idx] for idx in self.x])

        ret = []
        for xx, yy in zip(z, self.y):
            ret.append(xx + yy)
        return ret

a = A()
script = torch.jit.script(a)
```

It throws:
```
RuntimeError:                                    
cannot statically infer the expected size of a list in this context:
  File "a.py", line 20
    def forward(self, x: Dict[int, torch.Tensor]):   
        z = tuple([x[idx] for idx in self.x])    
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE                                                                                                                                               
                                 
        ret = []
```

I expect the length of `z` to be static so that I can use `zip` on it.

cc @gmagogsfm