sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/compile: inefficient assembly code generated by simple loop&branch code
Labels: Performance,NeedsFix

<!--
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.17 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
yes


### What operating system and processor architecture are you using (`go env`)?
centos8 & amd64

### What did you do?

Given the code:
<pre>
//go:noinline
func test_loop(arr []int) (resp int){
        max := 0
        for i := 0; i < len(arr); i++ {
                if (arr[i] > max) {
                        max = arr[i]
                }
        }
        return max
}
</pre>


### What did you expect to see?
<pre>
TEXT "".test_loop2(SB), ABIInternal
00001 (28) FUNCDATA $0, gclocals·1a65e721a2ccc325b382662e7ffee780(SB)
00002 (28) FUNCDATA $1, gclocals·69c1753bd5f81501d95132d08af04464(SB)
00003 (28) FUNCDATA $5, "".test_loop2.arginfo1(SB)
00004 (31) XORL CX, CX
00005 (31) XORL DX, DX
00006 (30) JMP 8
00007 (+30) INCQ CX
00008 (+30) CMPQ BX, CX
00009 (30) JLE 15
00010 (+31) MOVQ (AX)(CX*8), SI
00011 (31) CMPQ DX, SI
00012 (31) JGE 7
00013 (31) MOVQ SI, DX
00014 (+34) JMP 7
00015 (+36) MOVQ DX, AX
00016 (36) RET
00017 (?) END
</pre>


### What did you see instead?
<pre>
00000 (40) TEXT "".test_loop3(SB), ABIInternal
00001 (40) FUNCDATA $0, gclocals·1a65e721a2ccc325b382662e7ffee780(SB)
00002 (40) FUNCDATA $1, gclocals·69c1753bd5f81501d95132d08af04464(SB)
00003 (40) FUNCDATA $5, "".test_loop3.arginfo1(SB)
00004 (43) XORL CX, CX
00005 (43) XORL DX, DX
00006 (42) JMP 9
00007 (+42) INCQ CX
00008 (43) MOVQ SI, DX
00009 (+42) CMPQ BX, CX
00010 (42) JLE 16
00011 (+43) MOVQ (AX)(CX*8), SI
00012 (43) CMPQ DX, SI
00013 (43) JLE 7
00014 (43) MOVQ DX, SI
00015 (43) JMP 7
00016 (+47) MOVQ DX, AX
00017 (47) RET
00018 (?) END
</pre>

The above assembly code has 2 more invalid move operations than the first code. Can someone help explain the reason?
Repository: pytorch
Issue: Hope to obtain authorization for Chinese translation of official tutorials.
Labels: module: docs,triaged

## 📚 Documentation

<!-- A clear and concise description of what content in https://pytorch.org/docs is an issue. If this has to do with the general https://pytorch.org website, please file an issue at https://github.com/pytorch/pytorch.github.io/issues/new/choose instead. If this has to do with https://pytorch.org/tutorials, please file an issue at https://github.com/pytorch/tutorials/issues/new -->


cc @brianjo @mruberry
Repository: godot
Issue: Exported dictionary inspector 'Remove Item' option in new key/value dropdown prints error
Labels: bug,topic:editor,usability

### Godot version

3.3.4.stable.mono.official

### System information

Windows 10

### Issue description

The inspector of exported dictionaries has a 'Remove Item' entry in the dropdown of 'New Key' and 'New Value' and selecting this option prints an error to the console: "core/variant_call.cpp:1181 - Index p_type = 27 is out of bounds (VARIANT_MAX = 27)."
![grafik](https://user-images.githubusercontent.com/8841352/136656593-5e574278-e6db-4af7-a64c-b06c50a9353b.png)


### Steps to reproduce

export a dictionary (in the above case it was a System.Collections.Generic.Dictionary<string, string>, but it's the same for the Godot.Collections.Dictionary), open one of the described dropdowns and select the 'Remove Item' option.

### Minimal reproduction project

_No response_
Repository: pytorch
Issue: Feature Request: Add constant padding_mode for grid_sample
Labels: feature,module: nn,triaged,module: padding,module: interpolation

## 🚀 Feature
constant padding_mode for grid_sample

## Motivation

We need a constant padding_mode to train a new network.



cc @albanD @mruberry @jbschlosser @walterddr
Repository: go
Issue: regexp: doOnePass does unnecessary check when regexp has a prefix
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel go1.18-541ef34ada Sun Oct 3 18:09:11 2021 +0100 darwin/arm64
</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=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/bryan/Library/Caches/go-build"
GOENV="/Users/bryan/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/bryan/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/bryan/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/bryan/src/github.com/golang/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/bryan/src/github.com/golang/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="devel go1.18-541ef34ada Sun Oct 3 18:09:11 2021 +0100"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/bryan/src/github.com/golang/go/src/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bp/y4j6bp157f52wv55knd_j1fc0000gn/T/go-build3663975253=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

Small example: https://play.golang.org/p/y46WA2Dc2dI - adapted from regexp `BenchmarkAnchoredLiteralShortNonMatch`;
the expression has `.*$` added to make it go down the onepass branch.

This statement: https://github.com/golang/go/blob/e1c294a56d5d03cdba1f059cdb6b1225477dc546/src/regexp/exec.go#L431-L433
checks that the current runes match the op, but at regexp compile-time it is established that the start op must be `EmptyBeginText`:
https://github.com/golang/go/blob/e1c294a56d5d03cdba1f059cdb6b1225477dc546/src/regexp/onepass.go#L470-L473

`EmptyBeginText` will always match at position 0 of the input

### What did you expect to see?
The check `flag.match(syntax.EmptyOp(inst.Arg))` can be removed from run-time execution of the regexp, which means `i.hasPrefix` can be moved before the instruction and first runes are unpacked. 

### What did you see instead?
In the case where a onepass regexp has a prefix which does not match, a bit of unnecessary time is spent initializing.
Repository: rust
Issue: Debuginfo for `windows-msvc` treats `()` as `tuple$<>`
Labels: A-debuginfo,C-enhancement,T-compiler,O-windows-msvc

@michaelwoerister [found](https://github.com/rust-lang/rust/pull/89597#discussion_r724814185), debuginfo for the `windows-msvc` targets currently names the `()` type as `tuple$<>`. We should probably try to name the unit type `()` for consistency with Rust. 

Relatedly, it may make sense to have natvis which sets a `<DisplayString />` for ZSTs to just the type name.
Repository: godot
Issue: Deleting textures/resources from Tileset is permanent even if do not save and you also lose tilemap data
Labels: bug,topic:editor,topic:2d

### Godot version

3.3 stable

### System information

linux mint 19

### Issue description

If you delete an entry from the tileset:
![image](https://user-images.githubusercontent.com/12863685/136666436-015627ee-d7f4-429e-926d-f8e9abfc2aba.png)

For example I have removed the first texture, as you can see the scene file is marked as updated and needing saving:
![image](https://user-images.githubusercontent.com/12863685/136666483-b6ed59b2-3f3b-42c4-b00c-b99a4b81d4d3.png)

If you then close the scene without saving, when you open, then any changes you have made to the tilemap that do not involve those deleted textures, such as tilemap and config updates updates, are back to normal as you would expect, however, the tileset change is permanent and you have lost not only the entry in the tileset, but every tile is permanently set to -1 and those are lost too.

![image](https://user-images.githubusercontent.com/12863685/136666566-f3ea2614-b985-4595-9a91-3ddda69a04ea.png)


### Steps to reproduce

As above, remove a texture, do not save and you lose not only the tileset but every tile in the tilemap that ever used it on re-opening.

### Minimal reproduction project

_No response_
Repository: TypeScript
Issue: Const variables initialized with parenthesized arrow expression cannot get expando properties
Labels: Suggestion,Awaiting More Feedback

# Bug Report

### 🔎 Search Terms

expando, property assignments, arrow expression, #26368, #44988, #42203

### 🕗 Version & Regression Information

- This is the behavior in every version I tried since TypeScript 3.1

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.5.0-dev.20211009#code/C4TwDgpgBAIhDOBjATgSwEYEN0BsIDEBXAO0WFQHtioBeKAbwFgAoKNqAEwRVTHKoBcUeMDTEA5gG4W7KAAp4FALYQAgsnFDihJegjIAlEPQUKeTMWnMAvlZaIqIqBQDWQuEjRZcBEmUrUdHIAHlo6eoa0AHxQAGaYOPAQVq4AdFyevPyBUADkGTx8Abl2zA7ETi4U7txe2HhEpNm08iFhuvoG0XEJSQaSUAD0g1D6yBTIAIQsw7IAfnNQADwAtCtQAArjkMigeQVoRVS5UKjwUEpn8KgSLFXptVkBLfmPR8QlLCxAA)

### 💻 Code

```ts
type DescribableFunction = {
    description: string;
    (someArg: number): boolean;
};

const ok: DescribableFunction = (x: number) => false;
ok.description = 'description';

const ko: DescribableFunction = ((x: number) => false); // error!
//    ~~ <-- Property 'description' is missing
ko.description = 'description';
```

### 🙁 Actual behavior

`ko` is not recognized as a function capable of having expando properties added to it, while `ok` is recognized as such.

### 🙂 Expected behavior

Both `ok` and `ko` should behave the same way and allow expando properties as implemented in #26368.  I don't know if it's common or not to use parentheses in this situation, but it was surprising to me when I ran into this discrepancy.  I see from #44988 and #42203 that sometimes parentheses will disrupt things, so this is presumably an unanticipated use case that may not be important enough for anyone to address.
Repository: godot
Issue: OS.set_window_maximized(false) doesn't work
Labels: bug,platform:linuxbsd,topic:porting

### Godot version

v3.3.4.stable.official.faf3f883d

### System information

Ubuntu 20.04, GLES3,  Mesa Intel(R) UHD Graphics (ICL GT1)

### Issue description

`OS.set_window_maximized(false)` does nothing.
Expected to un-maximize the window. 

### Steps to reproduce

- Create a new project
- Add a User Interface (Control node) 
- Add a button node as a child of Control node
- Attach a script to the button node
- Connect `pressed` signal of button to self
Replace the button script with the below code-
```
extends Button

func _on_Button_pressed():
	if OS.is_window_maximized():
		OS.set_window_maximized(false)
	else:
		OS.set_window_maximized(true)

```

- Save the scene and run.
- Click the button to maximize and un-maximize the window


### Minimal reproduction project

[max_min.zip](https://github.com/godotengine/godot/files/7316095/max_min.zip)
Repository: flutter
Issue: TextField cursor display when the keyboard is closed should match the Platform
Labels: a: text input,platform-ios,framework,a: fidelity,a: quality,c: proposal,P2,team-framework,triaged-framework

In native development:

* In the **Android**, the text-field cursor should keep blinking when the soft keyboard is closed and the text-field has focus.
* In the **iPhone**, the text-field cursor should hide as soon as the keyboard is closed.

Flutter is only implementing the Android behavior. I'd like the `TextField` to implement this difference automatically, to match the Platform.

Please note: I know we can make `TextField(showCursor: false...)` to hide the cursor, but I can´t achieve that myself since I don´t know for sure when the keyboard is closed/open, and also some devices have physical keyboards.
Repository: rust
Issue: slice::rotate_left/right is not simplified for compile-time-constant small rotates
Labels: I-slow

The current (2021-10-08 nightly) and recent implementations of `slice::rotate_right` produce 15x more instructions than a manual special-case implementation for a small rotate by a compile-time constant offset. This results in a 5-50% performance difference, depending on the length of the slice in question.

godbolt demonstration: https://godbolt.org/z/a4YdqP1rn
```rust
pub fn shift_after_fast(vec: &mut [usize], i: usize) {
    if i > vec.len() || (vec.len() - i) < 2 {
        return;
    }
    unsafe {
        let tmp = core::ptr::read(vec.as_ptr().add(vec.len() - 1));
        core::ptr::copy(
            vec.as_ptr().add(i),
            vec.as_mut_ptr().add(i + 1),
            vec.len() - i - 1,
        );
        core::ptr::write(vec.as_mut_ptr().add(i), tmp);
    }
}

pub fn shift_after(vec: &mut [usize], i: usize) {
    vec[i..].rotate_right(1);
}
```

I think the current implementation doesn't optimize well because it is a `loop {` surrounding three rotate algorithms with their own predicates, the first of which is almost never known at compile time:
```rust
if (left + right < 24) || (mem::size_of::<T>() > mem::size_of::<[usize; 4]>()) {
```
and it is the second algorithm that we want to run in this case:
```rust
} else if cmp::min(left, right) <= mem::size_of::<BufType>() / mem::size_of::<T>() {
```

Simply pasting a copy of the second algorithm above the loop removes the performance difference and most but not all of the code size difference.

cc @scottmcm I've finally gotten around to reporting this after months

```
rustc 1.57.0-nightly (54bb4fec6 2021-10-08)
binary: rustc
commit-hash: 54bb4fec68cb592e23077896baea072919721573
commit-date: 2021-10-08
host: x86_64-unknown-linux-gnu
release: 1.57.0-nightly
LLVM version: 13.0.0
```
Repository: godot
Issue: Godot Engine has stopped working
Labels: bug,platform:windows,topic:core,needs testing

### Godot version

Godot_v3.3.4-stable_mono_win64

### System information

Windows 10

### Issue description

After I reset my laptop I have not been able to run Godot
every time I try to run Godot it badly runs the program before it stops immediately and comes up with a text box that says  "A problem caused the program to stop working correctly.  Windows will close the program and notify you if a solution is available"
I do not know what is wrong and it usually works before I reset my laptop...
I do not know if it may be because I also updated my driver and the update maybe have deleted some older versions of OpenGL and if that's the problem, how can I install them again?

### Steps to reproduce

![Screenshot (2)](https://user-images.githubusercontent.com/45533771/136674005-ed8d5bbb-f396-495e-8eca-df97f40e568c.png)


### Minimal reproduction project

_No response_
Repository: rust
Issue: `x.py clippy` doesn't work on Windows
Labels: T-bootstrap,C-bug

`x.py clippy` doesn't work on Windows.
I double checked and my default toolchain is set to `nightly` and the `clippy` component is installed.
However I get the following error message when running `x.py clippy` on Windows:
```
error: `x.py clippy` requires a host `rustc` toolchain with the `clippy` component
help: try `rustup component add clippy`
```
The error message seems to be really misleading.
As you can tell from the [source code](https://github.com/rust-lang/rust/blob/bc8ad24020a160e1acd7ac9f7671947dcc01264c/src/bootstrap/builder.rs#L962), it actually failed to run `rustc --version`.
The `host_version` (`Command::output()` of `rustc --version`) looks like this:
```
Ok(
    Output {
        status: ExitStatus(
            ExitStatus(
                101,
            ),
        ),
        stdout: "",
        stderr: "thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', src\\bootstrap\\bin/rustc.rs:47:41\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\n",
    },
)
```

### Meta
`rustc --version --verbose`:
```
rustc 1.57.0-nightly (54bb4fec6 2021-10-08)
binary: rustc
commit-hash: 54bb4fec68cb592e23077896baea072919721573
commit-date: 2021-10-08
host: x86_64-pc-windows-msvc
release: 1.57.0-nightly
LLVM version: 13.0.0
```
Repository: rust
Issue: False-positive `dead_code` warning for code only used in compile-time assertions
Labels: A-diagnostics,T-compiler,A-const-eval

Sometimes when I want to assert some safety invariant I'll write a constant that asserts it at compile time instead of a test to ensure my code won't compile if it's violating that invariant.

Given the following code: <https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=5c02e5e11f9bd262648dd7fb92dd9b81>

```rust
const fn one() -> usize {
    1
}

const _CT_ASSERT: () = {
    assert!(one() == 2);
};
```

The current output is:

```
warning: function is never used: `one`
 --> src/lib.rs:1:10
  |
1 | const fn one() -> usize {
  |          ^^^
  |
  = note: `#[warn(dead_code)]` on by default

error[E0080]: evaluation of constant value failed
 --> src/lib.rs:6:5
  |
6 |     assert!(one() == 2);
  |     ^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: one() == 2', src/lib.rs:6:5
  |
  = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0080`.
```

I'd expect rustc to not emit the `dead_code` warning because the function is clearly being used at compile time, the assert even fails in this case.

It is possible that I'm misusing const eval here and that the code in the constant initializer is not guaranteed to run at compile time if the constant itself is not used and therefore all code used in its initializer is not considered used either. (The warning does disappear when i use the constant itself, which would be consistent with this.) In which case I'd want to turn this into a question, is there any other way to write compile-time assertions like this one?
Repository: go
Issue: encoding/json: returned io.Writer errors can be confusing without wrapping
Labels: NeedsDecision

<!--
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 1.16

</pre>

### Does this issue reproduce with the latest release?
I must assume it does (not a bug, just poor design)


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
windows/amd64
</pre></details>

### What did you do?
```
package main

import (
	"encoding/json"
	"errors"
	"log"
	"os"
)

func main() {
	// read some data from myfile
	file, err := os.Open("myfile")
	if errors.Is(err, os.ErrNotExist) {
		// the file doesn't exist, let's create it

		// OOPS! I forgot to actually create the file!

		// Let's just try to populate it with some data
		var myData = 123
		err = json.NewEncoder(file).Encode(myData)
		if err != nil {
			log.Fatalln("error encoding:", err)
		}
	}
}
```
Of course, in a stripped-down example the error is obvious. And it was even obvious once I had a clue of what to look for. The reason why I'm posting this issue is because the error message was not only unhelpful, but very misleading. It is a result of the json (and gob and perhaps other) packages simply forwarding error messages from other packages without wrapping them for context.

### What did you expect to see?
A useful error message, telling me why Encode had failed.

### What did you see instead?
The plain error message "invalid argument", which is very misleading and caused some wasted time trying to source.
When you call a method and receive an error message "invalid argument", it is only natural to assume that the error was due to the arguments passed to said method. However, that is not the case here. The error is actually due to the file which was used to create the encoder. In addition, the error message is so short and plain, I had trouble trying to just determine from where it originated (due to poor searchability).
Repository: go
Issue: cmd/go/internal/cache: provide GOFUZZCACHE environment variable 
Labels: NeedsDecision,FeatureRequest,fuzz

Go provides `GOCACHE` and `GOMODCACHE` environment variables to control build and modules cache locations. There is no environment variable to control fuzz corpus cache location; it is hard-coded to be `$GOCACHE/fuzz`.

I think that fuzz cache is significantly different from the build (and test) cache:
* it is being cleaned by different `go clean` flags;
* it has a different lifetime (#48526);
* it is a bit more valuable than a build cache (it takes more time to find interesting inputs than "just" compilation);
* etc.

For that reason, I think it would be helpful to provide `GOFUZZCACHE` environment variable to control fuzz cache location. That would help people building automation around sharing that cache between machines.

(I'm also not really sure that fuzz cache directory should be a subdirectory of the build cache by default, but that might be too late to change that.)

/cc @katiehockman @jayconrod
Repository: rust
Issue: Enhance E0463 "can't find crate" error message by hints indicating the starting point of a path to a solution.
Labels: A-diagnostics,T-compiler

Given the following code: [Playground Link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=789e6c67bf0e73b4b49b82e6e91a5b96)

```rust
#![feature(plugin, core)]
#![plugin(phf_macros)]

fn main() {
    println!("hello world");
}
```

The current output is (for stable and nightly):

```
   Compiling playground v0.0.1 (/playground)
error[E0463]: can't find crate for `phf_macros`
 --> src/main.rs:2:11
  |
2 | #![plugin(phf_macros)]
  |           ^^^^^^^^^^ can't find crate

For more information about this error, try `rustc --explain E0463`.
error: could not compile `playground` due to previous error
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
   Compiling playground v0.0.1 (/playground)
error[E0463]: can't find crate for `phf_macros`
 --> src/main.rs:2:11
  |
2 | #![plugin(phf_macros)]
  |           ^^^^^^^^^^ can't find crate

Hints:
    - If using Cargo, double check your entry in `[dependencies]` section in Cargo.toml.
    - Check if the crate you want to use is present at crates.io.
    - When in a process of upgrading, double check the documentation of the crate you want to use.
      There may be a breaking change between the versions.

For more information about this error, try `rustc --explain E0463`.
error: could not compile `playground` due to previous error
```

Maybe it would be nice to get something like a small checklist on how to address this issue? I filled the proposed output above with things that came to my mind (and by copying from `rustc --explain E0463`) while writing the issue.