sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: Cannot mount the same PVC multiple times on one Pod
Labels: kind/bug,sig/storage,triage/accepted

### What happened?

When I mount the same PVC multiple times on one Pod, the Pod is stuck in `containerCreating` state.

Same issue described here: https://stackoverflow.com/questions/65931457/why-cant-i-mount-the-same-pvc-twice-with-different-subpaths-to-single-pod

### What did you expect to happen?

The mount of volumes should succeed, and the Pod should be created successfully.

Or, if Kubernetes treats this as a mis-configuration, a clear error message should be returned.

### How can we reproduce it (as minimally and precisely as possible)?

I am testing on a GKE cluster. The same PVC is used by one Pod twice.

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-claim
spec:
  accessModes:
    - ReadWriteOnce  
  resources:
    requests:
      storage: 1Gi  
  storageClassName: standard  
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx  
    volumeMounts:
    - name: my-pvc
      mountPath: /data/path1
    - name: my-pvc-2
      mountPath: /data/path2
  volumes:
  - name: my-pvc
    persistentVolumeClaim:
      claimName: my-claim  
  - name: my-pvc-2
    persistentVolumeClaim:
      claimName: my-claim  
```

### Anything else we need to know?

We have another similar issue documented: https://github.com/GoogleCloudPlatform/gcs-fuse-csi-driver/issues/48

According to the kubelet code: https://github.com/kubernetes/kubernetes/blob/8f15859afc9cfaeb05d4915ffa204d84da512094/pkg/kubelet/volumemanager/cache/desired_state_of_world.go#L296-L298

> For non-attachable and non-device-mountable volumes, generate a unique name based on the pod namespace and name and the name of the volume within the pod.

Since the user has two same PVCs specified on the Pod spec, the tow PVCs must bound to the same PV, meaning the `volumeHandle` is the same for the two volumes. Therefore, different volumes will be treated as the same volume. After kubelet mounts one of the volumes, the other volume will be treated as already mounted. As a result, the Pod will be stuck in volume mount stage.

### Kubernetes version

<details>

```console
$ kubectl version
Client Version: v1.29.7
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.6-gke.1326000
```

Note that this issue is not limited to any specific k8s verisons.

</details>


### Cloud provider

<details>
None
</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: neovim
Issue: treesitter: undoing confirmed substitution does not trigger reparse
Labels: bug,highlight,treesitter

### Problem

Given the following lua file:
```lua
local foo = {
  attribute1 = false,
  attribute2 = false,
}
```
If you do `%s/attribute/attr/gc`, confirm both changes and then press `u`ndo, the tree sitter parsing gets out of sync.

![Screenshot 2024-08-29 at 10 21 44 AM](https://github.com/user-attachments/assets/6a443860-484d-4790-8eb4-477dcc71a57e)

cc @gpanders and @clason

### Steps to reproduce

1. `nvim --clean`
2. `:hi @boolean guifg=red`

3. Paste in these file contents:
```lua
local foo = {
  attribute1 = false,
  attribute2 = false,
}
```

4. `:%s/attribute/attr/gc`
5. `y` `y`
6. `u`

### Expected behavior

`false` should be formatted in red and `attribute2` formatted in grey.

### Neovim version (nvim -v)

0.10.1

### Vim (not Nvim) behaves the same?

n/a

### Operating system/version

macos 14.6

### Terminal name/version

ghostty fcb8b040

### $TERM environment variable

xterm-ghostty

### Installation

homebrew
Repository: vscode
Issue: Notebook scrolls to reveal partially hidden cell when uncommenting cells
Labels: bug,notebook-layout,notebook-cell-editor

1. Select several cells in a row
2. Comment them with Ctrl+/
3. Scroll down so that the first cell is partially outside viewport
4. Uncomment them with Ctrl+/
5. :bug: notebook scrolls to top
Repository: terminal
Issue: Incorrect french translation
Labels: Issue-Bug,Product-Terminal,Area-Localization

### Windows Terminal version

 1.20.11781.0

### Windows build number

10.0.19045.4780

### Other Software

_No response_

### Steps to reproduce

Right-click when creating a new tab on a terminal on a Windows in French version

### Expected Behavior

The displayed text is correct french: `En tant qu'administrateur`

### Actual Behavior

The displayed text contains the incorrect "En temps qu'administrateur"


https://github.com/microsoft/terminal/blob/93d592bb4156e85f66f34a57ee7f707cc7ba0f15/src/cascadia/TerminalApp/Resources/fr-FR/Resources.resw#L858

