sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: Problems with Link | href | dynamic "as" | headers: next-url, referer 
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/MrOxMasTer/shopco/commit/f7d9e29b086159435e105cabf0521f56f08d8b8e

### To Reproduce

1. Run the application in dev mode (--turbo)
2. Click on the user's icon to go to the site with authorization
3. Click on the burger, which opens the menu page
4. Click on the cross and try to go back 

### Current vs. Expected behavior

After clicking the cross, return to the page where the user was before

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
Binaries:
  Node: 20.11.1
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.3
  eslint-config-next: 14.1.3
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.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)

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

1. The first moment. Using the next url. It can be used, but it breaks the site when updating

https://github.com/vercel/next.js/assets/59291123/e31e4171-25f6-42b3-8f3f-8613bf88b4f3

2. Pathname Usage. Does not go back to the page and on refresh causes an error that is not corrected in any way. Only by restarting dev

https://github.com/vercel/next.js/assets/59291123/eaa7ce45-0a2b-4902-9432-d42f2565146c

3. Applying as, so that the url that is specified in the string would be the url on refresh. There is no transition. When refreshing it breaks the page

https://github.com/vercel/next.js/assets/59291123/eabb07ee-bbf2-4188-9c01-b994c15ba10c


4. Attempting to apply a full reference which also fails to produce any results

https://github.com/vercel/next.js/assets/59291123/843227c8-7093-4133-a041-99ca80a7983b

The problem is that maybe I don't understand how "as" is supposed to work?

