sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: host rewrites client side navigation works all fine in dev mode, but stop working after deploy to Vercel (All works fine before this week)
Labels: bug

### 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 22.6.0: Wed Jul  5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.15.0
      npm: 9.5.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: N/A
    Next.js Config:
      output: N/A
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

App Router

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/TrustyTechSG/nextjs-rewrite-issue

Link to replay the issue: https://nextjs-rewrite-issue.vercel.app/

### To Reproduce

Clone the repo, which have a simple app folder structure of 
```
/app/[host]/[lang]
/app/[host]/[lang]/subpage
```
+ rewrites settings as below

```
  async rewrites() {
    return {
      afterFiles: [
        {
          has: [
            {
              type: "host",
              value: "(?<host>.*)",
            },
          ],
          source: "/:path*",
          destination: "/:host/:path*",
        }
      ],
    };
  }
```

Run in dev mode, you will see locahost and lang been display correctly on home page.
![image](https://github.com/vercel/next.js/assets/36871034/1b9201a8-c2b8-489c-9fa7-b9876b3dcb8e)

Then click the subpage link, you will see SUBPAGE, and the host and lang keep display correctly.
![image](https://github.com/vercel/next.js/assets/36871034/5273eaf2-e8e5-4536-8dfd-2c4970d8552e)

Now deploy the repo to Vercel. First time visit will still see the host and lang display correctly.
![image](https://github.com/vercel/next.js/assets/36871034/f1b614c7-a968-4daf-8c3d-70af1bfc7097)

But when you click on the subpage link. you will see the host wrongly show as "en", which prove the host rewrites stopped working.
![image](https://github.com/vercel/next.js/assets/36871034/78ca4910-43c5-4967-8b2b-25ba39c60d1f)

But if you continue make a full page refresh, then it will display correctly. feels this issue is only happen in client side navigation.
![image](https://github.com/vercel/next.js/assets/36871034/cf1849ac-82cd-4e79-918e-3964db352325)

We are using host rewrite with i18n for very long time now, all works fine before, just stop working now.





### Describe the Bug

Host wrongly show as "en", prove host rewrites stopped working.

### Expected Behavior

Host and lang should always shows correctly. 

### Which browser are you using? (if relevant)

Chrome

### How are you deploying your application? (if relevant)

Vercel
Repository: next.js
Issue: Cache returns last cached value when the request hits the server to fetch updated data
Labels: bug,Runtime,Pages Router

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: linux
      Arch: x64
      Version: #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2
    Binaries:
      Node: 16.18.1
      npm: 8.19.2
      Yarn: N/A
      pnpm: N/A
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: 13.4.4
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: N/A
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

App Router, Data fetching (gS(S)P, getInitialProps), Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/wizardly-feistel-mgqpw9?file=/app/page.tsx:8,11

### To Reproduce

Create a simple server:

`const express = require("express");
const app = express();
const port = 3001;

app.get("/hello", (req, res) => {
    console.log(`got requested at ${new Date().toISOString()}`)
  res.json({ time: new Date().toISOString() });
});

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});
`

add a simple route to fetch data from the server you created(ex: app/api/test/route.ts):

`import { NextRequest, NextResponse } from 'next/server';

export async function GET(req: NextRequest) {
  const response = await fetch('http://localhost:3001/hello', {
    next: { revalidate: 10 },
  });
  const json = await response.json();
  return NextResponse.json(json);
}
`

### Describe the Bug

When the revalidate time expires, calling the next.js test api will do a request to the server but the response it's the last cached outdated value, doing a new request on the revalidate time interval will return the correct value.

This means, if I have a client that closes my page and opens the page on the next day, the server response will be outdated with the previous day, unless he refreshes the browser.

The behaviour is if the cache is invalid (the revalidate time expired), next will correctly do the request to the server but the response on the first request made with invalid cache will always return the last cached value instead of the fresher one.

Once the cache is invalid and a request is made that returns the old cached value, any subsequent requests inside the revalidate interval will return the correct cached value.

[
![image](https://github.com/vercel/next.js/assets/44141438/510b2c76-c432-4052-838f-25e5564b1411)
](url)

### Expected Behavior

Once the cache is invalid (revalidate time expires) the next request made should return the newly requested data instead of the old cached one that will be corrected with subsequent requests.

### Which browser are you using? (if relevant)

Version 116.0.5845.110 (Official Build) (64-bit)

### How are you deploying your application? (if relevant)

AWS
Repository: electron
Issue: [Feature Request]: Ship an Electron runtime for Flatpak
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Several Electron apps are shipped as flatpaks.  This is the only reasonable way to install them on many distributions, but it it also causes duplicated effort and disk space.

### Proposed Solution

Provide a flatpak runtime that is shared by all apps using a given version of Electron.

### Alternatives Considered

None.

### Additional Information

Flatpak runtimes save disk space and memory by sharing code and data used by multiple flatpaks.
Repository: vscode
Issue: Settings UI doesn't respect custom `title` for extension configuration option
Labels: feature-request,settings-editor

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.81.1
- OS Version: Linux x64 6.1.44-1-MANJARO

Steps to Reproduce:

1. create a vscode extension project
2. add some options to `package.json#contributes.configuration.properties` with custom `title`
3. start extension debug
4. open extension settings
5. observe that added option have the title that generated from it's key, not a string from `title` property

Repo to reproduce:

https://github.com/b-fett/vscode-extension-fails-to-set-configuration-option-title

Expected result:

![image](https://github.com/microsoft/vscode/assets/33630339/0cb98391-47bd-4e5b-8a70-779a04ad999f)


Actual result:

![image](https://github.com/microsoft/vscode/assets/33630339/0a13dad4-b695-46bc-9612-acb3309bcf31)
Repository: pytorch
Issue: Pytorch versions without the abi3 flag
Labels: module: binaries,triaged,module: python frontend

### 🚀 The feature, motivation and pitch

In some projects I work on, I see not deterministic behavior when I try to import Pytorch with other libraries(for example-tensorrt).
The most famous issue is the imports order, which causes to different behaviors.
I can't share the code with you because of my company policy. But when I tried to figure out what is the problem, I came to conclusion that it might be the abi3 flag which you use(and the other libraries not).

Is there a reason why you don't publish wheel files without this flag?

Can you publish versions without the abi3 flag?
Or explain how I can do that by myself?

Thanks!

### Alternatives

_No response_

### Additional context

_No response_

cc @seemethere @malfet @albanD
Repository: pytorch
Issue: Integrate cutlass headers and scripts in pytorch package
Labels: oncall: releng,triaged,enhancement,topic: binaries,oncall: pt2

### 🐛 Describe the bug

Feature request : https://github.com/pytorch/pytorch/issues/106991
PR: https://github.com/pytorch/pytorch/pull/108015

Require cutlass integration:
Pytorch release: to properly release cutlass together with Pytorch, we need to find a way to pack cutlass into Pytorch package distribution. This includes both C++ header files (third_party/cutlass/include) as well as Python scripts and modules (third_party/cutlass/tools/library/scripts).

OS support - Linux only. Support CUDA 11.8, 12.1.

OSS use case: It's mainly for performance reason. Cutlass is the most efficient open source library on H100 for now (Triton is catching up). The template interface it provides make it easier to do epilogue fusions.
If it's necessary, we could also do some model level benchmark testing, though it would require quite some implementation work.

We could work with NVIDIA to package this into a cutlass python dependency. It also looks like there's some additional Python requirements for these scripts. One option is also always copy-pasting these files into our tree into a subfolder with the correct LICENSE header etc.

Questions:
 - Can we build this as special pypi or conda package so that we don't need to integrate cutlass in each of our binaries ? But depend dynamically on it.  See https://github.com/pytorch/builder/blob/main/conda/pytorch-cuda/meta.yaml for example of integration
 - Need to confirm if we need whole of cutlass/tools/library/, rather then only third_party/cutlass/tools/library/scripts @ipiszy could you please confirm this with a test ?
 - Since this code is property of Nivida do we have a rights to distribute it in this form ? cc @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang @wconstab @ptrblck 

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @seemethere @malfet @pytorch/pytorch-dev-infra @jansel @ipiszy @albanD @cpuhrsch

### Versions

2.2.0
Repository: next.js
Issue: Router Interception scrolling on close
Labels: bug

### 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 22.5.0: Mon Apr 24 20:52:24 PDT 2023; root:xnu-8796.121.2~5/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.12.1
      npm: 9.6.4
      Yarn: 1.22.19
      pnpm: 8.6.10
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: N/A
    Next.js Config:
      output: N/A
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

App Router

### Link to the code that reproduces this issue or a replay of the bug

Attached video

### To Reproduce

Click link which is captured by route interceptor. 
Scroll.
Close it using 
```ts
const router = useRouter()
  const onDismiss = useCallback(() => {
    router.back()
  }, [router])
```

### Describe the Bug

According to the docs, the current way of "closing" a route interception is the following:
```ts
const router = useRouter()
  const onDismiss = useCallback(() => {
    router.back()
  }, [router])
```
But this can give some issues, with the user being returned to a previous scroll position, exemplified in the video I have attached

https://github.com/vercel/next.js/assets/22572423/c8271d47-d3f1-4c52-a63e-490e54b446a8


I examined how the router.back() function worked, to see if it would be possible to implement a boolean scroll parameter, but since it's built on top of https://developer.mozilla.org/en-US/docs/Web/API/History/back, it seems like that's a nogo.

So I am just curious if there's anything that could be done to make this scrolling optional.



### Expected Behavior

Should not scroll to where the user was when they opened the route

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_
Repository: rust
Issue: Unable to use match with a borrowed value which will be mutated and returned within the match statement
Labels: A-borrow-checker,T-compiler,C-bug,fixed-by-polonius

When trying to mutate a value within a match statement which is borrowed by the statement and returned as the result of the function, the compiler fails with the error `E0506`.

I tried this code:

```rust
struct LazyItem {
    item: Option<String>
}

impl LazyItem {
    fn get_item(&mut self) -> &str {
        match &self.item {
            None => {
                self.item = Some("Greetings".to_string());
                let Some(content) = &self.item else { unreachable!() };
                content
            },
            Some(content) => content,
        }
    }
}

fn main() {
    let mut instance = LazyItem { item: None };
    assert_eq!(instance.get_item(), "Greetings");
}
```

I expected to see this happen: That the code compiles and runs successfully.

Instead, this happened: The compilation failed with the following error:

```
error[E0506]: cannot assign to `self.item` because it is borrowed
  --> src/main.rs:9:17
   |
6  |       fn get_item(&mut self) -> &str {
   |                   - let's call the lifetime of this reference `'1`
7  |           match &self.item {
   |           -     ---------- `self.item` is borrowed here
   |  _________|
   | |
8  | |             None => {
9  | |                 self.item = Some("Greetings".to_string());
   | |                 ^^^^^^^^^ `self.item` is assigned to here but it was already borrowed
10 | |                 let Some(content) = &self.item else { unreachable!() };
...  |
13 | |             Some(content) => content,
14 | |         }
   | |_________- returning this value requires that `self.item` is borrowed for `'1`

For more information about this error, try `rustc --explain E0506`.
```

Using `if` syntax the code compiles and runs successfully.
<details><summary>Code</summary>
<p>

```rust
struct LazyItem {
    item: Option<String>
}

impl LazyItem {
    fn get_item(&mut self) -> &str {
        if let None = &self.item {
            self.item = Some("Greetings".to_string());
            let Some(content) = &self.item else { unreachable!() };
            content
        } else if let Some(content) = &self.item {
            content
        } else {
            unreachable!()
        }
    }
}

fn main() {
    let mut instance = LazyItem { item: None };
    assert_eq!(instance.get_item(), "Greetings");
}
```

</p>
</details>

### Meta
`rustc --version --verbose`:
```
rustc 1.72.0 (5680fa18f 2023-08-23)
binary: rustc
commit-hash: 5680fa18feaa87f3ff04063800aec256c3d4b4be
commit-date: 2023-08-23
host: x86_64-unknown-linux-gnu
release: 1.72.0
LLVM version: 16.0.5
```

Nigthly version with the same result:
```
rustc 1.74.0-nightly (4e78abb43 2023-08-28)
binary: rustc
commit-hash: 4e78abb437a0478d1f42115198ee45888e5330fd
commit-date: 2023-08-28
host: x86_64-unknown-linux-gnu
release: 1.74.0-nightly
LLVM version: 17.0.0
```
Repository: tauri
Issue: [feat] Ability to get build timestamp in app_handler
Labels: type: feature request

### Describe the problem

Currently when opening the app in macOS, the macOS default about dialog will show a build timestamp, in format of `20220724.xxxxxx`, which is the exact moment when the release build is built.

<img width="421" alt="Screenshot 2023-08-30 at 10 00 29 AM" src="https://github.com/tauri-apps/tauri/assets/40067411/2e1e34f3-22db-4d8d-9883-6860c7a968e3">

In order to make the Linux/Windows about dialog align with the default macOS one, I need to get the timestamp from code. I tried app_handle.Config(), but seems that only configurations in `tauri.conf.json` were shown and I cannot find the build timestamp.

### Describe the solution you'd like

Ability to get the build timestamp from code.

### Alternatives considered

_No response_

### Additional context

_No response_
Repository: angular
Issue: Language Service MISSING_CONTROL_FLOW_DIRECTIVE false positive with multiple components in a single file
Labels: area: language-service,compiler: extended diagnostics

### Which @angular/* package(s) are the source of the bug?

language-service

### Is this a regression?

No

### Description

When a component is preceded in the same file by another component, the Angular Language service will report the MISSING_CONTROL_FLOW_DIRECTIVE warning twice, and will continue to report it even after it has been fixed. This issue does not occur on the initial load, and it does not occur if the component with the warning is the first or only component in the file.

The gif below demonstrates the language service working normally without the extra component in the file and working abnormally with the extra component in the file.

![language-service-bug](https://github.com/angular/angular/assets/12160067/0d6244f4-8a08-47d4-a831-420094208e4c)

### Please provide a link to a minimal reproduction of the bug

https://github.com/garrettld/angular-language-service-bug

### Please provide the exception or error you saw

Reproduction steps:
1. Create a file with two components in it, where the second component is standalone and uses the NgIf directive and imports it directly or via the CommonModule.
2. Remove the NgIf or CommonModule import from the component, and see the warning that says "The `*ngIf` directive was used in the template, but neither the `NgIf` directive nor the `CommonModule` was imported...."
3. Restore the NgIf or CommonModule import.

Expected result:
The warning should disappear.

Actual result:
The warning remains and is reported twice.


### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 16.2.0
Node: 18.16.0
Package Manager: npm 9.5.1
OS: win32 x64

Angular: 16.2.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router     

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1602.0
@angular-devkit/build-angular   16.2.0
@angular-devkit/core            16.2.0
@angular-devkit/schematics      16.2.0
@angular/cli                    16.2.0
@schematics/angular             16.2.0
rxjs                            7.8.1
typescript                      5.1.6
zone.js                         0.13.1
```


### Anything else?

_No response_
Repository: go
Issue: runtime/coverage: Eliminate dominator Coverage Units 
Labels: NeedsInvestigation

<!--
Our proposal process is documented here:
https://go.dev/s/proposal-process
-->

The current building for coverage implementation works by rewriting the source files adding some instrumentation statements that later are used to determine the code lines that were executed during runtime, in the following code snippets we can see an example of this workflow.

```go
package main

import "fmt"

func main() {
	a := 10
	if a >= 10 {
		a -= 10
	}
	fmt.Println(a)
}
```

```go
package main

import "fmt"

func main() {x_0[0] = 3 ; x_0[1] = x_P ; x_0[2] = 0; x_0[3] = 1; // Counters and metadata
	a := 10
	if a >= 10 {x_0[5]=1;
		a -= 10
	}
	x_0[4]=1;fmt.Println(a)
}
```

There are 3 coverable units in the example above, but only two of them are needed to cover the whole main function in our sample program. By knowing the state of `x_0[4]` and `x_0[5]` one can infer the state of `x_0[3]`:
- If `x_0[4]` has a value of 1, then x_0[3] must also have it, because it’s impossible to get to the block of code that x_0[4] covers without passing first through the code lines that `x_0[3]` covers.
- The same logic applies to `x_0[5]`. 

Following this assumption, one can see that some of the cover statements can be inferred from the value of others. One can know if a unit is inferable by generating the dominator tree out of the flow graph of the function (there’s going to be a one to one relationship between the coverable units and the nodes of the graph), if its corresponding node isn’t a leaf then the unit is inferable. In the figure below there’s the corresponding flow graph (first image) for the sample code and its dominator tree (second image).

![Flow graph](https://github.com/golang/go/assets/43709368/5dbb8554-02d6-4cab-ad62-2da16573ddd9)

![Dominator Tree](https://github.com/golang/go/assets/43709368/4f3fdf7f-e49c-446a-a99b-ff9259edb430)

## Limitations
With this proposal a new issue arise when we have a noninstrumented package which calls `os.Exit()` as we’re erasing some of the cover statements based in the flow of execution of the instrumented function, there might be cases when the information dumped is incomplete and there’s no way to recover it. In the following code snippets there’s an example of this behavior, after building the main package erasing inferable units and executing the program, we’ll get as result that any unit was hit, when that’s not the case.

```go
package noninstrumented

import “os”

func DoSomething(x int) bool{
    if x == 10 {
        os.Exit(0)
    }
    return true
}
```

```
package main

import “noninstrumented”

func main() { x_0[0] = 3 ; x_0[1] = x_P ; x_0[2] = 0;
    a := 0
    if noninstrumented.DoSomething(10) { x_0[5] = 1;
         a += 20
    }
    x_0[4] = 1;a++
}
```
## Motivation
One of the purposes of this proposal is to reduce the overhead of runtime instrumentation to detect dead code across codebases by running instrumented binaries during a certain amount of time and then gathering a report of the executed code lines.
Repository: vscode
Issue: Better distinguish overlapping arrows
Labels: feature-request,ux,diff-editor,question-discussion

Here in this case at first I was thinking there is an arrow going from one to the other side on the same editor:



![Image](https://github.com/microsoft/vscode/assets/900690/c40a4edb-8c31-485a-8288-9a704e24237a)