sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: attempting to use import.meta.resolve results in an error
Labels: Webpack,Turbopack

### Link to the code that reproduces this issue

https://github.com/souporserious/next-import-meta-resolve-bug

### To Reproduce

Attempt to use `import.meta.resolve('./any-path')` in a Server or Client Component

### Current vs. Expected behavior

`import.meta.resolve('./any-path')` should work as expected with Node.js `20.8.0` and above, currently this error is thrown when attempting to use it:

<img width="950" alt="Image" src="https://github.com/user-attachments/assets/d523b3ba-8d05-4d4e-b748-2c3e29a18c06" />

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.2.0: Fri Dec  6 19:01:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 21.2.0
  npm: 10.8.1
  Yarn: 1.22.21
  pnpm: 9.9.0
Relevant Packages:
  next: 15.1.6 // Latest available version is detected (15.1.6).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A
```

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

Webpack, Turbopack

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

next dev (local), next build (local)

### Additional context

_No response_
Repository: go
Issue: x/text/message: scientific format is incorrect
Labels: NeedsInvestigation

### Go version

N/A

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

```shell
N/A
```

### What did you do?

Formatting a float for scientific results in extra spaces around the superscriptingExponent. ICU4C does not produce these same spaces when using `unicode/scientificnumberformatter.h` and CLDR does not suggest them either in current standards. See [cel-go](https://github.com/google/cel-go/blob/2f7606a838a90cfabca5146a89365a9c074197a1/ext/formatting.go#L336) for the Go code.

### What did you see happen?

1.052033 × 10⁰³

Note the extraneous `NARROW NO-BREAK SPACE` around the exponent separator.

### What did you expect to see?

1.052033×10⁰³

Note the removal of the extraneous `NARROW NO-BREAK SPACE` around the exponent separator.
Repository: storybook
Issue: [Bug]: Type errors in stories where component has discriminated union in its prop type definition, and custom properties are used
Labels: bug,needs triage

### Describe the bug

It seems to be impossible to properly type a story, when a component

1. has discriminated union in its props type definition, and
2. its story contains custom storybook-only property

### Reproduction link

https://stackblitz.com/edit/storybook-type-errors?file=src%2Fstories%2FComponent.tsx,src%2Fstories%2FComponent.stories.tsx

### Reproduction steps

_No response_

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 15.2
    CPU: (14) arm64 Apple M4 Pro
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.11.0 - ~/.local/state/fnm_multishells/52967_1737709857083/bin/node
    npm: 10.9.0 - ~/.local/state/fnm_multishells/52967_1737709857083/bin/npm
    pnpm: 9.14.2 - ~/.local/state/fnm_multishells/52967_1737709857083/bin/pnpm <----- active
  Browsers:
    Chrome: 132.0.6834.110
    Safari: 18.2
  npmPackages:
    @storybook/addon-docs: ^8.6.0-alpha.2 => 8.6.0-alpha.2
    @storybook/addon-essentials: ^8.6.0-alpha.2 => 8.6.0-alpha.2
    @storybook/addon-interactions: ^8.6.0-alpha.2 => 8.6.0-alpha.2
    @storybook/addon-themes: ^8.6.0-alpha.2 => 8.6.0-alpha.2
    @storybook/blocks: ^8.6.0-alpha.2 => 8.6.0-alpha.2
    @storybook/nextjs: ^8.6.0-alpha.2 => 8.6.0-alpha.2
    @storybook/react: ^8.6.0-alpha.2 => 8.6.0-alpha.2
    @storybook/test: ^8.6.0-alpha.2 => 8.6.0-alpha.2
    eslint-plugin-storybook: ^0.11.2 => 0.11.2
    storybook: ^8.6.0-alpha.2 => 8.6.0-alpha.2
```

### Additional context

Originally found on v8.5.0 of storybook packages, tried to upgrade to latest versions to see if it’s fixed.
Repository: flutter
Issue: [SwiftPM] Xcode build does not update the generated package's supported platforms
Labels: platform-ios,tool,platform-mac,P3,team-ios,triaged-ios

### Problem

When using SwiftPM, the Flutter tool generates a `Package.swift` file that adds plugins to the app's builds. This `Package.swift`'s supported platforms should match the Xcode project's Minimum Deployments.

However, if in Xcode I update my Minimum Deployments and then do a build, the `Package.swift` file isn't updated to the latest supported platforms. See: https://github.com/flutter/flutter/issues/162072

### Repro

1. Create an app with a plugin:

   ```
   flutter create my_app
   cd my_app
   flutter pub add url_launcher
   ```

