sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tailwindcss
Issue: `src` descriptor in `@font-face` rule is transformed/formatted incorrectly
Labels: v3

<!-- Please provide all of the information requested below. We're a small team and without all of this information it's not possible for us to help and your bug report will be closed. -->

**What version of Tailwind CSS are you using?**

For example: both 3.4.13 and 4.0.0-alpha.30

**What build tool (or framework if it abstracts the build tool) are you using?**

This happens in the online playground as well. Originally Next.js with Turbopack

**What version of Node.js are you using?**

v20

**What browser are you using?**

Chrome

**What operating system are you using?**

macOS

**Reproduction URL**

https://play.tailwindcss.com/NObbqx3vf9?file=css

**Describe your issue**

Tailwind turns
```css
@font-face {
  font-family: 'Inconsolata';
  font-style: normal;
  font-weight: 200 900;
  font-stretch: 100%;
  font-display: swap;
  src: url(some/url/with/query?{%22url%22:%22https://fonts.gstatic.com/s/inconsolata/v32/QlddNThLqRwH-OJ1UHjlKENVzkWGVkL3GZQmAwLyxq15IDhunJ_o.woff2%22,%22preload%22:false,%22has_size_adjust%22:true}) format('woff2');
  unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+0300-0301, U+0303-0304, U+0308-0309, U+0323, U+0329, U+1EA0-1EF9, U+20AB;
}

```
into
```css
@font-face {
  font-family: 'Inconsolata';
  font-style: normal;
  font-weight: 200 900;
  font-stretch: 100%;
  font-display: swap;
  src: url(some/url/with/query? {
    %22url%22: %22https://fonts.gstatic.com/s/inconsolata/v32/QlddNThLqRwH-OJ1UHjlKENVzkWGVkL3GZQmAwLyxq15IDhunJ_o.woff2%22,%22preload%22:false,%22has_size_adjust%22:true;
  }
  ) format('woff2': ) format('woff2');
  unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+0300-0301, U+0303-0304, U+0308-0309, U+0323, U+0329, U+1EA0-1EF9, U+20AB;
}
```
Notice that `src:` value has some newlines, and that `format()` is duplicated with invalid syntax.
Repository: node
Issue: Incorrect version for `PerformanceObserverEntryList`
Labels: doc

### Affected URL(s)

https://nodejs.org/docs/latest/api/perf_hooks.html

### Description of the problem

this interface has shipped in v8.5.0, but the interface itself cann't be accessed before v16.7.0

see https://github.com/mdn/browser-compat-data/pull/25001 for full test
Repository: PowerToys
Issue: Unexpected behavior in Advanced Paste > Enable Paste with AI
Labels: Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

I had some repetitive work to do:

- copy values in my German Excel file with comma as decimal separator
- paste those values in Visual Studio as C# 2D array

So, I used "Advanced Paste" with "Enable Paste with AI". On the first time, I prompted "paste as C# 2D Array. Replace the comma decimal separator with the new decimal separator point".
I copied this prompt to a text file.
On the second time, I copied Excel values, opened Advanced Paste, copied the prompt and did not get my values as C# array but just the prompt.

I can fully understand, why this happens, but it is not what I expected. And I do not see a workaround for this kind of repetitive work.

What do you think about a "Prompt history"? This would make repetitive work just
Shift + Windows + V --> click

### Scenario when this would be used?

repetitive work

### Supporting information

_No response_
Repository: godot
Issue: Setting `TabContainer.current_tab` doesn't immediately change visibility
Labels: bug,topic:gui

### Tested versions

Reproducible in: 
- v4.3.stable.official [77dcf97d8]

### System information

Godot v4.3.stable - Debian GNU/Linux trixie/sid trixie - Wayland - Vulkan (Mobile) - dedicated AMD Radeon RX 7600 (RADV NAVI33) - AMD Ryzen 5 7600 6-Core Processor (12 Threads)

### Issue description

When setting `current_tab` on a `TabContainer` instance, the visibility of the tabs does not get updated immediately.

In my particular case, this was causing an issue because I wanted to set the UI focus after switching the tab, but `%my_tab.find_next_valid_focus()` was returning an element outside the tab.

To set the focus one needs to either:
a) `await get_tree().process_frame` after setting `current_tab`; or
b) Just `%my_tab.visible = true` instead of setting `current_tab`.


