sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: CSS order incorrect with the combination of server and client components
Labels: bug,Webpack,linear: next

### Link to the code that reproduces this issue

https://github.com/Netail/repro-app-dir-css-order

### To Reproduce

1. `yarn dev` & open `localhost:3000`
2. See 1 yellow and 1 blue component
3. Uncomment the 'use client' in the `navigation-wrapper.tsx`
4. Instead of 1 yellow & 1 blue component it becomes 2 blue ones (Even after a reload & restart)

### Current vs. Expected behavior

CSS streaming of client components mess with the order of the css bundle, resulting in being appended later and thus overriding certain server side styling.

In the example it should stay a yellow and blue component instead of 2 blue components when uncommenting 'use client'.

It seem like the page.css overwrites css from the layout.css due to importing order issues. Some classes which get streamed to page.css are already in layout.css, maybe a check could be built in if they were already present in the layout.css bundle?

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.8.1
  npm: 10.5.0
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 14.3.0-canary.45 // Latest available version is detected (14.3.0-canary.45).
  eslint-config-next: N/A
  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)

Webpack

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

_No response_
Repository: terminal
Issue: Freeze & crash Windows Terminal Preview 1.21.1272.0 with these few simple steps, you'll never guess what the 3rd one is!
Labels: Issue-Bug,Product-Terminal,Area-Quality,Tracking-External,zInbox-Bug

### Windows Terminal version

1.21.1272.0

### Windows build number

10.0.22631.3527 x64

### Other Software

Just Terminal Preview, crashes with any shell (tested cmd.exe, bash in Ubuntu in WSL2).

### Steps to reproduce

1. Open Windows Terminal Preview with your default shell
2. Click the `[v]` menu, and select Settings to display the settings page
3. Tear-off the Settings panel into its own window, making both settings and your shell visible
4. Select any shell profile, click `[Appearance >]`
5. Close the Settings tab, which closes its individual window.
6. Wait ~30 seconds (could be longer apparently if focus is changed)
7. Give the focus to some other app, then click on your shell panel to give it the focus again
8. ?
9. Profit!

I've crashed it 10 times using these steps, it works every single time.

Edit: I'm still trying to reduce the steps to the minimum required.

### Expected Behavior

Windows Terminal should keep running

### Actual Behavior

Windows Terminal freezes, its client area gets ghosty transparent, it receives the dreaded `(Not Responding)` suffix, and Dr. Watson comes along to put it out if its misery.
Repository: node
Issue: http.request regression > v16 regression, 400 Bad Request is thrown when GET http.request has a payload
Labels: http,https

### Version

v16.16.0 serverside, v20.13.0 clientside

### Platform

Linux intmrovpn 5.4.0-176-generic #196-Ubuntu SMP Fri Mar 22 16:46:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux (serverside),              Darwin **********.local 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64 (clientside)

### Subsystem

http

### What steps will reproduce the bug?

```js
const https = require("https");
async function main() {
    await new Promise((resolve, reject) => {
        let httpRequest = https.request(
            "https://intmrovpn.com/",
            {
                method: "GET",
            },
            async httpResponse => {
                let data = [];
                httpResponse.on("data", chunk => {
                    data.push(chunk);
                });

                await new Promise(resolve => {
                    httpResponse.on("end", resolve);
                });

                if (!httpResponse.statusCode?.toString().startsWith("2")) {
                    reject(new Error(`Error, ${httpResponse.statusCode} ${httpResponse.statusMessage}\n` + Buffer.concat(data).toString()));
                } else {
                    resolve(Buffer.concat(data));
                }
            }
        );
        httpRequest.on("error", reject);
        httpRequest.write(Buffer.from("{}"));
        httpRequest.end();
    });
}
main().catch(e => console.error(e)).finally(() => process.exit());
```

### How often does it reproduce? Is there a required condition?

v20.13.0 clientside, and v16.16.0 (running a NodeJS server) serverside.

v18 clientside worked, and the errors only started happening after updating to v20.

### What is the expected behavior? Why is that the expected behavior?