2. Generate the project configuration with SwiftPM on:

   ```
   flutter config --enable-swift-package-manager
   flutter build ios --config-only
   ```

3. Open the project in Xcode:

   ```
   open ios/Runner.xcworkspace
   ```

4. In Xcode, open Project Navigator > Package Dependencies > FlutterGeneratedPluginSwiftPackage.

   Check the generated package's supported platforms:

   ```swift
   let package = Package(
       name: "FlutterGeneratedPluginSwiftPackage",
       platforms: [
           .iOS("12.0")
       ],
       ...
   )
   ```

5. In Xcode, open Runner target > General > Minimum Deployments and set iOS to `15.0` 

6. In Xcode, build the app

7. Check the generated package's supported platforms. It will still be `.iOS("12.0")` ❌ 

### Workaround

To fix this, build the app using the Flutter tool:

```
flutter build ios --config-only
```

This regenerates the `Package.swift` file and updates its supported platforms.
Repository: flutter
Issue: [Text Selection] Text selection height should be based on the line height, not the character height
Labels: a: text input,platform-ios,framework,f: cupertino,a: quality,has reproducible steps,team-text-input,a: macros,found in release: 3.27,found in release: 3.28

### Steps to reproduce

Using a Flutter TextField, when you add both text and emojis and then select a region, the selection height appears inconsistent between characters and emojis. This is because the selection is applied by changing the background color of the character itself, with a few extra pixels added. This approach leads to an issue when both emojis and text appear on the same line, causing a mismatch in their selection heights.

### Expected results

The selection height should be uniform, as is seen with native text selection behavior.

### Actual results

Non-uniform selection that looks non-native. See attached pic. Selection area of 1 and 2 should have same height.

<img src="https://github.com/user-attachments/assets/99542c77-f534-40c8-ab0e-a6efb67728c5" width ="300"> 

### Code sample

<details open><summary>Code sample</summary>

```dart
Code is not needed
```

</details>


### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

[Upload media here]

</details>


### Logs

<details open><summary>Logs</summary>

```console
Not needed.
```

</details>


### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
[!] Flutter (Channel [user-branch], 3.24.5, on macOS 14.2.1 23C71 darwin-arm64, locale en-IT)
    ! Flutter version 3.24.5 on channel [user-branch] at /Users/delfme/Development/flutter
      Currently on an unknown channel. Run `flutter channel` to switch to an official channel.
      If that doesn't fix the issue, reinstall Flutter by following instructions at https://flutter.dev/setup.
    ! Upstream repository unknown source is not a standard remote.
      Set environment variable "FLUTTER_GIT_URL" to unknown source to dismiss this error.
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 15.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2024.1)
[✓] Connected device (4 available)
    ! Error: Browsing on the local area network for iPhone. Ensure the device is unlocked and attached with a cable or associated with the same local area
      network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)
[✓] Network resources
```

</details>
Repository: next.js
Issue: Cache Poisoning and XSS attacks caused a 500 status code (QoS issue)
Labels: Runtime,Pages Router

### Link to the code that reproduces this issue

https://github.com/ale-grosselle/next-js-bug-500

### To Reproduce

# Fetch Request Example

1. Run the application locally:

```bash
npm run dev
```

2. Send the following fetch request (you can use Curl or send it using the browser console):

```javascript
fetch("http://localhost:3002/gssp", {
  method: "GET",
  headers: {
    "x-now-route-matches": "-1"
  }
})
  .then((response) => {
    console.log("Status Code:", response.status);
    return response.text();
  })
  .then((data) => {
    console.log("Response Body:", data);
  })
  .catch((error) => {
    console.error("Error:", error);
  });
```

3. Observe the 500 error in the response and the logs.


### Current vs. Expected behavior


<img width="1507" alt="Image" src="https://github.com/user-attachments/assets/fe7dc09f-da93-4c32-b2aa-c8d828fdc69a" />

<img width="1433" alt="Image" src="https://github.com/user-attachments/assets/16261bdc-68a0-471e-8361-99408cd18687" />



### Provide environment information


```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Thu Sep 12 23:35:29 PDT 2024; root:xnu-10063.141.1.701.1~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.12.1
  npm: 10.5.1
  Yarn: 1.22.22
  pnpm: 9.15.4
Relevant Packages:
  next: 14.2.23 // An outdated version detected (latest is 15.1.6), upgrade is highly recommended!
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.7.3
Next.js Config:
  output: N/A
 ⚠ An outdated version detected (latest is 15.1.6), upgrade is highly recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue
```

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

Pages Router, Runtime

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

Other (Deployed)

### Additional context

Only version 14 (latest) has this issue, while version 15 does not have this problem.
On our side, it's a major problem because it generates many 500 errors when there's a potential attack, disrupts our QoS, and triggers the onColl (likely "on Collaboration" or "on Collect") alerts.

https://cyberpress.org/critical-vulnerability-in-next-js-framework-exposes-websites/
Repository: vscode
Issue: A developer command to show telemetry view
Labels: feature-request,telemetry

It is bit unreasonable to enable log level to trace to show the telemetry in the output. Instead there should be a developer command to show telemetry output and set log level to trace only for telemetry instead of all outputs
Repository: rust
Issue: Docs on safety of BufWriter are misleading
Labels: A-docs,T-libs

### Location

https://github.com/rust-lang/rust/blob/8231e8599e238ff4e717639bd68c6abb8579fe8d/library/std/src/io/buffered/bufwriter.rs#L9

### Summary

This one is long winded. Sorry. A reader may decide this represents an actual code bug. I believe it is *at least* a documentation bug. I may just be rediscovering something every other programmer already knows.

```
let mut file = std::fs::File::create("test")?;
file.write_all(b"Hello, world!")?;
file.flush()?; // This does nothing. It is implemented as return Ok()
file.sync_all()?; // This issues an fsync
drop(file); // Close happens here. Docs correctly say that errors are ignored, sync_all *must* have happened to force the fsync.
```

In my scenario I am writing a file to an NFS mount from Linux. The syscalls are of the pattern open+write+write+...+close.
Close *can* fail, and that *can* prevent data from previous writes (which reported success) from being actually saved. I have no way of seeing the output of close. So I need to call sync_all, giving me a safe open+write+write+...+fsync+close.

https://github.com/rust-lang/rust/blob/8231e8599e238ff4e717639bd68c6abb8579fe8d/library/std/src/io/buffered/bufwriter.rs#L9

> /// It can be excessively inefficient to work directly with something that
/// implements [`Write`]. [...]
///
/// `BufWriter<W>` can improve the speed of programs that make *small* and
/// *repeated* write calls to the same file or network socket. [...]
///
/// It is critical to call [`flush`] before `BufWriter<W>` is dropped. Though
/// dropping will attempt to flush the contents of the buffer, any errors
/// that happen in the process of dropping will be ignored. Calling [`flush`]
/// ensures that the buffer is empty and thus dropping will not even attempt
/// file operations.

This really advertises itself for the use case 
```
let mut buf = BufWriter::new(std::fs::File::create("test")?)
```
and then gives guidance on how to use it safely. This talks about errors during drop being lost (correct), says that calling flush is critical (true, but in a misleading way as the call to the inner file.flush is pointless). It does talk about *files*, not any old Write, steering me further towards madness.

Because I need to call
```
buf.into_inner()?.sync_all()?;
```
to avoid risk of silent data loss that is otherwise unobservable to the application.

I propose changing the wording at https://github.com/rust-lang/rust/blob/8231e8599e238ff4e717639bd68c6abb8579fe8d/library/std/src/io/buffered/bufwriter.rs#L21 to indicate that flush is necessary _but not sufficient_, and perhaps also adding as an example use of into_inner().
Repository: tauri
Issue: [bug] Error: 1/0 error Operation not permitted (os error 1) on iOS
Labels: type: bug,status: needs triage,platform: iOS

### Describe the bug

Trying to generate embeddings with embedanything in the Rust backend. Works fine on MacOS, throws

`Error: 1/0 error Operation not permitted (os error 1)`

on iOS.

![Image](https://github.com/user-attachments/assets/e1bbe354-7fec-41b7-9db9-961c48520995)

### Reproduction

Test repo with instructions: https://github.com/do-me/tauri-embedanything-ios/tree/main

### Expected behavior

All permissions are given, so it's supposed to work.

### Full `tauri info` output

```text
cargo tauri info

