sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/build: catch problems in x/ repos gated by module go directive version sooner
Labels: Builders,NeedsFix

Issue #67783 is an example of a test failure that happened only at tip (future Go 1.23 to be) and when the go directive in x/net is increased to Go language version 1.23.  Bumping x/net go directive to 1.23 will not happen on its own soon since Go 1.22 and 1.21 are still supported now, but it would be good to have at least one builder that could catch such problems sooner anyway. This is a tracking issue for that.

Edit: Discussion [here](https://go-review.googlesource.com/c/mobile/+/610800/comments/6e1305b9_a19719da) shows another case where having this implemented would help, by letting vet changes be rolled out more gradually without delay in signal.

More examples of issues that this could help with:

- #70082

CC @golang/release.
Repository: terminal
Issue: Window does not stay on top when "Always on top" is enabled
Labels: Help Wanted,Issue-Bug,Product-Terminal,Area-Windowing

### Windows Terminal version

1.19.11213.0

### Windows build number

Microsoft Windows NT 10.0.22631.0

### Other Software

_No response_

### Steps to reproduce

1. Toggle "Always on top" on in settings and save
2. Keep using terminal
3. Eventually it stops staying on top

The only way to resume the "Always on top" behaviour is to disable and re-enable the settings with a save in between.

### Expected Behavior

_No response_

### Actual Behavior

Terminal window does not stay on top of other windows.
Repository: PowerToys
Issue: PowerToys keeps disabling "Run at Startup" setting
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.81.1

### Installation method

Microsoft Store

### Running as admin

No

### Area(s) with issue?

General

### Steps to reproduce

a. GUI
1) Run C:\Program Files\PowerToys\PowerToys.exe
2) Right click system tray icon
3) select Settings
4) Hamburger menu -> General -> Switch "Run at Startup" from "Off" to "On"
5) Right click system tray icon
6) select Exit
7) Run C:\Program Files\PowerToys\PowerToys.exe
8) Right click system tray icon
9) select Settings

b. Directly editing settings.json
1) Open C:\Users\(username)\AppData\Local\Microsoft\PowerToys\settings.json
2) Change "startup" from false to true and save the file.
3) Run C:\Program Files\PowerToys\PowerToys.exe
4) Reopen C:\Users\(username)\AppData\Local\Microsoft\PowerToys\settings.json

[PowerToysReport_2024-06-03-12-27-07.zip](https://github.com/user-attachments/files/15536907/PowerToysReport_2024-06-03-12-27-07.zip)

### ✔️ Expected Behavior

a) Hamburger menu -> General -> "Run at Startup" should be "On"
b) C:\Users\(username)\AppData\Local\Microsoft\PowerToys\settings.json should have startup=true

### ❌ Actual Behavior

a) Hamburger menu -> General -> "Run at Startup" has reverted to "Off"
b) C:\Users\(username)\AppData\Local\Microsoft\PowerToys\settings.json has startup=false

### Other Software

_No response_
Repository: pytorch
Issue: Run existing eager DTensor tests under torch.compile
Labels: oncall: distributed,triaged,oncall: pt2,module: dtensor,pt2d-triage-nov2024

