sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Possibly confusing error message when deref/deref_mut are used.
Labels: C-enhancement,A-diagnostics,T-compiler

Beginners can be confused when `deref` and `deref_mut` are called implicitely:

- https://stackoverflow.com/questions/47060266/error-while-trying-to-borrow-2-fields-from-a-struct-wrapped-in-refcell
- https://stackoverflow.com/questions/54942045/accessing-two-vectors-in-a-struct-locked-by-a-mutex

In this given code:

```rust
struct Foo {
    a: Vec<i32>,
    b: Vec<i32>,
}

fn add(foo: std::sync::Mutex<Foo>) {
    let f = foo.lock().unwrap();

    for i in &mut f.a {
        for j in &f.b {
            *i += *j;
        }
    }
}
```

The error message is not the clearest:

```
error[E0502]: cannot borrow `f` as immutable because it is also borrowed as mutable
  --> src/lib.rs:10:19
   |
9  |     for i in &mut f.a {
   |              --------
   |              |    |
   |              |    mutable borrow occurs here
   |              mutable borrow used here, in later iteration of loop
10 |         for j in &f.b {
   |                   ^ immutable borrow occurs here
```

The users could not understand that the borrows are done by `deref` and `deref_mut`, since the calls are implicit. They could think that, for an unknown reason, the borrow checker does not understand that the fields are disjoint.

I think that it would be an improvement if the compiler added that the implicit call to `deref`/`deref_mut` is responsible of the borrowing:

```
error[E0502]: cannot borrow `f` as immutable because it is also borrowed as mutable
  --> src/lib.rs:10:19
   |
9  |     for i in &mut f.a {
   |              --------
   |              |    |
   |              |    mutable borrow occurs here due to a call to `Deref::deref`
   |              mutable borrow used here, in later iteration of loop
10 |         for j in &f.b {
   |                   ^ immutable borrow occurs here due to a call to `DerefMut::deref_mut`
```

This could be even better if the compiler gave the solution:

```
You can call `DerefMut::deref_mut` before borrowing the fields:
  --> src/lib.rs:8:1
7  |    let mut f = foo.lock().unwrap();
   |    let f = DerefMut::deref_mut(&mut f);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Repository: go
Issue: index/suffixarray: FindAllIndex gives wrong results for anchored regexp
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

It does reproduce with Go versions 1.3 to 1.12 (latest at the time of writing), but it works as expected in Go version 1.2.


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build610735870=/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.
-->

I called the suffixarray FindAllIndex method with a regexp anchored both to the beginning and end of text (https://play.golang.org/p/TaXeqtHt4Iq):

```
func main() {
	idx := suffixarray.New([]byte("banana"))
	re := regexp.MustCompile("^a$")
	fmt.Println(idx.FindAllIndex(re, -1))
	// Output:
	// [[1 2] [3 4] [5 6]]
}
```

### What did you expect to see?

I expected an empty result `[]`, the same result as for the equivalent regexp method FindAllIndex (https://play.golang.org/p/PVThOv1EE8S):
```
func main() {
	re := regexp.MustCompile("^a$")
	fmt.Println(re.FindAllIndex([]byte("banana"), -1))
	// Output:
	// []
}
```

### What did you see instead?

suffixarray FindAllIndex returned the following index pairs in "banana" for the regexp "^a$":
```
[[1 2] [3 4] [5 6]]
```
The FindAllIndex documentation reads:

> FindAllIndex returns a sorted list of non-overlapping matches of the regular expression r, where a match is a pair of indices specifying the matched slice of x.Bytes(). If n < 0, all matches are returned in successive order. Otherwise, at most n matches are returned and they may not be successive. The result is nil if there are no matches, or if n == 0. 

There are no matches for the expression "^a$" in the string "banana". Therefore the result should be empty, nil.

Go 1.2 produced the expected result. This is a regression in Go 1.3 where the behaviour of the regexp method LiteralPrefix changed. See the discussion in #30425.
Repository: rust
Issue: Compiler Team Steering Meeting
Labels: metabug,T-compiler

**This issue exists to describe the compiler team steering meeting and to collect links about it.** It is closed for comments since it's not meant to collect discussion; if you'd like to give feedback about the steering meeting, please feel free to [open a topic in Zulip][z].

[z]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler
[cal]: https://github.com/rust-lang/compiler-team#meeting-calendar

## What is it

The steering meeting is our chance to discuss procedural topics, track our progress, and just generally step back from the "daily grind" of triage. It takes place [every three weeks][cal] on [Zulip][z].

## How it works

The meeting begins with a **10 minute** announcement period. We then turn to more in-depth discussion of this week's topic(s).

After the meeting, a summary is posted to the [compiler-team repository](https://github.com/rust-lang/compiler-team/tree/master/minutes/steering-meeting). To aid with this, people use the `:point_up:` ☝️ emoji during the meeting to help highlight key comments that might want to be included in the summary.

The procedural stuff is more completely described here: https://github.com/rust-lang/compiler-team/blob/master/procedures/steering-meeting.md

## Handy links

- Between meetings, we track [potential agenda topics](https://hackmd.io/wsHwsi9zR3iq0ZF2SgEq9Q#) in a HackMd document.
- [Internals thread](https://internals.rust-lang.org/t/compiler-steering-meeting/8588/46) -- we post the agenda to this thread, along with summaries of the meetings.
- [Meeting summaries](https://github.com/rust-lang/compiler-team/tree/master/minutes/steering-meeting) -- after each meeting, we post a summary of what happened. You can view the full meeting by going to appropriate Zulip topic.
- The [compiler team calendar][cal] lists the steering meetings so you can track when they are.
Repository: go
Issue: cmd/go: confusing error on mod edit -replace=old=..
Labels: NeedsInvestigation,modules

### What version of Go are you using (`go version`)?

    go version devel +44d3bb998c Fri Mar 1 07:45:00 2019 +0000 linux/amd64

### Does this issue reproduce with the latest release?

Yes.

### What did you do?

```
$ mkdir test
$ cd test
$ go mod init test
go: creating new go.mod: module test
$ go mod edit -replace=foo.com/bar=..
go mod: -replace=foo.com/bar=..: invalid new path: malformed module path "..": double dot
$ go mod edit -replace=foo.com/bar=../
$ cat go.mod
module test

