sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go, x/tools/gopls: clarify error messages about std modules (which have no '.')
Labels: gopls

### Go version

go version devel go1.22-33d4a51 darwin/arm64

### Output of `go env` in your module/workspace:

```shell
Not relevant. It isn't a bug per se, but a request for better error messages.
```


### What did you do?

`go.mod`:
```go
module notstd

go 1.22
```
`server/server.go`:
```go
package main

import "notstd/proto"

func Insert(req *proto.InsertRequest) (*proto.InsertResponse, error) {
	return &proto.InsertResponse{Success: true}, nil
}
```
There are no Go files in the `proto` folder (yet):
```text
├── go.mod
├── proto
│   └── kv.proto
└── server
    └── server.go
```

### What did you see happen?

```sh
$ go run ./server/
server/server.go:4:2: package notstd/proto is not in std (/Users/meling/sdk/gotip/src/notstd/proto)
```
```sh
$ gopls check server/server.go
/Users/meling/tmp/notstd/server/server.go:4:2-16: could not import notstd/proto (no required module provides package "notstd/proto")
```
When opening the quick fix suggestions in VSCode, `gopls` or the Go extension suggests to `go get package notstd/proto`, which is nonsensical.

### What did you expect to see?

I would expect both the compiler and gopls to report that there are no Go files in the `proto` folder within the same module, since the import is explicitly trying to import its own package.

With the simple example it might seem trivial to figure out that you've forgotten to compile the proto file to populate the `proto` package. But in larger projects it may be easy to forget, and students don't necessarily understand what the problem is, if they are expected to compile the proto file themselves. Moreover, the error messages are not helpful in this case.

Edit: Added the `kv.proto` file to match the actual use case that triggered this and simplified the what to expect description.
Repository: PowerToys
Issue: Power Run with Service plugin: after trying to disable/enable service, then new status doesn't reflect on Power run unless, research again. 
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.76.1

### Installation method

WinGet

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

1. Search for `!GP`, to disable  `Plug and Play` service
2. Power run push notification "successful disable service"
3. But when look at power run status, still have old service status. 

### ✔️ Expected Behavior

When Power Run send successful notification, then should update search result to reflect new service status. 


### ❌ Actual Behavior

When Power Run send successful notification, it's doesn't update search result and display old service status. 

### Other Software

OS: Windows 11
Repository: next.js
Issue: locale is always the default locale on page reload when using the pages router + middleware + edge runtime
Labels: bug,Navigation,Runtime

### Link to the code that reproduces this issue

https://github.com/gabrielf/next-edge-runtime-locale-bug

### To Reproduce

1. Start the minimal bug reproduction using `npm run dev`
2. Visit `http://localhost:3000/en` in a browser

### Current vs. Expected behavior

As I visit `/en` I expect the locale to be `en` but it is `default`.

Clicking the link `English` leads to a client side navigation to the same page which correctly shows the locale as `en`.

Additional links and their purpose:

* `Dynamic route 1` - exists to show that the problem exists also for dynamic routes, not just static ones
* `Static route (unaffected)` - exists to show that the problem does not exist on routes that does not match the middleware

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.2.0: Wed Nov 15 21:55:06 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6020
Binaries:
  Node: 18.18.2
  npm: 9.8.1
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.1-canary.12 // Latest available version is detected (14.1.1-canary.12).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: N/A
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Internationalization (i18n), Middleware / Edge (API routes, runtime), Routing (next/router, next/navigation, next/link)

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local)

### Additional context

The bug may have been introduced in version 13.4.20-canary.24 as using 13.4.20-canary.23 works fine but 24 does not. The bug seems to have existed since then.
Repository: go
Issue: runtime/cgo: document the state of clang support and minimum required version
Labels: Documentation,NeedsDecision,compiler/runtime

We consistently encounter issues exclusive to Clang in the bug tracker, such as:

- https://github.com/golang/go/issues/64616
- https://github.com/golang/go/issues/65290
- https://github.com/golang/go/issues/64943
- https://github.com/golang/go/issues/64423
- https://github.com/golang/go/issues/58848
- https://github.com/golang/go/issues/64400
- https://github.com/golang/go/issues/53013