### Steps to reproduce

1. Set `current_tab` on a `TabContainer`
2. Check the visibility of the now-current tab (hidden)
3. Wait a frame
4. Check visibility again (visible)

The MRP has an `if true:` in the script, which can be `false`d to compare behaviour between setting `current_tab` and setting `visible` directly.

### Minimal reproduction project (MRP)

Self-contained MRP tscn:
[current_tab_test.zip](https://github.com/user-attachments/files/17702886/current_tab_test.zip)
Repository: next.js
Issue: revalidatePath or revalidateTag does not execute internal revalidation logic if called inside a setTimeout nor does it throw an exception
Labels: bug,Performance,Runtime

### Link to the code that reproduces this issue

https://github.com/trieb-work/nextjs-bug-revalidatetag-inside-settimeout

### To Reproduce

1. start the app with nodejs in production mode: `NODE_ENV=production VERCEL_ENV=production pnpm build && NODE_ENV=production VERCEL_ENV=production pnpm start`
2. open the index page http://localhost:3000 --> a random number will appear which will get cached
3. reload the index page: the same number is still present because it is cached
4. open http://localhost:3000/normal --> revalidatePath will get called for the index page 
5. open the index page --> a new number will be displayed because of the working revalidatePath
6. open http://localhost:3000/timeout --> revalidatePath will get called inside a setTimeout
7. open the index page --> the same old number is still present because revalidateTag/revalidatePath does not work inside of a setTimeout

### Current vs. Expected behavior

if revalidateTag/revalidatePath is used inside a setTimeout it does not have any effect (tested in nodejs), but still the remaining code inside the setTimeout is executed. I implemented my own cache handler (like here: https://nextjs.org/docs/app/api-reference/next-config-js/incrementalCacheHandlerPath) and could see that the revalidateTag function from the cache handler is never called if the nextjs revalidateTag function is called inside a setTimeout.

### 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
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.18.0
  npm: 10.8.2
  Yarn: 1.22.21
  pnpm: 8.15.8
Relevant Packages:
  next: 15.0.4-canary.5 // Latest available version is detected (15.0.4-canary.5).
  eslint-config-next: N/A
  react: 19.0.0-rc-5c56b873-20241107
  react-dom: 19.0.0-rc-5c56b873-20241107
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Performance, Runtime

### Which stage(s) are affected? (Select all that apply)

Other (Deployed)

### Additional context

I have not tested it in deployed vercel env as we are self hosting using docker and nodejs.

I have also tested to wrap the setTimeout in an `unstable_after` function but this has not helped as well.

As a workaround the code can be rewritten to use a sleep/delay function (`const sleep = (ms: number) => new Promise((res) => setTimeout(res, ms));`) instead of a setTimout directly. Calling revalidateTag after the sleep function works as expected (`await sleep(100); revalidatePath("/")`)
Repository: neovim
Issue: loader: .cache/nvim/luac/ contains 250k files when using nvim.appimage
Labels: bug,performance,lua,has:plan,startup

### Problem

Nvim started freezing almost every session for me. Eventually I found that my `~/.cache/nvim/luac` directory has more than 250,000 files in it.

These appear to be cache files generated and named according to the path of the original lua file.

The problem is the `nvim.appimage` release mounts nvim at a different temporary path each time it is invoked. The naming scheme of these cache files changes, then on every invocation, making the cache pointless and creating N additional files on every launch of nvim. For me, that led to a directory that currently has 246,768 files in it.

Here is an example of 2 identical files in the the `./luac/` directory that are named differently only because the temporary mounting paths generated by appimage are different:

`%2ftmp%2f.mount_nvim.a65Rja0%2fusr%2fshare%2fnvim%2fruntime%2flua%2fvim%2ftreesitter.luac`
`%2ftmp%2f.mount_nvim.aNpxXgo%2fusr%2fshare%2fnvim%2fruntime%2flua%2fvim%2ftreesitter.luac`

I originally encountered this with the 0.9.5 appimage on RHEL7, but have confirmed the v0.11.0-dev-1129+gadbffff5d0 pre-release still behaves the same way.

### Steps to reproduce

To reproduce:

1) install `nvim.appimage`
2) `mv ~/.cache/nvim/luac ~/.cache/nvim/luac.backup`
3) `nvim`
4) Observe contents of `~/.cache/nvim/luac/`
5) Close nvim and run `nvim` again
6) Observe contents of `~/.cache/nvim/luac/` and see that new identical files have been added with a different mount prefix