go 1.13

replace foo.com/bar => ../
```

### What did you expect to see?

Replacing a module to `..` would either succeed or give a useful error.

### What did you see instead?

An error saying "double dot", which makes no sense to me as a user. It was @myitcv who pointed out that adding a trailing slash would fix the problem.

From `go help go mod`:

> If the @v in new@v is omitted, the new path hould be a local module root directory, not a module path.

So nothing in the error nor the docs seemed to point me at the missing slash.

/cc @bcmills
Repository: go
Issue: proposal: cmd/go: 'go mod tidy' should remove stale 'replace' directives
Labels: Proposal,NeedsInvestigation,GoCommand

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12 windows/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
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPROXY=
set GORACE=
set GOTMPDIR=
</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.
-->

I created a `go.mod` file with two replaces in separate lines, then run `go mod tidy`. `foo3` replacement is unused.

<pre>
replace foo => bar
replace foo2 => bar2
replace foo3 => bar3
</pre>

### What did you expect to see?

A nicely formatted `go.mod`. Moreover, I think the unused replace should be removed.
<pre>
replace (
        foo => bar
        foo2 => bar2
)
</pre>

### What did you see instead?

The file is unchanged. Also, `go mod edit -fmt` does not format replaces.
Repository: go
Issue: cmd/go: go test -failfast doesn't stop immediately with t.Parallel()
Labels: Performance,NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.10.7 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
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jenkins/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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-build781955494=/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.
-->

```
func TestParallel1(t *testing.T) {
    t.Parallel()
    t.FailNow()
}

