sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: Internal server error: Install @vitejs/plugin-vue to handle .vue files. when `npx storybook@latest init`
Labels: bug,needs triage

### Describe the bug

When I tried `npx storybook@latest init` in my new nuxt3 project and `npm run storybook` an error appears: `Failed to parse source for import analysis because the content contains invalid JS syntax. Install @vitejs/plugin-vue to handle .vue files.`

It would be great if I able to use storybook without this error.

### Reproduction link

https://github.com/qkreltms/nuxt-storybook-playground

You can reproduce an error by doing these steps:
1. npm i
2. npm run storybook

### Reproduction steps

1. npx nuxi@latest init
3. npx storybook init --type vue3 --builder vite
4. npm run storybook

### System

```bash
System:
    OS: macOS 14.2.1
    CPU: (8) arm64 Apple M2
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 19.9.0 - ~/.nvm/versions/node/v19.9.0/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.6.3 - ~/.nvm/versions/node/v19.9.0/bin/npm <----- active
  Browsers:
    Chrome: 127.0.6533.120
    Safari: 17.2.1
  npmPackages:
    @storybook/addon-essentials: ^8.2.9 => 8.2.9 
    @storybook/addon-interactions: ^8.2.9 => 8.2.9 
    @storybook/addon-links: ^8.2.9 => 8.2.9 
    @storybook/addon-onboarding: ^8.2.9 => 8.2.9 
    @storybook/blocks: ^8.2.9 => 8.2.9 
    @storybook/test: ^8.2.9 => 8.2.9 
    @storybook/vue3: ^8.2.9 => 8.2.9 
    @storybook/vue3-vite: ^8.2.9 => 8.2.9 
    storybook: ^8.2.9 => 8.2.9
```


### Additional context

I was able to fix error by adding `@vitejs/plugin-vue` in my .storybook/main.js
```diff
+import { mergeConfig } from 'vite'
+import vue from '@vitejs/plugin-vue'
/** @type { import('@storybook/vue3-vite').StorybookConfig } */
const config = {
  stories: ['../stories/**/*.mdx', '../stories/**/*.stories.@(js|jsx|mjs|ts|tsx)'],
  addons: ['@storybook/addon-links', '@storybook/addon-essentials', '@chromatic-com/storybook', '@storybook/addon-interactions'],
  framework: {
    name: '@storybook/vue3-vite',
    options: {},
  },
  docs: {
    autodocs: 'tag',
  },
+  viteFinal: async( config) => {
+    return mergeConfig(config, {
+      plugins: [vue()]
+    })
+  }
};
export default config;

```
Repository: godot
Issue: Particles emit in the wrong direction when using double-precision, Vulkan, and local coordinates
Labels: bug,topic:rendering,topic:3d,topic:particles

### Tested versions

Latest master as of writing e3550cb20f5d6a61befaafb7d9cbdb57b24870e4

### System information

macOS 14.6.1

### Issue description

The particle direction is incorrect when using this exact configuration:
* Double-precision build of Godot `scons precision=double`
* Vulkan renderer (Forward+ or Mobile)
* Local coordinates enabled on the particles

If you use a single-precision build, or switch to Compatibility, or disable local coordinates, the particles behave correctly.

### Steps to reproduce

Open the minimal reproduction project with a double-precision build of Godot. It will look like this:

<img width="700" alt="Screenshot 2024-08-25 at 2 06 40 AM" src="https://github.com/user-attachments/assets/315e5c4b-93e8-44a3-9965-71c7a64faa66">

However, this is not correct. The particles node is rotated, so it should look like this, as it does in a single-precision build, when using OpenGL, and/or when local coordinates is unchecked:

<img width="700" alt="Screenshot 2024-08-25 at 2 07 04 AM" src="https://github.com/user-attachments/assets/70525873-e147-49ca-a893-daaac9c76bf2">


### Minimal reproduction project (MRP)