Every time `nvim` is launched, more files are added.

### Expected behavior

Expected behavior is not to allow unbounded growth of the number of files in `~/.cache/nvim/luac/`.

When using `nvim.appimage`, the cache is effectively rendered moot between launches of nvim. A simple workaround to address the problem I'm experiencing would be to either not cache or remove cached luac files on close when appimage is used.

A more ideal solution would allow the cached files to be used and probably involves some sort of translation of appimage mount paths to a common filename in the cache directory that can be shared among multiple instances of nvim that are compatible (same version?)

### Nvim version (nvim -v)

v0.11.0-dev-1129+gadbffff5d0 all the way back to v0.9.5

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

unlikely since these are lua cache files? Not sure how to even check this.

### Operating system/version

RHEL9.3, RHEL7, and RHEL8

### Terminal name/version

zsh 5.8

### $TERM environment variable

screen

### Installation

appimage
Repository: go
Issue: x/sync/errgroup: Group: document that Go may not be concurrent with Wait unless semaphore > 0
Labels: Documentation,help wanted,NeedsFix

(Edit: skip down to https://github.com/golang/go/issues/70284#issuecomment-2470418828; this is now a doc change request. --@adonovan)

### Go version

go version go1.23.1 darwin/amd64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/haaawk/Library/Caches/go-build'
GOENV='/Users/haaawk/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/haaawk/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/haaawk/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/haaawk/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/_y/nj5hcsh93l12tmsszxgx7ntr0000gn/T/go-build2396141927=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

When following code is run:
```
package main

import (
	"runtime"

	"golang.org/x/sync/errgroup"
)

func main() {
	runtime.GOMAXPROCS(1)
	g := &errgroup.Group{}
	g.SetLimit(1)
	ch := make(chan struct{})
	wait := make(chan struct{}, 2)
	g.Go(func() error {
		<-ch
		wait <- struct{}{}
		return nil
	})
	go g.Go(func() error {
		println("I'm not blocked")
		wait <- struct{}{}
		return nil
	})
	println("Ok let's play")
	close(ch)
	g.Wait()
	println("It's over already?")
	<-wait
	<-wait
}
```

https://go.dev/play/p/xTIsT1iouTd

### What did you see happen?

The program printed:
```
Ok let's play
It's over already?
I'm not blocked
```

### What did you expect to see?

The program printing:
```
Ok let's play
I'm not blocked
It's over already?
```
Repository: go
Issue: x/tools/gopls: specialize file watching with a setting rather than user agent
Labels: gopls,Tools

              Thinking more, I am more convinced that gopls shouldn't use the `ClientName` in adjusting its functionality.
              For example, we should've used an explicit setting instead of using the ClientName in  https://github.com/golang/tools/blob/f1f7c26696be8f94198beafd05b36843515ac2ba/gopls/internal/cache/snapshot.go#L950

_Originally posted by @hyangah in https://github.com/golang/go/issues/70205#issuecomment-2463393543_

Extracting this to an issue: for some reason (expedience, most likely) I chose to specialize file watching patterns based on the VS Code user agent (because VS Code performs very poorly with certain watch patterns). A more explicit (and therefore better) solution would have been to make the VS Code Go client inject a setting that selects the most appropriate watch patterns.
Repository: godot
Issue: Resizing editor window causes editor to render offset
Labels: bug,topic:rendering,topic:editor

### Tested versions

v4.0.stable.official [92bee43ad] through v4.4.dev4.official [36e6207bb]

### System information

Godot v4.4.dev4 - Windows 10.0.19045 - Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 980 Ti (NVIDIA; 32.0.15.6603) - Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 threads)

### Issue description

When resizing the Godot editor window, the editor stops rendering in the correct location of the window:

https://github.com/user-attachments/assets/b93d2c34-2841-48d5-88b4-48110e728b00

This does not happen with the Project Manager, but happens with any project.

Since this happens as early as 4.0, I expect this has already been reported, but I can't find the existing issue...