It should be instead:
```
 <value>Exécuter en tant qu'administrateur (restreint)</value> 
```
Repository: vscode
Issue: Support for experimental settings
Labels: feature-request,config,settings-editor

We currently have a very unstructured approach to settings related to experimental features. A few examples:

- `editor.experimental.treeSitterTelemetry`
- `editor.experimentalWhitespaceRendering`
- `accessibility.signalOptions.experimental.delays.warningAtPosition`
- `C_Cpp.experimentalFeatures`
- `timeline.pageOnScroll`, its description starts with `Experimental.`

This is problematic in a few key ways:

- There's no deterministic way to discover all experimental settings
- There's no clear way of knowing whether a specific setting is experimental
- There's no easy way to mark a setting as non-experimental; one must migrate

We should:

1. Support 1st party labeling of settings to be experimental
2. Surface this labeling in the settings UI
3. Support an easy `@experimental` query in the settings UI

Optionally:

1. Migrate all existing experimental settings to the new infrastructure
2. Add eslint rules preventing from using `*experiment*` in the setting name
Repository: rust
Issue: Invalid suggestion when using `serde` `serialize_with`
Labels: A-diagnostics,T-compiler

### Code

```Rust
use serde::{Serialize, Serializer};

fn f<T, S: Serializer>(_: &(), _: S) -> Result<<S as Serializer>::Ok, <S as Serializer>::Error> {
    todo!()
}

#[derive(Serialize)]
pub struct Matrix {
    #[serde(serialize_with = "f")]
    matrix: (),
}
```


### Current output

```Shell
error[E0282]: type annotations needed
 --> src/lib.rs:9:30
  |
9 |     #[serde(serialize_with = "f")]
  |                              ^^^ cannot infer type of the type parameter `T` declared on the function `f`
  |
help: consider specifying the generic arguments
  |
9 |     #[serde(serialize_with = "f"::<_, __S>)]
  |                                 ++++++++++
```


### Desired output

```Shell
error[E0282]: type annotations needed
 --> src/lib.rs:9:30
  |
9 |     #[serde(serialize_with = "f")]
  |                              ^^^ cannot infer type of the type parameter `T` declared on the function `f`
```


### Rationale and extra context

Inspired by #120922. The given suggestion is invalid syntax.

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.82.0 playground
```


### Anything else?

_No response_
Repository: electron
Issue: [Bug]: Enabling logging on Windows writes log files to numbered files in the current directory
Labels: platform/windows,bug :beetle:,has-repro-gist,30-x-y

### 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 bug report that matches the one I want to file, without success.

### Electron Version

30.4.0

### What operating system(s) are you using?

Windows

### Operating System Version

Windows 11 Home version 24H2

### What arch are you using?

x64

### Last Known Working Electron version

29.0.0

### Expected Behavior

Enabling logging should only write to the specified log file. In our Electron-based app we set `--enable-logging=file` and `--log-file=<resolved_file_path>` from the main process (as in the attached Fiddle). For versions of Electron prior to v30 this only wrote to the log file which was specified.

### Actual Behavior

Starting with Electron v30 we noticed that using the same configuration as above resulted in log files being written to the current directory from which Electron was run. For example, if we run Electron from `C:\Users\username\repo` then we would get numbered files in that directory with names like `1234`, `1111`, etc. Omitting the `--log-file` option also reproduces the issue. When the app is run from a desktop shortcut the files will be written to the desktop.

### Testcase Gist URL

https://gist.github.com/derekcicerone/69a9eae69fd731c786ec157389bcf5f6

### Additional Information

We were able to track this issue back to https://github.com/chromium/chromium/commit/9d2b795f72832aa7216d7c84bdbf5d2358346548. Reverting that commit fixes the issue for Electron v30 but in v31+ there are merge conflicts.

When running the Electron Fiddle the extra log files will be written to the Fiddle temp directory. In this example the file name was `2756`:
![image](https://github.com/user-attachments/assets/e96cf965-a97f-4e98-85bb-deaa64d1a75a)
Repository: godot
Issue: Screen not clearing in transparent background
Labels: bug,topic:rendering,confirmed

### Tested versions

v4.3.beta3.official [82cedc83c]

### System information

Godot v4.3.beta3 - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce RTX 2060 SUPER (NVIDIA; 31.0.15.5176) - Intel(R) Core(TM) i5-10400 CPU @ 2.90GHz (12 Threads)

### Issue description

In transparent background,  screen doesn't clearing
![image](https://github.com/user-attachments/assets/58c99d4f-e79e-4fe2-9c3b-431b77d934a2)


### Steps to reproduce

gl_compatibility 
WorldEnvironment:background_mode: canvas, glow_enabled = true
rendering/viewport/transparent_background = true
rendering/viewport/hdr_2d = true

### Minimal reproduction project (MRP)

[background_test.zip](https://github.com/user-attachments/files/16804856/background_test.zip)
Repository: go
Issue: cmd/compile: type parameter involving constraint with channels seems like it should be inferrable
Labels: TypeInference,compiler/runtime

### Go version

go1.23 and go tip

### Output of `go env` in your module/workspace:

```shell
n/a, using go.dev/play
```


### What did you do?

https://go.dev/play/p/-psvliJDE_j

```go
package main