func TestParallel2(t *testing.T) {
    t.Parallel()
}
```

run with ` go test -v -failfast -parallel 1` returns:
```
=== RUN   TestParallel1
=== PAUSE TestParallel1
=== RUN   TestParallel2
=== PAUSE TestParallel2
=== CONT  TestParallel1
=== CONT  TestParallel2
--- PASS: TestParallel2 (0.00s)
--- FAIL: TestParallel1 (0.00s)
FAIL
exit status 1
FAIL	test	0.075s
```

### What did you expect to see?

`TestParallel2` not continue.

### What did you see instead?

`TestParallel2` continued execution.
Repository: rust
Issue: sys::unix::fs::canonicalize can lead to undefined-ish behavior on Android
Labels: O-android,T-libs-api

Its code is:
```pub fn canonicalize(p: &Path) -> io::Result<PathBuf> {
    let path = CString::new(p.as_os_str().as_bytes())?;
    let buf;
    unsafe {
        let r = libc::realpath(path.as_ptr(), ptr::null_mut());
        if r.is_null() {
            return Err(io::Error::last_os_error())
        }
        buf = CStr::from_ptr(r).to_bytes().to_vec();
        libc::free(r as *mut _);
    }
    Ok(PathBuf::from(OsString::from_vec(buf)))
}
```

The problem comes from the pair of calls `libc::realpath`, `libc::free`. Under normal conditions, `libc::realpath` calls `malloc`, `libc::free` corresponds to `free` and everyone lives happily every after.

Now, funky things are funky. Say you have a binary that makes `malloc` and `free` be jemalloc. From rust, `libc::malloc` and `libc::free` then point to jemalloc. But here's the catch: libc's `malloc` is not necessarily jemalloc's. That is, while on e.g. Linux, when you have such a setup, libc will happily use jemalloc's `malloc`/`free` for its allocations (as long as it's not built with -Bsymbolic or -Bsymbolic-functions), that's not the case on Android: IIRC, libc is linked in such a way that all its "internal" function calls stay internal (that is, it's built with -Bsymbolic). So when `realpath` calls `malloc`, it calls libc's not jemalloc's. And then `canonicalize` calls `libc::free` with the resulting pointer, which is jemalloc's. Kaboom.

Yes, there is `__malloc_hook` and friends, which would solve the problem if they existed on Android. (Well, they do now, but they don't on Android versions < 9 (and apparently 7 for IoT if I'm to believe tags in the bionic repository).

https://bugzilla.mozilla.org/show_bug.cgi?id=1531887 is a real issue that results from this, although it doesn't involve `-Bsymbolic`, but some subtle dynamic linking setup where rust code is in libxul.so, which depends on libmozglue.so, which provides `malloc`/`free` as jemalloc's, for use by libxul, but all native Android code still ends up using libc's `malloc`/`free`.

For this particular case, it's possible to pass an appropriately-sized buffer to realpath instead of `null`, which makes it allocate on its own (https://pubs.opengroup.org/onlinepubs/009696799/functions/realpath.html says PATH_MAX ; the only system I know that doesn't use those limits is Hurd). For the more general case, it almost feels like there should be an overridable `GlobalAlloc` for the non-rust system allocator.

Cc: @SimonSapin
Repository: godot
Issue: Exported variables in extended script should follow godot natural inheritance order
Labels: enhancement,topic:gdscript

<!-- 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 non-official. -->
5e837b3f13ab1e3b31bb8d705e87820fa4eff21e

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Win7

**Issue description:**
<!-- What happened, and what was expected. -->

An script that extends other script class doesn´t shows in inspector the exported properties in the godot natural inheritance order.

Ej:
Script class named **full_enemy** that extends a class named**basic_enemy** that extends a class **enemy_object** that extends **kinematicBody2D** has this property order in inspector:

- enemy_object
- basic_enemy
- full_enemy
- KinematicBody2D
- PhysicsBody2D
-etc......

If we follow the order that godot naturally follow in inspector (Down in inheritance), the order should be:

- full_enemy
- basic_enemy
- enemy_object
- KinematicBody2D
- PhysicsBody2D
-etc......

(And could be great to see the class difference in inspector in the same way that you can see the differences between Node-Node2D-CanvasItem etc....)
Repository: go
Issue: cmd/compile: unnecessary hash/eq functions for global arrays
Labels: Performance,NeedsInvestigation,compiler/runtime

This is a generalization of the problem described in #30449.

Suppose we have a unexported global variable:
```
var myArray [4]T
```
and none of the operations performed on this array:
* let the array itself escape from the package (implies that the variable is unexported)
* rely on comparability of the array (e.g., use of `==` or as a map key)

For example, operations like indexing (e.g., `myArray[3]`) and slicing (e.g., `myArray[:]`) are permitted.

If the above conditions are met, I believe that hash/eq functions need not be generated for that array since it is provably not used in the package, and cannot be used dynamically since the array itself does not escape from the package.

---

The use case for this is code like:
```go
var globalMessageTypes [2]protoimpl.MesageType // Desire no hash/eq functions for this type

func (T) Type() protoreflect.MessageType {
    return &globalMessageTypes[0]
}

func (R) Type() protoreflect.MessageType {
    return &globalMessageTypes[1]
}

func init() {
    for i := range ... {
        globalMessageTypes[i] = ...
    }
}
```

We declare `globalMessageTypes` as an array so that the `T.Type` and `R.Type` methods do not need a bounds check when indexing into the global array. However, the generated hash/eq functions add significant binary bloat.

The workaround to this is to use a global slice instead of an array, but that has other issues (see #30529).
Repository: go
Issue: cmd/compile: unnecessary bounds check for global slices
Labels: Performance,NeedsInvestigation,compiler/runtime

Using `go1.12`

Suppose we have a unexported global variable:
```
var mySlice = make([]T, 4)
```
and none of the operations performed on this slice:
* let a reference to the slice itself escape from the package (implies that the variable is unexported)
* mutate the slice header itself (e.g., no assign to the variable)

For example, operations like element assignment (e.g., `mySlice[3] = ...`) and element addressing (e.g., `&mySlice[3]`) are permitted.

If the above conditions are met, I believe that indexes into the slice below the initial size could have the bounds check elided since the index is provably not going to exceed the bounds.

---

The use case for this is code like:
```go
var globalMessageTypes = make([]protoimpl.MesageType, 2)