Restarting the computer resolved the issue and I can no longer reproduce it, even though it was happening consistently until the restart.

### Steps to reproduce

1. Open Godot editor
2. Resize the window

### Minimal reproduction project (MRP)

N/A
Repository: TypeScript
Issue: Regression: Mapped type with recursive key remapping crashes tsc with "RangeError: Maximum call stack size exceeded" in TS@5.4+
Labels: Bug,Help Wanted

### 🔎 Search Terms

"Mapped type", "Recursive mapped type", "Recursive type", "RangeError: maximum call stack size exceeded"

### 🕗 Version & Regression Information

- This changed between versions 5.3.3 and 5.4.5

### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.4.5#code/KYDwDg9gTgLgBDAnmYcBiAbAhjGwB2AKssADwDKEArlAMaqh74AmAznBAEYBWwtMAGjiEsUAObAYAPjgBeOAG8AUHDgBtANLBEcAJb44Aa20QAZnEo16cLOy07GBNnFYwo+sStVwA-Bep0wJraALpwjizsXLz8Xt6+cAAGACQK9gC+AHSpxohm6Ni4BMQoFAH0wYghQiLikjIAZC5uHumJcd4AXHD2Hd34wABuwFAhALQ+3bUSMADcSunzSkgo6LrAGMzkG3zw8sqqMFicGMDdru74YvOqpuub5y1X8+lKyyRwAILMzFDArOx9l5IK4AMIQZhnZqXa5eSGsWjuMAwXQQfCPGE3Gw-P4AjEeF5vFaoACqrBGckUXl0zH6VAAtpwRlj8Fh6VCLgSvFgcf9WN1vr8+YT3qtMDgmMBmGSKfJxUUiCRSDKoEI0Pctjt+FJ5gB6XXxQ0APR8QA

### 💻 Code

```ts
export type FlattenType<Source extends object, Target> = {
  [Key in keyof Source as Key extends string
    ? Source[Key] extends object
      ? `${Key}.${keyof FlattenType<Source[Key], Target> & string}`
      : Key
    : never]-?: Target;
};

type FieldSelect = {
  table: string;
  field: string;
}

type Address = {
  postCode: string;
  description: string;
  address: string;
}

type User = {
  id: number;
  name: string;
  address: Address;
}

type FlattenedUser = FlattenType<User, FieldSelect>;
//         ^?
```


### 🙁 Actual behavior

Compilation crashes with "RangeError: maximum call stack size exceeded"

### 🙂 Expected behavior

No crash with the type working correctly or explicit error on the recursive type like "Type instantiation is excessively deep and possibly infinite. ts(2589)"

### Additional information about the issue

Same playground in version 5.3.3 where the type resolves with no crash
https://www.typescriptlang.org/play/?ts=5.3.3#code/KYDwDg9gTgLgBDAnmYcBiAbAhjGwB2AKssADwDKEArlAMaqh74AmAznBAEYBWwtMAGjiEsUAObAYAPjgBeOAG8AUHDgBtANLBEcAJb44Aa20QAZnEo16cLOy07GBNnFYwo+sStVwA-Bep0wJraALpwjizsXLz8Xt6+cAAGACQK9gC+AHSpxohm6Ni4BMQoFAH0wYghQiLikjIAZC5uHumJcd4AXHD2Hd34wABuwFAhALQ+3bUSMADcSunzSkgo6LrAGMzkG3zw8sqqMFicGMDdru74YvOqpuub5y1X8+lKyyRwAILMzFDArOx9l5IK4AMIQZhnZqXa5eSGsWjuMAwXQQfCPGE3Gw-P4AjEeF5vFaoACqrBGckUXl0zH6VAAtpwRlj8Fh6VCLgSvFgcf9WN1vr8+YT3qtMDgmMBmGSKfJxUUiCRSDKoEI0Pctjt+FJ5gB6XXxQ0APR8QA

We ran into this crash when upgrading the ts version in our project.

There's a workaround based on the approach described in https://blog.swmansion.com/deep-flatten-typescript-type-c0d123028d82 which doesn't cause a crash on these versions.

The original type that caused the crash has mostly the same motivation as the blog post above. The provided snippet was simplified to a minimal reproducible example.
Repository: bitcoin
Issue: RFC: Adopt C++ Safe Buffers?
Labels: Brainstorming

