sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: crypto/x509: VerifyOptions.Roots does not enforce that certificates are root certificates
Labels: NeedsDecision

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version

</pre>

1.18

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

https://go.dev/play/p/InpOJXUXnUl

A leaf and intermediate certificate can be provided to the root pool.

### What did you expect to see?

I expected that verification would fail due to the lack of root certificates.

### What did you see instead?

Successful verification.

It's unclear to me if this is an intentional feature or a bug.

Should a certificate in a root pool always be a CA certificate (related to [RFC5280 4.2.1.9](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9))? \
The check that a parent is a CA certificate occurs in `CheckSignatureFrom`, called in `buildChains`, which is bypassed because the leaf certificate is in the root pool (https://go.dev/src/crypto/x509/verify.go#L781). Allowing a non-CA certificate to be verified successfully against itself seems prone to bugs.

Is a root certificate meant to be defined as a self-signed certificate, or any certificate that forms the trust anchor?\
I expected that it must be a self-signed certificate, but an intermediate was permitted. This also seems prone to bugs, for example if a client supports a user-provided certificate chain and the client isn't enforcing that a chain is formed from a root.
Repository: neovim
Issue: `<C-o>` ignores context marks set via `nvim_buf_set_mark`
Labels: bug,api,marks

### Neovim version (nvim -v)

NVIM v0.7.0-dev+1319-gb81c310d4

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

Windows 10

### Terminal name/version

N/A

### $TERM environment variable

N/A

### Installation

build from repo

### How to reproduce the issue

Having a buffer with the content:
```
foo
bar
```
After `:clearjumps`, navigate to `r` in `bar`, without jumping. Press ``m` ``. Navigate to
some position on the first line, w/o jumping. Pressing `<c-o>` jumps to `r`.

Repeat the same process, but use ``:lua vim.api.nvim_buf_set_mark(0, '`', 2, 2, {})``.

### Expected behavior

`<c-o>` should jump to the position of the `` ` `` mark.

### Actual behavior

Pressing `<c-o>` has no effect. ``` `` ``` works as expected.
Repository: godot
Issue: Inspecting class variable via mouse hover when a local variable has a matching variable name causes local variable value to be shown
Labels: bug,topic:gdscript,topic:editor

### Godot version

v3.4.4.stable.official [419e713a2]

### System information

Windows 10

### Issue description

If a class variable is referenced in the same scope as a local variable with the same variable name, the hover inspector will show the value of the local variable instead of the object's.

![inspector_test](https://user-images.githubusercontent.com/25229644/160203501-4e47d7f4-8dfb-4546-a8b3-3254a542055f.png)


### Steps to reproduce

1. Create a class with a single variable of any type
2. In another script, create an instance of that class and set the variable to anything
3. Create a local variable of any type with the same variable name as the variable from step 1 but set the value to something different
4. Set a breakpoint after both of these are set and inspect the value of the class variable

### Minimal reproduction project

[InspectorTest.zip](https://github.com/godotengine/godot/files/8353911/InspectorTest.zip)
Repository: rust
Issue: AArch64: `target_feature=pmuv3` should not be assumed by default for all CPUs.
Labels: C-bug,O-AArch64

(This is a continuation from the discussion at the end of #95122.)

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this shell invocation:
```rust
rustc --target aarch64-unknown-none-softfloat --print cfg
```

I expected to see this happen:
No meaningful `target_feature`s should be printed.

Instead, this happened: 
```rust
debug_assertions
panic="abort"
target_abi="softfloat"
target_arch="aarch64"
target_endian="little"
target_env=""
target_feature="llvm14-builtins-abi"
target_feature="pmuv3"
target_has_atomic="128"
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_equal_alignment="128"
target_has_atomic_equal_alignment="16"
target_has_atomic_equal_alignment="32"
target_has_atomic_equal_alignment="64"
target_has_atomic_equal_alignment="8"
target_has_atomic_equal_alignment="ptr"
target_has_atomic_load_store="128"
target_has_atomic_load_store="16"
target_has_atomic_load_store="32"
target_has_atomic_load_store="64"
target_has_atomic_load_store="8"
target_has_atomic_load_store="ptr"
target_os="none"
target_pointer_width="64"
target_vendor="unknown"
```
There's apparently an assumption that `pmuv3` is always unconditionally available, which is demonstrably not true; this originally came up as an issue for the Apple M1 family of platforms, which have their own non-standard PMU instead, but even in the Arm ARM it states that FEAT_PMUv3 is optional.  This problem occurs not just for `aarch64-unknown-none-softfloat` but for all `aarch64` targets in current (2022-03-24) nightly.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.61.0-nightly (63b8f01bb 2022-03-24)
binary: rustc
commit-hash: 63b8f01bb5ca277e7df8d7efe094ed4244c1790c
commit-date: 2022-03-24
host: x86_64-apple-darwin
release: 1.61.0-nightly
LLVM version: 14.0.0
```
Repository: flutter
Issue: Add Documentation/Functionality to Programmatically take Screenshots During Flutter Integration Tests Run on Firebase Test Lab
Labels: c: new feature,framework,d: examples,c: proposal,f: integration_test,P3,team-framework,triaged-framework

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case
There is concise documentation on how to take screenshots in flutter integration tests, as well as how to run flutter integration tests on Firebase test lab. However there seems to be no ability to take screenshots on Firebase test lab. I would like this feature.

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

## Proposal
I would like to see documentation on how to programmatically take screenshots during flutter integration tests run on firebase test lab. If the functionality is not possible I would like to see it added to Flutter.
<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching something showing what you are imagining:
      * images
      * videos
      * code samples

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->
Repository: go
Issue: cmd/compile: slow with many methods on parameterized type
Labels: NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.18 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
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOVERSION="go1.18"
</pre></details>

### What did you do?

`git clone git@github.com:seborama/fuego.git -b v11_type_parameters && cd fuego`
Edit file `comparable_test.go` and add a comment anywhere in the file then save. This step is to ensure the build is executed without caching.
`go test -timeout 10s -v ./... -count 1 -run TestComparableStream_Max`
The execution of the test takes over 1 minute on my computer, rather than < 3s normally.

This problem may have started after I added `mapto.go` (generated via `make generate`).

The reason for generating so many parameterised methods comes from [issue 49085](https://github.com/golang/go/issues/49085).

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->



### What did you expect to see?

A fast test execution, at most 3 seconds, likely under 1s.

### What did you see instead?

The outcome is correct, but the test build takes a drastically long time.

Right now, I only have one computer on which to test this issue.
This may conceivably be related to an unknown particular of my environment set-up, although I cannot think of any.
Repository: TypeScript
Issue: Don't search the file system for node: modules
Labels: Domain: Performance

Running tsc on this .ts file results in a number of unnecessary file system accesses
```ts
import * as fs from "node:fs";

fs.chmod; // Prevent it from being unused
```

On my box, it searches
```
/home/amcasey/repos/perf_utils/node_modules/node:fs
/home/amcasey/repos/perf_utils/node_modules/node:fs.ts
/home/amcasey/repos/perf_utils/node_modules/node:fs.tsx
/home/amcasey/repos/perf_utils/node_modules/node:fs.d.ts
/home/amcasey/repos/perf_utils/node_modules/@types/node:fs
/home/amcasey/repos/perf_utils/node_modules/@types/node:fs.d.ts
/home/amcasey/repos/perf_utils/node_modules/node:fs.js
/home/amcasey/repos/perf_utils/node_modules/node:fs.jsx
```

Since file system access has been a performance bottleneck in the past, it would be nice to avoid these checks.

(Caveat: Linux actually allows colons in file names, so this would technically change the resolution behavior.  I can't tell whether it's by-design or not that it might find `node:fs.ts` on disk.)
Repository: rust
Issue: noalias on a Box doesn't seem to have an impact when compiling without `-C panic=abort`
Labels: A-codegen,T-compiler,C-bug,A-box

I tried this code:

```rust
struct Foo {
    x: i32
}
#[inline(never)]
fn function2() { println!("foo"); }

#[inline(never)]
fn function1() -> Box<Foo> { Box::new(Foo { x: 4}) }

pub fn foo() {
    let foo: Box<_> = function1();
    let value1 = foo.x;
    function2();
    let value2 = foo.x;
    assert_eq!(value1, value2);
}
```

I expect the assert_eq! to be compiled away. However, this only happens with `-C panic=abort`.

I'm using rustc 1.61.0-nightly (c84f39e6c 2022-03-20)
Repository: pytorch
Issue: [Structured] Make it possible to override create_out implementation on a per dispatch key basis (structured sparse)
Labels: triaged,enhancement,module: structured kernels

### 🐛 Describe the bug

@cpuhrsch wants to make the SparseCsr implementation of sum structured in https://github.com/pytorch/pytorch/pull/74766/files#diff-e9998363493c5dcd97969d077dcdea1e835c95bf39f2bbb5afde127a3c1ef728 which is forcing me to grapple with a problem that I wanted to punt on, which is how the heck to support sparse kernels in structured. The problem is twofold:

1. The meta kernel doesn't say anything about the sparsity of the output with respect to the inputs, so it doesn't know how to allocate the right thing
2. The meta kernel will interrogate the input for strides and try to allocate an output with those strides, which doesn't make sense for sparse

I have an idea for how to address the first problem, which is to allow for "add ons" to the meta kernel as part of codegen.  If we can somehow post facto override the `create_out` function in the generated classes on a per dispatch key basis, we can let a user customize what the creation of an output function should do.

Strides is harder, maybe we should just ignore it when we allocate.

### Versions

master
Repository: rust
Issue: "cannot return … reference to data owned by the current function" even though the result would be a harmless reborrow
Labels: A-diagnostics,A-borrow-checker,T-compiler,D-papercut,D-terse

Given [the following code:](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=22ac8e7675c9130c8cc01e5887fed93e)

```rust
fn func(foo: &mut i32) -> &i32 {
    &foo
}
```

The current output is:

```
error[E0515]: cannot return reference to function parameter `foo`
 --> src/lib.rs:2:5
  |
2 |     &foo
  |     ^^^^ returns a reference to data owned by the current function
```

Ideally the code would compile (just as it does when the function body is either `&*foo` or `foo`) or the message would contain a hint similar to `clippy::needless_borrow` that I just need to remove the `&`.

Usually, the wrong number of `&`s is either harmless or a type error; here, it produces a very confusing error. “What do you mean? I'm not returning anything I allocated inside the function. I'm returning a reference to the `Self` that already exists.” (My original case was a method.)

Tested on stable 1.59.0 and nightly. The same problem does not occur if the function's parameter is an `&` reference.
Repository: go
Issue: cmd/go: workspace recursive add should skip malformed module definitions
Labels: NeedsDecision,FeatureRequest,GoCommand,modules

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.18 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=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/shang/.cache/go-build"
GOENV="/home/shang/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/shang/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/shang/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK="/home/shang/go/src/go.work"
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-build895139390=/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 go.dev/play is best.
-->


```sh
mkdir /tmp/reproduce-issue/
cd /tmp/reproduce-issue/
git clone https://go.googlesource.com/tools
go work init
go work use -r .

cat <<EOF > hello.go
package main
import "fmt"
func main() {
    fmt.Println("hello world")
}
EOF

go run hello.go
```

### What did you expect to see?

Expected to see a functional workspace to be created, which should  have no effect over the final `go run hello.go` command.

### What did you see instead?

An un-usable workspace was created due to the `tools` repo containing some purposefully invalid `go.mod` files meant for unit testing, which `go work use -r .` added to the workspace, causing the final `go run hello.go` command to fail with:

```
go: malformed module path "αfake1α": invalid char 'α'
```

`go work use -r` should probably print a warning message for each malformed module definition that it encounters instead of adding those to the workspace.
Repository: godot
Issue: Unsupported class file major version 62 on android export.
Labels: platform:android,topic:buildsystem,needs testing,topic:export

### Godot version

3.4.4

### System information

Manjaro, Vega 8, Ryzen 3200 G

### Issue description

I got this error when trying to compile an apk with godot.

Could not compile settings file '/home/cris/Documentos/Git/Godot/Sheriff 22/android/build/settings.gradle'.
startup failed:
General error during conversion: Unsupported class file major version 62
java.lang.IllegalArgumentException: Unsupported class file major version 62

### Steps to reproduce

Download Godot from the website.
Install android studio.
Install dependencies.
Follow instructions.

Try to export.

### Minimal reproduction project

_No response_
Repository: flutter
Issue: Proposal to add flavor to pubspec.yaml
Labels: c: new feature,tool,c: proposal,P3,team-tool,triaged-tool


## Use case
when we want have a multiplatform flavor we should do many configs foreach platform
so I think it's better that we can config it just once in pubspec.yaml
Repository: godot
Issue: Auto update Material Icon in FileSystem
Labels: enhancement,topic:editor

### Godot version

Godot_v3.4.4-stable_win64.exe

### System information

Win 10

### Issue description

The icon preview and name of materials are not in sync

### Steps to reproduce

1. Add a new SpatiaMaterial to FIleSystem
2. double click on it to bring it settings to the inspector

![Capture](https://user-images.githubusercontent.com/31585224/160232507-7f51fabd-efc7-4be9-ada0-f1d61a180af6.PNG)
3. Rename the spatial material
[Issue 1] you will see the name is not updated in the inspector
![Capture](https://user-images.githubusercontent.com/31585224/160232637-132fc535-5024-4844-93e4-cb7fe2b931d5.PNG)

4. change the color of the Material Albedo in the inspector
[issue 2] you will see the icon does not update in the FileSystem
![Capture](https://user-images.githubusercontent.com/31585224/160232747-c1c1aea6-ea69-4c8b-9b26-eff967a27231.PNG)

This icon doesn't update until the SpatiaMaterial is renamed again


### Minimal reproduction project

_No response_
Repository: go
Issue: cmd/go: work use silently ignores nonexistent target
Labels: NeedsInvestigation,GoCommand

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
go version go1.18 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

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="{secret}"
GOENV="{secret}"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="{secret}"
GONOPROXY="{secret}"
GONOSUMDB="{secret}"
GOOS="darwin"
GOPATH="/Users/mac/go"
GOPRIVATE="{secret}"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.18/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.18/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK="{secret}"
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 x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rg/2ghbpv594593xwc66z446w5w0000gn/T/go-build2275001121=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->

Run the following commands:

(Format: $ {current_dir} > {command})
$ go > `mkdir workspace`
$ go > `cd workspace`
$ workspace > `go work init`
$ workspace > `ls -la`
total 8
-rw-r--r--  1 user  staff     8B Mar 26 17:51 go.work
$ workspace > `go work use ./lib`

### What did you expect to see?

Error, because the folder ./lib does not exist.

### What did you see instead?

Empty output.
Repository: rust
Issue: Confusing "the parameter type `Self` may not live long enough" error with dyn HRTB callback taking GAT
Labels: GATs-triaged,A-GATs,A-higher-ranked

I tried this code:

```rust
#![feature(generic_associated_types)]

trait FooBad {
    type Item<'a>;
    fn items(walker: &mut dyn for<'a> FnMut(Self::Item<'a>));
}
```

I expected to see this happen: No error.

Instead, this happened:

```
error[E0311]: the parameter type `Self` may not live long enough
 --> src/main.rs:5:22
  |
5 |     fn items(walker: &mut dyn for<'a> FnMut(Self::Item<'a>));
  |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: the parameter type `Self` must be valid for the anonymous lifetime defined here...
 --> src/main.rs:5:22
  |
5 |     fn items(walker: &mut dyn for<'a> FnMut(Self::Item<'a>));
  |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...so that the reference type `&mut dyn for<'a> FnMut(<Self as FooBad>::Item<'a>)` does not outlive the data it points at
 --> src/main.rs:5:22
  |
5 |     fn items(walker: &mut dyn for<'a> FnMut(Self::Item<'a>));
  |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

<details>
<summary>Outdated information</summary>
The strange thing is that this alternative version, which should in theory be totally identical, works fine:

```rs
trait FooGood {
    type Item<'a>;
    fn items(walker: &mut dyn ItemWalker<Self>);
}

trait ItemWalker<T: ?Sized + FooGood>: for<'a> FnMut(T::Item<'a>) {}
impl<T: ?Sized + FooGood, F: ?Sized> ItemWalker<T> for F where F: for<'a> FnMut(T::Item<'a>) {}
```

Edit: I later realized that this isn't totally identical at all, because `dyn ItemWalker<T>` and `dyn ItemWalker<U>` would not be considered the same type even if `T` and `U` have identical `Item` types. So it's not so easy to work around.
</details>

### Meta

`rustc --version --verbose`:
```
rustc 1.61.0-nightly (d53246fed 2022-03-25)
binary: rustc
commit-hash: d53246fedde4c193eae8a003546a8f0f9f85d223
commit-date: 2022-03-25
host: x86_64-unknown-linux-gnu
release: 1.61.0-nightly
LLVM version: 14.0.0
```