sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: many subcommands take nonsensical build flags
Labels: NeedsInvestigation,GoCommand

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.21.0 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What did you do?

```
go clean -n -gcflags=-S
```

### What did you expect to see?

I expected the `go` command to reject the `-gcflags` flag because it makes no sense for that subcommand.

### What did you see instead?

It quietly succeeded.

Many of the `go` subcommands are sensitive not just to which packages match the package pattern, but the specific set of source files selected for a build configuration. These call [`work.AddBuildFlags`](https://cs.opensource.google/go/go/+/master:src/cmd/go/internal/work/build.go;l=302;drc=96d8d3eb3294e85972aed190aec1806ef3c30712) to register the flags that affect source selection, but this function also registers many flags that only affect actual compilation and linking.

- The `clean` command is sensitive to source file selection because it finds all source files in the a package that have a correspondingly named binary in the directory (but are not part of package main) to delete the binaries.
- The `fix` command uses `work.AddBuildFlags`, but appears not to be sensitive to *any* build flags, because it uses `pkg.InternalAllGoFiles()` to list source files, which should returns all source files regardless of source file selection.
- The `generate` command only searches for `go:generate` directives in matched source files.

The full set of build flags makes sense for `build`, `install`, `get`, `run`, `test`, `vet`, and `list` because they all build source files (`vet` and `list -export` both invoke the toolchain to create up-to-date export files).

cc @bcmills
Repository: go
Issue: runtime: stack corruption on freebsd/arm
Labels: help wanted,OS-FreeBSD,NeedsInvestigation,arch-arm,compiler/runtime

```
#!watchflakes
post <- goos == "freebsd" && goarch == "arm" && log ~ `fatal error: unknown caller pc`
```

CC @golang/freebsd
Repository: go
Issue: misc/cgo/test: failures with SIGBUS on loong64
Labels: help wanted,NeedsInvestigation,arch-loong64,compiler/runtime

```
#!watchflakes
post <- goarch == "loong64" && pkg == "misc/cgo/test" && log ~ `signal: bus error`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/c324d3c1ea206b5d668e27381ae5f8c1a4e9a12a)):

    signal: bus error (core dumped)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: deno
Issue: npm:docker-modem doesn't work (and @testcontainers/* as a result)
Labels: bug,node compat

The blog post said we should report, so here we go:

I just trying to use testcontainers (@testcontainers/postgresql) with Deno when I got this strange error:

```
error: Error: (HTTP code 400) unexpected - starting container with non-empty request body was deprecated since API v1.22 and removed in v1.24
    at file:///Users/geoff/Library/Caches/deno/npm/registry.npmjs.org/docker-modem/3.0.8/lib/modem.js:343:17
    at getCause (file:///Users/geoff/Library/Caches/deno/npm/registry.npmjs.org/docker-modem/3.0.8/lib/modem.js:373:7)
    at Modem.buildPayload (file:///Users/geoff/Library/Caches/deno/npm/registry.npmjs.org/docker-modem/3.0.8/lib/modem.js:342:5)
    at IncomingMessageForClient.<anonymous> (file:///Users/geoff/Library/Caches/deno/npm/registry.npmjs.org/docker-modem/3.0.8/lib/modem.js:310:16)
```

So it seems there might be some http client compatibility issues, as the docker api is just HTTP last time I checked...

Here's the repro code which was inspired by [this Testcontainer Node quickstart repo](https://github.com/AtomicJar/testcontainers-cloud-nodejs-example) (which runs fine using node): 

```typescript
import { PostgreSqlContainer } from "npm:@testcontainers/postgresql";
import postgres from "https://deno.land/x/postgresjs/mod.js";

Deno.test("hello postgres", async () => {
  const initScript = `
            create table guides
            (
                id    bigserial     not null,
                title varchar(1023) not null,
                url   varchar(1023) not null,
                primary key (id)
            );

            insert into guides(title, url)
            values ('Getting started with Testcontainers',
                    'https://testcontainers.com/getting-started/'),
                   ('Getting started with Testcontainers for Java',
                    'https://testcontainers.com/guides/getting-started-with-testcontainers-for-java/'),
                   ('Getting started with Testcontainers for .NET',
                    'https://testcontainers.com/guides/getting-started-with-testcontainers-for-dotnet/'),
                   ('Getting started with Testcontainers for Node.js',
                    'https://testcontainers.com/guides/getting-started-with-testcontainers-for-nodejs/'),
                   ('Getting started with Testcontainers for Go',
                    'https://testcontainers.com/guides/getting-started-with-testcontainers-for-go/'),
                   ('Testcontainers container lifecycle management using JUnit 5',
                    'https://testcontainers.com/guides/testcontainers-container-lifecycle/')
            ;
        `;

  const container = await new PostgreSqlContainer("postgres:14-alpine",)
    .withCopyContentToContainer([
      { content: initScript, target: "/docker-entrypoint-initdb.d/init.sql" },
    ])
    .start();

  const sql = postgres(container.getConnectionUri());
  const res = await sql`select title, url from guides`;
  console.log(res);
});
```
Repository: godot
Issue: Vulkan: VoxelGI dynamic mesh rendering isn't counted in the frame time, making FPS calculation misleading
Labels: bug,topic:rendering,topic:editor,topic:3d

- *Related to https://github.com/godotengine/godot/issues/49117
  and https://github.com/godotengine/godot/issues/55359.*

### Godot version

4.2.dev c495eb510

### System information

Godot v4.2.dev (6758a7f8c) - Fedora Linux 38 (KDE Plasma) - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4090 (nvidia; 535.98) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)

### Issue description

In this image with only static VoxelGI, rendering is perfectly smooth:

![image](https://github.com/godotengine/godot/assets/180032/54b064a4-6d64-4745-a4b4-109b6c0f6f7c)

In this image with about a dozen dynamic VoxelGI meshes, rendering is actually around 20 FPS but the editor claims the FPS is much higher than it really is:

![image](https://github.com/godotengine/godot/assets/180032/533d6b47-e92f-4c2d-a26f-e7bc00a031b3)


### Steps to reproduce

- Create a VoxelGI node.
- Create a MeshInstance3D with a BoxMesh.
- Create a second MeshInstance3D with a BoxMesh, and set its GI mode to **Dynamic**. Give it an emissive material so you can see the result.
- Bake VoxelGI. Hide and show the second MeshInstance3D while **View Frame Time** panel is active. Make sure your editor is in fullscreen so performance drops are more noticeable. If no performance drops occur, try creating additional MeshInstance3D nodes with their GI mode set to **Dynamic**.

### Minimal reproduction project

[test_voxelgi_performance.zip](https://github.com/godotengine/godot/files/12272786/test_voxelgi_performance.zip)
Repository: vscode
Issue: Support aliasing URLs in the Output window
Labels: feature-request,output,keep

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
As part of messages that we are sending to the Output window, we'd like to be able to emit links to documentation, troubleshooting info, and more. While these links are generally short and direct, there are cases where the URLs become unweidy and lengthy. In these cases, it would be great if the Output window supported aliasing so that we can provide more concise and helpful messages rather than a run-on URL that adds visual clutter.
Repository: flutter
Issue: Remove definition of _availability_version_check
Labels: P3,team-engine,triaged-engine

To fix https://github.com/flutter/flutter/issues/132130, a strong definition of `_availability_version_check` was added to avoid the weak linkage of that symbol coming from the clang runtime library. The weak linkage of that symbol would cause apps to be rejected by the app store. When Clang 18 becomes the version used by Xcode, presumably the App Store will not have a problem with the symbol anymore, and we can therefore remove the file `flutter/shell/platform/darwin/common/availability_version_check.cc`, which was added in https://github.com/flutter/engine/pull/44711.
Repository: rust
Issue: Crash during thread teardown using TLS in global allocator on macOS
Labels: O-macos,A-allocators,T-compiler,A-thread-locals,C-bug,A-thread

<!--
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 code using [accounting_allocator](https://github.com/privacyresearchgroup/accounting-allocator-rs):

```rust
use accounting_allocator::AccountingAlloc; // accounting_allocator = "0.1" or "0.2"

#[global_allocator]
static GLOBAL_ALLOCATOR: AccountingAlloc = AccountingAlloc::new();

fn main() {
    let handle = std::thread::spawn(|| println!("Hello, world!"));
    handle.join().expect("ok")
}
```

On macOS Ventura 13.5 (x86_64-apple-darwin *or* aarch64-apple-darwin), this code executes successfully when compiled with Rust 1.69.0, but crashes when compiled with Rust 1.70 or later, including the latest nightly. The code executes successfully on Ubuntu.

Using thread-local storage in a global allocator is absolutely a heck of a thing to do, but the code is carefully using [`LocalKey::try_with`](https://doc.rust-lang.org/std/thread/struct.LocalKey.html#method.try_with) to avoid any issues during teardown, and it seemed to be working previously/elsewhere.

```
Thread 1 Crashed:
0   ???                           	               0x0 ???
1   accounting-allocator-test     	       0x104a96c79 std::sys::unix::thread_local_dtor::register_dtor::run_dtors::hfb57215a22a25a2b + 89
2   dyld                          	    0x7ff801a52fda invocation function for block in dyld4::RuntimeState::_finalizeListTLV(void*) + 53
3   dyld                          	    0x7ff801a52f6b dyld4::RuntimeState::_finalizeListTLV(void*) + 79
4   libsystem_pthread.dylib       	    0x7ff801d9e1e2 _pthread_tsd_cleanup + 465
5   libsystem_pthread.dylib       	    0x7ff801da0873 _pthread_exit + 70
6   libsystem_pthread.dylib       	    0x7ff801da01de _pthread_start + 136
7   libsystem_pthread.dylib       	    0x7ff801d9bbd3 thread_start + 15
```

### 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.71.0 (8ede3aae2 2023-07-12)
binary: rustc
commit-hash: 8ede3aae28fe6e4d52b38157d7bfe0d3bceef225
commit-date: 2023-07-12
host: x86_64-apple-darwin
release: 1.71.0
LLVM version: 16.0.5
```

(working version)
```
rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-apple-darwin
release: 1.69.0
LLVM version: 15.0.7
```

My colleague tested with 1.69.0 (works), 1.70.0 (fails), 1.71.0 (fails), 1.71.1 (fails), and the latest nightly (fails):
```
rustc 1.74.0-nightly (c469197b1 2023-08-22)
binary: rustc
commit-hash: c469197b19d53a6c45378568f73c00986b20a5a5
commit-date: 2023-08-22
host: x86_64-apple-darwin
release: 1.74.0-nightly
LLVM version: 17.0.0
```
Repository: kubernetes
Issue: Race window between scheduler and device plugin restart in kubelet
Labels: sig/scheduling,sig/node,kind/feature,needs-triage

### What happened?

We restart a device plugin frequently as part of our design.

When a device plugin goes down, kubelet [marks the devices it was managing as unhealthy](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/cm/devicemanager/manager.go#L240), removing it from allocatable, and preventing Pods from scheduling. However, it [keeps the resource in capacity for a grace period](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/cm/devicemanager/manager.go#L415) in hopes that the device plugin will come back up and scheduled pods can keep running with no disruption.

Kube-scheduler reads node state and chooses nodes to schedule pods on based on allocatable resources.

If the device plugin restarts between the kube-scheduler decision and when kubelet tries to start allocating resources for the new Pod, then the pod is rejected and enters a Failed state.

### What did you expect to happen?

The pod to either successfully schedule, or to stay in pending until the device plugin restarts

### How can we reproduce it (as minimally and precisely as possible)?

I have not found a reliable reproducer. I think adding a large sleep before the lock acquisition [here](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/cm/devicemanager/manager.go#L548) would widen the timing window significantly, but I could not figure out how to deploy a changed kubelet

### Anything else we need to know?

_No response_

### Kubernetes version

<details>
1.27
</details>

### Cloud provider

<details>
GCP (GKE)
</details>


### OS version

N/A

### Install tools

N/A

### Container runtime (CRI) and version (if applicable)

N/A

### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>
Cilium CNI
</details>
Repository: rust
Issue: expected type suggestion ends up needing turbofish
Labels: A-diagnostics,T-compiler

### Code

```Rust
struct ResponseVisitor<'b, const RELAXED: bool>(PhantomData<&'b ()>);

impl<'a, const RELAXED: bool> Deserialize<'a> for Response<'a, RELAXED> {
    fn deserialize<D: serde::Deserializer<'a>>(deserializer: D) -> Result<Self, D::Error> {
        deserializer.deserialize_map(ResponseVisitor(&()))
    }
}
```


### Current output

```Shell
error[E0308]: mismatched types
   --> ethers-providers/src/rpc/transports/common.rs:229:54
    |
229 |         deserializer.deserialize_map(ResponseVisitor(&()))
    |                                      --------------- ^^^ expected `PhantomData<&()>`, found `&()`
    |                                      |
    |                                      arguments to this struct are incorrect
    |
    = note: expected struct `PhantomData<&()>`
            found reference `&()`
note: tuple struct defined here
   --> ethers-providers/src/rpc/transports/common.rs:114:8
    |
114 | struct ResponseVisitor<'b, const RELAXED: bool>(PhantomData<&'b ()>);
    |        ^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0308`.
error: could not compile `ethers-providers` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...


==================================+
but, implementing the suggestion results in a turbofish:

error: comparison operators cannot be chained
   --> ethers-providers/src/rpc/transports/common.rs:229:65
    |
229 |         deserializer.deserialize_map(ResponseVisitor(PhantomData<&()>))
    |                                                                 ^   ^
    |
    = help: use `::<...>` instead of `<...>` to specify lifetime, type, or const arguments
    = help: or use `(...)` if you meant to specify fn arguments

error: could not compile `ethers-providers` (lib) due to previous error
```


### Desired output

```Shell
= note: expected struct `PhantomData::<&()>`
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Anything else?

I guess to solve this in the general case the rust compiler's type suggestions must themselves the syntax checked in context.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"edward-shen"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: go
Issue: x/website/_content/doc: refer that crypto/ecdsa.GenerateKey is no longer deterministic since Go 1.20
Labels: Documentation,Security,help wanted,NeedsInvestigation

This change (#58637) recently bit me when upgrading Go, and it left me mad looking for bugs in data transmission when the different keys were the problem.

I gained the habit of reading release notes (at least for major upgrades) to avoid issues, but only the change to the constant-time is mentioned.
As it changes existing behavior, I believe it should be in the release notes, so that no one suffers the same fate :)
Repository: PowerToys
Issue: MouseWithoutBorders Allow Any Keyboard Input
Labels: Idea-Enhancement,Needs-Triage,Product-Mouse Without Borders

### Description of the new feature / enhancement

Allow keyboard input from any connected device.
Currently, an active keyboard is required for input, and the experience is poor when using a mouse from one device and a keyboard from another device.

### Scenario when this would be used?

When I use a laptop device and a desktop device, I hope to use the laptop keyboard instead of the desktop keyboard, but the mouse still uses the desktop mouse instead of the laptop touchpad.

### Supporting information

_No response_
Repository: electron
Issue: [Enhancement]: support new documentPictureInPicture M116 Feature
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

26.1.0

### What operating system are you using?

macOS

### Operating System Version

macOS Ventura 13.5.1

### What arch are you using?

x64

### Last Known Working Electron version

unknown

### Expected Behavior

`await documentPictureInPicture.requestWindow();` shows new window

### Actual Behavior

`await documentPictureInPicture.requestWindow();` shows nothing

### Testcase Gist URL

_No response_

### Additional Information

I would like to know if I can use this feature from Chrome 116 in Electron.

https://developer.chrome.com/blog/new-in-chrome-116/#document-picture-in-picture
Repository: vscode
Issue: Recently opened project has the same name
Labels: bug,workbench-history,vscode.dev

ADD ISSUE DESCRIPTION HERE

Version: 1.81.1
Commit: 6c3e3dba23e8fadc360aed75ce363ba185c49794
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36
Embedder: vscode.dev

![image](https://github.com/microsoft/vscode/assets/11473889/ef496ec7-57d2-433b-a7b2-b5cd9b0c581a)

<!-- generated by web issue reporter -->
Repository: PowerToys
Issue: PowerToys Run OneNote plugin failed to load.
Labels: Issue-Bug,Product-PowerToys Run,Needs-Triage,Run-Plugin,Needs-Team-Response

### Microsoft PowerToys version

0.72.0

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

[2023-08-24 12:19:48.7465] [ERROR] [C:\a\_work\1\s\src\modules\launcher\Wox.Plugin\PluginPair.cs::201]
-------------------------- Begin exception --------------------------
Message: Fail to Init plugin: OneNote

Exception full name  : System.Xml.XmlException
Exception message    : '�', hexadecimal value 0xDD55, is an invalid character. Line 2, position 1600.
Exception stack trace:
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
   at System.Xml.XmlTextReaderImpl.ParseAttributeValueSlow(Int32 curPos, Char quoteChar, NodeData attr)
   at System.Xml.XmlTextReaderImpl.ParseAttributes()
   at System.Xml.XmlTextReaderImpl.ParseElement()
   at System.Xml.XmlTextReaderImpl.ParseElementContent()
   at System.Xml.Linq.XContainer.ReadContentFrom(XmlReader r)
   at System.Xml.Linq.XElement.ReadElementFrom(XmlReader r, LoadOptions o)
   at System.Xml.Linq.XElement.Load(XmlReader reader, LoadOptions options)
   at System.Xml.Linq.XElement.Parse(String text, LoadOptions options)
   at ScipBe.Common.Office.OneNote.OneNoteProvider.ParsePages(String xml)
   at ScipBe.Common.Office.OneNote.OneNoteProvider.<>c.<get_PageItems>b__3_0(Application oneNote)
   at ScipBe.Common.Office.OneNote.OneNoteProvider.CallOneNoteSafely[T](Func`2 action)
   at ScipBe.Common.Office.OneNote.OneNoteProvider.get_PageItems()
   at Microsoft.PowerToys.Run.Plugin.OneNote.Main.Init(PluginInitContext context)
   at Wox.Plugin.PluginPair.InitPlugin(IPublicAPI api)
Exception source     : System.Private.Xml
Exception target site: Void Throw(System.Exception)
Exception HResult    : -2146232000
-------------------------- End exception --------------------------

### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

![image](https://github.com/microsoft/PowerToys/assets/4505686/49523cf3-bcc9-4ddc-9d23-55e7aaf9e79e)

### Other Software

![image](https://github.com/microsoft/PowerToys/assets/4505686/da932093-644a-477a-acea-53ef37a53641)
Repository: create-react-app
Issue: react-scripts test not working if we use declare context statement inside a class component
Labels: needs triage,issue: bug report

### Describe the bug

Facing problem while running tests.

Seems like react-scripts do not support following statement inside class components
`declare context: React.ContextType<typeof FormContext>;`

### Did you try recovering your dependencies?

No

(paste the output of the command here.)

### Steps to reproduce

(Write your steps here:)

1. Create an app using command `npx create-react-app my-app --template typescript`
2. Create a class component :
```
import React, { Fragment } from "react";

class TestAbc extends React.Component {
    declare context: React.ContextType<typeof FormContext>;

    render() {
        return <Fragment>Hi</Fragment>
    }
    
}
```
3. Create a test case for component created in above step
```
import React from 'react';
import { render, screen } from '@testing-library/react';
import App from './App';
import TestAbc from './TestAbc';

test('renders learn react link', () => {
  render(<TestAbc />);
});

```
4. Run test case using command: `npm run test`

### Expected behaviour

Test case should pass

### Actual behaviour

Giving error while running test.
![Screenshot 2023-08-24 at 10 58 45 AM](https://github.com/facebook/create-react-app/assets/1009561/0293655e-41fe-4b69-b7c1-06a57c1193e2)

### Reproducible demo