sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: [docs] expand on sx performance tradeoff
Labels: docs,performance,package: system,support: docs-feedback

### Related page

https://mui.com/system/getting-started/usage/#performance-tradeoffs

### Kind of issue

Missing information

### Issue description

Helllo! Performance tradeoff page for sx prop lists a comparison between 4 ways of styling your components:

| Benchmark case |Code snippet | Time normalized |
|-----------------------|----------------|-------------|
| a. 1,000 primitives	|`<div className="…">` |100ms |
| b. 1,000 components |`<Div>`	| 112ms |
| c. 1,000 styled components | `<StyledDiv>`|181ms|
| d. 1,000 Box |`<Box sx={…}>`| 296ms |

I simply want to see 2 more cases:

e. `<Box p={...} m={..}>` (in other words, styled only with Box properties and I would hope that it's exactly the same as case `d`, but I don't know it.
f. This case, which somebody wondered before me, but nobody answered:
https://stackoverflow.com/questions/71481181/in-mui-v5-sx-prop-is-there-a-performance-difference-between-passing-an-object-li

```jsx
const sx = {p: 2};

const MyDiv = () => {
    return <Box sx={sx}/>
} 
```
So, the same as `d`, but with sx object lifted up, meaning it's hopefully isn't re-created 1000 times.

It would also be very nice to see what is the difference in terms of memory use. I tried using `window.performance.memory` and  Memory tab on chrome myself (for about 5 minutes) but I failed to isolate this.


### Context

I sort of expect an argument in PR's at my place between `d` and `f` - `d` is inline, but `f` hopefully helps to fight this:
![image](https://github.com/user-attachments/assets/d517f25d-ab77-4f08-8f55-7eed461c32c2)

Thanks! 

**Search keywords**: sx prop performance memory tradeoff
Repository: rust
Issue: `--crate-type=rlib` + `-Cdebuginfo=2` + `-Zremap-cwd-prefix=.` is not reproducible on Windows
Labels: A-testsuite,O-windows,T-compiler,C-bug,A-reproducibility,S-needs-repro

In https://github.com/rust-lang/rust/pull/128456#issuecomment-2289562440 we noticed that:

`--crate-type=rlib` + `-C debuginfo=2` + `-Z remap-cwd-prefix=.` on Windows caused the rlib to be unreproducible.

https://github.com/rust-lang/rust/blob/0f442e265c165c0a78633bef98de18517815150c/tests/run-make/reproducible-build/Makefile#L4-L5

Two source files:

1. https://github.com/rust-lang/rust/blob/0ba9db87e61adcfd9a978188f61c20d9b423a099/tests/run-make/reproducible-build/reproducible-build-aux.rs
2. https://github.com/rust-lang/rust/blob/0ba9db87e61adcfd9a978188f61c20d9b423a099/tests/run-make/reproducible-build/reproducible-build.rs

Steps:

- Let "root" test directory be called `$base_dir`.
- `rustc reproducible-build-aux.rs`
- `mkdir test`
- `cp reproducible-build.rs test/reproducible-build.rs`
- compiler 1: `rustc --crate-type=rlib -C debuginfo=2 -Zremap-cwd-prefix=. -L $cwd reproducible-build.rs`
- `mv libreproducible_build.rlib libfoo.rlib`
- `cd test`
- compiler 2: `rustc --crate-type=rlib -C debuginfo=2 -Zremap-cwd-prefix=. -L $base_dir --out-dir=$base_dir reproducible-build.rs`
- `cd $base_dir`
- check if `libreproducible_build.rlib` and `libfoo.rlib` are different

Marking as `S-needs-repro` as I'm not sure of the root cause or exact reproduction environment; the test case failed on `x86_64-msvc` ci job. I'm also not exactly sure of the intended semantics of `-Z remap-cwd-prefix=.`.
Repository: go
Issue: syscall: TestExecPtrace failures
Labels: help wanted,OS-OpenBSD,NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- pkg == "syscall" && test == "TestExecPtrace"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8739559683359464513)):

    === RUN   TestExecPtrace
    panic: test timed out after 27m0s
    	running tests:
    		TestExecPtrace (26m58s)
    
    goroutine 41 gp=0xc000084c40 m=3 mp=0xc000080008 [running]:
    panic({0x171740?, 0xc00011c5b0?})
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/panic.go:804 +0x18c fp=0xc000112ee0 sp=0xc000112e20 pc=0x8574c
    testing.(*M).startAlarm.func1()
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/testing/testing.go:2373 +0x334 fp=0xc000112fc0 sp=0xc000112ee0 pc=0xffc54
    ...
    runtime.gopark(0xc000050798?, 0x2?, 0x0?, 0x0?, 0xc000050788?)
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/proc.go:435 +0x114 fp=0xc0000505d8 sp=0xc0000505a8 pc=0x85af4
    runtime.selectgo(0xc000050798, 0xc000050784, 0x0?, 0x0, 0x0?, 0x1)
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/select.go:335 +0x774 fp=0xc000050730 sp=0xc0000505d8 pc=0x60a04
    runtime.ensureSigM.func1()
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/signal_unix.go:1060 +0x1ac fp=0xc0000507c0 sp=0xc000050730 pc=0x7d86c
    runtime.goexit({})
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/asm_ppc64x.s:1022 +0x4 fp=0xc0000507c0 sp=0xc0000507c0 pc=0x8dea4
    created by runtime.ensureSigM in goroutine 35
    	/home/swarming/.swarming/w/ir/x/w/goroot/src/runtime/signal_unix.go:1043 +0x118


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: godot
Issue: "vkCreateGraphicsPipelines failed with error -3" errors after OS upgrade.
Labels: bug,platform:macos,topic:rendering