Since resolving certain issues may involve implementing workarounds such as adjusting CFLAGS or incorporating specific compiler options like -Wno-something, it would be beneficial to determine the minimum compiler versions we target. This information is crucial in understanding whether these changes might adversely impact cgo programs, especially those relying on versions dating back to the minimum required version. This consideration is heightened by the fact that cgo directives must not only be compatible with clang but also with gcc.

Additionally, there are requests for expanded OS support for clang, specifically regarding [Windows support](https://github.com/golang/go/issues/17014). There is https://github.com/golang/go/issues/64563 that covers adding a Linux LUCI builder with a recent Clang toolchain.

Upon reviewing the [cgo wiki](https://go.dev/wiki/cgo) and [MinimumRequirements#cgo](https://go.dev/wiki/MinimumRequirements#cgo), there is no mention of Clang support or a specified minimum required version.

If we are actively pursuing Clang support in a consistent manner perhaps it would be beneficial to start documenting the support in some way.

In the decision made for https://github.com/golang/go/issues/43605, it was agreed to document the minimum GCC version as 4.6. We may consider specifying a corresponding clang version, such as 3.0, based on a similar timeframe (~2011).

cc @golang/runtime
Repository: next.js
Issue: next/og does not work with components which are using forwardRef
Labels: bug

### Link to the code that reproduces this issue

https://github.com/sdorra/og-with-forwardRef

### To Reproduce

1. Start the application (`pnpm run dev`)
2. Open the start page (http://localhost:3000)

### Current vs. Expected behavior

### Current
The sample og image shows only `World 👋` and does not show `👋 Hello` which is rendered by a component which is using `React.forwardRef`.

### Expected
The og image should render components which are using `React.forwardRef` and shows `👋 Hello World 👋`.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000
Binaries:
  Node: 21.6.1
  npm: 10.2.4
  Yarn: 1.22.21
  pnpm: 8.14.1
Relevant Packages:
  next: 14.1.1-canary.13 // Latest available version is detected (14.1.1-canary.13).
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Which stage(s) are affected? (Select all that apply)

next dev (local), next start (local)

### Additional context

The problem arose during the update from [react fontawesome 0.1 to 0.2](https://github.com/FortAwesome/react-fontawesome/compare/0.1.19...0.2.0).
Repository: next.js
Issue: [[...catchAll]] route doesn't work with parallel route
Labels: bug,linear: next

### Link to the code that reproduces this issue

https://github.com/MathiasStrohkirch/nextjs-parallel-routes-catch-all-bug

### To Reproduce

1. Start app with npm run dev
2. Go to /dashboard
3. Click "go to /dashboard/add/1" link. This page works
4. Refresh. 404

### Current vs. Expected behavior

Current behavior:
404 error after hard navigation to /dashboard/add/1

Expected behavior:
dashboard should render the optional catchAll page and @modal should render the add/[id] page

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Thu Oct 5 21:02:42 UTC 2023
Binaries:
  Node: 18.17.1
  npm: 10.2.3
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.1-canary.13 // Latest available version is detected (14.1.1-canary.13).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

I'm new to next, so please let me know if I am misunderstanding something!

<sub>[NEXT-2312](https://linear.app/vercel/issue/NEXT-2312/[catchall]-route-doesnt-work-with-parallel-route)</sub>
Repository: material-ui
Issue: [material-ui][Switch] Switch transformation issue with font size change
Labels: design: material,component: switch,package: material-ui,enhancement

### Steps to reproduce

Link to live example: Disclosure not possible due to data protection guidelines

Steps:
1. Setup only the minimum required packages (react, mui, emotion, I use vite)
2. Implement the Switch component with an label
3. Change the font-size in the browser settings (e.g. 72)


### Current behavior

When the font size in the browser is changed, the Switch's Label transforms correctly, but the Switch itself does not. It appears to be using pixels for sizes, leading to issues with responsiveness see attached image.

![image](https://github.com/mui/material-ui/assets/46647103/2914faa0-5ba3-461a-81e5-f01bf65c4ce1)

![image](https://github.com/mui/material-ui/assets/46647103/b2ba365b-3987-4f23-89e8-37ab051147aa)

### Expected behavior

The Switch should transform appropriately when the font size in the browser is changed. It should be responsive and adapt to different font sizes.

### Context

I am trying to create a responsive user interface, and the issue with Switch transformation is affecting the overall layout and user experience. This component is used in many places to maintain the personal and business related profile.

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Using Google Chrome Version 121.0.6167.85 (Offizieller Build) (64-Bit)
  System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 20.10.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD
    pnpm: Not Found
  Browsers:
    Chrome: Not Found
    Edge: Chromium (120.0.2210.144)
  npmPackages:
    @emotion/react: ^11.11.3 => 11.11.3
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.33
    @mui/core-downloads-tracker:  5.15.6
    @mui/material: ^5.15.6 => 5.15.6
    @mui/private-theming:  5.15.6
    @mui/styled-engine:  5.15.6
    @mui/system:  5.15.6
    @mui/types:  7.2.13
    @mui/utils:  5.15.6
    @types/react: ^18.2.43 => 18.2.48
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^5.2.2 => 5.3.3
```
</details>


**Search keywords**: switch, fontsize, transform, pixel, chrome, firefox
Repository: flutter
Issue: Make widget 'missing size' related problems visually identifiable
Labels: c: new feature,framework,a: quality,c: proposal,a: error message,P3,team-framework,triaged-framework

### Use case

This is a well-known, well-documented and easy to solve issue:
```dart
Row(children: [TextField()])
```

The result is a _Failed assertion: 'child!.hasSize': is not true_. (To solve it, just wrap the TextField in a Flexible or Expanded and it's done.)

The reason for opening this issue is not the error itself but the presentation of it. This is how you see it in the app:

<img width="315" alt="withrow" src="https://github.com/flutter/flutter/assets/29868050/b0afbbb9-0b32-4aaf-bc72-5883a71a5a81">
<img width="485" alt="le" src="https://github.com/flutter/flutter/assets/29868050/a357d933-b776-4ae2-98e0-f8d9989646da">

Nothing. No indicator at all. Sure, it has no size. 

The Flutter Inspector is similarly "helpful": it does not show any error indicator.

Of course, the logs will tell it all: there are 8 almost identical entries, 104 lines each. (Unless you use a pointer device, because in that case you'll get an overwhelming volume of _Cannot hit test a render box with no size_ messages.)
There is already an open issue targeting log clarity: **[ Error message from the framework is not helpful to debug (#89788)](https://github.com/flutter/flutter/issues/89788)** 

There are several similar cases (e.g. column and scrollview: _RenderFlex children have non-zero flex but incoming height constraints are unbounded._), on Stackoverflow the Flutter hasSize search has 99 results but the count may well be limited.

On the other hand, if anything has an overflow, in debug mode the app shows the striped ribbon in place, the Inspector adds an error label to the widget and there is only one clear log entry.

<img width="183" alt="overflow" src="https://github.com/flutter/flutter/assets/29868050/70401e86-8229-4e0a-b390-86edfadb0311">
<img width="350" alt="overflow_inspector" src="https://github.com/flutter/flutter/assets/29868050/441625c8-a1ed-481c-92a6-547408a68eef">




### Proposal

Make size error (has no size, unbundled width/heights) reporting more meaningful. In debug mode return a predefined size widget with a strong error indicator fill, similar to the oversize cases.

I made a hacky try to see how it will work: 
* made a copy of _DebugOverflowIndicator_ and changed it to _DebugNosizeIndicator_ by redefining the colors, debug info and the sizing.
* added try/catch to the TextField decorator rendering and draw _DebugNosizeIndicator_ if a sizing error occurred.
* by returning something that has a size, it's easier to find the faulty widget in the Inspector
 
It seems to be doable. This is how it may look like:

<img width="349" alt="withrowstriped" src="https://github.com/flutter/flutter/assets/29868050/2f5dddeb-e79e-4d70-ae2a-bfd787c71719">

## Expected result
The proposed new feature is about developer experience and efficiency. It helps finding and correcting layout errors faster.
Repository: TypeScript
Issue: TypeScript cannot always infer the correct type through a user-defined type guard using the 'is' operator.
Labels: Bug,Help Wanted

### 🔎 Search Terms

"typeguard", "is operator"

### 🕗 Version & Regression Information

Tested with typescript@5.1.3 and later

### ⏯ Playground Link

_No response_

### 💻 Code

```ts
enum kind {
	a = 'a',
	b = 'b',
	c = 'c'
}

type ID = {
	id: number
}

class Test<T extends kind> {
	value: T extends kind.a | kind.b ? ID : undefined
	type: T

	constructor(
		type: T,
		value: T extends kind.a | kind.b ? ID : undefined
	) {
		this.type = type
		this.value = value
	}

	hasID(): this is Test<Exclude<kind, kind.c>> {
		return this.type !== kind.c
	}

	do() {
		if (this.hasID()) {
			return this.value.id // Error: this.value: Object is possibly 'undefined'
			// return (this as Test<Exclude<kind, kind.c>>).value.id // this works
		}
	}
}
```


### 🙁 Actual behavior

TypeScript cannot infer that 'this' is of type 'Test<Exclude<kind, kind.c>>' even though there is a type guard. In the 'do' method, TypeScript throws a TSError stating that 'this.value': Object is possibly 'undefined'.

If we explicitly cast 'this' as 'Test<Exclude<kind, kind.c>>', we can access the 'value' attribute, and it works as it should. However, somehow the type guard does not have the same effect.

### 🙂 Expected behavior

Since there is a type guard around the 'this.value.id' line, TypeScript should handle 'this' as a 'Test<Exclude<kind, kind.c>>' type. At least, that's what type guards are for in my understanding.

### Additional information about the issue

_No response_
Repository: storybook
Issue: [Bug]: Storybook args table documentation missing Description, Default, and complex controls
Labels: bug,web-components,argtypes,sev:S2,stencil

### Describe the bug

# Overview
Using Storybook to showcase components made with StencilJS, I can showcase that any component's table to display arguments are missing the following fields:
- Description
- Default

Additionally, complex controls that are controlled by a typescript `type` (for example) display as a simple text field as opposed to a select dropdown with fields to choose from based on the type.

# Basic example
A stencil component's props are marked with JSDoc documentation:
`/** This is label documentation. */`
`@Prop() label!: TestComponentProps['label'];`

The docs table in storybook does not show any information for Description or Defaults:
![image](https://github.com/storybookjs/storybook/assets/13452773/8cb54c6d-1bc3-49a4-8e64-429ce90064da)

Additionally, controls that should display in a pre-defined `select` dropdown based on a Typescript `type`, only shows a simple text box (as opposed to React where this `select` dropdown appears without issue):
![image](https://github.com/storybookjs/storybook/assets/13452773/3c46b264-18c3-44e9-82b0-9a457a5f7cea)


### To Reproduce

# Reproduction repository
A reproduction repository can be found [HERE](https://github.com/greggbursey/stencil-docs-issue-in-storybook).

### System

```bash
Storybook Environment Info:

  System:
    OS: Windows 11 10.0.22621
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i9-12900H
  Binaries:
    Node: 20.5.0 - C:\Program Files\nodejs\node.EXE
    npm: 9.8.0 - C:\Program Files\nodejs\npm.CMD <----- active
  Browsers:
    Edge: Chromium (120.0.2210.144)
  npmPackages:
    @storybook/addon-essentials: ^7.6.7 => 7.6.8
    @storybook/addon-links: ^7.6.7 => 7.6.8
    @storybook/addon-mdx-gfm: ^7.6.7 => 7.6.8
    @storybook/blocks: ^7.6.7 => 7.6.8
    @storybook/web-components: ^7.6.7 => 7.6.8
    @storybook/web-components-vite: ^7.6.7 => 7.6.8
    storybook: ^7.6.7 => 7.6.8
```


### Additional context

_No response_
Repository: pytorch
Issue: Thread local patch on Dynamo/Inductor config
Labels: high priority,feature,triaged,months,oncall: pt2

### 🐛 Describe the bug

Today, we support context managers/decorators which allow people to modify Dynamo/Inductor configuration by patching the global variable involved. This patching process is not thread safe, because Dynamo/Inductor configuration is global. See https://github.com/pytorch/pytorch/issues/118260 for a concrete example of the problem.

To fix this problem, I propose that we introduce a thread local "patch" layer on top of configuration. It works like this:

* When we patch configuration, instead of directly modifying the global variable, we instead update a TLS entry
* When we lookup configuration, we consult the TLS entry first before the global

We should discourage use of mock.patch to update configuration entries, as these updates are not thread safe. The most important sites to apply this change are the config patching we do in the built in Dynamo decorators, as arguably end user patches can be made in contexts where they can safely assume no multithreading is occurring.

### Versions

main

cc @gchanan @zou3519 @kadeng @msaroufim @bdhirsh @anijain2305 @chauhang
Repository: pytorch
Issue: Audit all global mutable state in PT2 to see if it should be thread local instead
Labels: feature,triaged,oncall: pt2,module: inductor,module: dynamo

### 🐛 Describe the bug

Related https://github.com/pytorch/pytorch/issues/118387 https://github.com/pytorch/pytorch/issues/111569 

The task here is to go through all global mutable state in torch/_dynamo and _inductor and check if it should have been TLS rather than global state.

It would be even better if we could write some sort of lint rule to flag when people add global mutable state to the Python library, but I don't know how we can actually enforce this.

cc @msaroufim @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @suo @Skylion007 

### Versions

main
Repository: next.js
Issue: allow empty array for generateStaticParams
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/compassionate-wilson-qcxws4?file=%2Fapp%2Ffoo%2F%5Bslug%5D%2Fpage.tsx%3A12%2C47

### To Reproduce

1. See that the file in `app/foo/[slug]/page.tsx` has a `generateStaticParams` function that returns an empty array, and there are two possible ways to build the app, one with `output: 'export'` (`npm run build:export`) and one with `output: undefined` (`npm run build:ssr`)
2. Try  `npm run build:export` and see that it fails with the error message:
```
Error: Page "/foo/[slug]" is missing "generateStaticParams()" so it cannot be used with "output: export" config.
```

### Current vs. Expected behavior

It is a real use case of Next.js to have two ways of running the same codebase: one in SSR mode (output: undefined) for users of the CMS (that the Next.js app is connected to) to be able to use the draft mode and preview their work, and one in SSG mode (output: 'export') that is used for production, by just hosting its output on a CDN.

### Current Behavior
If a `page.tsx` has a `generateStaticParams` function that returns an empty array (for example because the writers are working on unpublished documents on the CMS, only available through the draft mode in SSR), then the same codebase cannot be used for a production SSG build as it will crash when building with `output: 'export'` ! This is problematic.

### Expected behavior
There should be a way to allow SSG builds (with `output: 'export'`) to proceed even if a `page.tsx` has a `generateStaticParams` function that returns an empty array.



### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 14.1.1-canary.13 // Latest available version is detected (14.1.1-canary.13).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: export
```


### Which area(s) are affected? (Select all that apply)

App Router, Static HTML Export (output: "export")

### Which stage(s) are affected? (Select all that apply)

next build (local)

### Additional context

I'm fairly sure the problem was already present in version 13.4.
Issues https://github.com/vercel/next.js/issues/58171 and https://github.com/vercel/next.js/issues/57996 are related.
Repository: godot
Issue: Godot crashes when merging tileset atlas created by PlaceholderTexture2d
Labels: topic:editor,needs testing,topic:2d

### Tested versions

Reproducible in 4.3.dev2, 4.2.1.stable

### System information

Godot v4.3.dev2.mono - openSUSE Tumbleweed 20240123 - Wayland - Vulkan (Mobile) - integrated AMD Radeon Graphics (RADV RENOIR) () - AMD Ryzen 7 4800U with Radeon Graphics (16 Threads)

### Issue description

Godot crashes when merging tileset atlas created by PlaceholderTexture2d.

### Steps to reproduce

- Create a tileset and a PlaceholderTexture2d.
- Add two atlas created by PlaceholderTexture2d in tileset.
- Open atlas merging tool, press Ctrl and select atlas, and then godot crashes.

### Minimal reproduction project (MRP)

N/A