sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Adding #[track_caller] on #[alloc_error_handler] seems to cause undefined behavior
Labels: C-bug,requires-nightly,F-track_caller

Playground link: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c830f805f27e1be14b718b4d7510bf66

Example playground output:
```
Standard Error

   Compiling playground v0.0.1 (/playground)
    Finished dev [unoptimized + debuginfo] target(s) in 1.67s
     Running `target/debug/playground`
timeout: the monitored command dumped core
/playground/tools/entrypoint.sh: line 11:     8 Segmentation fault      timeout --signal=KILL ${timeout} "$@"

Standard Output

panicked at 'oof: Layout { size_: 4, align_: 4 }', 
```
(It seems to print garbage in release mode)

While trying to debug my OS kernel, I slapped `#[track_caller]` on my `#[alloc_error_handler]` to try and figure out what was attempting to allocate memory that caused an OoM, however every time I hit that it would hang on an invalid memory access when it went to print the source location for the panic. I was able to reproduce the issue by... sternly talking the playground into producing a `#![no_std]` binary and running it with a global allocator that always fails.
Repository: youtube-dl
Issue: youtube-dl cookies in config.txt
Labels: bug,question


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- Look through the README (http://yt-dl.org/readme) and FAQ (http://yt-dl.org/faq) for similar questions
- Search the bugtracker for similar questions: http://yt-dl.org/search-issues
- Finally, put x into all relevant boxes (like this [x])
-->

- [x ] I'm asking a question
- [ x] I've looked through the README and FAQ for similar questions
- [x ] I've searched the bugtracker for similar questions including closed ones


## Question

<!--
Ask your question in an arbitrary form. Please make sure it's worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient.
-->

WRITE QUESTION HERE

```
-o I:/youtube-dl/%(extractor)s/%(title)s-%(uploader)s-%(channel_id)s-%(channel)s-%(id)s.%(ext)s
-f bestvideo[height<=?1080]+bestaudio/best
--write-thumbnail 
--cookies C:\Users\GEN32UC\AppData\Roaming\youtube-dl\cookies.txt
--write-sub
--write-auto-sub
--sub-lang en-GB
```


i'm download video on facebook, but cookies wont work, i need to add it into command instead

eg:
youtube-dl facebookURL --cookies C:\Users\GEN32UC\AppData\Roaming\youtube-dl\cookies.txt

did my config file is wrong ? ty
Repository: create-react-app
Issue: Support logical assignment operators
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

ES 2021 [Logical assignment operators](https://caniuse.com/?search=logical%20assignment) are supported in Chrome/Edge/Firefox/Safari, but will break the Create React App build.

### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

Update the Babel config/version to take advantage of logical assignment parsing.

### Describe alternatives you've considered

<!--
  Let us know about other solutions you've tried or researched.
-->

Custom config with Craco, not really worth it.

### Additional context

<!--
  Is there anything else you can add about the proposal?
  You might want to link to related issues here, if you haven't already.
-->

I assume this is on it's way anyway with or without this issue, but the only other issue I could find is more specific and appears to be from someone who assumed that it should be working. https://github.com/facebook/create-react-app/issues/9908
Repository: go
Issue: cmd/go: clarify the implication when module name is 'main'
Labels: NeedsFix

go version 1.16

Consider a case where `go.mod` has module path `main`, and the top-level package is a non-main package.
A module's path is the prefix for package paths within the module [[ref](https://golang.org/ref/mod#module-path)], so the following behavior may not be too surprising. But the behavior difference between `go build` and `go test` was surprising.

```
--- go.mod ---
module main

go 1.16

--- w.go ---
package w

func F() {}

--- w_test.go ---
package w

import "testing"

func TestF(t *testing.T) {
        t.Error("error")
}
```

```
$ tree
.
├── go.mod
├── w.go
└── w_test.go
$ go build
$ go test
# main.test
/var/folders/bw/6r6k9d113sv1_vvzk_1kfxbm001py5/T/go-build2194496096/b001/_testmain.go:13:2: cannot import "main"
FAIL    main [build failed]
```
Repository: rust
Issue: `run-make-fulldeps/rustdoc-io-error` passes even without `chmod` calls
Labels: A-testsuite,T-rustdoc,C-bug

The test passes even if I remove the `chmod` calls, which should cause the test
to fail. So, it seems the test is not testing anything.

There might be other rustdoc `run-make-fulldeps` test that are likewise
ineffective. We should test those too to make sure they work.
Repository: pytorch
Issue: Support docstring definition in torch/library.h operator definition
Labels: triaged,enhancement

Suggested by @kennyhorror; the basic idea would be to make it possible to say something like `m.def(schema, docstring)` (or maybe some other API) and then have this docstring be made available from our Python bindings (possibly among other things). This would let people place documentation for operators at the same logical location as where they define it.
Repository: node
Issue: "zlib.createGunzip()._transform" results in an abort
Labels: stream

<!--
Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help


Please fill in as much of the template below as you're able.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or output of `"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"` in PowerShell console (Windows)
Subsystem: if known, please specify affected core module name
-->

* **Version**: v14.15.1
* **Platform**:  Linux 5.8.0-38-generic #43~20.04.1-Ubuntu SMP Tue Jan 12 16:39:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
* **Subsystem**: zlib.createGunzip

### What steps will reproduce the bug?
Setup a node instance,
```
» node
```
and run the following javascript code.
```
zlib.createGunzip()._transform("")
```
Then an abort occurs.
<!--
Enter details about your bug, preferably a simple code snippet that can be
run using `node` directly without installing third-party dependencies.
-->

### How often does it reproduce? Is there a required condition?
This abort can always be triggered following the steps above.

### What is the expected behavior?
If any error occurs, an exception or other similar error-reporting stuff should be thrown. There is no reason to abort the whole node process.
<!--
If possible please provide textual output instead of screenshots.
-->

### What do you see instead?
```
» node
Welcome to Node.js v14.15.1.
Type ".help" for more information.
> zlib.createGunzip()._transform("")
node[180922]: ../src/node_zlib.cc:316:static void node::{anonymous}::CompressionStream<CompressionContext>::Write(const v8::FunctionCallbackInfo<v8::Value>&) [with bool async = true; CompressionContext = node::{anonymous}::ZlibContext]: Assertion `Buffer::HasInstance(args[1])' failed.
 1: 0xa03530 node::Abort() [node]
 2: 0xa035ae  [node]
 3: 0xac2baa  [node]
 4: 0xbe369b  [node]
 5: 0xbe4c46  [node]
 6: 0xbe52c6 v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [node]
 7: 0x13ff259  [node]
[1]    180922 abort (core dumped)  node
```
<!--
If possible please provide textual output instead of screenshots.
-->

### Additional information

<!--
Tell us anything else you think we should know.
-->
Repository: pytorch
Issue: Add OpInfo metadata for "is_torch_functional" and a skip for these ops in TestOperatorSignatures.test_get_torch_func_signature_exhaustive
Labels: module: tests,triaged,module: fx

PyTorch has some "Torch functionals":

https://github.com/pytorch/pytorch/blob/ba9f12d2353b775ea272f0658e0c8f12b2bf4dc0/torch/functional.py#L19

which test_fx.py's TestOperatorSignatures.test_get_torch_func_signature_exhaustive would prefer to filter. See the test at:

https://github.com/pytorch/pytorch/blob/4a74b0f2ddb3a01c0968a94d28d32f6160753c00/test/test_fx.py#L2170

We should update the OpInfos for these operators with `is_torch_functional=True` and either skip them in the test or filter the ops the test runs over to exclude them. 

See discussion here for background: https://github.com/pytorch/pytorch/pull/53994#issuecomment-805094422.

cc @mruberry @ezyang @VitalyFedyunin @walterddr @jamesr66a
Repository: go
Issue: x/tools/gopls: support renaming an embedded field at its declaration
Labels: NeedsInvestigation,FeatureRequest,gopls,Tools

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +f4b918384d Tue Mar 23 05:12:39 2021 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.1.1-0.20210319205745-d7a25adab0d9
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20210319205745-d7a25adab0d9
</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
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel +f4b918384d Tue Mar 23 05:12:39 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1525600331=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Follow up from https://github.com/golang/go/issues/43616#issuecomment-759058419 (cc @mdempsky)

Relatively frequently I find myself in the following situation:

```
type T int

type S struct {
    T
}
```

With the cursor on the embedded `T` in `S`.

I then initiate a rename, but get:

```
gopls.Rename failed: can't rename embedded fields: rename the type directly or name the field
```

The fix in this instance is to jump to the definition of `T`, rename, then jump back. But obviously `gopls` can do that 😄 

To my mind this case is distinct from the case of selector expressions mentioned in https://github.com/golang/go/issues/43616#issuecomment-759058419: such a situation is more ambiguous because we can't be sure the user knows the field in question is an embedded field. 

But in this case our cursor is on the declaration of the embedded field, so there can be no ambiguity. 

cc @findleyr 

FYI @leitzler
Repository: pytorch
Issue: Question when I use Pytorch Mobile
Labels: needs reproduction,triaged,oncall: mobile

## ❓ Questions and Help

Hello, I'm using Pytorch Mobile to deploy a model to phone via Android Studio.

I follow the official direction turn the model in to '.pt' , and load it in android studio, but it seems that it doesn't give the right prediction after turn it into '.pt', it always predict to the same label no matter any label of image I feed in.

The second question is that ,how can I avoid normalization in function  `TensorImageUtils.bitmapToFloat32Tensor`  , just  turn it in to Tensor.
Repository: ant-design
Issue: Modal/Dialog ESC close only works on topmost one when there are multiple Modals/Dialogs opening in parallel
Labels: Inactive,improvement,⌨️ Accessibility

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[https://ant.design/components/modal/#components-modal-demo-confirm-router](https://ant.design/components/modal/#components-modal-demo-confirm-router)

### Steps to reproduce
Press Esc key and try to close opening dialogs one after another. 

### What is expected?
For each one of them, Esc key close should work in a consistent manner, which is closing the dialog.

### What is actually happening?
Only the topmost dialog would be closed. Then it stops working for the rest of them.

| Environment | Info |
|---|---|
| antd | 4.14.1 |
| React | v16  |
| System | macos catalina |
| Browser | chrome 89 |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: flutter
Issue: pubspec with faulty git config leads to error 128 and infinite retries
Labels: tool,dependency: dart,a: error message,has reproducible steps,P2,found in release: 3.0,found in release: 3.1,team-tool,triaged-tool

My CI was up all night banging his head on the wall.
This git error should, IMO, ideally be caught and be deemed more terminal.

(For some reason it Worked On My Machine and I've since fixed the access for the CI too, this issue is really just about the infinite loop)

Log looping as follows:
```
Git error. Command: `git clone --mirror git@github.com:xxxxxxxxxxx.git xxxxxxxxxxxxxx`

stdout: 

stderr: Cloning into bare repository 'xxxxxxxxxxxxxx'...

git@github.com: Permission denied (publickey).

fatal: Could not read from remote repository.



Please make sure you have the correct access rights

and the repository exists.

exit code: 128

pub get failed (server unavailable) -- attempting retry 668 in 64 seconds...

```
Repository: go
Issue: doc: remove undefined concept from getting-started documentation
Labels: Documentation,NeedsInvestigation

On page https://golang.org/doc/tutorial/getting-started
Change "Use the Go package discovery tool to find packages you can use in your own code. " to
"Use pkg.go.dev to find published packages you can use in your own code."

If that's not good enough I suggest to define what a "package discovery tool" is, before using this concept in a getting-started document.
Repository: vscode
Issue: Git - No more surrounding or auto-closing in commit msg box
Labels: bug,help wanted,git

<!-- ⚠️⚠️ 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.54.3
- OS Version: Windows_NT x64 10.0.19042

Steps to Reproduce:

1. Write a commit message
2. Select a word, type `` ` ``

Expected: the word is surrounded by `` ` `` like in VS Code v1.44.2.

Since 1.45, this doesn't happen anymore, instead the word is replaced by `` ` ``. It's the same with auto-closing.

This was very useful to type markdown-like commit messages. If this is not a bug/intended, is there a way to reenable this behavior?

v1.44.2 : 
![recording (3)](https://user-images.githubusercontent.com/1735067/112293907-efba2600-8c92-11eb-9862-40ab128e7852.gif)

v1.54.3 (1.51.1 for the capture but it's the same since 1.45) : 
![recording (4)](https://user-images.githubusercontent.com/1735067/112294056-18422000-8c93-11eb-85f6-866dbaf31526.gif)

<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes
Repository: PowerToys
Issue: Two different records with the same name and subtitle
Labels: Issue-Bug,Product-PowerToys Run,Area-Quality,Area-User Interface,Planning-Consideration

We need to figure out If it is legal to have two records with the same name and subtitle as in https://github.com/microsoft/PowerToys/issues/3148#issuecomment-802665505. Note that programs are different. It also can happen with shortcuts.

If it is legal then we have to change `UserSelectedRecord.json` logic as right now it uses `Title+Subtitle` as a key.
Repository: go
Issue: x/crypto/ssh: Wrap error in NewClientConn
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.10 linux/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
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mv/.cache/go-build"
GOENV="/home/mv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/mv/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/mv/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/mv/.local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/mv/.local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.2"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build650852416=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->

https://play.golang.org/p/CdUXyBdUq2g

### What did you expect to see?

Using type assertion or `errors.As` for things like `*net.OpError` on errors returned by `NewClientConn` works.

### What did you see instead?

The returned error is a `*errors.errorString` due to the fact that it's returned using `fmt.Errorf` and `%v` instead of `%w`.
Repository: electron
Issue: [Feature Request]:  close asar manually
Labels: enhancement :sparkles:,component/asar

Asar fd not closed on windows after use (by sandboxed renderer).
A lock was held by the main process, preventing the file to be removed.

### Proposed Solution

Implement asar cache management and expose public API to allow asar files be closed manually.


#28195 was not fixed by #28137.

As of v12.0.2, there were issue with asar file fd handling on Windows.

The file would be kept open by the main process once used, and no way to close it.

#28195 was previously submitted, but NOT resolved by #28137.

Maybe It's time to provide a public API to manage asar files. 

In my scenario, ASAR files was to be used as plugin packages, thus needs to be replaced or removed when process is still running.
It seems ok to do it on macOS , but not on Windows.


I guess some of asar related code is to be refactored, so please consider this proposal.

Thanks.
Repository: pytorch
Issue: Make searchsorted and bucketize API consistent
Labels: module: docs,triaged,module: numpy,module: deprecation,module: ux

## 🐛 Bug

I was a bit surprised by the fact that the API of `searchsorted` and `bucketize` is different, since the first two arguments are in opposite order.

I was originally using `searchsorted` with a 1-D array and noticed the following *Note* in the documentation:
> If your use case is always 1-D sorted sequence, `torch.bucketize()` is preferred, because it has fewer dimension checks resulting in slightly better performance.

So I switched to use `bucketize` and noticed that the API is incompatible, which I think is an unnecessary inconvenience from the user perspective. (Of course I'm not sure if this was a conscious decision based on information I'm not aware of :P )
But if not, is it possible to align the two?  

Currently: 
```py
torch.searchsorted(sorted_sequence, values, ...)
torch.bucketize(input, boundaries, ...)
```
I think more natural would be to align `bucketize` to `searchsorted` by swapping the arguments and IMHO also renaming them as I find the `searchsorted` naming more self-documenting.


Small additional sidenote re the *Note* in the documentation. I wasn't really able to see any speed difference between the two.
When looking at [Bucketization.cu](https://github.com/pytorch/pytorch/blob/2ecb2c79312eac6924182fe343dc3cd9a205305c/aten/src/ATen/native/cuda/Bucketization.cu) and [Bucketization.cpp](https://github.com/pytorch/pytorch/blob/2ecb2c79312eac6924182fe343dc3cd9a205305c/aten/src/ATen/native/Bucketization.cpp)  it seems that `bucketize` really just forwards its search to `searchsorted` so the only speedup could potentially come, from the additional `__builtin_expect` which is injected via the  `TORCH_CHECK` call in `bucketize`. But was it ever actually checked that this enabled the compiler to do something smarter and thus make `bucketize` faster ?




cc @brianjo @mruberry @rgommers @heitorschueroff
Repository: go
Issue: x/build/cmd/relui: add checkbox to Go installers to delete previous GOENV configuration file
Labels: Builders,NeedsInvestigation,FeatureRequest

I had a problem recently (#45174) where after reinstalling golang the `go env file` would remain unchanged and this caused multiple issues since all tools and binaries were compiled for 386 arch and not for amd64 arch (as I expected).

I understand that many people want to preserve the old configuration after an update or reinstallation... but sometimes a "true" clean install might be useful.

What I suggest is to add a checkbox in the golang installation program that, if set to true, will wipe out all previous config (either all or some selectable folders) (`%GOENV%`, `%GOPATH%`, `%GOCACHE%` ... etc).

thanks