[particle-direction-double-vulkan-bug.zip](https://github.com/user-attachments/files/16739582/particle-direction-double-vulkan-bug.zip)
Repository: react-native
Issue: Bug: TextInput with multiline and lineHeight has height issue when controlled
Labels: Issue: Author Provided Repro,Component: TextInput,Newer Patch Available

### Description

I'm experiencing a bug with the TextInput component when using it as a controlled component with both multiline and lineHeight properties. This issue occurs only on iOS; it does not occur on Android.

### Expected Behavior:
The TextInput should adjust its height according to the content without any unexpected changes.

### Actual Behavior:
On iOS, when the TextInput is controlled, the height of the TextInput increases unexpectedly as the number of lines increases.
This issue does not occur when the TextInput is uncontrolled.

### Steps to reproduce

1. Create a TextInput component with the following properties:
    - multiline={true}
    - lineHeight set to a specific value (e.g., 60)
    - Controlled by a state variable (value and onChangeText props).
2. Type text into the TextInput to increase the number of lines.

### React Native Version

0.75.2
I have confirmed that this issue does not occur in version 0.73.2.

### Affected Platforms

Runtime - iOS

### Output of `npx react-native info`

```text
System:
  OS: macOS 14.4
  CPU: (8) arm64 Apple M1 Pro
  Memory: 236.09 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.12.2
    path: ~/.nvm/versions/node/v20.12.2/bin/node
  Yarn:
    version: 1.22.22
    path: ~/.nvm/versions/node/v20.12.2/bin/yarn
  npm:
    version: 10.5.0
    path: ~/.nvm/versions/node/v20.12.2/bin/npm
  Watchman:
    version: 2024.07.15.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.4
      - iOS 17.4
      - macOS 14.4
      - tvOS 17.4
      - visionOS 1.1
      - watchOS 10.4
  Android SDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2411.12071903
  Xcode:
    version: 15.3/15E204a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.12
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react: Not Found
  react-native: Not Found
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found
```


### Stacktrace or Logs

```text
-
```


### Reproducer

https://snack.expo.dev/@holyunwoo/eager-indigo-cereal?platform=ios

### Screenshots and Videos

#### Uncontrolled

https://github.com/user-attachments/assets/7c359007-c157-4e68-814d-45a60c97239d

#### Controlled

https://github.com/user-attachments/assets/1cf5a2e8-0cc7-4a81-bb6d-4b9ae0741e1b

<img width="300" alt="SCR-20240825-qgyj" src="https://github.com/user-attachments/assets/ed8acf6f-9351-4004-aeec-75c87421ae40">
Repository: godot
Issue: Empty doc tab appears, when Ctrl+clicking on undocumented identifier in GDscript editor
Labels: bug,topic:editor

### Tested versions

Reproducible on 4.3.stable

### System information

Linux

### Issue description

It seems that this happens only for identifiers that are missing the documentation.
I'm not sure whether such classes should be even available through GDscript, but they're being hinted while writing the code.
When I try to use such class I get this error:
```
Native class GDScriptNativeClass used in script doesn't exist or isn't exposed.
```

Details in the attached video:

https://github.com/user-attachments/assets/ee2ef302-1186-4c4d-aa98-46ae63c5881a


### Steps to reproduce

1. Open any *.gd file
2. Start writing a code that uses an undocumented class (e.g. `MovieWriterMJPEG`)
3. Hold Ctrl key and click on it
4. Observe, that a new tab appeared, but it's content didn't open
5. Try to click on it to observe that an empty Docs window opens.

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: `load()` returns `GDScript` even with `Parse error`, but `new()` method can't be called and error is undetectable
Labels: discussion,topic:gdscript

### Tested versions

v4.2.1.stable.official [b09f793f5]
v4.3.stable.official [77dcf97d8]

### System information

Godot v4.2.1.stable

### Issue description

When loading a `.gd` script using the `load()` function in Godot, the function returns a `GDScript` object even if there are parsing errors in the script. This is unexpected because:
- A valid `GDScript` object should always have a `new()` method.
- Despite `loaded.has_method("new")` returning `true`, calling `loaded.new()` results in the error:
```
Invalid call. Nonexistent function 'new' in base 'GDScript'.
```

This issue is problematic because there's no clear way to detect or handle this scenario programmatically. Even with parse errors, the script loads and appears valid according to the checks. The only way to detect that the script has issues is by using `loaded.reload()`, which returns a non-zero value if errors are present. However, relying on this method for error detection is not intuitive or well-documented.

### Expected behavior:
- If there are parsing errors, load() should return null or provide a clear and intuitive way to detect errors.
- A valid GDScript should always have a new() method that can be called without errors.

### Steps to reproduce

Here’s an example of the code and its output in both normal and error scenarios:

### Code:
```gdscript
# res://main.gd
var loaded = load("res://error.gd")
print("loaded: ", loaded)
print("loaded == null: ", loaded == null)
print("loaded is GDScript: ", loaded is GDScript)
print("loaded.has_method('new'): ", loaded.has_method("new"))
print("loaded.new: ", loaded.new)
print("loaded.has_source_code(): ", loaded.has_source_code())
print("loaded.reload(): ", loaded.reload())
loaded.new()
```
```gdscript
# res://error.gd
error
```

### Output with a valid script:
```
loaded: <GDScript#-9223371840326459786>
loaded == null: false
loaded is GDScript: true
loaded.has_method('new'): true
loaded.new: GDScript::new
loaded.has_source_code(): true
loaded.reload(): 0
```

### Output with a script containing parse errors:
```
loaded: <GDScript#-9223371833011593533>
loaded == null: false
loaded is GDScript: true
loaded.has_method('new'): true
loaded.new: GDScript::new
loaded.has_source_code(): true
loaded.reload(): 43
```

### Error encountered:
```
Invalid call. Nonexistent function 'new' in base 'GDScript'.
```

### Steps to reproduce:
1. Use the code provided above to load a script and check its validity.
2. Create a .gd script with syntax errors and attempt to load it.
3. Observe that loaded.has_method("new") returns true, but calling loaded.new() raises an error.
4. Note that loaded.reload() returns a non-zero value, indicating an error that isn't detectable by other checks.

### Minimal reproduction project (MRP)

[gdscript load issue project.zip](https://github.com/user-attachments/files/16739816/gdscript.load.issue.project.zip)
Repository: tauri
Issue: [feat] ".tauri" folder for mobile plugin prepare initialize
Labels: type: feature request

### Describe the problem

".tauri" folder is not created until the mobile app is launched. So in plugin development, Open plugin directory that from Xcode or Android Studio has error until the mobile app is launched.

- plugin-directory/.tauri  // iOS tauri directory
- plugin-directory/android/.tauri // Android tauri directory

### Describe the solution you'd like

".tauri" folder change to Swift Package Manager and mavenCentral.
If that is not possible by design, you will probably need a command to copy.

Example: package.json: `“preinstall”: “tauri plugin ios install”`

### Alternatives considered

_No response_

### Additional context

_No response_
Repository: ollama
Issue: llama_get_logits_ith: invalid logits id 11, reason: no logits
Labels: bug

### What is the issue?

llama_get_logits_ith: invalid logits id 11, reason: no logits


### OS

Linux

### GPU

Nvidia

### CPU

Intel

### Ollama version

_No response_
Repository: godot
Issue: Custom script icons render too small on Retina display
Labels: bug,topic:editor,usability

### Tested versions

v4.3.stable.official [77dcf97d8]

### System information

Godot v4.3.stable - macOS 14.6.1 - GLES3 (Compatibility) - Intel(R) UHD Graphics 617 - Intel(R) Core(TM) i5-8210Y CPU @ 1.60GHz (4 Threads)

### Issue description

When setting a custom `@icon` on a script, the icon renders smaller than expected in the Scene Tree. The icon preview in the FileSystem renders at the correct size.

<img width="272" alt="icon-issue" src="https://github.com/user-attachments/assets/93381422-d34d-47d7-b908-29ee2f83f9b9">

I'm using a MacBook Air with a high DPI / Retina display:

Screen Width: 1440 pixels
Screen Height: 900 pixels
DPR (Device Pixel Ratio): 2

### Steps to reproduce

- Create a new script
- Add a custom `@icon` pointed at an asset in the FileSystem (.png and .svg both tested)

```
@icon ("res://assets/icons/icon_save.svg")
extends Node2D
class_name SaveDataResource
```

- Observe icon in FileSystem pane at incorrect size

### Minimal reproduction project (MRP)

[customiconsizeissue.zip](https://github.com/user-attachments/files/16740466/customiconsizeissue.zip)
Repository: rust
Issue: Compiler does not recognize the reserve-r9 target feature
Labels: A-LLVM,O-Arm,T-compiler,A-target-feature

This issue is similar to [this](https://github.com/rust-lang/rust/issues/121970) issue. On the armv7a-none-eabi target, specifying the reserve-r9 target feature using the flag -Ctarget-feature=+reserve-r9 results in the following warning:
```
warning: unknown and unstable feature specified for `-Ctarget-feature`: `reserve-r9`
  |
  = note: it is still passed through to the codegen backend, but use of this feature might be unsound and the behavior of this feature can change in the future
  = help: consider filing a feature request
```

The feature is currently working and is used by me and [others](https://internals.rust-lang.org/t/fixed-r9-in-arm/20842) too.
Repository: godot
Issue: When running in Wayland, taskbar and window icons do not use Godot icon because Godot does not use a consistent `app_id` throughout its execution
Labels: bug,platform:linuxbsd,topic:porting

### Tested versions

Reproducible in v4.3.stable.official [77dcf97d8], v4.3.rc1.official [e343dbbcc]

### System information

Gentoo Linux, KDE Plasma 5.27.11, Wayland graphics platform

### Issue description

Wayland maps a window to an application by matching the application's `app_id` to a matching `.desktop` file in `/usr/share/applications` or `~/.local/share/applications/`. The `.desktop` file included in the Godot source is `misc/dist/linux/org.godotengine.Godot.desktop`, meaning that once that file is properly copied to the appropriate directories Wayland will only be able to match the window to the application when the app_id is exactly `org.godotengine.Godot`.

The `.desktop` files appropriately placed in the application directories is also what allows application menus to automatically populate all the applications installed in the system.

In `platform/linuxbsd/wayland/display_server_wayland.cpp`, function `DisplayServerWayland::_get_app_id_from_context`, Godot sets a different app_id based on the context it is running in: `org.godotengine.Editor`, `org.godotengine.ProjectManager`, `org.godotengine.Godot`, or the value set in `application/config/name`.

Consequently the taskbar and window frame show the default Wayland app icon instead of the Godot icon.

The value set in `application/config/name` would of course be the user's responsibility to have a `.desktop` file appropriate for their own game, so that is not an issue for this bug, although may require some documentation changes to note the connection between the `application/config/name` and the user’s own generated and distributed `.desktop` file.

### Steps to reproduce

Enable the Prefer Wayland option in the editor settings.

Copy the file `misc/dist/linux/org.godotengine.Godot.desktop` to either `/usr/share/applications` or `~/.local/share/applications/`

Run Godot, opens in ProjectManager context with the app_id org.godotengine.ProjectManager.

Open a project, Godot reloads with the app_id org.godotengine.Editor

In both of these contexts, the taskbar and window decoration icons use the default Wayland icon.

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: Grabbing native Popup window resize edge closes window instead of resizing
Labels: bug,topic:gui

### Tested versions

- 4.3.stable

### System information

macOS 14.6.1

### Issue description

On resizable native Windows (and Popups) you can grab the edge to resize them. At least on macOS the system makes it easier for you to resize by allowing you to grab the window edge a couple of pixels inside and a couple of pixels outside the window edge, as indicated by where the cursor changes to a resize cursor.

On resizable native Window object in Godot this works as expected as you can see. However for Popup windows, if you start doing the resize outside the window the popup closes instead. 

https://github.com/user-attachments/assets/f09327db-f626-4903-a94e-b7a99fb24b13

Since popups can be dismissed by clicking outside them I'm guessing this is simply what is happening, and it's not accounting for the fact that this click outside the window should actually start a resize drag instead of dismissing the Popup.

### Steps to reproduce

Show a native resizable Popup window using popup()
Try grabbing the edge to resize it where the cursor changes to the resize cursor just outside the window edge.
Observe the popup close.

### Minimal reproduction project (MRP)

[popupresize.zip](https://github.com/user-attachments/files/16740994/popupresize.zip)
Repository: ui
Issue: [bug]: Input field has default bg-white and text-white
Labels: bug

### Describe the bug

When importing a Input field it has default text-white and bg-white for the input field. This gets bad after the focus is on the input field and have to manually make changes in the input ui component of the projects. 

![Screenshot from 2024-08-25 21-04-59](https://github.com/user-attachments/assets/05d2b53c-1458-4a4a-859b-d1617e9f1523)
This image show that there is text in the input filed because we can see the auto-correct's red underline. 

![Screenshot from 2024-08-25 21-06-41](https://github.com/user-attachments/assets/15dd79b5-b9ed-4523-b17b-56c966a0faa7)
Here i have attached a snapshot of the code that I have made change to to resolve this issue.


### Affected component/components

Input

### How to reproduce

1. Import **Input** component from [ui.shadcn.com](https://ui.shadcn.com/docs/components/input) to you project folder.
2. Use the input component in you code with proper import statements.
3. Start the development server and open the localhost:3000.
4. Start typing in the input field.

### Codesandbox/StackBlitz link

_No response_

### Logs

No response in log

### System Info

```bash
browser- brave 128(latest updated version)
system - Linux
os- Ubuntu 
version-22.04
system-binaries up-to date and other system files.
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [x] I've searched for existing issues
Repository: vscode
Issue: Terminal Suggest: Add support for other shells (eg. zsh, bash)
Labels: feature-request,on-testplan,api-proposal,terminal-suggest

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

### Feature Request

https://github.com/microsoft/vscode/labels/terminal-suggest support for zsh and bash shells, similar to the [existing support for Powershell](https://code.visualstudio.com/docs/terminal/shell-integration#_experimental-intellisense-for-powershell):

![image](https://github.com/user-attachments/assets/ee16e15d-766f-4b65-bd0f-eb2d2cb06880)

Ideally, VS Code would pick up the completions that a user already configured for their terminal. As a zsh user (at work) and bash user (at home), I wouldn't mind if enabling this feature required some minimal `.zshrc`/`.bashrc` changes (we're used to that kind of thing). It also wouldn't be a deal-breaker if I needed to hit TAB to generate the list of completions, but it'd be nice to have the completions updated after each input change.

### Motivation

Terminal completion pop-ups are a feature available in several newer terminals/IDE's like Warp, Fig/AmazonQ, and JetBrains/IntelliJ. I'm quite excited to see that VS Code is adding support for this! However, switching to pwsh isn't in the cards for me. Plus, my teammates all use either zsh or bash, and it's harder for me to sell the idea of using VS Code without this feature.

Beyond the obvious aesthetic improvement, having a pop-up, scrollable list of options can be quite helpful for long lists of completion options, such as `git <TAB>`:
```
zsh: do you wish to see all 141 possibilities (141 lines)?
```

### Prior Work

PR https://github.com/microsoft/vscode/pull/211962 disabled the https://github.com/microsoft/vscode/labels/terminal-suggest feature for all shells except powershell. Therefore it seems not possible to use this feature for any other shells, even with an extension.
Repository: rust
Issue: `slice::Iter` + `max` on array: Regression since Rust 1.65 (LLVM 15)
Labels: A-LLVM,I-slow,P-low,T-compiler,C-bug,regression-untriaged,llvm-fixed-upstream

<!--
Thank you for filing a regression report! 🐛 A regression is something that changed between versions of Rust but was not supposed to.

Please provide a short summary of the regression, along with any information you feel is relevant to replicate it.
-->

### Code

I tried this code:

```rust
pub fn fna(x: [u8; 1024]) -> u8 {
    x.into_iter().max().unwrap()
}

pub fn fnb(x: [u8; 1024]) -> u8 {
    *x.iter().max().unwrap()
}
```

[Godbolt](https://rust.godbolt.org/z/f36snahTn)

I expected to see this happen:

1. Both functions should optimize away the unwrap
2. (Bonus) Both functions should inline the respective iterator functions and auto-vectorize

Instead, this happened:

1. `fna` has no unwrap in the assembly output, but `fnb` has.
2. (Bonus) Both inline their respective iterators (according to the MIR output on the playground). `fna` auto-vectorizes, but `fnb` doesn't.

`fnb` generates a byte-wise max implementation. Interestingly, it keeps _some_ information about the array length around, influencing the codegen. A byte-wise `max` implementation for `[u8; 1024]` will need to do 1023 comparisons (since the first value of the array will be the initial `max` result value), and 1023 is divisible by 3, so the compiler emits a loop that emits a loop that runs 341 times, doing 3 `max` computations each. If I change the length of the array to 1025, it will do 4 `max` computations each.

Even though the generated code relies on the number of array entries, it still doesn't elide the `Option::unwrap` check for the `max` result. In Rust 1.45-1.64 `fnb` also generates the 3-byte-at-a-time loop, but _does_ remove the `Option::unwrap`.

### Version it worked on

It most recently worked on: Rust 1.64. (For context: Rust 1.65 added LLVM 15.)

It (initially?) started working in 1.45 (that version added LLVM 10).

### Version with regression

Any version since Rust 1.65.

-----

Since I thought this behavior was unexpected, I polled it on mastodon before looking further into it. ATM about half of the respondents thought just like me that both should be optimized (at least the unwrap part):

![image](https://github.com/user-attachments/assets/809ff640-b7b2-42dd-98af-a28aaa1706f2)