[✔] Environment
    - OS: Mac OS 15.1.1 arm64 (X64)
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.86.0-nightly (419b3e2d3 2025-01-15)
    ✔ cargo: 1.86.0-nightly (088d49608 2025-01-10)
    ✔ rustup: 1.27.1 (2024-04-24)
    ✔ Rust toolchain: nightly-aarch64-apple-darwin (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.10.0
    - npm: 10.2.3
    - deno: deno 2.1.6

[-] Packages
    - tauri 🦀: 2.1.1
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.2
    - tao 🦀: 0.30.8
    - tauri-cli 🦀: 2.2.4

[-] Plugins
    - tauri-plugin-log 🦀: 2.2.0
    - tauri-plugin-os 🦀: 2.2.0
    - tauri-plugin-http 🦀: 2.2.0
    - tauri-plugin-opener 🦀: 2.2.5
    - tauri-plugin-fs 🦀: 2.2.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../src-www
    - devUrl: http://0.0.0.0:3000/

[-] iOS
    - Developer Teams: Dominik .... (ID: ...)
```

### Stack trace

```text
App installed:
• bundleID: app.somethin.ggggg
• installationURL: file:///private/var/containers/Bundle/Application/70694BF9-C4BE-4A64-BC7D-10FBB3836550/Offline%20OSM.app/
• launchServicesIdentifier: unknown
• databaseUUID: A409327F-6C64-4235-A282-608D7112A156
• databaseSequenceNumber: 2964
• options: 
23:44:20  Enabling developer disk image services.
23:44:20  Acquired usage assertion.
Launched application with app.somethin.ggggg bundle identifier.
    Info Watching /Users/dome/work/general/tauri/tauri-offline-maps/src-tauri for changes...
[connected]
```

### Additional context

_No response_
Repository: next.js
Issue: next lint fails when using ESLint v8 flat config
Labels: Linting,linear: next

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/xenodochial-voice-lfgj88?workspaceId=ws_XCEs1GT1FEw6tFStZG4Cnd

### To Reproduce

1. Open the terminal
2. Run linting using Next.js and observe that it fails to run, indicating there are invalid ESLint config options
```
$ pnpm exec next lint

Invalid Options:
- Unknown options: useEslintrc, extensions, resolvePluginsRelativeTo, rulePaths, ignorePath, reportUnusedDisableDirectives
- 'extensions' has been removed.
- 'resolvePluginsRelativeTo' has been removed.
- 'ignorePath' has been removed.
- 'rulePaths' has been removed. Please define your rules using plugins.
- 'reportUnusedDisableDirectives' has been removed. Please use the 'overrideConfig.linterOptions.reportUnusedDisableDirectives' option instead.
```
3. Run linting using ESLint and observe that it runs successfully
```
$ pnpm exec eslint .
``` 

### Current vs. Expected behavior

### Current behavior
`next lint` does not work with an ESLint flat config (e.g., `eslint.config.js`) on `eslint@^8.21.0`. 
It does work successfully with `eslint@^9`.

### Expected behavior
It is expected that `next lint` runs successfully with a valid ESLint flat config on `eslint@^8` and `eslint@^9`.

ESLint introduced the flat config in [v8.21.0](https://eslint.org/blog/2022/08/eslint-v8.21.0-released/) and it is the default format in v9.x.
Although ESLint v8.x has reached end-of-life, some widely used shared configs have not yet migrated to v9.x (e.g., [eslint-config-airbnb](https://github.com/airbnb/javascript/issues/2961)). Flat config compatibility with `next lint` and ESLint v8.x allows codebases tied to ESLint v8.x to avoid or move away from the deprecated eslintrc format.

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4242
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 15.2.0-canary.25 // Latest available version is detected (15.2.0-canary.25).
  eslint: 8.57.1
  eslint-config-next: 15.1.6
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```

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

Linting

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

next build (local)

### Additional context

I believe the culprit is the following ESLint v9.x version check:

https://github.com/vercel/next.js/blob/v15.2.0-canary.25/packages/next/src/lib/eslint/runLintCheck.ts#L178-L193

Patching it to support ESLint versions greater than v8.21.0 worked in my case:

```diff
-        if (_semver.default.gte(eslintVersion, '9.0.0') && useFlatConfig) {
+        if (_semver.default.gte(eslintVersion, '8.21.0') && useFlatConfig) {
             for (const option of [
                 'useEslintrc',
                 'extensions',
```
Repository: next.js
Issue: console.error in catch block triggers ErrorBoundary in strict mode when using Pages Router
Labels: Pages Router

### Link to the code that reproduces this issue

https://github.com/lukasb/error-repro

### To Reproduce

1. npm run dev
2. navigate to app

### Current vs. Expected behavior

For pages router:
Current: ErrorBoundary is shown
Expected: ErrorBoundary is not shown, since error was caught

For app router:
Current: "1 error" badge shown
Expected: no badge shown, since error was caught

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 20.18.1
  npm: 10.8.2
  Yarn: 1.22.5
  pnpm: 9.4.0
Relevant Packages:
  next: 15.1.4 // There is a newer version (15.1.6) available, upgrade recommended!
  eslint-config-next: 15.1.4
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.7.3
Next.js Config:
  output: N/A
```

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

Pages Router

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

next dev (local)

### Additional context

see investigation and patches by @icyJoseph here: https://github.com/vercel/next.js/discussions/75060#discussioncomment-11935972
Repository: storybook
Issue: [Bug]: experimental test addon ^8.5.0 prevents custom vitest commands being registered
Labels: bug,addon: test

### Describe the bug

The changes in 8.5.0 to the vite plugin which updates the vitest config overwrites the commands setting applied in a workspace file.

There is a workaround which is to register a plugin after the `testStorybook` plugin and inject the commands there, but this shouldnt be required and should retain the existing commands registered:

```ts
import { storybookTest } from "@storybook/experimental-addon-test/vitest-plugin";
import { defineWorkspace } from "vitest/config";
import * as commands from "./.storybook/vitest.commands";

export default defineWorkspace([
  "vite.config.ts",
  {
    extends: "vite.config.ts",
    plugins: [
      storybookTest({ configDir: ".storybook" }),
      // having to register my commands here because merged config has them removed.
      {
        enforce: "pre",
        name: "patch-vitest-browser-commands",
        config(config) {
          config.test.browser.commands = {
            ...config.test.browser.commands,
            ...commands,
          };
          return config;
        },
      },
    ],
    test: {
        //...
      browser: {
        // these are ignore/removed
        commands
      }
    }
  }
]);
```

### Reproduction link

na

### Reproduction steps

1. register commands in vitest browser config object
2. note these commands are not available during tests

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 15.2
    CPU: (16) arm64 Apple M4 Max
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 23.6.0 - ~/.nvm/versions/node/v23.6.0/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v23.6.0/bin/yarn <----- active
    npm: 10.9.2 - ~/.nvm/versions/node/v23.6.0/bin/npm
  Browsers:
    Chrome: 131.0.6778.265
    Safari: 18.2
  npmPackages:
    @storybook/addon-a11y: ^8.5.1 => 8.5.1 
    @storybook/addon-coverage: ^1.0.4 => 1.0.5 
    @storybook/addon-essentials: ^8.5.1 => 8.5.1 
    @storybook/addon-links: ^8.5.1 => 8.5.1 
    @storybook/blocks: ^8.5.1 => 8.5.1 
    @storybook/builder-vite: ^8.5.1 => 8.5.1 
    @storybook/experimental-addon-test: ^8.5.1 => 8.5.1 
    @storybook/manager-api: ^8.5.1 => 8.5.1 
    @storybook/react: ^8.5.1 => 8.5.1 
    @storybook/react-vite: ^8.5.1 => 8.5.1 
    @storybook/test: ^8.5.1 => 8.5.1 
    @storybook/theming: ^8.5.1 => 8.5.1 
    eslint-plugin-storybook: ^0.11.1 => 0.11.2 
    storybook: ^8.5.1 => 8.5.1 
    storybook-addon-data-theme-switcher: ^1.0.0 => 1.0.0 
    storybook-addon-tag-badges: ^1.2.1 => 1.4.0
```

### Additional context

_No response_
Repository: godot
Issue: RichTextLabel has no property for `line_spacing`, just `line_separation`
Labels: enhancement,feature proposal,discussion,topic:gui

### Tested versions

- Reproducible in `v4.4.beta1.mono.official [d33da79d3]`

### System information

macOS Sonoma 14.6.1

### Issue description

`RichTextLabel` has no `line_spacing` property, which would set the space only _between_ lines. Instead, it has `line_separation`, which adds that amount of space after _each_ line. E.g. in this picture, there is a lot of blank space below "Line 3":

<img width="308" alt="Image" src="https://github.com/user-attachments/assets/8f9eb18d-4894-4847-9818-8b0dad135af8" />

The best workaround I could find is making a `FontVariation` that has `spacing_bottom` set to a negative value while keeping `line_separation` at a positive value. I believe this is similar to specifying the BBCode `[font bt=5]` but in such a way that you don't need to modify every `RichTextLabel` in your game.

### Steps to reproduce

- Make a `RichTextLabel`
- Increase its `line_separation` property to make it more obvious

### Minimal reproduction project (MRP)

[richtextlabelspacingrepro.zip](https://github.com/user-attachments/files/18543572/richtextlabelspacingrepro.zip)