import "fmt"

// Constraint to allow function to operate on a channel,
// regardless of the channel's directionality.
type channelConstraint[T any] interface {
	chan T | <-chan T | chan<- T
}

func main() {
	var sendOnlyCh chan<- string = make(chan string)
	printCap(sendOnlyCh)
	// Needs to be:
	printCap[string](sendOnlyCh)

	var receiveOnlyCh <-chan int = make(chan int, 1)
	printCap(receiveOnlyCh)
	// Needs to be:
	printCap[int](receiveOnlyCh)

	bidiCh := make(chan any)
	printCap(bidiCh)
	// Needs to be:
	printCap[any](bidiCh)
}

// printCap prints the capacity of ch,
// regardless of ch's directionality.
func printCap[T any, C channelConstraint[T]](ch C) {
	fmt.Println(cap(ch))
}
```

I want to write a small utility that takes a specific action that is determined by a channel's length and/or capacity. In this codebase, there are a general mix of directional and bidirectional channels. I thought I would be able to write a constraint such that my helper can accept a channel of any directionality. And I can indeed write that constraint, but when I call a function with that constraint, I have to provide the channel's element type as a type parameter in order to get the program to compile.

I am surprised that I have to provide the channel's element type, but maybe I am missing something about constraints or generics.

### What did you see happen?

> `./prog.go:13:10: in call to printCap, cannot infer T (prog.go:28:15)`

### What did you expect to see?

I expected that `printCap(ch)` would compile; that I would not have to write `printCap[int](ch)`.

I tried searching the issues for variations of "constraints", "channels", and "direction" or "directionality" but I was not able to find any issues that looked similar.
Repository: godot
Issue: [Dotnet]Exporting a project in c# after switching aot can be problematic
Labels: enhancement,topic:dotnet,topic:export

### Tested versions

v4.4.dev1.mono.official [28a72fa43]

### System information

Godot v4.4.dev1.mono - Arch Linux #1 ZEN SMP PREEMPT_DYNAMIC Tue, 20 Aug 2024 15:33:58 +0000 - Wayland - GLES3 (Compatibility) - Mesa Intel(R) UHD Graphics 630 (CFL GT2) - Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz (8 Threads)

### Issue description

If aot is not enabled for the first export of c# project, and is enabled for the second export, their c# data will be mixed with each other. under linux this will result in the runtime of the second exported game actually using the c# assembly from the first export, not the aot binary from the second export. (windows seems to have a worse problem with this)

### Steps to reproduce

1. Export the project and run it, the screen should display `Hello CSharp!`.
2. Modify `PublishAot` in `TestAot.csproj` to `true`.
3. Use the same export path as the first time, re-export and run. Ideally it should display `Hello CSharp Aot!`. Under Linux, it will actually display `Hello CSharp!`. I have not tested it under Windows.
(When the export option of `embed_build_outputs` is enabled, this problem will still occur even if the two export paths are inconsistent)

### Minimal reproduction project (MRP)

[test-aot.zip](https://github.com/user-attachments/files/16805517/test-aot.zip)
Repository: TypeScript
Issue: Find all references in TS is off by 1 line in this specific case
Labels: Bug,Help Wanted

Appologies for the slow reaction in https://github.com/microsoft/TypeScript/issues/57888. Creating a new issue because I can't reopen the existing issue.

I can still reproduce this in latest vscode Insiders (tried 2 times and reproduced 2 times).

Steps:
* clone the vscode repository
* `git checkout c2d75edf8a7`
* open `src/vs/editor/common/viewModel/viewModelImpl.ts`
* reload window
* while the window is loading do in the terminal `git checkout 3f0f51bde08 `
* find all references on `ViewModel` (line 45)
* observe that the references in `codeEditorWidget.ts` are off by one line


https://github.com/user-attachments/assets/6b247ff2-1a28-4cd4-8f85-35cffef861b1


```
Version: 1.93.0-insider
Commit: ae45c9d4b0f71d53151edc6d18be09107903c229
Date: 2024-08-29T05:04:03.909Z
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.6.0
```


![Image](https://github.com/user-attachments/assets/aec3e657-70df-49ed-a403-839d5811b696)
Repository: vscode
Issue: Flaky `Ternary Search Tree` test
Labels: bug,unit-test-failure

https://dev.azure.com/vscode/VSCode/_build/results?buildId=130125&view=logs&j=f3dd96f0-7bf9-51c6-1e87-22c4cfa2ad69&t=cf063406-446c-522c-4fbd-8e958d7b189e

```
  8800 passing (3m)
  74 pending
  1 failing

  1) Ternary Search Tree
       TernarySearchTree: Cannot read property '1' of undefined #138284 (random):
     
  RangeError: Invalid array length
      at Array.push (<anonymous>)
      at TernarySearchTree._delete (http://localhost:33887/079953d7545e7ca308c82fce64738984/out/vs/base/common/ternarySearchTree.js:427:27)
      at TernarySearchTree._delete (http://localhost:33887/079953d7545e7ca308c82fce64738984/out/vs/base/common/ternarySearchTree.js:466:30)
      at TernarySearchTree.delete (http://localhost:33887/079953d7545e7ca308c82fce64738984/out/vs/base/common/ternarySearchTree.js:415:25)
      at Context.<anonymous> (http://localhost:33887/079953d7545e7ca308c82fce64738984/out/vs/base/test/common/ternarySearchtree.test.js:732:31)

```
Repository: pytorch
Issue: Dynamo x autograd.Function x funtorch transform: intermediate sliced tensor doesn't require grad caused incorrect result 
Labels: triaged,oncall: pt2,module: functorch,module: dynamo,dynamo-autograd-function,dynamo-functorch

### 🐛 Describe the bug

Let's use this small repro to demonstrate this issue:
```
import torch
import inspect

@torch.compile(backend="eager", fullgraph=True)
def fn(x):
    x = torch.vmap(gn)(x)
    return x + 1

def gn(x: torch.Tensor) -> torch.Tensor:
    if x.requires_grad:
        return x + 1
    else:
        return x - 1

x = torch.ones(2, 3, requires_grad=True)
print(fn(x))

```
The output:
```
tensor([[1., 1., 1.],
        [1., 1., 1.]], grad_fn=<AddBackward0>)
```
This means the ```gn``` function goes with the ```else``` branch, because of the intermediate sliced tensor doesn't require grad. However, if ```gn``` is an autograd function, then we would check if the input tensor requires grad and decide how to proceed.
https://github.com/pytorch/pytorch/blob/b977abd5de0ea8c37f6100e7fc170830a07ff47b/torch/_dynamo/variables/misc.py#L652-L656

We need to revisit the behavior of how to compile autograd function regarding to ```requires_grad=True/False```.

### Versions

N/A

cc @ezyang @chauhang @penguinwu @zou3519 @Chillee @samdow @kshitij12345 @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames @rec
Repository: ollama
Issue: Inconsistent API Behavior
Labels: bug

### What is the issue?

I'm calling the generate API as follows:

```
url = 'http://localhost:11434/api/generate'
data = {
  "model": model_name,
  "stream": False,
  "options": {
      "temperature": 0.2,
      "top_p": 0.8,
      "seed": 42,
      "num_predict": 300,
  },
  "system": set_role()
}

response = requests.post(url, json=data).json()
```

Although I set the stream flag to false, sometimes I don't get the whole response in one package (done = False in the first received package).
The other problem is that sometimes, even when the package is final (done=true), I don't see all the expected additional information there, for example, prompt_eval_count is missing.

This problem also persists with the Python library. I’ve carefully checked the documentation, and I believe it might be some sort of bug.

### OS

Linux

### GPU

Nvidia

### CPU

Intel

### Ollama version

0.3.5
Repository: neovim
Issue: grepprg settings have unexpected behavior since 0.10
Labels: documentation,defaults

### Problem

Since switching the default grep program to rg, unfortunately it appears that any `grepprg` values that explicitly call grep no longer work properly. I noticed this originally because I had the following line in one of my local .lvimrc files:

```
setlocal grepprg=grep\ -nIH\ --exclude=tags\ --exclude=tags.vim\ --exclude='*.o*'\ --exclude='Module.symvers'\ --exclude='.*.mod.cmd'\ --exclude='*.mod'
```

From what I can tell - the problem appears to be that when ripgrep is installed on the system (this is a machine I just setup, I wasn't even aware I installed this) neovim doesn't just use it as a default - but it also changes the default value of `grepformat`. As a result - it doesn't process the text output from `grep` correctly, leading to some confusing behavior where it suddenly seems as if the location list has stopped working. Some example screenshots:

(Before)

![image](https://github.com/user-attachments/assets/f381479f-0724-4597-921e-c2ccb536f094)

(After)

![image2](https://github.com/user-attachments/assets/bf250397-9d33-424a-a322-990430935073)

### Steps to reproduce

nvim --clean
:setlocal grepprg=grep\ -nIH
:lgrep [some arguments…]

### Expected behavior

I would expect that between upgrades, unless it's documented otherwise: the behavior of grepprg should remain the same. Or at the very least, it should remain the same when the grep binary is explicitly mentioned in the command line…

Considering this bug has probably been around for a while of course, I don't think it'd be reasonable for me to ask for the behavior to change! But perhaps it should be documented in https://neovim.io/doc/user/news-0.10.html that `grepformat` also changes and this might change the behavior of custom `grepprg` settings? The page there does mention that the default grep program that gets used is changed, but I don't think this change in behavior is particularly obvious if you're in a situation like me where it's been years since you touched `grepprg` last

### Neovim version (nvim -v)

0.10

### Vim (not Nvim) behaves the same?

no

### Operating system/version

Fedora Linux 40

### Terminal name/version

neovim-gtk (first screenshot)/tilix (second screenshot)

### $TERM environment variable

xterm-256color

### Installation

dnf (package manager)
Repository: PowerToys
Issue: Additional File Explorer add-on to selectively hide folders that are system folders
Labels: Needs-Triage

### Description of the new feature / enhancement

I would love to be able to have an add-on that lets me collapse or hide specific folders that I not care to see.  For example, I want to know these are hidden, maybe with one collapsed folder. For example, you could take all these folders, selectively hide them, and then they get grouped into a new hidden virtual folder, that is not a folder, but just a collapsed representation of your hidden folders.

You could possible even set it to do wild card all .* folder names for example, folders starting with backup*

So this
![image](https://github.com/user-attachments/assets/7312189b-c21c-48e2-80df-2a12f2bf7921)


Could be this
![image](https://github.com/user-attachments/assets/d68b0ab2-e3fc-4c5a-acb6-df3cd828ed4c)


### Scenario when this would be used?

This would just save me eye strain and distance scrolling around windows and folders
Set it to do wild card all ".*" folder names 
Folders starting with "backup-*"

### Supporting information

_No response_
Repository: flutter
Issue: integration_test deprecation warning: 'windows' is deprecated: first deprecated in iOS 15.0 - Use UIWindowScene.windows on a relevant window scene instead
Labels: f: integration_test,P3,team-ios,triaged-ios

When targeting iOS 15 or later, integration_test has an analysis warning:
```
integration_test/IntegrationTestPlugin.m:76:55 'windows' is deprecated: first deprecated in iOS 15.0 - Use UIWindowScene.windows on a relevant window scene instead
```
https://github.com/flutter/flutter/blob/77a17873beaa12a3b7a8611dff1090edce3a707a/packages/integration_test/ios/integration_test/Sources/integration_test/IntegrationTestPlugin.m#L76-L77

To reproduce, open the [example app](https://github.com/flutter/flutter/tree/77a17873beaa12a3b7a8611dff1090edce3a707a/packages/integration_test/example) iOS project and set the iOS minimum target to iOS 15.
Repository: angular
Issue: docs: fix the brokens links on the API pages. 
Labels: help wanted,good first issue,P3,area: docs-infra

### Describe the problem that you experienced

The angular.dev toolchain generates warnings whenever it encounters broken links inside the API entries. 

For example: 

```
INFO: From Action packages/common/common_docs_html:
WARNING: ***@link Router*** is invalid, Router is unknown in this context
WARNING: ***@link * Router*** is invalid, * is unknown in this context
WARNING: ***@link Component*** is invalid, Component is unknown in this context
WARNING: ***@link Component*** is invalid, Component is unknown in this context
```

We'll make this an umbrella issue, to keep track that there is work to do on this side and we'll welcome doc contributions around this ! 

To run the docs locally, run `yarn docs`, and check the console for the remaing warnings