func (T) Type() protoreflect.MessageType {
    return &globalMessageTypes[0] // Desire no bounds check here
}

func (R) Type() protoreflect.MessageType {
    return &globalMessageTypes[1] // Desire no bounds check here
}

func init() {
    for i := range ... {
        globalMessageTypes[i] = ...
    }
}
```
We could use an array instead to avoid the bounds check, but that has other issues (see #30528).
Repository: TypeScript
Issue: JSDoc Class extending Array not supported (?)
Labels: Bug

Got a Class that Extends Array (FooArray) and am trying to create a Typed FooArray in another place. JSDoc suggests that I would be correct by using `FooArray.<Type>` (As the "normal" suggested method is either `Type[]` or `Array.<Type>`) and this markdown indeed seems to be parsed by jsdoc without issues, however VSC ends up detecting neither `FooArray` nor `Type`

Full example:

```
/**
 * @class FooArray
 * @extends {Array}
 */
class FooArray extends Array {
	constructor() {
		super();
		//whatever
	}


	/**
	 * returns "baz"
	 * @returns {string}
	 */
	bar() {
		return "baz";
	}
};

//This array will be filled with only values of type XYZ

/** @type {Array.<XYZ>} => instance[0] is correctly tagged / detected, instance.bar() is not (Obviously) */
/** @type {FooArray} => instance.bar() is documented but JSDoc has no idea of the values in the Array */
/** @type {FooArray.<XYZ>} => Neither is detected / documented */
let instance = new FooArray();
```
Repository: go
Issue: gerrit: improve revert commit message template, if possible
Labels: help wanted,NeedsInvestigation,FeatureRequest,DevExp,Community

When using Gerrit UI to create a revert of a CL, it populates the commit message with the following template:

```
Revert "{{.OriginalTitle}}"

This reverts commit {{.CommitHash}}.

Reason for revert: <INSERT REASONING HERE>
```

For example:

![image](https://user-images.githubusercontent.com/1924134/53676112-fde01880-3c6b-11e9-86f7-6511733a212d.png)

In most contexts of the Go project, we refer to changes by the CL number or a shortlink of the form `golang.org/cl/nnn`. This has some advantages compared to using the commit hash:

- shorter and less visual noise
- CL page contains code review discussion, in addition to the change; commit requires one extra click to get to discussion

If possible, we should consider changing the template to be:

```
Revert "{{.OriginalTitle}}"

This reverts https://golang.org/cl/{{.OriginalCL}}.

Reason for revert: <INSERT REASONING HERE>
```

Or perhaps the `This reverts CL {{.OriginalCL}}.` form.

Revert CLs are generally created in situations that involve more time pressure and stress compared to normal CLs, so it's less reliable for us to depend on people to remember to do this manually, or to reference documentation like at https://golang.org/wiki/CommitMessage. It's better to adjust the template.

### Implementation

I'm not very familiar with the configurability of our Gerrit instance and whether this is possible. /cc @andybons @bradfitz From looking at its source at https://gerrit.googlesource.com/gerrit/+/v2.16.6/polygerrit-ui/app/elements/change/gr-confirm-revert-dialog/gr-confirm-revert-dialog.js#50, it may be the case that this is not a configurable Gerrit feature, and so this may be blocked on a feature request for Gerrit.

This issue is to investigate whether this is possible, and whether we agree it's a good idea. /cc @ianlancetaylor
Repository: pytorch
Issue: Caffe2 C++ script for classification/object_detection with CMakeLists.txt 
Labels: caffe2

## ❓ Questions and Help

I was looking for caffe2 c++ script that supports latest version. But I couldn't find any good resource. Can anyone provide caffe2 c++ example script for classification. 

Thanks.
Repository: flutter
Issue: Android project build error with v2 embedding when using Java 1.7 libraries
Labels: platform-android,engine,a: existing-apps,P2,team-android,triaged-android

I use the flutter as a module in my android project， but there is a issue when I update my flutter sdk，it is：
Invoke-customs are only supported starting with Android O (--min-api 26)
Message{kind=ERROR, text=Invoke-customs are only supported starting with Android O (--min-api 26), sources=[Unknown source file], tool name=Optional.of(D8)}

however I do nothing，how can I fix this problem，please。
Repository: godot
Issue: Previous built-in scripts are not restored on project opening
Labels: bug,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
b84b015


**Issue description:**
If you have "Restore Scripts On Load" enabled, it will not restore built-in scripts when reopening a project.
Repository: flutter
Issue: Card should apply surface color for background  from material guideline
Labels: framework,f: material design,c: proposal,P3,team-design,triaged-design

I am building a flutter app with google material. But I am unable to apply surface color to cards and sheets. Material should apply surface color to cards, bottom sheets and menu as per material.io guidelines.