sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Unable to compile CUDAExtension with Pytorch 1.5 or above
Labels: module: bc-breaking,module: cpp-extensions,module: cuda,triaged,topic: bc breaking

## 🐛 Bug

<!-- I can't compile CUDAExtension in the advanced version of PyTorch -->

## To Reproduce

Steps to reproduce the behavior:

1.I try to reproduce some projects that need to compile CUDAExtension, such as 
      https://github.com/baowenbo/DAIN/blob/master/PWCNet/correlation_package_pytorch1_0/setup.py
   But it only works with PyTorch 1.4 and below and now I hope to implement this project on 3090 GPU


Traceback (most recent call last):
  File "/root/miniconda3/envs/ddd/lib/python3.8/site-packages/torch/utils/cpp_extension.py", line 1516, in _run_ninja_build
    subprocess.run(
  File "/root/miniconda3/envs/ddd/lib/python3.8/subprocess.py", line 512, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['ninja', '-v']' returned non-zero exit status 1.

I also tried other methods, such as changing - v to -- version. Not successful
## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->
Would you please tell me what should I do to solve this problem?

## Environment

 - PyTorch Version (e.g., 1.0):1.7.1
 - OS (e.g., Linux): Ubuntu 16.04.6 LTS (x86_64)
 - How you installed PyTorch (`conda`, `pip`, source): conda 
 - Build command you used (if compiling from source):
 - Python version:3.7
 - CUDA/cuDNN version: 11.0
 - GPU models and configuration:3090
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->


cc @ezyang @gchanan @malfet @zou3519 @ptrblck @yf225 @glaringlee @ngimel
Repository: rust
Issue: Non returning compilation on 1.48, 1.49, 1.50-beta and nightly-2021-01-13
Labels: P-medium,T-compiler,regression-from-stable-to-stable,C-bug,I-hang

Hi!

The crate located here:
https://github.com/krtab/diff/releases/tag/infiloop **at commit** c7d13ab3473147785a7f35f97461d828e9421fd2
Makes cargo/rustc go to an infinite loop. (I tried for 4 hours, it went up to 80GB of RAM).

```shell
git clone 'https://github.com/krtab/diff.git'
cd diff
git checkout c7d13ab3473147785a7f35f97461d828e9421fd2
cargo check
```

Given the amount of type-level black-magic, I'd wager there is some cycle/infinite recursion when trying to type-check.

### 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.
-->

`rustc --version --verbose`:
```
rustc 1.49.0 (e1884a8e3 2020-12-29)
binary: rustc
commit-hash: e1884a8e3c3e813aada8254edfa120e85bf5ffca
commit-date: 2020-12-29
host: x86_64-unknown-linux-gnu
release: 1.49.0
```
I have also tried 1.50-beta and today's nightly, and ask someone to test 1.48, to no avail.

Given that it doesn't finish, there is no backtrace.

Let me know how I can help!
Repository: pytorch
Issue: PyTorch mobile perf recipes, fails when building android 
Labels: module: android,oncall: mobile

## ❓ Questions and Help

### Please note that this issue tracker is not a help form and this issue will be closed.

We have a set of [listed resources available on the website](https://pytorch.org/resources). Our primary means of support is our discussion forum:

- [Discussion Forum](https://discuss.pytorch.org/)

Android NDK: ndk/22.0.7026061


>>> referenced by CheckFunctionExists.c:17 (/usr/local/Cellar/cmake/3.19.3/share/cmake/Modules/CheckFunctionExists.c:17)
>>>               CMakeFiles/cmTC_6e6f4.dir/CheckFunctionExists.c.o:(main)
>>> did you mean: sem_unlink
>>> defined in: /Users/ankita/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot/usr/lib/aarch64-linux-android/21/libc.so
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [cmTC_6e6f4] Error 1
make: *** [cmTC_6e6f4/fast] Error 2


What should be the approach in debugging the problem here?
Anyone who has faced similar issues? 
Any help is appreciated, Thanks in Advance.
Repository: storybook
Issue: Is it possible to set a Global variable (`globalTypes`) from within a Story?
Labels: question / support,args

I managed to add a toolbar icon that sets my locale for my Storybook app, thanks to https://storybook.js.org/docs/react/essentials/toolbars-and-globals#gatsby-focus-wrapper documentation 🎉 

But, when I manipulate my "change language button" nothing happens (unsurprisingly), because it cannot change the Storybook global variable state. Is there a way to set my `locale` variable? Through hooks maybe? I couldn't find any documentation about this.

Video showcasing the behavior difference: 
https://youtu.be/nbvkXpRWz24

It's not highly critical, but if there is a way for me to make the story preview behave as in the main app, that'd be great!
Repository: tensorflow
Issue: Remove no_cuda_on_cpu_tap tag and fix tests
Labels: stat:awaiting tensorflower,type:build/install,comp:gpu,TF 2.4

This is using TF 2.4.0

**Describe the problem**

When building and running tests I stumbled over the seemingly required test tag `no_cuda_on_cpu_tap` which is only documented in one place:
```
    # Running cuda on cpu will trigger tests guarded by GOOGLE_CUDA but NCHW
    # won't be available, which result in test failures. So disable that.
```

This sounds like a workaround for a problem when writing the tests. The most obvious incarnation for this is e.g. `//tensorflow/core/common_runtime:ring_reducer_test`. That is added with `tf_cuda_cc_test` which adds 2 tests: One with `_gpu` suffix gpu tags and one without. However as the test code uses `GOOGLE_CUDA` to decide whether to test on CPU or GPU the CPU test version cannot be run when TF is built with CUDA, which is (AFAIK) the regular case.

Hence my suggestion would be to "fix" the tests to run only on GPU if it is tagged with `gpu` and pass that to the test code as a define (e.g. `TF_TEST_USE_GPU`)
Repository: pytorch
Issue: Non-avairable nightly version for converting models to NNAPI
Labels: oncall: mobile

Hello, PyTorch team.

I would like to convert models to NNAPI for non-commercial use (to write an academic paper).
I followed this site, 
https://pytorch.org/tutorials/prototype/nnapi_mobilenetv2.html
and accessed
https://download.pytorch.org/whl/nightly/cpu/torch_nightly.html
But I couldn't download
```
torch==1.8.0.dev20201106+cpu
```
and
```
torchvision==0.9.0.dev20201107+cpu
```

I think the old versions are not released on the site, so could you release them again?
Newer versions have some issues for the converting.

Thank you.
Repository: godot
Issue: Error printing to logs from Godot is not rate limited
Labels: bug,topic:core

**Godot version:**
3.2.3.stable.mono (also previous versions at least as far back as 3.2.1)


**OS/device including version:**
GLES3, both Windows and Linux


**Issue description:**
When Godot engine encounters an error, it prints it to logs. It's good that all error text is printed (and ignores normal print limit per second), however I've experienced this a few times and gotten reports from players, that in some cases when Godot really locks up on some error, it will infinitely spam an error message as fast as possible. One user reported that before they managed to kill the Godot process, the log file was over 2 gigabytes large. I can't guarantee this, but I've also received 3 reports total that my game, that uses Godot, has caused the user's computer to totally lockup, and in 2 cases rebooting and trying to run the game again didn't work (the game files had become corrupted). So I very strongly think that there needs to be some limit in all Godot error printing to stop gigabytes of logs being generated that freeze computers.

This issue is related to: https://github.com/godotengine/godot/issues/37652 however this is not the same, as I'm saying that all of the error printing code should have an inbuilt fail-safe to kill the process before ridiculous amounts of repeating logs are printed.

<!-- What happened, and what was expected. -->
Game using Godot froze / locked up (presumably) in a physics related bug. Instead of the game properly crashing and process exiting, instead the process just stayed open printing the same repeating error in log files that ended up taking gigabytes of space. I expected that the engine would have some kind of fail-safe to just give up on writing logs at some point.

I tried to find an issue about this, but I only found specific cases where infinite errors are printed, and not a general report about the problem of really big log files.

**Steps to reproduce:**
Enable logging to a file, then hit a very serious bug in godot, for example https://github.com/godotengine/godot/issues/37652 and wait some time while Godot is frozen to generate really big log files.
Repository: flutter
Issue: Flutter can switch the network used by the application ,Proposal to allow Flutter to switch the network used by the application
Labels: c: new feature,framework,would be a good package,c: proposal,P3,team-framework,triaged-framework


## Use case

The flutter application is embedded in the native app. Because of the need, the mobile phone is connected to a WiFi that is not available on the network, but the native app will switch the network request of the application to the 4G network, but the flutter still uses the WiFi that is not available on that network. So what method does flutter provide to switch which network channel the network request goes to

## Proposal

flutter provide function to switch which network channel the network request goes to
Repository: node
Issue: Add support for `SSL_verify_client_post_handshake`
Labels: tls,openssl

**Is your feature request related to a problem? Please describe.**

For `TLSv1.2` and below, it is possible to renegotiate the session if you need to request the peer certificate ([docs](https://nodejs.org/api/tls.html#tls_tlssocket_renegotiate_options_callback)).

The `TLSv1.3` spec does not support renegotiation, so connections using this protocol cannot use renegotiation to request the peer certificate. From OpenSSL's [wiki](https://wiki.openssl.org/index.php/TLS1.3#Renegotiation)

> TLSv1.3 does not have renegotiation so calls to SSL_renegotiate() or SSL_renegotiate_abbreviated() will immediately fail if invoked on a connection that has negotiated TLSv1.3.
> 
> A common use case for renegotiation is to update the connection keys. The function SSL_key_update() can be used for this purpose in TLSv1.3.
> 
> Another use case is to request a certificate from the client. This can be achieved by using the SSL_verify_client_post_handshake() function in TLSv1.3.


**Describe the solution you'd like**

OpenSSL describes an alternative method to request the peer certificate: `SSL_verify_client_post_handshake` ([docs](https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html)).

Similar to how Node.js exposes `SSL_renegotiate()`, I would like to see Node.js expose `SSL_verify_client_post_handshake` to that we can consume this from application code.

**Describe alternatives you've considered**

For my [specific use case](https://github.com/elastic/kibana/issues/88325), I only need to renegotiate because resumed/reused TLS sessions do not always contain the full certificate chain, which is a requirement for me. Forcing renegotiation solves my problem for TLSv1.2 and below, but I don't have a solution for TLSv1.3 at this time.
Repository: create-react-app
Issue: CRA 4.0.1 FAST REFRESH does not work in micro frontend setup with multiple HMR client instances running parallel
Labels: needs triage

Hi guys,

I'm trying to integrate CRA 4.0.1 in our setup with micro frontend, means: container app is running on a WDS (Webpack Dev Server) instance and the micro-frontend app is running on it's own WDS instance on other port. container app will then load js bundle from the WDS of the micro frontend app and mount the micro frontend component in it's DOM dynamicall at runtime.

FAST REFRESH works so far for code changes of container app, but NOT for changes coming from the micro frontend component. The HMR client instance (`webpackHotDevClient.js`) of the micro frontend gets notifified any time it's code has been changed and kicks off the hot update process, but it does nothing. I have added some console logs into the `webpackHotDevClient.js` to see what happen on the hot update process, you may want to take a look at them:

```
handleWarnings isHotUpdate= true
bundle-investorprofile-finances.js:127197 TB tryApplyUpdates - module.hot= {_acceptedDependencies: {…}, _declinedDependencies: {…}, _selfAccepted: false, _selfDeclined: false, _selfInvalidated: false, …}
bundle-investorprofile-finances.js:127201 TB tryApplyUpdates - isUpdateAvailable()= true
bundle-investorprofile-finances.js:127202 TB tryApplyUpdates - canApplyUpdates()= true
bundle-investorprofile-finances.js:127237 TB tryApplyUpdates - result of module.hot.check = Promise {<pending>}
bundle-investorprofile-finances.js:127239 TB tryApplyUpdates - updatedModules = ["./src/themenblock/investorprofile-finances/steps/WphgPickUp.tsx"]0: "./src/themenblock/investorprofile-finances/steps/WphgPickUp.tsx"length: 1__proto__: Array(0)
bundle-investorprofile-finances.js:127212 TB handleApplyUpdates - hasReactRefresh = true
bundle-investorprofile-finances.js:127213 TB handleApplyUpdates - wantsForcedReload = false
```


If you take a look at the log line:
`TB tryApplyUpdates - updatedModules = ["./src/themenblock/investorprofile-finances/steps/WphgPickUp.tsx"]`
you see, that the hot update process of the HMR client in `webpackHotDevClient.js` gets the right piece of code that has been changed, it is `./src/themenblock/investorprofile-finances/steps/WphgPickUp.tsx`, but somehow it does not know how to use it to update the DOM, so nothing happens to the DOM.

If you have any idea where i have to take a look at pls help! I'm lost!

Thanks!
Repository: node
Issue: test-crypto-secure-heap fails on IBM i
Labels: flaky-test,ibm i

<!--
Thank you for reporting a flaky test.

Flaky tests are tests that fail occasionally in the Node.js CI, but not
consistently enough to block PRs from landing, or that are failing in CI jobs or
test modes that are not run for every PR.

Please fill in as much of the template below as you're able.

Test: The test that is flaky - e.g. `test-fs-stat-bigint`
Platform: The platform the test is flaky on - e.g. `macos` or `linux`
Console Output: A pasted console output from a failed CI job showing the whole
failure of the test
Build Links: Links to builds affected by the flaky test

If any investigation has been done, please include any information found, such
as how consistently the test fails, whether the failure could be reproduced
locally, when the test started failing, or anything else you think is relevant.
-->

* **Test**: parallel/test-crypto-secure-heap
* **Platform**: IBM i
* **Console Output:**
```
09:04:30 not ok 525 parallel/test-crypto-secure-heap
09:04:30   ---
09:04:30   duration_ms: 3.340
09:04:30   severity: fail
09:04:30   exitcode: 1
09:04:30   stack: |-
09:04:30     node:assert:119
09:04:30       throw new AssertionError(obj);
09:04:30       ^
09:04:30     
09:04:30     AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
09:04:30     
09:04:30     null !== 0
09:04:30     
09:04:30         at ChildProcess.<anonymous> (/home/iojs/build/workspace/node-test-commit-ibmi/nodes/ibmi72-ppc64/test/parallel/test-crypto-secure-heap.js:59:10)
09:04:30         at ChildProcess.<anonymous> (/home/iojs/build/workspace/node-test-commit-ibmi/nodes/ibmi72-ppc64/test/common/index.js:377:15)
09:04:30         at ChildProcess.emit (node:events:379:20)
09:04:30         at Process.ChildProcess._handle.onexit (node:internal/child_process:285:12) {
09:04:30       generatedMessage: true,
09:04:30       code: 'ERR_ASSERTION',
09:04:30       actual: null,
09:04:30       expected: 0,
09:04:30       operator: 'strictEqual'
09:04:30     }
09:04:30   ...
```
* **Build Links**: https://ci.nodejs.org/job/node-test-commit-ibmi/223

This test was newly added earlier in the week by 03c056401f23fe83ab6f16741759182e95a407bd and has been intermittently failing on IBM i (the CI for which is only run on the daily CI run) since.
Repository: bitcoin
Issue: add option to bumpfee RPC to prevent it adding new inputs
Labels: Feature

**Is your feature request related to a problem? Please describe.**

When I use the `bumpfee` RPC it adds new inputs, potentially damaging privacy. I created the original transaction carefully using coin control to avoid linking specific UTXOs, but `bumpfee` undoes this by adding new inputs apparently at random.

This is further exacerbated by the way in which `bumpfee` decides whether to add new inputs or not. It attempts to bump the fee by reducing the change output if possible, but I label my change outputs which causes IsChange() not to recognize them as change. Any labelled UTXO is considered not to be change, which is incorrect:

    bool CWallet::IsChange(const CScript& script) const
    {
        // TODO: fix handling of 'change' outputs. The assumption is that any
        // payment to a script that is ours, but is not in the address book
        // is change.

**Describe the solution you'd like**

I'd like to be able to tell `bumpfee` not to add new inputs. I see in recent release notes:

> The fundrawtransaction RPC now supports add_inputs option that when false prevents adding more inputs if necessary and consequently the RPC fails.

Something like that for `bumpfee` would be ideal.

I'd also like to be able to bump the fee on transactions where the change is labelled without adding new inputs, and to be able to specify which new inputs to add if new inputs need adding. Basically coin control for bumpfee.
Repository: godot
Issue: Imported packed TextureAtlas doesn't go wider than 2048, will go over 16384 tall instead.
Labels: enhancement,topic:core,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.2.3
but also 3.2.4 beta 5


**OS/device including version:**
Ubuntu 20.04, intel i52400u


**Issue description:**
When creating Atlas as shown in https://godotengine.org/article/atlas-support-returns-godot-3-2 the atlas will go 2048 wide, but then it will procceed to get taller. It will fail to be generated above 16384 tall, but it will never utilize the remaining 87,5% of available maximum width. It would be ideal if it would try to maintain a square shape in order to fit as much stuff as possible before breaking.


**Steps to reproduce:**
Import a lot of stuff as TextureAtlas.


**Minimal reproduction project:**
[TextureAtlasBreakTest.zip](https://github.com/godotengine/godot/files/5815530/TextureAtlasBreakTest.zip)
The project packs 36 2kx2k maps as atlas. It should be no problem to fit them as 16kx16k map can fit 64 of those, but packing fails.
Repository: go
Issue: x/review/git-codereview: reword doesn't work properly in alternate worktree
Labels: NeedsFix

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +9734fd482d Thu Jan 14 08:31:22 2021 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What did you do?

$  git worktree list
/ssd2/go   bcd9ec47a1 [abi_wrap_gen]
/ssd2/xgo  f9fbdb4640 [dwarf_minimal_line_table]
/ssd2/ygo  9734fd482d [dev.regabi]
$ cd /ssd2/xgo 
$ git codereview reword HEAD


### What did you expect to see?

Normal reword

### What did you see instead?

Instead got error 

  git-codereview: cannot save messages: open /ssd2/xgo/.git/REWORD_MSGS: not a directory

Looks like the recipe that 'git codereview reword' is using to locate the .git dir is not correct in the presence of multiple work trees. I will send a patch.
Repository: go
Issue: cmd/go: for package loading errors, decide when to show source position or import stack
Labels: NeedsDecision

In [`cmd/go/internal/load.PackageError.Error`](https://go.googlesource.com/go/+/refs/tags/go1.16beta1/src/cmd/go/internal/load/pkg.go#414), we have some complicated logic that decides whether we print a source position or an import stack with an error. Currently, we print the source position if it's available (with one exception for importing an internal package from a place that's not allowed). If the source position isn't available, we print the import stack.

For deeply imported packages, especially those in other modules, the source position isn't necessarily more useful than the import stack. The user may have no knowledge of an indirect dependency that can't be loaded in their specific configuration. We may also want to print the source position together with the import stack.

We should document whatever we decide, even if we don't change anything to avoid confusion in the future.

This shouldn't affect the output of `go list -json` or `go list -f`.

cc @bcmills @matloob
Repository: godot
Issue: A sub-viewport Camera2D has inconsistent position results at runtime. 
Labels: bug,topic:core

<!-- 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. -->
a329de566c109557d6b3bb76f7511911fa8ff1c3

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Win 10

**Issue description:**
<!-- What happened, and what was expected. -->
When in the editor a sub viewport will show the results of a camera relative to the anchor option.  At runtime the **ANCHOR_MODE_DRAG_CENTER** option doesn't work.

I'm not sure which side of the inconsistency is incorrect.  Isn't the camera supposed to match the viewport?  Is the problem with the way the editor is displaying it or the way the game is?

![godot windows tools 64_ZwcynjRIHy](https://user-images.githubusercontent.com/13004169/104626304-6ab4fe00-569e-11eb-9ba2-6e628371944d.png)


**Steps to reproduce:**
Setup a sub-viewport and use a Camera2D with the centering option.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[Viewport Camera Issue.zip](https://github.com/godotengine/godot/files/5815998/Viewport.Camera.Issue.zip)
Repository: go
Issue: cmd/vet: warn about "// go:" comments (with space)
Labels: Proposal,Proposal-Accepted,Analysis

The `embed.FS` type added for #41191 documents the following behavior:
> An `FS` is a read-only collection of files, usually initialized with a `//go:embed` directive. When declared without a `//go:embed` directive, an `FS` is an empty file system.

I expect that package authors essentially _never_ intend to end up with an empty read-only filesystem in a production package. (In tests, perhaps, but not otherwise.) For the few cases where they do, they should be able to add an explicit `//go:embed` directive indicating that the filesystem is _intentionally_ empty.

Otherwise, it is too easy for an unintentional typo in the `//go:embed` directive, such as the one discovered in https://github.com/golang/go/issues/43682#issuecomment-760344342, to result in a difficult-to-debug failure at run time.

I propose that `cmd/vet` should emit a warning when:
* a package-level variable is declared with type `embed.FS`,
* without any corresponding `//go:embed` directive (not even one with an empty pattern list),
* in a non-test source file.