C++ is unsafe, meaning that any code written in it may cause undefined behavior at runtime. One possible source of undefined behavior is out-of-range memory access.

While some limited compiler warnings exist to detect some obvious cases, tracking down out-of-range memory access is usually done at runtime with debugging tools such as Valgrind or Asan. However, such tools can normally not be used in production, because they are not hardening tools, see https://stackoverflow.com/a/70004411/2084795. Some C++ standard libraries provide options to enable a hardened build, which can also be used in production, see https://libcxx.llvm.org/Hardening.html.

However, this requires using the standard library containers or primitives to represent buffers. For example, instead of using a raw C-array, `std::array` should be preferred. Also, instead of using a raw C-pointer, `std::span` should be preferred.

My understanding is that only libc++ offers such a hardened build right now, so the benefit would be limited. Also, the required patch is large-ish. However, I think it would be good to keep this hardening feature in mind and use `std::array` and `std::span` for new code. Possibly in the future, those can be enforced. `std::array` via https://clang.llvm.org/extra/clang-tidy/checks/modernize/avoid-c-arrays.html and `std::span` (really all buffer representations) via `-Wunsafe-buffer-usage` https://clang.llvm.org/docs/SafeBuffers.html.
Repository: PowerToys
Issue: Option to disable quick access
Labels: Needs-Triage

### Description of the new feature / enhancement

Having a switch (enabled by default) to allows the user to enable/disable the powertoys systemtray quick access menu.
There is nothing in that menu so being able to disable it would be nice.
Even having the option to change it behavior would also be welcome like single click opens powertoys settings.

### Scenario when this would be used?

People that do not use the feature having more choice.

### Supporting information

I do not use it and when I click it I just want it to open powertoys settings and not the quick access since there is nothing that menu anyway.
Having the option to disable or change the behavior gives the user more choice on how the access powertoys and/or it's features.
Repository: godot
Issue: `Align Transform with View` don't change position when in orthogonal mode
Labels: bug,discussion,topic:editor,topic:3d

### Tested versions

4.4.dev

### System information

Windows 11 - Vulkan (Forward+)

### Issue description

`Align Transform with View` only changes position when the view is in perspective mode. In orthogonal mode, it just changes rotation having the same effect as `Align Rotation with View`.

It should work in orthogonal mode too. As reference, Blender's align to view feature works in both perspective and orthogonal mode.

### Steps to reproduce

- Set the 3D view to orthogonal mode
- Create a camera (or any `Node3D`)
- Select the camera and go `3D view menu > Align Transform with View`. It just rotates.

### Minimal reproduction project (MRP)

N/A
Repository: pytorch
Issue: There is probably a destructor ordering accident going on with registerPythonModule
Labels: module: crash,module: cpp,triaged,module: python frontend

Thanks to @ezyang for suggesting this.

Here's what I think it looks like:
- m.set_python_module initializes the pythonModulesSingleton
- during program exit, the pythonModulesSingleton gets destroyed first (statically initialized objects are destroyed in reverse order)
- m (the torch::Library)'s destructor runs and needs to access pythonModulesSingleton
- undefined behavior ensures.

The implication is that somehow we need to initialize the pythonModulesSingleton before the torch::Library object. The thing I'm not sure about is: how does torch::Library and the dispatcherSingleton interact? They have this same problem, unless we always initialize a dispatcherSingleton before the torch::Library object or this theory is wrong.

This needs a little more investigation

cc @jbschlosser @albanD
Repository: ui
Issue: [bug]: Calender UI is messed up after updating to react-day-picker
Labels: bug

### Describe the bug

Calender component has issue i updated react-day-picker then issue appeared. UI of calender is messed up terible UI.

Look on following image:

![image](https://github.com/user-attachments/assets/54a3164e-a802-47d0-9e91-311079743848)

**I am using NextJs14 and problem version of react-day-picker is ^9.3.0**

Another thing i noticed that the dev of react-day-picker has changed something on it like currently i am getting error on 
![image](https://github.com/user-attachments/assets/39107e23-ba36-4307-9f53-b4a60b60990c)

Thanks @shadcn 

### Affected component/components

Calender Component

### How to reproduce

Just update react-day-picker to latest version that is 9.3.0

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Windows 10
NextJs14
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues