sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: Localisation is partially incorrect
Labels: bug,platform:windows,localization,complexity:low

### Problem

NVim somehow sets the language to german. I am on a Windows 11 install with english as the primary language:

![ApplicationFrameHost_YLBhpyKVSj](https://github.com/neovim/neovim/assets/19377618/373a4876-0072-4084-8757-5c39090edd7e)

I don't even have the german language pack installed, I basically just have the keyboard layout. Since I have multiple keyboards. It doesn't matter which keyboard layout is active when I start nvim, it's always german.

I don't have any language specific environment variables set and tried starting with ´--clean`.

```
Aktuelle Sprache: "LC_COLLATE=de_DE;LC_CTYPE=de_DE;LC_MONETARY=de_DE;LC_NUMERIC=
C;LC_TIME=de_DE"
```

**NOTE that not everything is german. Just parts are, such as the status in the toolbar and some other generic things. Those part are however not german anymore if I explicitly set the language to `en_US`.

### Steps to reproduce

```
scoop install nvim
nvim --clean
```

### Expected behavior

The language should be set to english, but definitely not german, as the system doesn't even have a german language pack.

### Neovim version (nvim -v)

v0.9.4

### Vim (not Nvim) behaves the same?

No, vim works correctly: 7.4

### Operating system/version

Windows 11

### Terminal name/version

Tried multiple (Alacritty, Windows Terminal, WezTerm)

### $TERM environment variable

-

### Installation

scoop
Repository: go
Issue: x/tools/gopls: incorrectly suggests internal/singleflight completion
Labels: gopls,Tools,gopls/imports

Reported from @seankhliao in slack: gopls reported `internal/singleflight` (from std) as a completion candidate, while not working in std.

Though related to unimported completion of standard library candidates, I think this is distinct from #63767. Specifically, I am suspicious of the 'fast path' unimported completion which looks at packages already in the import graph:
https://cs.opensource.google/go/x/tools/+/master:gopls/internal/lsp/source/completion/completion.go;l=1695;drc=7f23bc81dc216f83d56b5256abc053109bf5c58b

@seankhliao can you `go list -deps ./... | grep singleflight` to confirm that this package is in your import graph?
Repository: godot
Issue: Modified replication config of instanced MultiplayerSynchronizer scene doesn't get saved
Labels: bug,topic:multiplayer

### Godot version

v4.1.3.stable.official [f06b6836a]

### System information

Godot v4.1.3.stable - Debian GNU/Linux trixie/sid trixie - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 (nvidia) - Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz (6 Threads)

### Issue description

If one has a scene based on a `MultiplayerSynchronizer` node, its associated `SceneReplicationConfig` can be modified in the editor on instances of that scene.  Doing so changes the config in the MultiplayerSynchronizer's base scene, since the `SceneReplicationConfig` is shared.
If the MultiplayerSynchronizer scene is open in the editor, it gets a `*` marker to indicate it's been changed.  But if said scene is _not_ already open:
- There's no indication that anything needs to be saved;
- Saving the scene which contains the instance will not save the replication config;
- Opening the MultiplayerSynchronizer scene after the fact will *not* show the `*`;
- Running the project will _not_ save the modified MultiplayerSynchonizer scene
- Thus, running the project will _not_ use the modified replication config
- You'll not get any warning about unsaved changes when quitting the editor

This lost me a lot of time and brainpower yesterday, since I could see in the editor that the config was there, but it didn't appear to do anything.  Then I re-opened the editor this morning and the replication config entries I had added the previous day were missing! :confounded: 

Possibly somewhat related to https://github.com/godotengine/godot/issues/80717 and https://github.com/godotengine/godot/issues/74381 (which appear to duplicate each other?)

### Steps to reproduce

1. Create and save a scene with a `MuiltiplayerSynchronizer` as the root node.
2. Create and save another scene which has the previous `MultiplayerSynchronizer` scene instantiated as a child node.
3. Close the `MultiplayerSynchronizer` scene's tab.
4. Add files to VCS (eg. Git)
5. Add a property to the instanced replication config in the UI
6. :warning: The scene has no "changes made" indicator
7. Save the scene anyway
8. "Scene -> Reload saved scene"
9. Run the project
10. :eyes: Notice that the replication config still has the extra property
11. :eyes: Notice that no changes have been made to the files according to the VCS
12. "Project -> Reload current project"
13. :eyes: Notice no warning about unsaved changes
14. :warning: Notice that the replication config doesn't have the extra property any more



### Minimal reproduction project

The repro is simple, but this covers reproduction steps 1-3 if you need: [sync-scene-config.zip](https://github.com/godotengine/godot/files/13328296/sync-scene-config.zip)
Repository: rust
Issue: Error message E0568 doesn't match actual restrictions on auto traits
Labels: A-diagnostics,F-auto_traits

I noticed this while looking at #117829.

### Code

```rust
#![feature(auto_traits)]

struct A {}

auto trait B where
    A: B,
{
}

fn main() {}
```

### Error output

```text
error[E0568]: auto traits cannot have super traits or lifetime bounds
 --> np.rs:5:14
  |
5 |   auto trait B where
  |  ____________-_^
  | |            |
  | |            auto traits cannot have super traits or lifetime bounds
6 | |     A: B,
  | |_________^ help: remove the super traits or lifetime bounds

error: aborting due to previous error

For more information about this error, try `rustc --explain E0568`.
```

### The problem

The error message [E0568](https://doc.rust-lang.org/error_codes/E0568.html) refers to "super traits or lifetime bounds", but this code isn't trying to use either of those features.

I guess the error message should be updated to reflect the actual rule, or split into two error messages. But I'm not sure what the actual rule is for auto traits. No bounds at all, whether directly on the trait or in `where` clauses?

CC @FabianWolff who updated the rule and error message in #89494

### Version

```
rustc 1.75.0-nightly (fdaaaf9f9 2023-11-08)
binary: rustc
commit-hash: fdaaaf9f923281ab98b865259aa40fbf93d72c7a
commit-date: 2023-11-08
host: x86_64-apple-darwin
release: 1.75.0-nightly
LLVM version: 17.0.4
```

@rustbot label +A-diagnostics +f-auto_traits
Repository: godot
Issue: Mouse event handling doesn't work correctly for Area2D when overlaping ColorRect is on CanvasLayer with lower index
Labels: discussion,topic:input

### Godot version

v4.1.3.stable.official [f06b6836a]

### System information

MacOs 14.1 (intel)

### Issue description

I've encountered a potential issue with mouse event handling when using a Sprite with Area2D and CollisionShape2D in conjunction with a CanvasLayer and ColorRect. The setup is as follows:

- A scene containing a Sprite with an attached Area2D and CollisionShape2D.
- The Area2D has a connected input_event signal.
- A CanvasLayer with a ColorRect, where the CanvasLayer has an index of -1, placing the ColorRect behind the sprite.

**Expected behavior:**
The input_event on the Area2D should trigger for all mouse events, regardless of the presence of the ColorRect in the CanvasLayer.

**Current behavior:**
When the ColorRect is added to the scene:

- Left and right mouse button click events are not registered by the Area2D input_event, seemingly blocked or absorbed by the ColorRect.
- However, mouse wheel events are still registered as expected.

**Workaround:**
Setting the Mouse Filter property of the ColorRect to Pass allows the Area2D input_event to receive left and right mouse button events.



### Steps to reproduce

Create a scene with a Sprite that includes Area2D and CollisionShape2D.
Connect an input_event signal on the Area2D.
Add a CanvasLayer with an index of -1.
Place a ColorRect in the CanvasLayer.
Observe that left and right mouse click events on the Sprite do not trigger the input_event, while mouse wheel events do.

### Minimal reproduction project

[area2dButtonEvent.zip](https://github.com/godotengine/godot/files/13328340/area2dButtonEvent.zip)
Repository: godot
Issue: Unordered/ordered list tags don't work in auto-created documentation
Labels: enhancement,documentation

### Godot version

v4.2.beta5.official [4c96e9676]

### System information

Windows 10

### Issue description

When using unordered/ordered lists (with the [ul] or [ol] tags) in documentation, no list will be generated in the resulting help file. Instead, the tags are displayed unprocessed in the help. The tags works correctly in RichTextLabel.



### Steps to reproduce

Write a documentation comment (to a function for example) using the syntax:
```
## This is a test
## [ul]
## line 1
## line 2
## [/ul]
```

This will produce this result in the help file:
```
This is a test [ul] line 1 line 2[/ul]
```

Using [br]after each line doesn't produce the lists either.

### Minimal reproduction project

[doctest.zip](https://github.com/godotengine/godot/files/13328533/doctest.zip)
Repository: storybook
Issue: [Bug]: Storybook Controls doesn't work for `export default function`
Labels: bug,react,has workaround,argtypes,sev:S4

### Describe the bug

Autogeneration of Storybook Controls works properly for the following component declaration:

```tsx
function Component(props: {...}) {...}

export default Component
```

But not for:

```tsx
export default function Component(props: {...}) {...}
```

### To Reproduce

_No response_

### System

```bash
System:
    OS: Windows 11 10.0.22621
    CPU: (6) x64 Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
  Binaries:
    Node: 20.9.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.1.0 - C:\Program Files\nodejs\npm.CMD
    pnpm: 8.10.0 - ~\AppData\Roaming\npm\pnpm.CMD <----- active
  Browsers:
    Edge: Chromium (119.0.2151.58)
  npmPackages:
    @storybook/addon-essentials: 7.5.3 => 7.5.3 
    @storybook/addon-interactions: 7.5.3 => 7.5.3 
    @storybook/addon-links: 7.5.3 => 7.5.3 
    @storybook/blocks: 7.5.3 => 7.5.3 
    @storybook/csf: 0.1.1 => 0.1.1 
    @storybook/nextjs: 7.5.3 => 7.5.3
    @storybook/react: 7.5.3 => 7.5.3
    @storybook/testing-library: 0.2.2 => 0.2.2
    eslint-plugin-storybook: 0.6.15 => 0.6.15
    storybook: 7.5.3 => 7.5.3
```
```


### Additional context

- https://storybook.js.org/docs/react/essentials/controls
- https://github.com/styleguidist/react-docgen-typescript/issues/501
Repository: rust
Issue: Confusing note about trait method signature.
Labels: A-diagnostics,T-compiler

### Code

```Rust
pub struct Point<T> {
    x: T,
}
pub trait MyTrait1 {
    fn fun<T>(&self, p: Point<T>);
}
pub struct MyStruct;
impl<T> MyTrait1 for Point<T> {
    fn fun<T>(&self, p: Point<T>) {
        todo!();
    }
}

fn main() {
    todo!();
}
```


### Current output

```Shell
error[E0403]: the name `T` is already used for a generic parameter in this item's generic parameters
 --> test.rs:9:12
  |
8 | impl<T> MyTrait1 for Point<T> {
  |      - first use of `T`
9 |     fn fun<T>(&self, p: Point<T>) {
  |            ^ already used

error[E0053]: method `fun` has an incompatible type for trait
 --> test.rs:9:25
  |
8 | impl<T> MyTrait1 for Point<T> {
  |      - found type parameter
9 |     fn fun<T>(&self, p: Point<T>) {
  |            -            ^^^^^^^^
  |            |            |
  |            |            expected type parameter `T`, found a different type parameter `T`
  |            |            help: change the parameter type to match the trait: `Point<T>`
  |            expected type parameter
  |
note: type in trait
 --> test.rs:5:25
  |
5 |     fn fun<T>(&self, p: Point<T>);
  |                         ^^^^^^^^
  = note: expected signature `fn(&Point<T>, Point<T>)`
             found signature `fn(&Point<T>, Point<T>)`
  = note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
  = note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0053, E0403.
For more information about an error, try `rustc --explain E0053`.
```


### Desired output

```Shell
sry, have no idea...
```


### Rationale and extra context

I was confused when I noticed the notes:

- expected type parameter 'T', but a different type parameter 'T' was found.
- note: expected signature `fn(&Point<T>, Point<T>)`, but found signature `fn(&Point<T>, Point<T>)`.

It tries to indicate that a different type is found. Based on its own explanation, however, the expected signature with type parameter T is the same as the found signature.

Is there anything that needs to be modified?

### Other cases

_No response_

### Anything else?

_No response_
Repository: rust
Issue: Are publicly re-exported items from a `doc(hidden)` module considered public API?
Labels: T-rustdoc,A-rustdoc-json

Let's look at this example from the doc comment in #117810:
```rust
#[doc(hidden)]
pub mod foo {
    pub struct Bar;
}

pub use foo::Bar;
```

To me, this seems like a public re-export of an intended-to-be-public item. In other words, when I see this code, I expect its `doc(hidden)` semantics to be that it is the _module_ that is hidden, but non-hidden ways to access its contents are public API and "fair game." In my interpretation, if the programmer intended that to not be the case, they could have hidden the re-export (or `pub struct Bar` itself).

If `pub struct Bar` is always considered hidden regardless of re-exports (whether themselves hidden or not), I think that has strange implications for what is and is not public API. In that interpretation, the re-export is public API but the item it points to is not public API ... which is just confusing. It seems like it says "I make it part of the public API that this non-public-API type reserves a name in the public API" and nothing else. That's just strange! What public API operations are allowed over that re-export item? It feels to me like the answer is that the item is "neither here nor there" with respect to being public API or not.

It also seems to risk opening a terrible can of worms with further edge cases:
```rust
mod defn {
    pub struct Example;
}

#[doc(hidden)]
pub mod hide {
    pub use crate::Example as Example;
}

// Here, `Example` is public API.
pub use defn::Example;

// Replace it with the below code and `Example` is no longer public API.
// Worse, we can't distinguish between these two cases via rustdoc JSON,
// so this interpretation would permanently break cargo-semver-checks.
// pub use hide::Example;
```

For these reasons, I think a better interpretation of whether an item is `doc(hidden)` is one based on reachability: if you can reach the item without going through any `doc(hidden)` items (the item itself + any modules and re-exports), it is not hidden. If all paths require going through at least one hidden item, the item is hidden. This is also how visibility works as well — the pub-in-priv trick wouldn't work otherwise — so I think it makes a lot of sense for `doc(hidden)` to work that way too.

_Originally posted by @obi1kenobi in https://github.com/rust-lang/rust/issues/117810#issuecomment-1806850905_
Repository: godot
Issue: Lock selected Node(s) only works on the parents of selected
Labels: topic:editor,needs testing

### Godot version

Godot Engine v4.1.2.stable.official.399c9dc39

### System information

Windows10, Vulkan API 1.3.260 - Forward+

### Issue description

![ezgif-5-f455ede0c6](https://github.com/godotengine/godot/assets/78771410/f3d742c3-ef87-4a2a-86e9-44d6242c0f82)

It doesn't lock all selected nodes

### Steps to reproduce

Create any tree, select some nodes and try to lock them

### Minimal reproduction project

N/A
Repository: godot
Issue: "Make Sub-Resources Unique" dissapear if you select more than one node
Labels: enhancement,topic:editor

### Godot version

4.3 stable

### System information

Windows 10, Vulkan API 1.3.260 - Forward+

### Issue description

If you select more than one node the "Make Sub-Resources Unique" dissapear in the "Manage object properties" botton.

![image](https://github.com/godotengine/godot/assets/78771410/33c49f27-5890-490c-979d-5202d13ec2fa)

![image](https://github.com/godotengine/godot/assets/78771410/af74307a-6893-4c17-a00e-33a7da6b78f8)


I can't see any reason why it would be intended.

### Steps to reproduce

Select several nodes and try to make their sub-resources unique

### Minimal reproduction project

N/A
Repository: PowerToys
Issue: Environment Variables: CPU details
Labels: Product-Environment Variables

### Microsoft PowerToys version

0.75.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Environment Variables

### Steps to reproduce

Open Environment Variables and look for hardware properties under **System**.

### ✔️ Expected Behavior

CPU properties are hardware related and should not be changeable.


### ❌ Actual Behavior

1. Looks like I can change the NUMBER_OF_PROCESSORS or PROCESSOR_REVISION or PROCESSOR_ARCHITECTURE (etc.) at any time
2. I'm seeing PROCESSOR_ARCHITECTURE = AMD64 whilst having a **Intel64 Family 6 Model 58 Stepping 9, GenuineIntel** aka "Intel Core i7-3770"

### Other Software

_No response_
Repository: godot
Issue: Camera3D gizmo does not reflect actual FOV
Labels: bug,topic:editor,topic:3d

### Godot version

v4.1.3.stable.official [f06b6836a]

### System information

Godot v4.1.3.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Ti (NVIDIA; 31.0.15.3713) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

When the project settings viewport width is greater than the height on `Keep Height` or the height is greater than the width on `Keep Width` the camera gizmo shows the incorrect FOV. `Keep Height` uses the camera FOV as the horizontal FOV when it should be using it as vertical FOV and `Keep Width` uses it as the vertical FOV when it should be used as the horizontal FOV.

### Steps to reproduce

1. Create a Camera3D node
2. Create a MeshInstance3D node with BoxMesh
3. Move MeshInstance3D to (-1, 0, 0) (Should be just outside of the camera gizmo)
4. Run scene (MeshInstance3D should be visible even though it is outside the gizmo)

### Minimal reproduction project

[FOV MRP.zip](https://github.com/godotengine/godot/files/13328983/FOV.MRP.zip)
Repository: ollama
Issue: Ollama on FreeBSD
Labels: feature request

Hello there:

      is there any chance to get ollama working on freebsd please??
Repository: rust
Issue: Add input parsing function to standard library
Labels: T-libs-api,C-feature-request

Willing to submit the PR myself with guidance.  Here's my idea:
```rust
use std::io::{self, Write};
use std::str::FromStr;
use std::fmt::{self, Debug, Display, Formatter};
use std::error::Error;

/// Custom error type for input function.
#[derive(Debug)]
pub enum InputError {
    IoError(io::Error),
    ParseError(String),
}

impl Display for InputError {
    fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result {
        match self {
            InputError::IoError(e) => write!(f, "IO error: {}", e),
            InputError::ParseError(e) => write!(f, "Parse error: {}", e),
        }
    }
}

impl Error for InputError {}

impl From<io::Error> for InputError {
    fn from(e: io::Error) -> Self {
        InputError::IoError(e)
    }
}

/// A function similar to Python's `input`, allowing for a prompt and reading a line from stdin.
/// 
/// # Arguments
///
/// * `prompt` - An optional prompt to display before reading input.
/// * `flush` - Whether to flush stdout after displaying the prompt.
/// 
/// # Errors
///
/// This function will return an error if there's an issue with reading from stdin
/// or parsing the input into the desired type.
pub fn input<T: FromStr>(prompt: Option<&str>, flush: bool) -> Result<T, InputError>
where
    T::Err: Display {
    if let Some(p) = prompt {
        print!("{}", p);
        if flush {
            io::stdout().flush()?;
        }
    }

    let mut input = String::new();
    match io::stdin().read_line(&mut input) {
        Ok(0) => Err(InputError::IoError(io::Error::new(io::ErrorKind::UnexpectedEof, "EOF reached"))),
        Ok(_) => input.trim().parse::<T>().map_err(|e| InputError::ParseError(e.to_string())),
        Err(e) => Err(e.into()),
    }
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn get_int() {
        let i: i32 = input(None, false).unwrap();
        println!("{}", i);
        let j: i32 = input(None, true).unwrap();
        println!("{}", j);

    }

    #[test]
    fn get_int_2() {
        let i: i32 = input(Some("Input: "), false).unwrap();
        print!("Output: {}", i);
    }

    #[test]
    fn hacker_rank() {
        let s: String = input(None, true).unwrap();
        println!("hello, {}", s);
    }

}
```
Repository: godot
Issue: `SubViewportContainer` has limited mouse-cursor support
Labels: bug,enhancement,topic:gui

### Godot version

v4.2.beta.custom_build [e5bacbc47]

### System information

Debian Linux X11 Xfce

### Issue description

`SubViewportContainer` currently doesn't set Mouse Cursor, in order to let the content of the SubViewport set the mouse cursor.

This behavior was introduced while resolving #74805. A more elaborate solution needs to be implemented, in order to solve all use-cases.

Original mention of this issue: https://github.com/godotengine/godot/pull/79805#issuecomment-1652129321

After fixing this issue, #84661 needs to be reevaluated again.

See for details: https://github.com/godotengine/godot/pull/84661#pullrequestreview-1723141984

### Steps to reproduce

SceneTree:
- SubViewportContainer with a MouseCursor not Arrow
  - SubViewport without any children-nodes.

When hovering over the SubViewportCintainer, the specified MouseCursor doesn't show.

### Minimal reproduction project

n/a at the moment
Repository: rust
Issue: Error suggestion modifies `#[derive(foo)]` to `#[derive(foo.to_string())]`
Labels: A-diagnostics,A-macros,T-compiler,C-bug,A-suggestion-diagnostics,D-invalid-suggestion,A-proc-macros

### Code

```Rust
use serde::{Serialize, Serializer};

#[derive(Serialize)]
pub struct Data {
    #[serde(serialize_with = "ser")]
    pub value: String,
}

// This function has `String` instead of `&String`, causing compilation error
fn ser<S: Serializer>(v: String, s: S) -> Result<S::Ok, S::Error> {
    s.serialize_none()
}
```


### Current output

```Shell
error[E0308]: mismatched types
 --> src/lib.rs:3:10
  |
3 | #[derive(Serialize)]
  |          ^^^^^^^^^- help: try using a conversion method: `.to_string()`
  |          |
  |          expected `String`, found `&String`
4 | pub struct Data {
5 |     #[serde(serialize_with = "ser")]
  |                              ----- arguments to this function are incorrect
  |
note: function defined here
 --> src/lib.rs:9:4
  |
9 | fn ser<S: Serializer>(v: String, s: S) -> Result<S::Ok, S::Error> {
  |    ^^^                ---------
  = note: this error originates in the derive macro `Serialize` (in Nightly builds, run with -Z macro-backtrace for more info)
```


### Desired output

```Shell
?
```


### Rationale and extra context

The error message suggests auto-appliable `#[derive(Serialize.to_string())]` -- clearly an error

### Other cases

```Rust
I have also observed similar but somewhat different error messages when the value type is my own `struct` type rather than a `String`.
```


### Anything else?

_No response_