sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: internal/trace/v2: TestTraceStress failures
Labels: help wanted,NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- pkg == "internal/trace/v2" && test == "TestTraceStress"
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/92cc6bbe7fb28ad16031cd2339e43f11eaccecaa)):

    --- FAIL: TestTraceStress (3.33s)
        --- FAIL: TestTraceStress/Default (3.33s)
            trace_test.go:551: stderr: SIGSEGV: segmentation violation
                PC=0x9ef0fac m=9 sigcode=1 addr=0x90
    
                goroutine 0 gp=0xc000007ba0 m=9 mp=0xc00007a008 [idle]:
                runtime.readgstatus(...)
                	/tmp/buildlet/go/src/runtime/proc.go:1056
                runtime.traceWriter.writeProcStatusForP({{0xc00007a008?, 0xa0000000a?}, 0x300000002?}, 0x70000fc3bd38?, 0x56?)
                	/tmp/buildlet/go/src/runtime/trace2status.go:91 +0xcc fp=0x70000fc3bcf0 sp=0x70000fc3bcb8 pc=0x9ef0fac
    ...
                r13    0x1
                r14    0xc000007ba0
                r15    0x3
                rip    0x9ef0fac
                rflags 0x10246
                cs     0x2b
                fs     0x0
                gs     0x0
                exit status 2
            trace_test.go:553: exit status 1


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: godot
Issue:  In 4.2 Stable GPUParticles3D using Directed Points emission shape produces wrong emission direction
Labels: bug,topic:3d,topic:particles

### Godot version

v4.2.stable.mono.official [46dc27791]

### System information

Godot v4.2.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 Ti (NVIDIA; 31.0.15.1640) - AMD Ryzen 7 4800H with Radeon Graphics (16 Threads)

### Issue description

Using the Directed Points emission shape with GPUParticles3D works as expected for PlaneMesh and Quadmesh primitives, but for other meshes the particles are not emitted in the right direction. For example, using a BoxMesh to generate the emission points will make only some of the particles be emitted normal to the faces of the box. Some of the particles are emitted in the opposite direction (ie. into the inside of the box) and some are emitted normal to the surface. Using a mesh imported from blender produces the same issue.

### Steps to reproduce

In the included Minimal reproduction project the directed emission shape has been generated from the BoxMesh. When the camera is inside the box you can see that some particles are being emitted backwards into interior of the mesh, and also that some particles (most even?) are actually being emitted tangent to the faces rather than normal to them.

The spawn velocity direction of the particle system is set to zero, but playing with the spawn velocity direction does has an effect. I would expect that spawn velocity direction would be overridden by the Emission Normal Texture, or maybe added to it, neither seems to be the case. Setting the spawn velocity direction to be the Z direction seems to do nothing, while setting it to the Y direction or X direction does quite strange things.

### Minimal reproduction project