Today, DTensor has a large number of eager mode tests [here](https://github.com/pytorch/pytorch/tree/main/test/distributed/_tensor).

There is also a dedicated test file for compile-testing [here](https://github.com/pytorch/pytorch/blob/main/test/distributed/_tensor/test_dtensor_compile.py) - it started out with some basic tests, and a few tests have been added over time that test a few boundary cases with compile that showed up internally + in torchtitan.

However, the compile tests for DTensor are not nearly as comprehensive as the eager tests. Taking the existing eager tests today and running them with compile would be a great way to have more confidence in DTensor's coverage with compile, and also root out any issues proactively.

There is some existing infra already for "take an eager-mode test suite and run compile on it". In particular, we have a `TEST_WITH_TORCHINDUCTOR` env var built into the testing harness ([link](https://github.com/pytorch/pytorch/blob/main/torch/testing/_internal/common_utils.py#L2773)).

One thing to note is that using that infra out-of-the-box will run compile on the **entire** tests, including (potentially) distributed init code. This might expose some issues with how dynamo handles distributed's init code (ideally it should gracefully graph break on this code). One option is to try all of this out - and if the distributed init code is not handled well, see how much effort would be required to fix it (this seems like a useful thing for compile to handle gracefully). But if this becomes very involved, it might be higher ROI just to compile the test code without including the initialization logic.

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o @chauhang @penguinwu @tianyu-l @XilunWu @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @yf225 @ezyang @msaroufim @anijain2305
Repository: flutter
Issue: [Impeller] impellerc's spirv optimization pass produces for loop that is invalid in WebGL.
Labels: P3,e: impeller,team-engine,triaged-engine,e: webgl

When targeting OpenGL, the spirv optimization pass in impellerc produces shaders that have a for loop syntax that is invalid in WebGL. @chinmaygarde may have some more details as to the exact nature of the syntax incompatibility.
Repository: godot
Issue: Renaming a global group creates a scene group
Labels: bug,topic:editor

### Tested versions

Tested in v4.3.beta1.official [a4f2ea91a]

### System information

Godot v4.3.beta1 - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 SUPER (NVIDIA; 31.0.15.5244) - AMD Ryzen 7 3800X 8-Core Processor (16 Threads)

### Issue description

Renaming a (EDIT: checked) global group creates a scene group with the same name and checks it. The renamed group becomes unchecked.
I renamed the global group "test" to "test2":

<img width="500" alt="image" src="https://github.com/godotengine/godot/assets/35117125/20106f96-995e-4082-b918-593a74381b79">


### Steps to reproduce

1. Create new project
2. Create new scene
3. Create global group
4. Rename global group to something else
5. EDIT: Seems to happen only if the global group that gets renamed is checked

### Minimal reproduction project (MRP)

N/A
Repository: flutter
Issue: [Impeller] gaussian and morphology shaders use a dynamic for loop bound, which is incompatible with WebGL.
Labels: P3,e: impeller,team-engine,triaged-engine,e: webgl

Whatever version of GLSL that WebGL uses requires the loop bound for `for` loops to be completely static, it doesn't appear it is even allowed to be a uniform. As a result, both the gaussian and morphology shaders don't compile properly in WebGL.

This might be able to be resolved just by tweaking the flags to the spirv compiler and setting the right target versions.
Repository: flutter
Issue: [Impeller] OpenGLES backend tries to reuse buffers across different buffer targets, which fails on WebGL.
Labels: P3,e: impeller,team-engine,triaged-engine,e: webgl

Impeller's OpenGLES backend tries to reuse buffers across different buffer targets (i.e. `GL_ARRAY_BUFFER` vs `GL_ELEMENT_ARRAY_BUFFER`). WebGL doesn't like this and rejects the call to `glBindBuffer`. See this section of the WebGL spec on buffer binding restrictions: https://registry.khronos.org/webgl/specs/latest/2.0/#BUFFER_OBJECT_BINDING
Repository: go
Issue: runtime: sync fatal error swallows panic message
Labels: NeedsFix,compiler/runtime

```
package main

import (
	"net/http"
	"sync"
)

func main() {
	var mu sync.Mutex
	defer mu.Unlock()
	http.DefaultClient.Transport.RoundTrip(new(http.Request))
}
```

```
% go run x.go
fatal error: sync: unlock of unlocked mutex
[signal SIGSEGV: segmentation violation code=0x2 addr=0x18 pc=0x1001c3ed8]

goroutine 1 [running]:
sync.fatal({0x1001c9eb2?, 0x140000021c0?})
	/Users/rsc/go/src/runtime/panic.go:1031 +0x20
sync.(*Mutex).unlockSlow(0x1400000e250, 0xffffffff)
	/Users/rsc/go/src/sync/mutex.go:229 +0x38
sync.(*Mutex).Unlock(...)
	/Users/rsc/go/src/sync/mutex.go:223
panic({0x1002337e0?, 0x100342140?})
	/Users/rsc/go/src/runtime/panic.go:785 +0x124
main.main()
	/private/tmp/x.go:11 +0x68
exit status 2
% 
```

Removing the sync.Mutex, the program crashes with

```
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x18 pc=0x102e43ea4]

goroutine 1 [running]:
main.main()
	/private/tmp/x.go:8 +0x34
exit status 2
```

Note that the panic text is missing from the original crash.

Just as nested panics print all the panic values, so too this fatal error should print the earlier panic value.
Repository: TypeScript
Issue: `for (const x in #b)` is allowed
Labels: Bug,Help Wanted

### 🔎 Search Terms

Private identifier, for...in

### 🕗 Version & Regression Information

- This changed between versions 4.5.5 and 4.6.4

### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.5.0-dev.20240603#code/MYGwhgzhAECC0G8BQ1oGIBGAKAlIlq0AZgPYBO0WwJAdhAC7RjQCWN6Geyh0Avgf35A

### 💻 Code

```ts
class A {
  #b() {
    for (const a in #b) {
    }
  }
}
```


### 🙁 Actual behavior

No errors

### 🙂 Expected behavior

Error: `Private identifiers are only allowed in class bodies and may only be used as part of a class member declaration, property access, or on the left-hand-side of an 'in' expression`

### Additional information about the issue

Noticed this while working on https://github.com/typescript-eslint/typescript-eslint/pull/9232. There's a very suspicious condition in code: https://github.com/microsoft/TypeScript/blob/5a4134470128a062a8297f404dfb3321f8f55798/src/compiler/checker.ts#L33699

```ts
    function checkGrammarPrivateIdentifierExpression(privId: PrivateIdentifier): boolean {
        if (!getContainingClass(privId)) {
            return grammarErrorOnNode(privId, Diagnostics.Private_identifiers_are_not_allowed_outside_class_bodies);
        }

        if (!isForInStatement(privId.parent)) {
            if (!isExpressionNode(privId)) {
                return grammarErrorOnNode(privId, Diagnostics.Private_identifiers_are_only_allowed_in_class_bodies_and_may_only_be_used_as_part_of_a_class_member_declaration_property_access_or_on_the_left_hand_side_of_an_in_expression);
            }

            const isInOperation = isBinaryExpression(privId.parent) && privId.parent.operatorToken.kind === SyntaxKind.InKeyword;
            if (!getSymbolForPrivateIdentifierExpression(privId) && !isInOperation) {
                return grammarErrorOnNode(privId, Diagnostics.Cannot_find_name_0, idText(privId));
            }
        }

        return false;
    }
```

I don't know what `isForInStatement` is supposed to do there. I was unable to find the commit that introduced this—git blame took me to #44648 but that didn't have this condition.
Repository: material-ui
Issue: [material-ui][table] Aligning expandable parent and child rows
Labels: waiting for 👍,component: table,package: material-ui,enhancement

### Steps to reproduce

Link to live example: (required)
[
Steps:
1. Hi all I have a problera with the childRow I would like it to align to the header like the parent row, Can anyone help me? thanks
2.https://codesandbox.io/p/sandbox/create-edit-record-wkdp6c?file=%2Fsrc%2FApp.tsx
3.
]

### Current behavior

_No response_

### Expected behavior

_No response_

### Context

_No response_

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
```
</details>


**Search keywords**: Expand/Collapse
Repository: stable-diffusion-webui
Issue: [Bug]: inpaint img2img over-exposed
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [ ] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [X] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

last step on inpaint img2img (overexposed)


### Steps to reproduce the problem

goto img2img
tab "img2img"
put an image
write a prompt
cfg 5
denoise 0.8 or higher (you see it more 0.95)
picture is fine until last step (overexposed)
(with VA without, with refiner without)
model: origianl juggernautXL

### What should have happened?

in tab "inpaint"
i draw i mask
same settings 
no overposed area

### What browsers do you use to access the UI ?

_No response_

### Sysinfo

win10
rtx4060
v1.9.3

### Console logs

```Shell
no errors in console
```


### Additional information

bofore last step (screenshoot)
![grafik](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/118767589/40d10d30-5a5d-4ed9-9712-293b85ef84e0)

ready
![grafik](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/118767589/00b27ad6-3397-4e3f-93f6-7f780942b771)
Repository: electron
Issue: [Bug]: Unusable Electron application on a scalled wayland display.
Labels: platform/linux,bug :beetle:,has-repro-comment,30-x-y

### 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

30.0.7

### What operating system are you using?

Other Linux

### Operating System Version

Alpine Linux x86_64 v.3.20

### What arch are you using?

x64

### Last Known Working Electron version

-

### Expected Behavior

Electron app launches and it isn't glitching on window scalling / maximalization, when running on host with scalled wayland display.

### Actual Behavior

Electron is misinterpreting input, not scaling it's app viewport more than the default screen resolution, regardless of screen scaling used.

### Testcase Gist URL

_No response_

### Additional Information

Problem can be reproduced with KDE Plasma with Wayland support and display scaling set to be lower than `100%` in the display configuration. Electron ozone platform should be set as follows:
```
export ELECTRON_OZONE_PLATFORM_HINT="wayland"
```
Repository: go
Issue: proposal: syscall/js: add way to import() es modules 
Labels: Proposal

### Proposal Details

I don't know if this is a thing that already exists or not. I want to be able to import ESM modules in Go. I can do this in JavaScript via the dynamic `import()` expression. Right now the only way I know how to do this _without extra modifications_ (where I expect the consumer to just copy-paste `wasm_exec.js`, `wasm_exec_node.js`, or `wasm_exec.html` into their source tree and use that) is to use `eval()` which seems... not ideal.

```go
package main

import (
	"syscall/js"
	"log"
)

// import is a function-like keyword, not a global function
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import
var jsImportFunc = js.Global().Get("eval").Invoke("(s,o)=>import(s,o)") // 🟥🟥🟥
func jsImport(specifier string, options any) js.Value {
	return jsImportFunc.Invoke(specifier, options)
}
// https://stackoverflow.com/questions/68415674/await-js-async-function-promise-inside-a-go-function
func jsAwait(promise js.Value) js.Value {
	c := make(chan js.Value)
	jsOnResolve := js.FuncOf(func(this js.Value, args []js.Value) any {
        c <- args[0]
		return nil
    })
	jsOnReject := js.FuncOf(func(this js.Value, args []js.Value) any {
		// act the same as if a function threw
		panic(&js.Error{Value:args[0]})
		return nil
	})
	promise.Call("then", jsOnResolve, jsOnReject)
	return <-c
}

func main() {
	jsPrettier := jsAwait(jsImport("prettier", js.Value{}))

	jsFormatted := jsAwait(jsPrettier.Call("format", "hello();world();", map[string]any{
		"parser": "typescript", // https://prettier.io/docs/en/options#parser
	}))
	log.Print(jsFormatted.String())
}
```

The `eval()` breaks when a user of the Go wasm blob disallows unsafe `eval()` via Content-Security-Policy.

I know, I know. I could just do `globalThis.import = (s,o)=>import(s,o)` in JavaScript before I run the Go `test.wasm` blob. But I don't control how the user uses my WASM blob and it would be really nice if I didn't have to ask them to "hey please add this thing when you use the `wasm_exec.js` to load this wasm file".

A cool minor change to do this would be to add a `Go.prototype._import()` method that is just this:

```js
class Go {
	_import(specifier, options) {
		return import(specifier, options)
	}
}
```

and then in the syscall/js Go code:

```go
func Import(specifier string, options any) js.Value {
	return whateverThePrivateGoRuntimeVariableIsCalled.Call("_import", specifier, options)
}
```

or you could add it to the `importObject` thing instead. The point is that this _syntax thing_ (not a global function) is currently unobtainable without resorting to `eval()` or forcing the user of the `my-cool-go-thing.wasm` to include a special snippet in addition to the `wasm_exec.js` standard Go wasm+js runtime.
Repository: pytorch
Issue: ghstack and pytorch-bot can race
Labels: triaged,module: devx

This issue is meant to track instances of when ghstack and pytorch-bot race, causing the ghstack info to get overriden inadvertently.

Example where ghstack filled in the stack info but then pytorch-bot replaced it with the `oncall: distributed` tags:
<img width="642" alt="Screenshot 2024-06-03 at 3 00 49 PM" src="https://github.com/pytorch/pytorch/assets/31054793/f6d34fe1-370b-45c2-8539-b58bb76c4aad">

Taken from https://github.com/pytorch/pytorch/pull/127786

cc: @clee2000 

cc @ZainRizvi @kit1980 @huydhn @clee2000
Repository: PowerToys
Issue: Ability to add custom unicode characters to Quick Accent
Labels: Needs-Triage

### Description of the new feature / enhancement

I have some unicode characters that I frequently copy paste from google. It'd be great to have ability to add let's say: `U+0020`, `U+00A0`, `U+2007`, ... as accents for regular space character. I think you get the idea.




### Scenario when this would be used?

Sometimes we need to get some weird unicode characters that are not normally accessible through keybord for various reasons such as testing or just text styling. Having this ability baked into PowerToys would be so convenient I can't explain with words, since it also have ability to show the unicode name of the character when highlighted while selecting, making non-visibly differentiable characters easily differentiable.

### Supporting information

There are LOADS of such apps floating on github, most of them are ok, but as said before having that functionality baked into PowerToys would be game-changing for some.
Repository: pytorch
Issue: Inductor lowerings for magic methods are suspicious
Labels: triaged,oncall: pt2,module: dynamic shapes,module: inductor

### 🐛 Describe the bug

Steps to reproduce:
1. Patch in https://github.com/pytorch/pytorch/pull/126905 (landing soon)
2. Edit torch/_inductor/graph.py

```
            elif is_magic_method(n.target):
                # TODO: this is sus, it probably should be handled in the
                # lowerings themselves similarly to sym_size/sym-stride
                debug("is_magic_method")
                if isinstance(
                    n.meta["val"], (torch.SymInt, torch.SymFloat, torch.SymBool)
                ):
                    result = n.meta["val"].node.expr
                else: 
                    result = super().run_node(n)
```

remove the node.expr direct run check.

Tests will fail, because the lowerings will be doing insane things. Why are there insane lowerings in the table? I'm not sure...

### Versions

main

cc @msaroufim @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire
Repository: storybook
Issue: [Bug]: RSC stories that use "react-server" exports do not get bundled correctly
Labels: bug,react,sev:S2,rsc

### Describe the bug

Hi there! 👋 

Apollo has a package for integrating streaming + apollo client found here: https://github.com/apollographql/apollo-client-nextjs/

Recently they migrated to `react-server` conditional exports (RFC found here: https://github.com/reactjs/rfcs/blob/main/text/0227-server-module-conventions.md#react-server-conditional-exports) such that code that's supposed to only run on the server never gets imported in a client bundle. This obviously breaks in storybook where the RSC implementation is actually running in the browser. Does anyone have any suggestions around how to make this work? I expect more and more packages are going to use `react-server` for exports/bundling so it feels like this is something storybook should be prepared to handle. 

I provided a simple repo below that could be a starting point for coming up with a fix - it's just a barebones Next app with storybook 8 installed. 

### Reproduction link

https://github.com/shawngustaw/storybook-rsc-repro

### Reproduction steps

1. npm i
2. npm run dev 
3. verify `Pokemon` component renders correctly in NextJS app router using RSC's
4. npm run storybook
5. verify the same does not run within storybook

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.4.1
    CPU: (12) arm64 Apple M2 Pro
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.17.0 - ~/.nvm/versions/node/v18.17.0/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v18.17.0/bin/yarn
    npm: 9.6.7 - ~/.nvm/versions/node/v18.17.0/bin/npm <----- active
    pnpm: 9.1.4 - ~/.nvm/versions/node/v18.17.0/bin/pnpm
  Browsers:
    Chrome: 125.0.6422.61
    Safari: 17.4.1
  npmPackages:
    @storybook/addon-essentials: ^8.1.5 => 8.1.5 
    @storybook/addon-interactions: ^8.1.5 => 8.1.5 
    @storybook/addon-links: ^8.1.5 => 8.1.5 
    @storybook/addon-onboarding: ^8.1.5 => 8.1.5 
    @storybook/blocks: ^8.1.5 => 8.1.5 
    @storybook/nextjs: ^8.1.5 => 8.1.5 
    @storybook/react: ^8.1.5 => 8.1.5 
    @storybook/test: ^8.1.5 => 8.1.5 
    eslint-plugin-storybook: ^0.8.0 => 0.8.0 
    storybook: ^8.1.5 => 8.1.5
```


### Additional context
I brought this up with the Apollo team here: https://github.com/apollographql/apollo-client-nextjs/issues/307
_No response_