Ideally there wouldn't be an error. I think the error is due to a combination of the serverside NodeJS https.Server, and the clientside https.request function.

If resolving the error is impossible, a quick fix would be to add a warning when "GET" requests have a body written to them. Otherwise this bug can be almost impossible to debug. The server receives the request, and the request handler is called, but then while the handling is still running (after the first async delay) the client receives a 400.

Fixing this, or adding a warning, would hopefully prevent the next poor soul from spending hours debugging where the blasted 400 error is coming from.

### What do you see instead?

Error, 400 Bad Request

### Additional information

_No response_
Repository: godot
Issue: Building .Net projects containing custom C# ResourceFormatLoader and ResourceFormatSaver after altering scripts throw errors
Labels: bug,topic:editor,topic:dotnet

### Tested versions

- Tested on 4.3 dev 6 and 4.2.2

### System information

Godot v4.3.dev6.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.5161) - 11th Gen Intel(R) Core(TM) i5-11600K @ 3.90GHz (12 Threads)

### Issue description

When having custom ResourceFormatSaver and ResourceFormatLoader in C# (with ```[GlobalClass]``` attribute or using ```ResourceLoader.AddResourceFormatLoader()``` and ```ResourceSaver.AddResourceFormatSaver()``` ), building the project throw several  ```Failed to add a custom resource saver, script 'res://script.cs' does not inherit 'ResourceFormatSaver'.``` errors (same for ResourceFormatLoader) after altering scripts, like adding a new comment line.

Despite theses errors, godot manages to use the customs ResourceFormat when running the project.

### Steps to reproduce

- Add a new c# script, extending either ResourceFormatSaver or ResourceFormatLoader.
- If the script has already been added, write a new comment line in a script.
- Build the project.

### Minimal reproduction project (MRP)

