sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Preview file in Recycle Bin
Labels: Idea-New PowerToy

### Provide a description of the new feature / enhancement

I want to preview the file in Recycle Bin as it is in the normal folder. Because I want to verify if I delete wrong or remember what it is.
Repository: create-react-app
Issue: Introduce explicit, shorter, timeout for latest version check
Labels: issue: proposal,needs triage

### Problem Statement

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

In environments with restricted connectivity (proxies, ...) the `checkForLatestVersion` request [here](https://github.com/facebook/create-react-app/blob/fddce8a9e21bf68f37054586deb0c8636a45f50b/packages/create-react-app/createReactApp.js#L1125), designed as [an optimisation over `npm view create-react-app version`](https://github.com/facebook/create-react-app/blob/fddce8a9e21bf68f37054586deb0c8636a45f50b/packages/create-react-app/createReactApp.js#L189-L194) causes a _lengthy_ delay before `create-react-app` does anything meaningful.

The `https.get` request responsible (below) does not specify a timeout, meaning that it takes the [default 2 minutes](https://nodejs.org/docs/latest-v12.x/api/http.html#http_server_timeout) to give up.

https://github.com/facebook/create-react-app/blob/fddce8a9e21bf68f37054586deb0c8636a45f50b/packages/create-react-app/createReactApp.js#L1125-L1129

### Proposed Solution

<!--
  Provide a clear and concise description of what you want to happen.
-->

Given that this is intended as an optimisation over a ~slow `npm` `child_process.execSync` call, I would propose giving it an explicit timeout of something more like 10 seconds.

Probably a "Good First Issue"!
Repository: go
Issue: net: add UDPMsg, (*UDPConn).ReadUDPMsgs, (*UDPConn).WriteUDPMsgs
Labels: Proposal,Proposal-Accepted

(co-written with @neild)

Linux has [`recvmmsg`](https://man7.org/linux/man-pages/man2/recvmmsg.2.html) to read multiple UDP packets from the kernel at once.

There is no `Recvmmsg` wrapper func in golang.org/x/sys/unix. That's easy enough to add, but it's not ideal: it means all callers of it would be using a thread while blocked waiting for a packet.

There is, however, batch support in golang.org/x/net/ipv{4,6}: e.g. https://pkg.go.dev/golang.org/x/net/ipv4#PacketConn.ReadBatch (added around  https://github.com/golang/net/commit/b8b13433cc9973c2ad1c7217f0cf4a59d00b135d). But it has the same thread-blocking problem. And it has the additional problem of having separate packages for IPv4 vs IPv6.

It'd be nicer to integrate with the runtime's poller.

Adding API to do this in the net package would mean both:

1. we'd be able to integrate with the runtime poller (epoll, etc) and not waste a thread during a read
2. there'd be portable API to do this regardless of whether the platform/kernel version supports something like recvmmsg.

For writing, [`net.Buffers`](https://golang.org/pkg/net/#Buffers) already exists, as does golang.org/x/net/ipv{4,6}'s PacketConn.WriteBatch, so is less important, but could be done for consistency.

As far as a potential API, https://pkg.go.dev/golang.org/x/net/ipv4#PacketConn.ReadBatch is close, but the platform-specific flags should probably not be included, at least as an int. While there's some precedent with https://golang.org/pkg/net/#UDPConn.ReadMsgUDP use of `flags int`, we could probably use a better type if we need flags for some reason.

Alternatively, if callers of x/sys/unix or x/net/ipv{4,6} could do this efficiently with the runtime poller, that'd also work (even if they'd need to use some build tags, which is probably tolerable for anybody who cares about this).
Repository: godot
Issue: Script editor is slow to render on hiDPI displays at large resolutions when an external monitor is connected
Labels: platform:macos,topic:editor,performance

**Godot version:**
3.3.0 (but tried a few older versions like 3.2.x and they seemed to have the same problem)

**OS/device including version:**
MacOS 10.15.5

**Issue description:**
When running Godot full-screen on my 27 inch mac display (basically this https://www.amazon.com/Apple-MC914LL-27-inch-Thunderbolt-Display/dp/B004YLCKYA - though I suspect it happens on other large displays) the Godot script editor is noticeably laggy. 

The most obvious problem is that clicking and dragging to select text runs at like 1FPS. It also lags when I hold down a key to repeatedly input it - though I have my repeat rate set really high so this may not happen for everyone.

**Steps to reproduce:**

1. Run Godot on a big monitor. 
2. Try to select some text
3. Notice the text selection is redrawn really slowly

**Minimal reproduction project:**
None needed?
Repository: pytorch
Issue: Delay errors of inference tensor to backward pass?
Labels: triaged,enhancement,module: dispatch,inference mode

Inference tensor currently can error out in forward pass, e.g. if it's saved for backward or inplace updated outside inference mode. 

When replacing `AutoNonVariableTypeMode` with `InferenceMode`, there're cases `AutoNonVariableTypeMode` guard was only added for a subset of tensor operations while all tensor operations should be run in inference mode(e.g. only `forward` is guard but not `preprocess/postprocess`). And it was sometimes hard to get a backtrace to locate the offending inplace operation in some applications(in this example it was an oculus application). 

An alternative to current behavior that works better for this use case is : when inplace update happens we mark the tensor as "corrupted for autograd", and we only check it in backward pass. (I don't have a detailed plan how this will be implemented, but might be through hacking `grad_fn` or similar new field). 

The advantage of this alternative solution is obvious: you only hit errors when you really run backward pass and it might work better for migrating existing code with ``AutoNonVariableTypeMode``. 

But I currently still prefer erroring out in the forward pass for the following reasons:
1. If you don't want to run backward at all, inference_mode should be enabled at the highest level of user code (e.g. in python when python wrapper is available). This gives you the best inference perf you can get.
2. Erroring out in backward is good that it delays errors as much as possible, but when it happens, it's much harder to locate the offending code in forward pass (like the offending inplace operation) compared to the current solution.
3. `AutoNonVariableTypeMode` is going away, I have only seen one case described above among >200 callsites. So we should really just get the backtrace and fix that one (or put the guard in highest level java user code) instead of stretching the behavior of inference mode API.

Based on the arguments above I prefer to keep the current behavior of `InferenceMode` as it is, but I'm happy to revisit this decision in the future if users have a valid use case.
Repository: pytorch
Issue: gen_proto_typestubs_helper.py is slow
Labels: module: build,triaged

## 🐛 Bug

It seems that no matter how many files I changed, the following script will always rerun.
```
[1/34] Generating proto/gen_proto_typestubs_helper.py
```

And this script is very slow. As a result, every time when I rebuild PyTorch, I have to wait for a long time even if I only changed one file.

cc @malfet @seemethere @walterddr
Repository: node
Issue: node request pipe is creating a buffer size oveflow  'ERR_STRING_TOO_LONG'
Labels: wrong repo

* **Version**:  16.0.0
* **Platform**: Linux
* **Subsystem**:

My code can be viewed at this project if interested: 

https://github.com/makingglitches/GooglePhotoDownload

All its doing is using the pipe() method of a requestpromise to send data retrieved from the url to a file.

When the network speed is fast this is resulting in this error:

node:buffer:806
    return this.utf8Slice(start, end);
                ^

Error: Cannot create a string longer than 0x1fffffe8 characters
    at Buffer.toString (node:buffer:806:17)
    at Request.<anonymous> (/Data/Documents/CensusProject/AcctBackup/node_modules/request/request.js:1128:39)
    at Request.emit (node:events:377:35)
    at IncomingMessage.<anonymous> (/Data/Documents/CensusProject/AcctBackup/node_modules/request/request.js:1076:12)
    at Object.onceWrapper (node:events:471:28)
    at IncomingMessage.emit (node:events:377:35)
    at endReadableNT (node:internal/streams/readable:1312:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  code: 'ERR_STRING_TOO_LONG'
}

_So this bug is an elusive one. And seems part of the node js lib itself._
Repository: flutter
Issue: Remove extra copies from platform messages
Labels: team,framework,P2,team-framework,triaged-framework

Work outlined in document: https://docs.google.com/document/d/1oNLxJr_ZqjENVhF94-PqxsGPx0qGXx-pRJxXL6LSagc/edit#

- [ ] Add performance tests
- Embedder copy
  - [ ] Pass ownership of message memory to embedder when receiving messages from flutter
  - [ ] Pass ownership of message memory to the engine when sending results from embedder
- Dart VM copy
  - [ ] Pass ownership of message from dart vm to engine when receiving a message from flutter (typedata)
  - [ ] Pass ownership of message from engine to dart vm when sending response a message to flutter (typedata)
Repository: flutter
Issue: Consider validating code formatting of template code
Labels: team,tool,P2,team-tool,triaged-tool

We sometimes have formatting mistakes creep into our template code; see https://github.com/flutter/flutter/pull/81561 for an example. It might be interesting to have a test that runs `flutter create` for all platforms, and then for all the platforms where we generally use an auto-formatter for that platform's native code, see if it passes. That would prevent purely accidental deviations like the above.

The downside would be that if we wanted to follow some other format for some specific reason (similar to the decision not to auto-format Dart code in flutter/flutter), it wouldn't allow for that.
Repository: go
Issue: runtime: "morestack on g0" on freebsd-386
Labels: OS-FreeBSD,NeedsInvestigation,compiler/runtime

[2021-04-30T18:14:41-d9bfda8/freebsd-386-12_2](https://build.golang.org/log/52a210c6f5e0f3563c02af0794e4924c4a08b44d)

```
##### ../misc/cgo/errors
--- FAIL: TestReportsTypeErrors (0.50s)
    --- FAIL: TestReportsTypeErrors/issue33061.go (3.60s)
        errors_test.go:82: expected error output to contain `issue33061\.go:16:`
        errors_test.go:87: actual output:
            fatal: morestack on g0
            SIGTRAP: trace trap
            PC=0x80a6752 m=0 sigcode=1
            
            goroutine 0 [idle]:
            runtime.abort()
            	/tmp/workdir/go/src/runtime/asm_386.s:843 +0x2
            runtime.morestack()
            	/tmp/workdir/go/src/runtime/asm_386.s:418 +0x1f
            
            goroutine 22 [running]:
FAIL
```

This may be related to #31683.

CC @ianlancetaylor @cherrymui @prattmic @mknyszek
Repository: godot
Issue: Invalid call. Nonexistent function 'new' in base 'VisualScript'.
Labels: bug,topic:visualscript

<!-- 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.3.0

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Win10 GLES3

**Issue description:**
<!-- What happened, and what was expected. -->
I try to instance from Script(VisualScript) using
```
print(load("res://new_script.vs").can_instance()) # prints true
add_child(load("res://new_script.vs").new())
```
![image](https://user-images.githubusercontent.com/20573784/116740329-2c491200-a9f5-11eb-8bce-178735fb0310.png)
**expected** new instanced child in tree
**happend** error : Invalid call. Nonexistent function 'new' in base 'VisualScript'.

**Steps to reproduce:**
create new VisualScript that extend (any)Node and try to instance using load or preload

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[error VS can_instance.zip](https://github.com/godotengine/godot/files/6407488/error.VS.can_instance.zip)

**My understanding so far**
The .new() function actually returns a instance.
.can_instance() is called on the common parent 'Script' of VisualScript and GDScript. The extended Node is instance able so returns true.
GDScript, NativeScript and PluginScript have the .new() Function
This is forgotten in VisualScript
If it is a technical limitation `print(load("res://new_script.vs").can_instance())` # should print false
![image](https://user-images.githubusercontent.com/20573784/116742059-22281300-a9f7-11eb-91e2-db86ec971b92.png)
![image](https://user-images.githubusercontent.com/20573784/116742177-4e439400-a9f7-11eb-9cef-6e23581c8c77.png)

I do not think it is directly related but #48248
Repository: tensorflow
Issue: TF_AddGradientsWithPrefix doesn't seem to lock the gradients properly
Labels: stat:awaiting tensorflower,type:bug,comp:ops,TF 2.8

**System information**
- Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Using TF-Java
- OS Platform and Distribution (e.g., Linux Ubuntu 16.04): macOS
- TensorFlow installed from (source or binary): Maven Central binary
- TensorFlow version (use command below): v2.4.1

**Describe the current behavior**

When training a model I'm hitting a non-determinism issue, the models are initialized identically, and fed identical data in an identical order, with inter-op and intra-op parallelism both set to 1, but I can get complete training failure when building simple MLPs and CNNs on MNIST.

TF-Java uses TF_AddGradientsWithPrefix to construct the gradients. We then wrap that in Optimizers to make a higher level front end to training, similar to the v1 optimizers package, and Keras in v2. As gradients are only available in Graph mode in the C API our code is most similar to the v1 optimizers package. I think we want to have the gating behaviour set to `GATE_OP` (https://www.tensorflow.org/api_docs/python/tf/compat/v1/train/Optimizer), but that's all implemented entirely in python, and the C API codepath doesn't seem to add the required control dependencies to ensure the gradients are all computed before being back-propped any further (in Python that's performed here - https://github.com/tensorflow/tensorflow/blob/85c8b2a817f95a3e979ecd1ed95bff1dc1335cff/tensorflow/python/ops/gradients_util.py#L692, but there doesn't seem to be an equivalent in the C API here - https://github.com/tensorflow/tensorflow/blob/5dcfc51118817f27fad5246812d83e5dccdc5f72/tensorflow/cc/framework/gradients.cc#L568).

**Describe the expected behavior**

The model should train identically with identical gradients.

**Standalone code to reproduce the issue**

See this test in TF-Java - https://github.com/Craigacp/tensorflow-java/blob/03402b30e271a46438c1feff12409095737f3d3e/tensorflow-framework/src/test/java/org/tensorflow/framework/optimizers/GradientDescentTest.java#L121. This test when run complains that out of the 20 runs some of them diverged even when trained using identical graph defs on identical data, for an identical number of steps, when using single threaded computation.
Repository: pytorch
Issue: Asserts all tensor are defined in dispatch wrapper
Labels: triaged,enhancement

## 🚀 Feature
Asserts all tensor are defined in dispatch wrapper

## Motivation

Undefined tensor should only be used internally in PyTorch.  Thus tensors should be defined at dispatch time.  Some are recently fixed via https://github.com/pytorch/pytorch/pull/53218 .  There are still some cases undefined tensors passed to dispatcher, as demonstrated in https://github.com/pytorch/pytorch/pull/56564 . 


<!-- 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 -->

## Pitch

<!-- A clear and concise description of what you want to happen. -->

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->
Repository: go
Issue: cmd/go: "go install" of std/cmd in a different GOROOT silently does the wrong thing
Labels: NeedsInvestigation,GoCommand

```
$ pwd
/home/mvdan/tip/src/cmd/gofmt
$ go version
go version devel go1.17-8e91458b19 Fri Apr 30 20:00:36 2021 +0000 linux/amd64
$ go install
$ which gofmt
/home/mvdan/tip/bin/gofmt
$ /usr/bin/go version
go version go1.16.3 linux/amd64
$ /usr/bin/go install
$ go version $(which gofmt)
/home/mvdan/tip/bin/gofmt: devel go1.17-8e91458b19 Fri Apr 30 20:00:36 2021 +0000
```

Note that Go 1.16.3 happily does nothing when it's told to `go install` cmd/gofmt from tip, even though that should most definitely error. From the last command, you can see that the gofmt I'm using has not changed. The gofmt from /usr/bin can't have been changed either, as I'm not root.

I think I get why this is happening. `/usr/bin/go install` turns into `/usr/bin/go install cmd/gofmt`, so that ends up installing 1.16.3's cmd/gofmt, which is already up to date - hence nothing to do.

But that feels wrong. If I'm installing the package at the current directory, and this is a package under *a different* GOROOT than the toolchain's, that should simply fail very early on.

This caused me confusion on https://go-review.googlesource.com/c/go/+/284139. After a rebase on a cmd/gofmt change, I ran `go install` and it finished incredibly quickly, even though I knew I had likely made a mistake. Plus, I would expect the first build to take about a second, as I'd need a new binary for sure. It was five minutes later that I realised I had forgot to re-run `make.bash` earlier in the day, so my `go` binary was falling back to the system's 1.16.3, rather than tip.

cc @bcmills @matloob
Repository: vscode
Issue: Shift+arrow should honor the OS's selection handling
Labels: feature-request,macos

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
- VS Code Version: 1.55.2
- OS Version: macOS 10.15.6

Steps to Reproduce:

1. Double-click to select a word
2. Shift+left arrow to add to the selection

Expected Behavior:
Characters to the left of the selection get added to the selection

Observed behavior:
Characters at end of the selection get removed from the selection

<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Repository: go
Issue: x/blog: defer statements execute before/after the caller returns
Labels: Documentation,help wanted,NeedsFix

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.16.2 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env

</pre></details>

### What did you do?

In this [example](https://play.golang.org/p/cbD3jZcS01k) the defer function doesn't change the returned value whereas using the named return values would do the trick in this [example](https://play.golang.org/p/pKjOj490xjo).

If the defer function is executed after the caller returns as this blog [post](https://blog.golang.org/defer-panic-and-recover) suggests, that would explain it. However, the [doc](https://golang.org/ref/spec#Defer_statements) says defer functions are executed before the caller returns.


### What did you expect to see?

The blog post and the Golang doc being consistent.

### What did you see instead?

The blog [post](https://blog.golang.org/defer-panic-and-recover) says the list of saved calls is executed **after** the surrounding function returns whereas the Golang doc says the list of saved calls is executed **before** the surrounding function returns
Repository: pytorch
Issue: Simplified API for custom inplace & view kernel 
Labels: triaged,enhancement,module: custom-operators,module: dispatch

Currently we ask users to register a proper kernel for ADInplaceOrView key if they are implementing a customized kernel. https://github.com/pytorch/tutorials/pull/1494/files#  But we can infer inplace/view relationship from the JIT schema and in the ideal end state, we should be able to handle this for users, e.g. when computing the dispatch table, look at the schema and register different kernels: 

```
inplace op: boxed_kernel_for_inplace_op
view op: boxed_kernel_for_view_op
functional op: fallthrough
```


- Pro: this makes the API for custom op implementer cleaner and easier to understand. 
- Cons: it might slows down the dispatch table computation. 

I used to think that this task was blocked, but after a second thought it's possible to implement it today if we are okay to pay the price of parsing JIT schema I think. 

Note that even with this feature, kernel implementers still need to be aware of `Autograd/ADInplaceOrView` differences:
in the inplace op case, they need to use `AutoDispatchBelowAutograd` while for functional ops, `AutoDispatchBelowADInplaceOrView` should be used.
Repository: rust
Issue: Support building and testing std with panic=abort
Labels: A-testsuite,T-bootstrap

`panic=abort` is needed in resource-constrained environments, wasm, and when building with the [cranelift backend](https://github.com/bjorn3/rustc_codegen_cranelift/blob/6d30315d055e92464026c2ac0d7f3ad8b02539b6/scripts/test_rustc_tests.sh#L24-L41).

Building and testing std with `panic=abort` today is fraught for at least two reasons:

1. `panic=unwind` is still needed for proc macros, so setting target-specific rustflags doesn't work if you want to do this on a host platform.
2. Many tests (~80 by my count: [1], [2]) depend on unwinding, and the test framework doesn't know how to automatically disable them. Many of these are disabled for individual platforms (wasm) or dealt with externally in a somewhat brittle way.

[1]: https://github.com/bjorn3/rustc_codegen_cranelift/blob/6d30315d055e92464026c2ac0d7f3ad8b02539b6/scripts/test_rustc_tests.sh#L13-L16
[2]: https://github.com/bjorn3/rustc_codegen_cranelift/blob/6d30315d055e92464026c2ac0d7f3ad8b02539b6/scripts/test_rustc_tests.sh#L24-L41

In order to make this work, rustbuild should support this option directly and tests relying on unwinding need to be labelled with `needs-unwind`.

Given the number of tests this affects and the likelihood of regression, we may also want to test this configuration explicitly in CI. But the wasm builders would serve this purpose almost as well.
Repository: pytorch
Issue: [lint] Make sure that all CMake options have a corresponding output in the summary
Labels: triaged,better-engineering

It's too easy to add a hidden option that may or may not change build behavior (i.e. #57061), so we should have something that ensures that anything declared with `option(...)` is referenced in a `message()` inside of `cmake/Summary.cmake`.