### Tested versions

4.2.2

### System information

MacOS 12.7.6, NVIDIA GeForce GTX 680 2 GB (Metal supported), Forward+

### Issue description

After upgrading from MacOS 10.15 (Catalina) to 12.7.6 (Monterey), I'm getting these errors in Godot:

>   vkCreateGraphicsPipelines failed with error -3 for shader 'SceneForwardClusteredShaderRD:9'.
  servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 - Condition "pipeline.is_null()" is true. Returning: RID()
  This render pipeline requires (0) bytes of push constant data, supplied: (16)
  No render pipeline was set before attempting to draw.
  vkCreateGraphicsPipelines failed with error -3 for shader 'SceneForwardClusteredShaderRD:9'.
  servers/rendering/renderer_rd/pipeline_cache_rd.cpp:61 - Condition "pipeline.is_null()" is true. Returning: RID()
  This render pipeline requires (0) bytes of push constant data, supplied: (16)
  No render pipeline was set before attempting to draw.

And 3D scenes are not rendered anymore.

The hardware is unchanged, but I suspect the drivers are different since the OS was upgraded.

Is there something I can try to fix this before having to downgrade to my previous setup?

### Steps to reproduce

N/A

### Minimal reproduction project (MRP)

N/A
Repository: excalidraw
Issue: Text breaks out of shape when pasting in left aligned mode
Labels: text wrapping