[CustomResourceFormatSaverLoader_MRP.zip](https://github.com/godotengine/godot/files/15240883/CustomResourceFormatSaverLoader_MRP.zip)

The mrp, when running, save the data of a custom resource in a custom save file, then load the file, read and display the content with a print. This process is just to show we can use the custom formats for saving and loading files despite the errors.
Repository: rust
Issue: flag to dump proc-macro's generated tokenstream to file for debugging
Labels: C-enhancement,T-compiler,A-proc-macros

I think it would be useful for rustc to have flags to dump a proc-macro's generated tokenstream to a file when rustc generates an error or if you choose to always dump the macro's output.

the existing `Zunpretty=expanded` flag is not suitable because it fails if rustc can't parse the generated tokenstream, it expands all macros in the generated tokenstream instead of showing exactly what the proc-macro generated, and it usually generates a huge amount of output which makes finding the output of any particular proc macro invocation very annoying.

This came up [here](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Revisiting.20the.20Module.20System.20in.202027/near/437531591) where the workaround I'm currently using is inspired by iirc https://github.com/drahnr/expander where the proc-macro writes an output file itself and generates `include!("path/to/generated/file.rs")`
Repository: go
Issue: proposal: runtime: surface silent panic-recovers
Labels: Proposal

### Proposal Details

We propose a feature to expose whether or not Go programs are frequently recovering from panics without explicitly handling recover values.

**Background**

In very large Go codebases, we observe that application crashing panics frequently cause production issues. In response, teams have created and proliferated a wide variety of solutions ranging from frameworks like code-generated recovery decorators to recovery-wrapped goroutine libraries paired with linters against plain go routine usage. Unfortunately, these solutions are often unknowingly mashed together and not standardized.

Over years, we’ve experienced a fundamental tension with these “automagic” panic recover patterns. They are a safety net that can prevent application crashes but they also frequently enable serious underlying panics and problems to go unnoticed in production.

**Solution Idea**

Adding logging and metric emissions to thousands of recover sites is often not feasible internally and not easy to do for 3rd party libraries we depend on. At Uber, we’re experimenting with changing go’s recover statement to automatically print a standard message with configurable formatting very similar to how the GOTRACEBACK setting helps Go users debug the causes of panics. Printing the recover value helps surface issues and printing the stacktrace helps users meaningfully debug the underlying panic.

Go runtime exported metrics are a possible alternative to provide Go users a sense of overall application health but can’t easily surface where individual panics are happening.
Repository: material-ui
Issue: [material-ui][Select] Checkmark select is failing Axe scan, interactive controls must not be nested
Labels: accessibility,component: select

### Steps to reproduce

https://mui.com/material-ui/react-select/#checkmarks

**Required dependencies:** Axe DevTools browser extension

Steps:
1. Navigate to https://mui.com/material-ui/react-select/#checkmarks
2. Open DevTools for your browser of choice (tested in Chrome 124.0.6367.119)
3. Expand the `select` control within the `Charkmarks` example
4. `Scan ALL of my page` with `Axe DevTools`

Attempted to resolve this issue a few different ways but none of them worked.
```
<Checkbox									
	disabled   // this works but the styling defaults to the disabled look
	checked={/* put your checked code here */}
	// tried different combinations of the following but none of these worked
	inputProps={{
		'tabIndex': -1,
		'aria-hidden': true,
		'aria-label': option.name,
		'title': option.name,
	}}
/>
```

### Current behavior

Axe DevTools flags each of the nested checkboxes as an issue. "Interactive controls must not be nested".

![AxeIssues_NestedControlsMUISelectCheckbox_NoGUI](https://github.com/mui/material-ui/assets/169182630/3eddbe1c-0295-49ae-abe4-676573b29138)


### Expected behavior

Either the MUI documentation should note the charkmarks select variant example is not compliant with accessibility rules or the Checkmarks select variant example code should be compliant.

### Context

Our UX designers desire a checkbox nested drop down control because the checkboxes more clearly delineate a selected state over the selection highlighting.

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Chrome 124.0.6367.119
    System:
    OS: Windows 10 10.0.19045
  Binaries:
    Node: 18.19.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.3 - C:\Program Files\nodejs\npm.CMD
    pnpm: 9.0.6 - C:\Program Files\nodejs\pnpm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Chromium (124.0.2478.67)
  npmPackages:
    @emotion/react: ^11.11.1 => 11.11.1
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base: 5.0.0-beta.28 => 5.0.0-beta.28
    @mui/icons-material: ^5.14.19 => 5.14.19
    @mui/material: ^5.15.7 => 5.15.16
    @types/react: ^18.2.42 => 18.2.43
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^5.3.3 => 5.3.3
```
</details>


**Search keywords**: checkbox select nested accessibility
Repository: flutter
Issue: [Impeller] Deprecate and remove Texture::SetContents in favor of BlitPass.
Labels: P2,e: impeller,team-engine,triaged-engine

This API has a few problems, namely:

* It exists at the core layer, before command buffers are defined. But encoding/uploading safely requires a cmd buffer object on Vulkan and Metal. Vulkan works around this by internally creating a cmd buffer and performing a copy to a VMA buffer, but this is extra wasteful.
* The metal implementation uses an unsafe API.
* It duplicates functionality that already mostly exists in the BlitPass.

Ripping out in one go is too difficult though, as its used all over the place and exposed via flutter gpu.
Repository: go
Issue: path/filepath: COM0 and LPT0 are now reserved on Windows
Labels: OS-Windows,NeedsDecision

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file states that COM0 and LPT0 are reserved names. I believe that this page used to only list COM[1-9] and LPT[1-9] as reserved, and empirically these names are available for use on the Windows versions I've tested.

We need to decide whether `filepath.IsLocal` should consider these names local or not.

In favor of `filepath.IsLocal("COM0")==false`: Current behavior, empirically you can create a file named `COM0`.

In favor of `filepath.IsLocal("COM0")==true`: Documented as a reserved name.
Repository: rust
Issue: Add lint on reference-to-pointer transmutes
Labels: A-lints,A-diagnostics,T-lang,T-compiler

Inspired by https://github.com/rust-lang/rust/issues/124861, specifically https://github.com/glium/glium/commit/ebdc18e06570d685884b68b8010b01d2aece8e3a

There's no reason to use an unsafe transmute to get a pointer from a reference, and as that code example shows it can easily hide bugs.  We should (at least) warn about it.

- For `&T` to `*const T`, recommend https://doc.rust-lang.org/std/ptr/fn.from_ref.html (machine-applicable, because it's always right)
- For `&mut T` to `*mut T`, recommend https://doc.rust-lang.org/std/ptr/fn.from_mut.html (machine-applicable, because it's always right)
- For `&T` to `*mut T`, recommend `from_ref`+`cast_mut`, but not auto-applicable because we should comment that it's probably wrong, and they probably want `from_mut` instead, but that will require larger reworking of the code.
- For `&mut T` to `*const T`, recommend https://doc.rust-lang.org/std/ptr/fn.from_mut.html with a note that in a generic context it might also need `.cast_const()`.
Repository: PowerToys
Issue: 文件无法接触占用
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.80.1

### Installation method

Microsoft Store

### Running as admin

None

### Area(s) with issue?

File Locksmith

### Steps to reproduce

删除文件时，提示文件有占用。使用该工具解除占用，却提示"找不到结果"。

### ✔️ Expected Behavior

解除文件占用。或者提示占用的进程的PID，以手动解除。

### ❌ Actual Behavior

使用该工具解除占用，却提示"找不到结果"。

### Other Software

_No response_
Repository: terminal
Issue: HDR: What if we supported colors beyond the mortal realm?
Labels: Issue-Feature,Area-Rendering,Product-Terminal

I think it'd be kind of funny if we supported scRGB with half-precision floats, just like what DWM uses for composition on HDR displays. That would allow us, either just for fun when defining colors in a theme, or maybe for dithering, to use fine grained floating point brightness values and chromaticity (color) values. That way we could finally ship an official "Barbie+" theme were all colors are pink but some are even pinker than the others. Here's what scRGB looks like, the white triangle is sRGB:

![ScRGB svg](https://github.com/microsoft/terminal/assets/2256941/34247a74-7044-4648-8760-c987ce8caa46)
([Source](https://en.wikipedia.org/wiki/File:ScRGB.svg))

This requires two changes:
* Make the renderer HDR aware. This would probably also require a HDR setting menu similar to those found in video games where, at a minimum, the paper white brightness can be configured.
  All relevant documentation can be found here: https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range#setting-up-your-directx-swap-chain
* Get rid of `til::color` in most places inside WT as it's limited to sRGB. It's just fine for VT related code or code based around `COLORREF`, however. The settings model needs a color struct that can represent any arbitrary space and gamut in order to not be tied down to any particular representation. The render can then convert it losslessly to scRGB floats. This also avoids loss during blending.
Repository: react
Issue: Bug: Incorrect form data when using an image submit button
Labels: Type: Bug,React 19

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: canary

## Steps To Reproduce

1. Render the following:
    ```jsx
    <>
      <form action={(formData) => console.log(new URLSearchParams(formData).toString())}>
        <button name="submitter" value="vanilla">Vanilla</button>
        <input type="image" name="submitter" href="/some/image.png" alt="Image" />
      </form>
   </>
    ```
2. Click on the image submit button

[Link to code example](https://codesandbox.io/p/sandbox/admiring-yalow-77vwdy?file=%2Fsrc%2FApp.js)

## The current behavior
`submitter=` is logged

## The expected behavior
Something like `submitter.x=5&submitter.y=10` should be logged

When an image submit button is activated, the form data set should include entries for the X and Y coordinates, indicating the relative position where the user clicked. This will keep the behavior consistent with a vanilla form submission ([MDN explainer](https://developer.mozilla.org/en-US/docs/Glossary/Submit_button#form_data_entries), relevant [section](https://html.spec.whatwg.org/#constructing-form-data-set) of the HTML spec)

## Additional commentary
We could probably just simplify all of [this code](https://github.com/facebook/react/blob/e7d213dfb0760dc9f6506fca6d6cfbac708a40e2/packages/react-dom-bindings/src/events/plugins/FormActionEventPlugin.js#L82-L103) to just `const formData = new FormData(form, submitter);` ... the submitter parameter is [widely available](https://caniuse.com/mdn-api_formdata_formdata_submitter) (87.42%); if we're concerned about browsers that don't support it, note that:
1. Many of them also [don't support `SubmitEvent.submitter`](https://caniuse.com/?search=SubmitEvent.submitter), which means the existing approach won't work for them either
2. FormData submitter can easily be [polyfilled](https://www.npmjs.com/package/formdata-submitter-polyfill) for developers that care about named submit buttons working correctly in old browsers

IMO React doesn't need to maintain its own hacky partial polyfill for an increasingly diminishing edge case :)

See some previous discussion on the topic [here](https://github.com/facebook/react/pull/26674/files/5a7629ddb4f22072e37ba1ae581977ce03bdf288#r1178495317).
Repository: next.js
Issue: next.js typescript plugin autocomplete not working for `viewport`
Labels: bug,TypeScript

### Link to the code that reproduces this issue

https://github.com/esau-morais/emots.dev

### To Reproduce

1. go to `app/layout.tsx`
2. remove `satisfies Viewport`
3. try using autocomplete
4. notice that it doesnt work

ps.: works for `metadata`, but not for `viewport`

### Current vs. Expected behavior

should autocomplete, once it's said in the docs

![image](https://github.com/vercel/next.js/assets/55207584/535b6be6-4d41-4c94-ad64-4fbfc7df210f)

current
![image](https://github.com/vercel/next.js/assets/55207584/324ee97a-6e09-467d-bc0c-4c25130e3e42)

expected
![image](https://github.com/vercel/next.js/assets/55207584/4fa7b5ed-b12e-4de9-a1e9-9a681309d406)


### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr  4 14:39:20 UTC 2
  Available memory (MB): 31195
  Available CPU cores: 12
Binaries:
  Node: 18.19.0
  npm: 10.2.3
  Yarn: 1.22.21
  pnpm: 9.1.0
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 13.3.0
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.0.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

TypeScript

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

_No response_
Repository: pytorch
Issue: ☂️ `torch.compile` generates slower code for LLMs than eager on ARM platform (M1/AARCH64)
Labels: module: performance,module: arm,oncall: pt2,oncall: cpu inductor

### 🐛 Describe the bug

On my M2 Pro, using https://github.com/pytorch-labs/gpt-fast/tree/malfet/set-prec-to-float16 and stories110M model:
```
python generate.py --checkpoint_path checkpoints/stories110M/model.pth
```
yields 166 tokens/sec, but the same one with compile only 100 tokens/sec

### Versions

nightly

cc @msaroufim @snadampal @ezyang @bdhirsh @anijain2305 @chauhang
Repository: PowerToys
Issue: System Crash
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response

### Microsoft PowerToys version

0.80.1

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

General

### Steps to reproduce

The system gets crashed all the time. Especially when working on Google Chrome.

### ✔️ Expected Behavior

Smooth Running

### ❌ Actual Behavior

The application runs smoothly but it had diverse effects on other applications.

### Other Software

Google Crome Version 124.0.6367.119 (Official Build) (64-bit)
Repository: godot
Issue: 2D physics pin joint angular limits do nothing
Labels: bug,topic:physics,topic:2d

### Tested versions

Godot 4.2.2 stable mono

### System information

Linux - Forward+

### Issue description

I have a very simple setup of a Node2D with two rigid body children and a pin joint child. The pin joint affixes the two bodies together. I attempt to enable "angular limit" but no matter what settings I use for the bounds nothing is affected. The body pivots just fine and can be motorized without issue. According to the code it is enabled.

### Steps to reproduce

- create a Node2D scene
- create 2 rigid bodies as children, each with collision shapes and sprites
- create a pin joint 2d and attach the two bodies
- enable angular limit
- instantiate this scene into a different, larger scene
on run the limb just falls loosely
![image](https://github.com/godotengine/godot/assets/50785295/d36bea18-4e6d-4eeb-b08f-e3d049f8bed4)
![image](https://github.com/godotengine/godot/assets/50785295/7a08eceb-0efb-4d5e-95f5-976d661a5ba3)


### Minimal reproduction project (MRP)

[project.zip](https://github.com/godotengine/godot/files/15242726/project.zip)