I also can't switch to normal dev mode OR update the package because it says that my modal component is not server-side, even though the modal doesn't even have 'use client' in the higher-order components (Like the components inside) (next 14.2.0-canary.28):
![image](https://github.com/vercel/next.js/assets/59291123/1728b4c5-822d-4ba2-bfb6-7266c7d92708)
![image](https://github.com/vercel/next.js/assets/59291123/2985890e-f005-4572-bc3f-f1ddc6550cf5)
![image](https://github.com/vercel/next.js/assets/59291123/18f6315c-882a-4f7d-94ad-8d15f1d6d90f)
![image](https://github.com/vercel/next.js/assets/59291123/0e8befa8-e9c0-4626-bded-2bc7a7473662)
![image](https://github.com/vercel/next.js/assets/59291123/34fb989f-258a-498e-9939-eba042304746)

P.S.
Forgot to mention 2 details with js disabled:

next-url always has value = "/" and if used, it always redirects to the home page
pathname (from referer) - works as it should. Normally redirects to the pages from which the user came from the menu.
Repository: godot
Issue: Appears to be unclosed PIX event markers which make performance profiling difficult
Labels: discussion,topic:rendering,topic:thirdparty,performance

### Tested versions

4.3.dev [68ad520da4]

### System information

Windows 11, d3d12, Nvidia RTX 3060 ti driver 551.76

### Issue description

I was interested in checking out how Godot looks in PIX timing captures (profiling tool) after the acyclic graph rendering update and noticed the PIX events look wrong. The most likely reason is an unclosed PIX event.

The first clue is PIX detects an unusually large event depth of >2500:
![image](https://github.com/godotengine/godot/assets/6880264/6423b435-c11f-4d66-9ab6-ebf36e44f5df)

Which you can see in the Timeline view on either the API queue or thread (after unchecking flatten events):
![image](https://github.com/godotengine/godot/assets/6880264/7da8746a-bd4a-4d1e-8c0d-6a33b3e9015d)


### Steps to reproduce

1. Build with d3d12 and pix support
```
python misc/scripts/install_d3d12_sdk_windows.py
scons d3d12=yes use_pix=yes dev_build=yes
```
2. Clone the Desert Light demo: https://github.com/RPicster/godot4-demo-desert-light
3. Open Desert Light demo, go to Project Settings | Rendering Device and change it to D3D12
4. Download WinPIX (I used 2403.08) from https://devblogs.microsoft.com/pix/download/
5. Run the Desert Light demo and attach WinPIX (ensure "For GPU Capture" is unchecked). Enable "GPU timings" in the timing capture options and start the capture
![image](https://github.com/godotengine/godot/assets/6880264/7f6403c5-8625-4b68-8952-a4900551e9d0)
6. Let it capture for a bit (I did 20ish seconds), then click stop timing capture
7. Inspect the capture (see screenshots from issue description)

I uploaded a zip of the capture I took (it's too big to upload directly to GitHub): https://1drv.ms/u/s!AuL5V9eLegCYg-YSTLb-EG8lp0LIpw?e=3qETCe

### Minimal reproduction project (MRP)

See repro steps for a good example. You can see evidence of it if create a brand new project, set rendering device to d3d12, and just add a Node3D as scene root and run.
Repository: godot
Issue: OptionButton throwing errors in exported release build: "Attempt to disconnect a nonexistent connection" for signal `focus_entered` and ` tree_exited`
Labels: bug,platform:linuxbsd,confirmed,regression,topic:gui,topic:export

### Tested versions

 - Reproducible in Godot Engine v4.2.stable.official [46dc27791], v4.2.1.stable.official, v4.2.2.rc2.
 - Does not seem to happen in v4.1.3.stable.official [f06b6836a].

### System information

Windows 11 Home

### Issue description

Interacting with an OptionButton produces an error message:
ERROR: Attempt to disconnect a nonexistent connection from 'root:<Windows#24779948753>'. Signal: 'focus_entered', callable:...
at: (core/object/object.cpp:1420)
ERROR: Attempt to disconnect a nonexistent connection from 'root:<Windows#24779948753>'. Signal: 'tree_exited', callable:...
at: (core/object/object.cpp:1420)

Only when the project is exported to executable, both release and debug, but does not produce an error when run in the editor.

### Steps to reproduce

Starting from an empty project with the root node being a control node, add a child OptionButton and add 2 items to it, labeled Option 1 and Option 2. Then, export the project with the console to an executable. The console executable will display an error when an option is selected in the OptionButton.

### Minimal reproduction project (MRP)

[Test.zip](https://github.com/godotengine/godot/files/14640937/Test.zip)
Repository: rust
Issue: Cannot call method that requires a non-array unsized coercion, contrary to the reference
Labels: A-associated-items,C-bug,T-types

In short: why can't I call `Cell::new([1, 2, 3]).as_slice_of_cells()`?

Minimal example:

```rust
struct Foo<T: ?Sized>(T);
impl<T> Foo<[T]> {
    fn foo_generic_slice(&self) {}
}

Foo([1u8, 2, 3]).foo_generic_slice();
```

**I expected to see this happen**: this should compile. As [documented by the reference](https://doc.rust-lang.org/reference/expressions/method-call-expr.html), these candidates should be considered in the above method call:
- `Foo<[u8; 3]>`
- `&Foo<[u8; 3]>`
- `&mut Foo<[u8; 3]>`
- `Foo<[u8]>` (by unsized coercion)
- `&Foo<[u8]>`
- `&mut Foo<[u8]>`

The `foo_generic_slice` method should be called via the unsized coercion to `Foo<[u8]>`.

**Instead, this happened**: I get a compile error, stating that I must perform the unsized coercion manually:

```
error[E0599]: no method named `foo_generic_slice` found for struct `Foo<[u8; 3]>` in the current scope
  --> src/main.rs:34:9
   |
6  | struct Foo<T: ?Sized>(T);
   | --------------------- method `foo_generic_slice` not found for this struct
...
34 |     foo.foo_generic_slice();
   |         ^^^^^^^^^^^^^^^^^ method not found in `Foo<[u8; 3]>`
   |
   = note: the method was found for
           - `Foo<[T]>`
```

In contrast, if the unsized coercion is from `[T; N]` to `[T]` rather than for a custom DST, the method can be called. This happens every time `.len()` is called on an array. See [this playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=00d5d32f03a6f1748a85df3b1fad2eb6) which tests other broken and working scenarios.

There's also another unsized coercion that seems to be ignored entirely - the coercion from `T` to `dyn Trait` is ignored for inherent methods implemented on `dyn Trait` - it seems that actually looking up all of these candidates as described by the reference could be incredibly costly, especially for the `Foo<T>` to `Foo<dyn Trait>` coercion.

### Meta
Happens in Rust 1.76.0 and 1.79.0-nightly (2024-03-17 eb45c844407968ea54df). Appears to occur in every version of Rust.
Repository: tauri
Issue: [bug] Drag area for resizing is too big
Labels: type: bug,status: needs triage

### Describe the bug

When dragging over the edge of a window, the area for dragging to resize appears to be far bigger than the area of other programs. (Showcased in the videos) Possibly this is a HiDPI issue?

https://github.com/tauri-apps/tauri/assets/40795980/0cf8cf52-1ebf-4b70-9575-69e880bb3a1f
https://github.com/tauri-apps/tauri/assets/40795980/fa4337dc-43f6-4438-a28f-2c9eeed2ea3e

### Reproduction

https://github.com/AlexProgrammerDE/tauri-app <- default template without modifications

### Expected behavior

Have a smaller area for dragging (like other windows), so the elements at the edge (scrollbar) can actually be clicked.

### Full `tauri info` output

```text
[✔] Environment
    - OS: Pop!_OS 22.04 X64
    ✔ webkit2gtk-4.0: 2.42.5
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.76.0 (07dca489a 2024-02-04)
    ✔ cargo: 1.76.0 (c84b36747 2024-01-18)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.11.1
    - pnpm: 8.12.0
    - yarn: 1.22.21
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 1.6.1
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.7
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.11

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

Decorations need to be disabled for this to happen. With decorations enabled everything works fine.
Repository: go
Issue: proposal: runtime/pprof: cross system stack transitions in the heap profiler
Labels: Proposal

### Proposal Details

### Summary

I propose that the heap profiler cross system stack transitions in tracebacks, to be consistent with the other profilers.

The user-visible changes would be:

* For heap allocations on the systemstack we would see the user stack leading to the allocation
* For the same allocations, we would no longer see the runtime frames (since the heap profiler hides them)

### Background

The runtime profilers are inconsistent in how they handle system stack transitions in tracebacks. Given a sequence of calls like this:

```
main.main                  <--+
main.foo                      +-- User portion
runtime.bar                   |
runtime.systemstack_switch <--+

runtime.systemstack        <--+
runtime.bar.func1             +-- System portion
runtime.interestingEvent      |
runtime.recordEvent        <--+
```

The profilers report a traceback like so:

* The CPU profiler shows both the system and user portion of the traceback
* The block and mutex profilers show the user portion of the traceback
  * The recently-added runtime lock profiling shows the system and user portions
* The runtime execution tracer shows the user portion of the traceback
* The heap profiler shows only the system portion of the traceback, when the sampled allocation happens on a system stack

As a rule of thumb, I think we want the entire sequence of calls leading up to the event of interest, possibly excluding implementation details at the end of the sequence. More often than not, the _user_ portion of the traceback is the most informative as a developer.

The heap profiler is the only one which won't show the user portion of the stack consistently. We see this in practice, for example, when starting a new goroutine requires allocating a new `g`. Today we'd see a traceback leading from `runtime.systemstack` to `runtime.malg`, but we wouldn't see the user portion of the call stack leading to the `go` statement. Note that under this proposal we wouldn't see the system stack frames after the `go` statement, because the heap profiler elides runtime frames from the end of tracebacks. ([Source](https://cs.opensource.google/go/go/+/master:src/runtime/pprof/protomem.go;l=36;drc=0a6f05e30f58023bf45f747a79c20751db2bcfe7))

This is in part motivated by trying to use frame pointer unwinding for more of the runtime profilers, see https://go.dev/cl/540476. Naive frame pointer unwinding isn't going to know whether or not it's crossing the systemstack transition. Either of crossing the transition or just capturing the user portion of the call stack would be much more straightforward to match with frame pointer unwinding than only capturing the system portion.

cc @golang/runtime @prattmic
Repository: pytorch
Issue: [CI] Node-20 update
Labels: high priority,module: ci,triaged

### 🐛 Describe the bug

PyTorch Dev Infra needs to update runners to Linux flavor capable of running node-20 as node-16 and 18 are being deprecated by GitHub, see https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/

### Versions

CI

cc @ezyang @gchanan @zou3519 @kadeng @seemethere @pytorch/pytorch-dev-infra
Repository: pytorch
Issue: Some inference-only serialized Inductor SDPA patterns?
Labels: triaged,oncall: pt2,module: inductor

### 🚀 The feature, motivation and pitch

## Background

Currently, some [SDPA patterns in Inductor](https://github.com/pytorch/pytorch/blob/main/torch/_inductor/fx_passes/fuse_attention.py) have inference-only UTs ([`check_train` is `False` for them](https://github.com/pytorch/pytorch/blob/main/test/inductor/test_fused_attention.py#L520)), but they are also being serialized for training.

There are two possibilities:
1. UTs of such patterns are not representative of the corresponding training pattern, OR
2. The above case, and also, these training patterns are not matched even when their representative/reference workload (not UT, but end-to-end model) is run, and only their inference counterpart matches.

## Proposal

In case of possibility 1 (UTs of such patterns not being representative of the corresponding training pattern) discussed above, those UTs should be fixed.

But in case of possibility 2 (the training patterns don't even match when the reference workload they were created for is run), would it be better not to serialize them until the issues that cause mismatch are resolved?

### Benefits
**Performance-impact**: insignificant improvement in compile-time.
**Main benefit**: Code-clarity. Currently, it's not obvious from looking at `torch/_inductor/fx_passes/fuse_attention.py` that some training patterns don't match when their representative workload is run.

Thanks!


### Alternatives

We could simply add comments if such serialized training patterns are to be retained although they don't match when their representative workload is run.

### Additional context

_No response_

cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @amjames @desertfire
Repository: go
Issue: proposal: cmd/vet: warn when the iterator variable on 3-clause for loops where is written to in a go statement after 1.22
Labels: Proposal

### Proposal Details

The proposal is to extend the `loopclosure` checker to additionally warn with a variables in a 3-clause for loop is written to after Go 1.22. A part of the new semantics is to copy the iterator variable at the end of the for loop. This is a READ that can race with writes from other goroutines.

Example:
```
for i := 0; i < N; i ++ {
  go func() {
    i *= 10  // warn "loop variable i written by func literal"
    println(i)
  }()
}
```

Criteria to use:
1) There is a 3-clause for loop declaring a variable `v`.
2) It is in a file with GoVersion >= 1.22.
3) The 'last' instruction in the loop body is a `go` statement.
4) The function executed is a function literal.
5) The function literal contains an assignment (or IncDecStmt).
6) The assignment updates the loop variable according to the following recursive definition in some left hand side:
  * `Updates(id)` holds when `id` refers to the variable,
  * `Updates(e.X)` holds when `Updates(e)`,
  * `Updates(e[g])` holds when `Updates(e)`,
  * `Updates(*e)` holds when `Updates(e)`,
  * and otherwise `Updates(e)`  does not hold.

Additionally:  
* See loopclosure `forEachLastStmt` for the operational definition of 'last'.
* In addition to `go` statements this would be reported for `errgroup.Go` and `t.Run()` when `t.Parrallel` is present. It will not be reported for `defer` statements.

To discuss: The requirements give at the moment dereference pointers. This is not sufficient to ensure a race has occurred. Just that a race is overwhelmingly likely. This seems to be in the spirit of the existing loopclosure check. Curious whether others agree or think we should not report if there is indirection.
Repository: next.js
Issue: [Next 14] not-found.js page fetches API on every page load
Labels: bug,Pages Router

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/blissful-greider-qpqnc3?file=%2Fapp%2Fnot-found.tsx

### To Reproduce

1. Create a basic not-found.ts page, and add a console log in the server render
2. create any other page.
3. make a build, and start the server, and visit the other page. 
4. Notice that the log in not-found fires. 

```
export default async function NotFoundPage() {
    console.log("FETCHING NOT FOUND PAGE");
    const date = await (await fetch("http://worldtimeapi.org/api/timezone/America/New_York")).json()

    return (
        <>
            {new Date(date.datetime).getTime()}
        </>
    );
}

export const dynamic = "force-static";
export const revalidate = false;
```

### Current vs. Expected behavior

Current: not-found makes API calls on every page load
https://www.capster.io/video/ZO6pbiLQATta

Expected: not-found only makes API calls when `notFound()` is invoked. 



### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 23.0.0: Fri Sep 15 14:43:05 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6020
    Binaries:
      Node: 20.6.1
      npm: 9.8.1
      Yarn: 1.22.5
      pnpm: N/A
    Relevant packages:
      next: 13.4.7
      eslint-config-next: N/A
      react: N/A
      react-dom: N/A
      typescript: 4.9.5
```


### Which area(s) are affected? (Select all that apply)

App Router, Data fetching (gS(S)P, getInitialProps)

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed)

### Additional context

_No response_
Repository: flutter
Issue: Make upgrading Simulator version (when upgrading Xcode) easier
Labels: platform-ios,engine,P2,team-ios,triaged-ios

When we upgrade Xcode version, we also manually upgrade the Simulator version to the latest. This requires manually changing a hard coded value in various places in flutter/packages and flutter/engine. In addition, in flutter/engine, we have to generate and replace iOS Scenarios golden files.

These processes could be improved by doing the following:
- [ ] Update test steps so we use the current Xcode's preferred simulator runtime rather than a hardcoded value
- [ ] Create a script/tool to automate updating of iOS engine golden files and Scenarios project.pbxproj file (perhaps could be part of https://github.com/flutter/engine/tree/main/tools/engine_tool?)

## flutter/packages
Places we use a hardcoded Simulator version:
* https://github.com/flutter/packages/blob/60a1ffc2f77fade3e375a98177729b2f3e90e06e/.ci/scripts/create_simulator.sh#L12
* https://github.com/flutter/packages/blob/60a1ffc2f77fade3e375a98177729b2f3e90e06e/.ci/targets/ios_platform_tests.yaml#L25
* https://github.com/flutter/packages/blob/60a1ffc2f77fade3e375a98177729b2f3e90e06e/packages/pigeon/tool/shared/test_suites.dart#L299-L300

## flutter/engine
Places we use a hardcoded Simulator version:
* https://github.com/flutter/engine/blob/ea848c3b2443d822dcdb7830b35c215559ec047a/testing/scenario_app/run_ios_tests.sh#L63-L64

Example of upgrading iOS Scenarios golden files
* https://github.com/flutter/engine/pull/49833

## flutter/flutter
We already do this for flutter/flutter: https://github.com/flutter/flutter/blob/56cc7923ceb86286368914c3847b20e6debe47d4/dev/devicelab/lib/framework/ios.dart#L69-L125
Repository: stable-diffusion-webui
Issue: cant launch ui [Bug]: 
Labels: bug-report

### Checklist

- [ ] 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
- [ ] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

./webui.sh: line 246: bc: command not found
./webui.sh: line 246: [: -eq: unary operator expected


### Steps to reproduce the problem

launch ./webui.sh

### What should have happened?

launched ui

### What browsers do you use to access the UI ?

Mozilla Firefox

### Sysinfo

12gb gpu nvidea 4 gb gpu amd

### Console logs

```Shell
Repo already cloned, using it as install directory
################################################################

################################################################
Create and activate python venv
################################################################

################################################################
Launching launch.py...
################################################################
glibc version is 2.39
Check TCMalloc: libtcmalloc_minimal.so.4
./webui.sh: line 246: bc: command not found
./webui.sh: line 246: [: -eq: unary operator expected
libtcmalloc_minimal.so.4 is linked with libc.so,execute LD_PRELOAD=/usr/lib/libtcmalloc_minimal.so.4
Python 3.11.8 (main, Feb 12 2024, 14:50:05) [GCC 13.2.1 20230801]
Version: v1.8.0
Commit hash: bef51aed032c0aaa5cfd80445bc4cf0d85b408b5
```


### Additional information

_No response_