![font-align](https://github.com/user-attachments/assets/24905882-0973-45bb-963f-919b868b7b2a)
Repository: storybook
Issue: Introduce portable stories support for Web components
Labels: feature request,web-components,portable stories

When running portable stories tests with a setup file that does:

```ts
import { setProjectAnnotations } from "@storybook/web-components"

setProjectAnnotations([])
```

the `renderToCanvas` annotation is used, which is the most important bit that provides PS support for a renderer.

This issue encompasses:
- Checking how much effort it actually is to add PS support for Web Components
- Seeing how feasible are the tests (because of shadow-dom)
- Updating the storybook add postinstall script to allow installation for this renderer
- Updating docs
Repository: next.js
Issue: Error: You cannot use both an required and optional catch-all route
Labels: bug,Parallel & Intercepting Routes

### Link to the code that reproduces this issue

https://github.com/imCorfitz/next-modal-issue-example

### To Reproduce

1. Set up a Next.js app using intercepted parallel routes as per the example: https://github.com/vercel/nextgram
2. Assume you are building a site fully managed from a headless CMS, and move the root `page.tsx` file to a catch-all route e.g. `app/[[...params]]/page.tsx`
3. Create a `page.tsx` file in `app/photos` folder `export default function Page() { return <div>All Photos here</div>; }` (we could also add params logic to the catch all route, but this is simpler for testing).
4. Add a link to the modal linking to `all photos` - `<Link href="/photos'>All photos</Link>`
5. Test link.. Result: Modal remains open when navigating to the photos route.
6. Read and follow documentation telling us to create a `[...catchall]` route in the `@modal` directory, with a page that returns `null`
7. See error: `Failed to reload dynamic routes: Error: You cannot use both an required and optional catch-all route at the same level ("[...catchall]" and "[[...params]]" )`.

### Current vs. Expected behavior

I believe this is to be expected - however an alternative approach or solution to closing the modal on navigation is needed in that case.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 22.5.1
  npm: 10.8.2
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 14.2.5 // Latest available version is detected (14.2.5).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: N/A
Next.js Config:
  output: N/A
```


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

Parallel & Intercepting Routes

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

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

### Additional context

_No response_
Repository: react
Issue: [React 19] `use()` promise from state causes "async/await is not yet supported in Client Components" error
Labels: Type: Bug,React 19

## Summary

https://stackblitz.com/edit/vitejs-vite-kbccdh?file=src%2FApp.tsx

```tsx
import { use, useState } from 'react';

export default function App() {
  const [p] = useState(() => new Promise((res) => setTimeout(res, 500)));

  use(p);
  return 'hello!';
}
```

Note: I do not have a parent Suspense boundary.

### Actual behaviour

An error is thrown

> Error: async/await is not yet supported in Client Components, only Server Components. This error is often caused by accidentally adding `'use client'` to a module that was originally written for the server.

### Expected behaviour

I think this should render "hello!". If I lift the promise out of the state initialiser into the module, there is no error - React holds from rendering the app until the promise resolves.

```tsx
// This works fine, even without a parent <Suspense>
const p = new Promise((res) => setTimeout(res, 500));
export default function App() {
  use(p);
  return 'hello!';
}
```

If it's expected to throw an error in this scenario, then I think the error message should be improved. It should log the error message about the component suspended without a parent suspense boundary. I do think this is inconsistent though, and in original example should just work.
Repository: next.js
Issue: Incorrect caching
Labels: bug

### Link to the code that reproduces this issue

https://github.com/mastoj/more-cache-experiments

### To Reproduce

1. Build app and start
2. Open http://localhost:3000/cache/a/b/c and http://localhost:3000/revalidate in two different tabs (tab A and B)
3. Refresh tab A over and over again until the first time stamp changes, which is as expected
4. Wait 5 seconds and click "Revalidate A" in tab B
5. Go back to refreshing tab A over and over again until both timestamp changes

(you can test on the deployed version here https://more-cache-experiments.vercel.app/cache/a/b, https://more-cache-experiments.vercel.app/revalidate)

### Current vs. Expected behavior

### Current behavior:

What happens when you click "Revalidate A" seems to be that the next time the page will be revalidated is based on the revalidation time only on the "refreshed" fetch calls. This leads to the second timestamp being updated later than it should be. This could lead to weird scenarios when having long revalidation times I think.

### Expected behavior:

A little bit tricky, but I think the expected behavior should be to set a new revalidation time for the page to be the lowest of the times for newly calculated value and the existing one, but I'm not 100% that is correct.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:14:38 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6020
  Available memory (MB): 65536
  Available CPU cores: 12
Binaries:
  Node: 18.17.0
  npm: 10.8.2
  Yarn: 1.22.21
  pnpm: 9.1.0
Relevant Packages:
  next: 14.2.5 // Latest available version is detected (14.2.5).
  eslint-config-next: 14.2.5
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
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 start (local), Vercel (Deployed)

### Additional context

_No response_
Repository: storybook
Issue: Introduce portable stories support for HTML
Labels: feature request,html,portable stories

When running portable stories tests with a setup file that does:

```ts
import { setProjectAnnotations } from "@storybook/html"

setProjectAnnotations([])
```

the `renderToCanvas` annotation is used, which is the most important bit that provides PS support for a renderer.

This issue encompasses:
- Checking how much effort it actually is to add PS support for HTML
- Updating the storybook add postinstall script to allow installation for this renderer
- Updating docs
Repository: storybook
Issue: Introduce portable stories support for Angular
Labels: feature request,angular,portable stories

When running portable stories tests with a setup file that does:

```ts
import { setProjectAnnotations } from "@storybook/angular"

setProjectAnnotations([])
```

the `renderToCanvas` annotation is used, which is the most important bit that provides PS support for a renderer.

This issue encompasses:
- Checking how much effort it actually is to add PS support for Angular (with analogjs)
- Updating the storybook add postinstall script to allow installation for this renderer
- Updating docs
Repository: storybook
Issue: Introduce portable stories support for Preact
Labels: feature request,preact,portable stories

When running portable stories tests with a setup file that does:

```ts
import { setProjectAnnotations } from "@storybook/preact"

setProjectAnnotations([])
```

the `renderToCanvas` annotation is used, which is the most important bit that provides PS support for a renderer.

This issue encompasses:
- Checking how much effort it actually is to add PS support for Preact
- Updating the storybook add postinstall script to allow installation for this renderer
- Updating docs
Repository: pytorch
Issue: torch quantize error
Labels: oncall: quantization

### 🐛 Describe the bug

```python
import torch
t = torch.tensor(torch.inf, dtype=torch.float32)
qt = torch.quantize_per_tensor(t, 1, 133, torch.quint8)
r = torch.int_repr(qt)
print(r)  # tensor(0, dtype=torch.uint8) 
```
In the code above, **torch.inf** is computed by other operators. When quantization is performed at this point, the result will be 0. However, the correct result should be 255, because inf at this point has reached the upper bound of quantization, not the lower bound. The result can only be 0 when the quantization input parameter is **-torch.inf**.


### Versions

torch==2.1.2
using cpu backend qnnpack

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel @msaroufim
Repository: tauri
Issue: [bug] pointerType always falls back to "mouse" using the pointerdown event.
Labels: type: bug,status: upstream,platform: Linux

### Describe the bug

When using the pointerdown event in Javascript, the pointerType property is always set to "mouse" instead of "pen" or "touch" respectively. This also goes for the pressure property that's always set to 0.5, making it imposible to distinguish between a mouse, a pen and touch input.

I already tested the functionality of this event on other browsers to discard it's a problem with my Linux set up and the event fired just fine, and the property was correct.

### Reproduction

Add the event listener "pointerdown" and log the output of the event.pointerType property.

This bug was found on Arch Linux on the Cinnamon desktop environment under Wayland.

### Expected behavior

When using an active stylus pen, returning the "pen" property and the "touch" property for a touchscreen.

### Full `tauri info` output

```text
[⚠] Environment
    - OS: Arch Linux Unknown X64
    ✔ webkit2gtk-4.0: 2.44.2
    ✔ rsvg2: 2.58.2
    ✔ rustc: 1.80.1 (3f5fd8dd4 2024-08-06) (Arch Linux rust 1:1.80.1-1)
    ✔ cargo: 1.80.1 (376290515 2024-07-16)
    ⚠ rustup: not installed!
      If you have rust installed some other way, we recommend uninstalling it
      then use rustup instead. Visit https://rustup.rs/
    ⚠ Rust toolchain: couldn't be detected!
      Maybe you don't have rustup installed? if so, Visit https://rustup.rs/
    - node: 22.6.0
    - yarn: 1.22.22
    - npm: 10.8.2
    - bun: 1.1.24

[-] Packages
    - tauri [RUST]: 1.7.1
    - tauri-build [RUST]: 1.5.3
    - wry [RUST]: 0.24.10
    - tao [RUST]: 0.16.9
    - @tauri-apps/api [NPM]: 1.6.0
    - @tauri-apps/cli [NPM]: 1.6.0

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: React
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: go
Issue: proposal: net/http: maximum size and number of parts in ParseMultipartForm
Labels: Proposal

### Proposal Details

Please provide a way to limit the maximum size and number of parts when using `http.ParseMultipartForm`.

`http.ParseMultipartForm` is handy when the application knows that the files being uploaded are small; in that case, one does not need to go through the hassle of `http.MultipartReader`.  However, there appears to be no way to cause `http.ParseMultipartForm` to reject the upload if the parts are larger than a given size (say, a megabyte), and no way to reject posts with more than a given number of parts (say, 10).

I propose the addition of the following function (name to be reconsidered):
```
func (r *Request) ParseMultipartFormLimited(maxMemory int64, maxPartSize int64, maxParts int) error
```
This is just like `ParseMultipartForm`, except that:
  * if `maxPartSize` is strictly larger than 0, then any of the parts is larger than `maxPartSize` bytes, the function returns `http.ErrMessageTooLarge`;
  * if `maxParts` is strictly larger than 0, then if there are more than `maxParts` parts the function returns `http.ErrMessageTooLarge`.

If the function returns `http.ErrMesageTooLarge`, then the body of the request has been closed.
Repository: PowerToys
Issue: 未找到命令
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.83.0

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

General

### Steps to reproduce

![image](https://github.com/user-attachments/assets/aef36ac1-32f3-4633-8eb3-054939347c0e)


### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: angular
Issue: @angular/forms email validator doesn't support internationalized addresses
Labels: area: forms,forms: validators

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

No

### Description

Email validator from `@angular/forms` incorrectly validates internationalized email addresses like `vrána@vřeští.eu` or `маша@пошта.рф` as invalid.

It is described as an implementation of the WHATWG HTML specification (with some minor adjustments), but contrary to the specification, it doesn't convert the internationalized email address to punycode before validating it against the regex.

> User agents may transform the [value](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-fe-value) for display and editing; in particular, user agents should convert punycode in the domain labels of the [value](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-fe-value) to IDN in the display and vice versa.

https://html.spec.whatwg.org/multipage/input.html#email-state-(type=email)

While the validator is not a user agent per se, its behavior should be as close as possible to the browsers (at least that's my expectation), and all the major browsers correctly implement the behavior of converting internationalized addresses to punycode before validation.

### Please provide a link to a minimal reproduction of the bug

_No response_

### Please provide the exception or error you saw

_No response_

### Please provide the environment you discovered this bug in (run `ng version`)

_No response_

### Anything else?

_No response_
Repository: tauri
Issue: [bug] [tauri v2][iOS] Xcode project directory is outdated because you have modified your "identifier" in the Tauri configuration. Please run `tauri ios init` and try again. 
Labels: type: bug,status: needs triage,platform: iOS

### Describe the bug

Running **npm run tauri ios init** does not update xcode project directory. 

**npm run tauri ios dev 'iPhone 15'** keeps throwing the same error:

Error Xcode project directory is outdated because you have modified your "identifier" in the Tauri configuration. Please run `tauri ios init` and try again. 



### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
> relative_motion@1.0.67 tauri
> tauri info


[✔] Environment
    - OS: Mac OS 14.6.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.80.1 (3f5fd8dd4 2024-08-06)
    ✔ cargo: 1.80.1 (376290515 2024-07-16)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 20.11.0
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 2.0.0-rc.2
    - tauri-build [RUST]: 2.0.0-rc.2
    - wry [RUST]: 0.41.0
    - tao [RUST]: 0.28.1
    - @tauri-apps/api [NPM]: 2.0.0-rc.0
    - @tauri-apps/cli [NPM]: 2.0.0-rc.3

[-] App
    - build-type: bundle
    - CSP: <removed>
    - frontendDist: ../src
    - bundler: Webpack

[-] iOS
    - Developer Teams: <Removed>
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: rust
Issue: Run merged doc-tests by default in the same process and add opt-out attribute
Labels: T-rustdoc,C-discussion

https://github.com/rust-lang/rust/pull/126245 merged support in Edition 2024 for consolidating doctests into as few binaries as possible, with an opt-out of a `standalone` attribute.

I propose by default doc-tests should be run in parallel in the same process.

What's the motivation for the proposed change? For example when working on the Rust standard library, I usually run the tests for `core` and `std/alloc`, that takes incremental ~84s on my Zen 3 5900X machine. Out of that ~66s are spent running the ~4k core doc tests. That's on Linux, on Windows I expect this to be even slower, due to a higher process spawning overhead. Merged doc tests is tied to the Rust 2024 edition because it can break behavior. So there is already precedent for having a new default that is better in the common case, but may break existing projects that opt into the new edition, requiring some work. I believe and doing some code analysis via grep.app would support that the majority of doc tests can be run in parallel in the same binary. So that should be the default. For the cases that depend on some kind of singleton, log lib init, etc. they can be marked with an attribute as requiring a standalone process. That would make for two possible attributes: build isolated and run isolated. If this is deemed too complex, it's imaginable that there is only a single attribute that implies both build and run isolated.

Tagging @GuillaumeGomez