[particle directed emission issue.zip](https://github.com/godotengine/godot/files/13531521/particle.directed.emission.issue.zip)
Repository: deno
Issue: %d and %i should use parseInt() all the time
Labels: bug,good first issue

_even if_ they are bigints.

https://github.com/denoland/deno/blob/a1d823e27d1b605b5658fddc1c9273667f0e9e84/ext/console/01_console.js#L3110-L3119

should be

```js
// Format as an integer.
const value = args[a++];
if (typeof value === "symbol") {
  formattedArg = "NaN";
} else {
  formattedArg = `${NumberParseInt(value)}`;
}
```

if im interpreting the specification correctly:

> 1. If specifier is %d or %i:
>     1. If [Type](https://tc39.github.io/ecma262/#sec-ecmascript-data-types-and-values)(current) is Symbol, let converted be NaN
>     2. Otherwise, let converted be the result of [Call](https://tc39.github.io/ecma262/#sec-call)([%parseInt%](https://tc39.github.io/ecma262/#sec-parseint-string-radix), undefined, « current, 10 »).

https://console.spec.whatwg.org/#formatter

this is what Bun does. this is what browsers do.

Chrome:
```js
console.log("%d", 10000n)
VM43:1 10000
```

Firefox:
```js
console.log("%d", 10000n)
10000
```

Bun
```js
> console.log("%d", 1000n)
1000
```

Current Deno:
```js
> console.log("%d", 1000n)
1000n
```

Should be:
```js
> console.log("%d", 1000n)
1000
```
Repository: go
Issue: net/http: TestTransportDiscardsUnneededConns failures with `use of closed network connection`
Labels: NeedsInvestigation

```
#!watchflakes
post <- pkg == "net/http" && test == "TestTransportDiscardsUnneededConns" && `use of closed network connection`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/c7a42ca7d046b80e69f7fa60e09b06697e3a8adc)):

    --- FAIL: TestTransportDiscardsUnneededConns (0.00s)
        --- FAIL: TestTransportDiscardsUnneededConns/h2 (2.54s)
            clientserver_test.go:1141: 10 connections opened, 8 closed; want 9 to close
            clientserver_test.go:210: server log: http: TLS handshake error from 127.0.0.1:51208: read tcp 127.0.0.1:51199->127.0.0.1:51208: use of closed network connection


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: rust
Issue: Emit a warning around thin `&CStr` interior mutability breaks
Labels: A-diagnostics,T-compiler,T-libs

From @chorman0773 https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/CStr.20as.20thin.20pointer/near/405432566

Passing an `&UnsafeCell<CStr>` to `size_of_val` is currently sound because it just returns the length parameter of the fat pointer. After making `CStr` thin however, `size_of_val` will need to call `strlen` on the data. This is not ok in a `&UnsafeCell` because another context could be writing the data, e.g. temporarily overwriting the `\0`.

This seems like something we may be able to emit a warning for?

Thin cstr: https://github.com/rust-lang/rust/issues/59905

@rustbot label +T-libs +T-compiler +A-diagnostics
Repository: rust
Issue: -Z macro-backtrace doesn't provide new information
Labels: C-enhancement,A-diagnostics,T-compiler,A-proc-macros

### Code

Any (I think) proc macro which outputs syntactically correct but semantically invalid code. I encountered this issue [here](https://github.com/Einliterflasche/pg-worm/blob/bd2724d5147970145f48ba58ac7aa6039f8c4380/pg-worm-derive/src/lib.rs#L12) when running `cargo test easy`.


### Current output


This is the compiler error without `-Z macro-backtrace`:
```Shell
error[E0282]: type annotations needed
   --> pg-worm/src/query/table.rs:225:14
    |
225 |     #[derive(Model)]
    |              ^^^^^ cannot infer type
    |
    = note: this error originates in the derive macro `Model` (in Nightly builds, run with -Z macro-backtrace for more info)
```
And this is the ouput with the flag:
```Shell
error[E0282]: type annotations needed
   --> pg-worm/src/query/table.rs:225:14
    |
225 |     #[derive(Model)]
    |              ^^^^^
    |              |
    |              cannot infer type
    |              in this derive macro expansion
    |
   ::: /home/me/code/pg-worm/pg-worm-derive/src/lib.rs:12:1
    |
12  | pub fn derive(input: OldTokenStream) -> OldTokenStream {
    | ------------------------------------------------------ in this expansion of `#[derive(Model)]`
```


### Desired output

I would expect `-Z macro-backtrace` to show the error in the expanded code, so something like this (assuming this were the code produced):

```Shell
error[E0282]: type annotations needed
   --> pg-wprm/src/query/table.rs:255:14
225 |     let foo = "bar".into();
    |                     ^^^^
    |                     |
    |                     cannot infer type
    |                     in this derive macro expansion
    |
    | ------------------------------------------------------ in this expansion of `#[derive(Model)]`
```


### Rationale and extra context

As it stands, when code produced by a proc macro fails to compile for semantic reasons we only receive the error message, no span or note etc. Debugging such an error is no pleasant task and aften spending hours on separate days going through the `cargo expand` output I still can't figure out what is wrong with my code. I would expect the `macro-backtrace` flag to produce a more detailed account of what went wrong, including the span of the error in the expanded code.

### Other cases

_No response_

### Anything else?

_No response_
Repository: material-ui
Issue: [joy-ui] Typography crashes if used with `dangerouslySetInnerHtml`
Labels: on hold,component: Typography,package: joy-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example:
https://codesandbox.io/p/sandbox/dazzling-visvesvaraya-y9tgkk

Steps:

1.
```
export default function TypographyBasics() {
  return <Typography dangerouslySetInnerHTML={{ __html: "test" }} />;
}
```


### Current behavior 😯

Uncaught Error: Can only set one of `children` or `props.dangerouslySetInnerHTML`.

### Expected behavior 🤔

Renders text

### Context 🔦

Render md -> html and set it as content of the typography.

I'm not sure how to apply typography's styles to text otherwise

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

  System:
    OS: Windows 11 10.0.22621
  Binaries:
    Node: 20.9.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.1.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Chromium (119.0.2151.97)
  npmPackages:
    @emotion/react: ^11.11.1 => 11.11.1
    @emotion/styled: ^11.11.0 => 11.11.0
    @mui/base: 5.0.0-beta.25 => 5.0.0-beta.25
    @mui/icons-material: ^5.14.19 => 5.14.19
    @mui/joy: 5.0.0-beta.16 => 5.0.0-beta.16
    @types/react: ^18.2.39 => 18.2.39
    react: ^18.2.0 => 18.2.0
    react-dom: ^18.2.0 => 18.2.0
    typescript: ^5.3.2 => 5.3.2
</details>
Repository: vscode
Issue: Consider increasing the terminal.integrated.scrollback default value
Labels: help wanted,feature-request,terminal-process

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

[vscode/src/vs/workbench/contrib/terminal/common/terminalConfiguration.ts](https://github.com/microsoft/vscode/blob/b91245de85dc5429ad340fa491abaa4510da4ec4/src/vs/workbench/contrib/terminal/common/terminalConfiguration.ts#L262)

Line 262 in [b91245d](https://github.com/microsoft/vscode/commit/b91245de85dc5429ad340fa491abaa4510da4ec4)

 default: 1000 
This line hasn't been changed for 3 years. And that was just a move. So as far as I can tell, this hasn't been changed in many many years (maybe ever). Computers continue to get faster, so I believe that the average user could easily handle 2000 lines of history. The benefit would be less frustration when running commands that spit out more than 1k lines of output.

This is a duplicate issue of https://github.com/microsoft/vscode/issues/162983 that I promised to bring up again once terminal perf was improved
Repository: vscode
Issue: Handle markdown links better
Labels: feature-request,debt,l10n-platform

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Often we get issues like this:
https://github.com/microsoft/vscode/issues/199715

where our translators have messed up markdown links because they've added spaces between `]` and `(` in `[...](...)`.

We have _a_ mechanism for stopping this... adding a comment in the localize call like:
```ts
localize(
  {
    key: 'asdf',
    comment: ['{Locked="](https://github.com)"}']
  },
  'here is a [link](https://github.com).'
)
```
and in extensions:
```ts
l10n.t({
    message: 'here is a [link](https://github.com).',
    comment: ['{Locked="](https://github.com)"}']
})
```

This programmatically makes sure these locked strings don't change.

but we have a lot of markdown links in our strings... maybe we can do this somehow automatically.
Repository: next.js
Issue: Not-found broken with multiple root layouts
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/blissful-fog-nflrh6

### To Reproduce

1. Open sandbox and click `not found page`
2. It will redirect to the generic nextjs 404 page

### Current vs. Expected behavior

Generic 404 Nextjs error page is shown when I navigate to any unknow urls.

 I expect to be redirected to my custom 404 UI handler

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56 PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64
Binaries:
  Node: 20.9.0
  npm: 10.1.0
  Yarn: N/A
  pnpm: 8.9.0
Relevant Packages:
  next: 14.0.3
  eslint-config-next: 13.5.6
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


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

App Router, Routing (next/router, next/navigation, next/link)

### Additional context


> Good to know: In addition to catching expected notFound() errors, the root app/not-found.js file also handles any unmatched URLs for your whole application. This means users that visit a URL that is not handled by your app will be shown the UI exported by the app/not-found.js file.

 https://nextjs.org/docs/app/api-reference/file-conventions/not-found
 --- 

According to the docs in order to be able to handle any unmatched URLs in the application we are bound to the fixed path for the not-found UI that must be placed at the root of the app -> `app/not-found.js` 

This breaks not-found custom UI handling as per provided example.

I've 2 root layout groups https://nextjs.org/docs/app/building-your-application/routing/route-groups#creating-multiple-root-layouts

1. Auth group (which is publicly accessible)
2. Main group (which is accessible if user is authenticated and basically contains the whole app routing)

With this setup and not having app root not-found file it's not possible to be able to handle 404 with custom UI as any 404 url handling is bound to the root `app/not-found.tsx`.
I believe this should not be bound to the fixed path but rather the `top most` existing `not-found` file and if no file exist then generic 404 should intercept. This also applies for the error.tsx I believe.
Repository: godot
Issue: Flickering when changing scenes
Labels: bug,topic:core,confirmed,regression

### Godot version

4.2 stable

### System information

Windows 11 NVIDIA RTX 3060 Laptop GPU Vulkan / MacOS 14.1.1 M1, M2 Metal

### Issue description

When changing scenes with a shader transition the game screen will flash white for a brief second when the new scene loads. This is happening on Windows and MacOS. This does not happen in 4.2 RC1 but became an issue in RC2 and is still present in stable. Does this on all modes, Forward+, Compatibility, Mobile

### Steps to reproduce

Create a scene that has a shader transition that when the scene changes it does a "fade out" and "fade in"

### Minimal reproduction project

[Flicker.zip](https://github.com/godotengine/godot/files/13532779/Flicker.zip)
Repository: next.js
Issue: Critical dependency: the request of a dependency is an expression
Labels: bug

### Link to the code that reproduces this issue

https://github.com/baserun-ai/baserun-next

### To Reproduce

1. `yarn install`
2. Get api key from https://baserun.ai/
3. Set it with `BASERUN_API_KEY`. If you need one - you can also ping me on twitter https://x.com/timsuchanek
4. Set the `OPENAI_API_KEY`
5. `yarn dev`
6. Open `http://localhost:3000`

See the warning.
The warning is coming from this file: https://github.com/baserun-ai/baserun-js/blob/main/src/patches/modules.ts

### Current vs. Expected behavior

I know that we do janky stuff in https://github.com/baserun-ai/baserun-js/blob/main/src/patches/modules.ts, it's needed to auto-instrument the `openai` and `@anthropic/sdk` packages though.
As users of Baserun install the `baserun` sdk, it's a negative experience if they see this warning.

How could we make this warning go away? Thanks!
<img width="481" alt="image" src="https://github.com/vercel/next.js/assets/1094804/af5699cb-8e24-4342-a088-c236b6a2093c">


### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:33:00 PDT 2023; root:xnu-10002.41.9~7/RELEASE_ARM64_T6031
Binaries:
  Node: 21.2.0
  npm: 10.2.1
  Yarn: 1.19.1
  pnpm: 8.8.0
Relevant Packages:
  next: 14.0.3
  eslint-config-next: 14.0.3
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.2
Next.js Config:
  output: N/A
```


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

Not sure

### Additional context

Note, I'm aware that this isn't a bug, but something on our end, but the bug template made most sense to share all the relevant context.
Repository: flutter
Issue: [google_sign_in_web] Enable incremental authorization for Code Model.
Labels: platform-web,p: google_sign_in,P3,team-web,triaged-web

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

It's not super clear by [the instructions](https://developers.google.com/identity/oauth2/web/guides/use-code-model), however the [API](https://developers.google.com/identity/oauth2/web/reference/js-reference#CodeClientConfig) seems to suggest that the CodeClient is able to do incremental authorization through the `include_granted_scopes` configuration value.

The current implementation of `google_sign_in_web` exposes a CodeClient that only supports setting `scopes` when it's [created](https://github.com/flutter/packages/blob/2c8512a0277d190a2f64bb4e7edd9bb4a4eb3395/packages/google_sign_in/google_sign_in_web/lib/src/gis_client.dart#L55-L61), but not again [when it's used](https://github.com/flutter/packages/blob/2c8512a0277d190a2f64bb4e7edd9bb4a4eb3395/packages/google_sign_in/google_sign_in_web/lib/src/gis_client.dart#L291-L297).

### Proposal

Modify the API that the web plugin exposes of the CodeClient so additional `scopes` can be requested as needed. This might entail:

* Add a `List<String> scopes` parameter to the `requestServerAuthCode`
* Re-create the `CodeClient` as needed to support multiple requests
* Pass the `include_granted_scopes` parameter when creating the client
Repository: pytorch
Issue: DISABLED test_matmul_triton_kernel_benchmark (__main__.TestKernelBenchmark)
Labels: module: rocm,triaged,skipped

Platforms: rocm

This test was disabled because it is failing on main branch ([recent examples](https://hud.pytorch.org/failure?name=rocm%20%2F%20linux-focal-rocm5.7-py3.8%20%2F%20test%20(default%2C%201%2C%203%2C%20linux.rocm.gpu)&jobName=linux-focal-rocm5.7-py3.8%20%2F%20test%20(default%2C%201%2C%203%2C%20linux.rocm.gpu)&failureCaptures=%5B%22inductor%2Ftest_kernel_benchmark.py%3A%3ATestKernelBenchmark%3A%3Atest_matmul_triton_kernel_benchmark%22%5D)).

This starts failing on ROCm after https://hud.pytorch.org/pytorch/pytorch/commit/68a8d74f3f4abc76899e8b5007737d541c6eca17.  The test wasn't run as part of the subset ROCm tests in trunk

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Repository: godot
Issue: Using "Stop Running Project(F8)" button prevents generating vulkan pipeline cache
Labels: bug,topic:rendering,needs testing

### Godot version

4.2.stable

### System information

Godot v4.2.stable - Windows 10.0.22000 - Vulkan (Forward+) - dedicated AMD Radeon RX 5600M (Advanced Micro Devices, Inc.; 31.0.21023.2010) - AMD Ryzen 7 4800H with Radeon Graphics (16 Threads)

### Issue description

Edit: Check my latest reply, looks like using "Stop Running Project(F8)" button prevents generating vulkan cache file.




Shader loading is very slow on Forward+ compared to mobile and compatibility renderers, when running a project with F5/F6. 

Shader cache and vulkan pipeline cache at %AppData%\Godot\app_userdata\projectname\ directory don't regenerate, but most shaders don't load any faster. 

I deleted all caches and used --verbose output to measure shader loading times. Looks like there is no way to output timestamps, I had to screen record console output.

Caches I deleted:
%AppData%\Roaming\Godot\
%AppData%\Local\Godot\
.godot
/AMD folders from each drive(includes directx caches but deleted anyway)
Shader cache from gpu driver

I repeated the test multiple times, timings below were consistent each run. Shader time is time between first and last "Shader 'shadername' (group x) SHA256: XXXX..." line in verbose output.

| Project loading time from project manager | Without cache | With Cache | Shaders Without Cache | Shaders With Cache |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| Forward+ | 8000ms   | 6800ms | 1600ms | 1000ms |
| Mobile  | 7000ms   | 6100ms | 733ms  | 267ms |
| Compat | 6867ms   | 5900ms  | 366ms  | 133ms | 

| Project running time with F6 | Without cache | With Cache | Shaders Without Cache | Shaders With Cache |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| Forward+ | 14133ms | 13200ms| 12633ms | 11900ms |
| Mobile  | 3100ms | 2433ms| 1600ms | 966ms |
| Compat | 1533ms | 1400ms | 334ms | 100ms  | 


| Notable Forward+ shaders | Without cache | With Cache | 
| ------------- | ------------- | ------------- | 
| ParticlesCopyShaderRD | 500ms | 500ms| 
| SsilShaderRD | 267ms | 233ms | 
| SdfgiPreprocessShaderRD | 2100ms | 2067ms |  
| SdfgiDirectLightShaderRD | 300ms | 300ms |  
| SdfgiIntegrateShaderRD | 433ms | 400ms |  
| GiShaderRD | 4033ms | 4000ms |  
| VolumetricFogProcessShaderRD | 200ms | 200ms |  
| CubemapFilterShaderRD | 1133ms | 1100ms|  

 I have this issue in all godot 4 builds I tried. If there is a way to profile shader loading times please let me know. I don't know how accurate verbose output is.



### Steps to reproduce

- Open a new project with forward+, add any nodes.
- Run with F5/F6, then repeat. It should load faster in second run but it doesn't(at least on my machine). 

### Minimal reproduction project

[bench.zip](https://github.com/godotengine/godot/files/13533129/bench.zip)
Repository: node
Issue: node: ../deps/uv/src/unix/linux.c:1091: uv__poll_io_uring: Assertion `uv__has_active_reqs(loop)' failed.
Labels: libuv,linux

### Version

v20.10.0

### Platform

Ubuntu 22.04.3 LTS

### Subsystem

_No response_

### What steps will reproduce the bug?

https://github.com/un-ts/synckit/actions/runs/7067518826/job/19240983880#step:6:16

Just run `yarn && yarn benchmark:esm`

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

consistent

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

No error like other OSes

### What do you see instead?

```log
node: ../deps/uv/src/unix/linux.c:1091: uv__poll_io_uring: Assertion `uv__has_active_reqs(loop)' failed.
Aborted (core dumped)
error Command failed with exit code 134.
```

### Additional information

_No response_