sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: ollama
Issue:  Pleias
Labels: model request

[Pleias has been announced!](https://huggingface.co/blog/Pclanglais/common-models) An LLM trained only on text it's allowed to train on.

It would be fantastic to have this available in ollama, especially for us folks using computers with plenty of system RAM but barely any VRAM.


Here's a list of the models: https://huggingface.co/collections/PleIAs/common-models-674cd0667951ab7c4ef84cc4
Repository: deno
Issue: Ability to read the current stdin raw options so that setRaw() can be part of a reversible transaction
Labels: public API,suggestion

I want to create an operation that uses raw input from stdin, but then resets it afterwards to whatever it was when the operation started. In other words, if it was already raw, then it should remain raw. If it was not, then it should be reset to be not raw. The same applies for the value of the raw options: e.g. {cbreak: true }

However, raw options are currently write-only and there is no way to get the current state that it should be set back to. I imagine it would look something like:

```ts
let originalRawOptions = Deno.stdin.getRawOptions();

try {
  Deno.stdin.setRaw(true, { cbreak: true });
  // do stuff
} finally {
  Deno.stdin.setRaw(...originalRawOptions)
}
```

See [`ReadStream.isRaw](https://nodejs.org/api/tty.html#readstreamisraw) for a similar API in Node
Repository: vscode
Issue: Characters go into each other with fontLigatures and RTL characters.
Labels: bug,editor-core,editor-rendering

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.93.1
- OS Version: NixOS 24.05 (not relevant)

Steps to Reproduce:

1. Set the font to `FiraCode`
2. Enable `editor.fontLigatures`
3. Type or copy `سلام ===` into the editor.
4. See that characters go into each other:

![Image](https://github.com/user-attachments/assets/a6324377-dd36-47e5-b389-e81c8faeaa74)

The desired output is something like this:

![Image](https://github.com/user-attachments/assets/ffc668fd-ca33-45a7-98f0-863e34d8f75c)
Repository: godot
Issue: Setting Control `size` doesn't update when difference is small
Labels: bug,confirmed,regression,topic:gui

### Tested versions

- Reproducible in: v4.3.stable.official [77dcf97d8], v4.4.dev6.official [1f47e4c4e]

### System information

Godot v4.4.dev6 - Debian GNU/Linux trixie/sid trixie on Wayland - X11 display driver, Multi-window, 2 monitors - Vulkan (Forward+) - dedicated AMD Radeon RX 7600 (RADV NAVI33) - AMD Ryzen 5 7600 6-Core Processor (12 threads)

### Issue description

If one tries to set the `size` of a `Control` to something which is nearly, but not quite, the same as its current `size`, nothing happens.

Eg. when the `size` is `(463.9962, 44)`, setting it to `(464, 44)` does nothing. This can leave UI elements slightly off:

![Image](https://github.com/user-attachments/assets/3ba913b1-58ef-44c4-9fa5-b11f5897d802)

I hit this when interpolating one control's position and size to another.  When the two controls are close enough together, the interpolating control's `size` is set to the target control's `size`. However, sometimes the interpolating Control would stop at a point slightly smaller than the target.

I've worked around it for now by adding and them immediately removing a larger value:

```gdscript
if size.is_equal_approx(target_size):
    size = target_size + Vector2.ONE
    size -= Vector2.ONE
```

EDIT: I've just noticed that this seems to also affect `Control.position`.

### Steps to reproduce

Create a scene with a `Control` node, anchor it to top-left (to avoid some warnings), and attach this script:

```gdscript
extends Control

func _ready() -> void:
	size = Vector2(120, 40.0003)
	print("start => ", size)
	size.y = 40
	print("40 => ", size)
	size = Vector2(120, 40)
	print("(120, 40) => ", size)
	size = Vector2(121, 40)
	print("(121, 40) => ", size)
```
Output:
```
start => (120.0, 40.0003)
40 => (120.0, 40.0003)
(120, 40) => (120.0, 40.0003)
(121, 40) => (121.0, 40.0)
```

### Minimal reproduction project (MRP)

n/a
Repository: TypeScript
Issue: Discriminating property with never as possible type makes its enclosing object type disappear when narrowing
Labels: Suggestion,In Discussion

### 🔎 Search Terms

discriminated union never, discriminating property never 

### 🕗 Version & Regression Information

It happens in every version I tried.

### ⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.8.0-dev.20241206#code/C4TwDgpgBAIglgZwMYFUB2cD2aoF4BQAPlAN5QAmiSACgE6ZgBcUaEAbhLQDRQCGzARigBfIqQpU6DZgCIw9MDJ4AjZgCYRYspWRSmUAK5pyEAGZxW5HkmYBmTfhNIANr1rQk2BMCiZm8ZHQsNHx8OFMACkwAOh0aBQBKUnwoXxSoAHoMqAA9AH58YSgIZwRoEnTMdKzcgtEwyIBCGLi9JIrUqtSa-MLi0vLK6uze4SA

### 💻 Code

```ts
type DiscUnion =
| { discProp: never, a: 1 }
| { discProp: "prop", b: 2 }
| { discProp: undefined, c: 3 }

declare const o: DiscUnion

if(o.discProp) {
  o
  // ^? { discProp: "prop"; b: 2; }
} else {
  o
  // ^? { discProp: undefined; c: 3; }
}

if(!o.discProp) {
  o
  // ^? { discProp: undefined; c: 3; }
} else {
  o
  // ^? { discProp: "prop"; b: 2; }
}
```


### 🙁 Actual behavior

`{ discProp: never, a: 1 }` disappears!

### 🙂 Expected behavior

In the first `if`, I expect `{ discProp: never, a: 1 }` to be a possible type of `o` in the `else` branch. Viceversa, in the second `if` I expect it to be a possible type of `o` in the `then` branch.

### Additional information about the issue

_No response_
Repository: rust
Issue: Tracking issue for release notes of #130190: [discussion] `ErrorKind::FilesystemQuotaExceeded` from `io_error_more`
Labels: T-libs-api,relnotes,relnotes-tracking-issue


This issue tracks the release notes text for #130190.

### Steps

- [ ] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Stabilized APIs
- [`io::ErrorKind::QuotaExceeded`](https://doc.rust-lang.org/stable/std/io/enum.ErrorKind.html#variant.QuotaExceeded)
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @GrigorenkoPV -- origin issue/PR authors and assignees for starting to draft text
Repository: rust
Issue: Tracking issue for release notes of #130191: [discussion] `ErrorKind::CrossesDevices` from `io_error_more`
Labels: T-libs-api,relnotes,relnotes-tracking-issue


This issue tracks the release notes text for #130191.

### Steps

- [ ] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Stabilized APIs
- [`io::ErrorKind::CrossesDevices`](https://doc.rust-lang.org/stable/std/io/enum.ErrorKind.html#variant.CrossesDevices)
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @GrigorenkoPV -- origin issue/PR authors and assignees for starting to draft text
Repository: rust
Issue: Adding `lto = true` causes duplicated symbol errors on `.weak` symbols
Labels: A-linkage,A-inline-assembly,T-compiler,C-bug,A-LTO

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

Here's a minimal reproducer for the issue described in the title.

`.cargo/config.toml`:
```toml
[build]
target = "riscv32imc-unknown-none-elf"

[unstable]
build-std = ["core,panic_abort"]
```
`memory.x` (exact contents unimportant, but provided for convenience):
```
MEMORY
{
  IMEM : ORIGIN = 0x80000000, LENGTH = 1024K
  DMEM : ORIGIN = 0x10000000, LENGTH = 256K
}

REGION_ALIAS("REGION_TEXT", IMEM);
REGION_ALIAS("REGION_RODATA", DMEM);
REGION_ALIAS("REGION_DATA", DMEM);
REGION_ALIAS("REGION_BSS", DMEM);
REGION_ALIAS("REGION_HEAP", DMEM);
REGION_ALIAS("REGION_STACK", DMEM);
```
`build.rs`:
```rs
use std::env;
use std::fs;
use std::path::Path;

fn main() {
    let out_dir = env::var("OUT_DIR").expect("No out dir");
    let dest_path = Path::new(&out_dir).join("memory.x");
    fs::write(dest_path, include_bytes!("memory.x")).expect("Could not write file");

    if env::var("CARGO_CFG_TARGET_ARCH").unwrap() == "riscv32" {
        println!("cargo:rustc-link-arg=-Tmemory.x");
        println!("cargo:rustc-link-arg=-Tlink.x");
    }
    println!("cargo:rustc-link-search={out_dir}");

    println!("cargo:rerun-if-changed=memory.x");
    println!("cargo:rerun-if-changed=build.rs");
}
```
`src/main.rs`:
```rs
#![no_std]
#![no_main]

use riscv_rt::entry;

#[entry]
fn main() -> ! {
    loop {}
}

#[panic_handler]
fn panic_handler(_: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[unsafe(export_name = "ExceptionHandler")]
fn exception_handler(_: &riscv_rt::TrapFrame) -> ! {
    loop {}
}

#[unsafe(export_name = "DefaultHandler")]
fn default_handler(_: &riscv_rt::TrapFrame) -> ! {
    loop {}
}
```
`Cargo.toml`:
```toml
[package]
name = "lto-bug-repro"
version = "0.1.0"
edition = "2021"

[profile.release]
lto = true # Commenting out this line should allow it to compile successfully

[dependencies]
riscv-rt = "0.13.0"
```

As is documented in `riscv-rt`, `ExceptionHandler` and `DefaultHandler` are weak symbols, and I verified in the source code for the crate that they're marked with `.weak` in `global_asm!` ([relevant src](https://docs.rs/crate/riscv-rt/0.13.0/source/src/asm.rs#263-270)). What I don't understand is why enabling `lto = true` causes the build to fail with the errors
```
error: DefaultHandler changed binding to STB_GLOBAL

error: symbol 'DefaultHandler' is already defined

error: ExceptionHandler changed binding to STB_GLOBAL

error: could not compile `lto-bug-repro` (bin "lto-bug-repro") due to 3 previous errors
```
I also have no idea how to track down what's causing this.
Repository: rust
Issue: Tracking issue for release notes of #132187: Add Extend impls for tuples of arity 1 through 12
Labels: T-libs-api,relnotes,relnotes-tracking-issue


This issue tracks the release notes text for #132187.

### Steps

- [ ] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Stabilized APIs
- [impl std::iter::Extend for tuples with arity 1 through 12](https://doc.rust-lang.org/stable/std/iter/trait.Extend.html#impl-Extend%3C(A,)%3E-for-(EA,))
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @shahn, @dtolnay -- origin issue/PR authors and assignees for starting to draft text
Repository: godot
Issue: [4.3] VRAM compressed textures import at extremely low quality
Labels: bug,topic:import

### Tested versions

v4.3.stable.official [77dcf97d8]

### System information

Windows 10 - Godot v4.3 stable - Vulkan Forward+ renderer. nVidia GTX 1080. 16GB RAM. Intel Core i5-4690K CPU @ 3.50GHz.

### Issue description

Importing textures intended for 3D models using the default VRAM compressed mode (with "high quality" turned off) produces extremely low quality results; worse than they should be. This is particularly noticeable with textures 1024 pixels square and lower.

As an example, below is a container prop with an ORM material applied and 512 x 512 textures. Godot has converted the ORM and base colour to DXT1 and the normal map to RGTC. The texture should appear as mostly yellowy orange with some light edge wear exposing the underlying metal. Due to the low quality of the texture compression, however, the edge wear displays as large, blocky green blotches along all the mesh edges.

![Image](https://github.com/user-attachments/assets/9a6f595d-9457-4a1b-ae50-2a395ecbaf89)

Below is the original source file for the base colour, in PNG format.

![Image](https://github.com/user-attachments/assets/fb1365cd-a32c-484e-9edc-a87b61e40cd6)

For comparison, here's the same texture run through nVidia's DXT Tools at the default settings. The below image was saved to DDS, then converted to PNG for upload.

![Image](https://github.com/user-attachments/assets/b4909cad-aab3-4c6a-a6eb-0b2785d2325d)

Note how the compression artifacts are barely visible.

Below is another example, this time run through an online image converter called [Convertio](https://convertio.co/dds-converter/). While the quality is not quite as good as nVidia's, the results are significantly better than Godot's own.

![Image](https://github.com/user-attachments/assets/852ab0b0-20e8-474d-af32-a78d85b2e45c)

Here is the container again, only this time with the base colour texture replaced with the Convertio version. Notice how the green discolouration is completely gone.

![Image](https://github.com/user-attachments/assets/56bbf629-51d7-4773-98fb-765c0be94bed)


### Steps to reproduce

1. Right-click and download the above source base colour texture for the crate. Drop it into a Godot project and set the compress mode to VRAM compressed
2. Create a MeshInstance3D, assign it a plane mesh, a material, and assign this texture as the base colour
3. Use any suitable image converter (Convertio is a good choice if you wish to exactly replicate my results) to convert the PNG to DDS yourself, then add the DDS to the project
4. Create a new MeshInstance3D, assign it another plane mesh and material then assign this new texture to the base colour
5. Observe the quality difference between the two examples

### Minimal reproduction project (MRP)

N/A
Repository: vscode
Issue: Brackets Snippet deleting chars
Labels: bug,snippets

Brackets Snippet in replace mode deletes char when prefix already exists
![Image](https://github.com/user-attachments/assets/70acd3cb-be83-486f-a9bd-9acd809b45c4)

Steps to Reproduce:

1. Set `editor.suggest.insertMode` to `replace`
1. Create new global snippet `workbench.action.openSnippets`
```jsonc
{
	"Brackets": {
		"scope": "plaintext",
		"prefix": "()",
		"body": "()",
		"description": "Set `editor.suggest.insertMode` to `replace`\nWhen `()` already exists, the snippet deletes the next following char\n "
	}
}
```
2. Create new `plaintext` file with example text
```
()!!
()  
()aa
```
3. Place cursor in-between brackets
4. Press ctrl+space and select `Brackets` Snippet

Expected:
nothing
(Cursor moves 1 to the right)
![Image](https://github.com/user-attachments/assets/5b1c21c8-0ecc-4593-9c10-505f995e9880)

Actual:
1 character is deleted after the `()` 🐛
doesn't matter if the char is a `wordPattern` or `wordSeparator` or `whitespace`
![Image](https://github.com/user-attachments/assets/26548e46-133c-4f66-94df-4d06c23c6579)



Notice that using other characters other than brackets `()` does **not** result in chars being deleted

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.95.3
- OS Version: Windows 11
Repository: vscode
Issue: Automatically dismiss messages
Labels: feature-request,workbench-notifications

<!-- ⚠️⚠️ 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. -->

![Image](https://github.com/user-attachments/assets/ca488ea1-9074-478a-89e2-ee3fd6fb324e)

How can i configure a timeout to get rid of these? its annoying to constantly click the X.
Repository: go
Issue: x/tools/gopls: invoking source.addTest from CLI fails with ENOENT
Labels: gopls,Tools

While working on https://go.dev/cl/634197, I tried the new "Add test for function 'fingerprint'" code action within Emacs+eglot, and got an unhelpful "Internal error". I tried it again from the gopls CLI, and got a different error:
```
$ gopls codeaction -kind=source.addTest -exec ./gopls/internal/cache/methodsets/fingerprint.go:54
gopls: edits not applied because of getFile: file:///Users/adonovan/w/xtools/gopls/internal/cache/methodsets/fingerprint_test.go: open /Users/adonovan/w/xtools/gopls/internal/cache/methodsets/fingerprint_test.go: no such file or directory
```

Then I tried it from VS Code, and it worked great. (That said, the code action was not visible in the Command-. quick menu, and had to be selected from the right-click > Source Actions... menu. We should reinvestigate the endlessly fiddly algorithm that governs this.)

So, I don't think there's a bug in gopls' Code Action or command handler, but there is in the CLI, and in Eglot, and perhaps they are related.
Repository: godot
Issue: Create Physical Skeleton option doesn't care parent node scale
Labels: bug,topic:editor,topic:3d

### Tested versions

- Functionality broken after => 4.3dev3 (4.3dev4/dev5/dev6)
- Works as intended < 4.3dev2 (dev1, 4.2)

### System information

win 10 :  forward + : rtx4060

### Issue description

After Using the Create Physical Skeleton on a Sekelton3D the bone (PhysicalBone3D) collision shape (CollisionShape3D) sizes are out of proportion
4.3dev2:
![4.3dev2](https://github.com/user-attachments/assets/d9692b03-f806-4d2c-9fc9-46e1e5bef0f9)  

4.3dev3:
![Image](https://github.com/user-attachments/assets/066cc377-b557-4d79-8637-bb607eb8ec16)




### Steps to reproduce

From 3d model .glb -> New Inherited Scene -> Skeleton3D ->Create Physical Skeleton

*used mixamo to get a model (.fbx) -> blender -> export as glTF 2.0

### Minimal reproduction project (MRP)

[repro.zip](https://github.com/user-attachments/files/18042919/repro.zip)
model used ^
New Inherited Scene -> Skeleton3D ->Create Physical Skeleton
Repository: rust
Issue: "error[E0106]: missing lifetime specifiers" suggests creating unusable `&'a mut Foo<'a>` references
Labels: A-diagnostics,T-compiler

### Code

```Rust
struct Borrowed<'a>(&'a ());
struct Transformed<'a>(&'a ());

fn foo(_borrowed: &mut Borrowed) -> &mut Transformed {}
```

### Current output

```Shell
error[E0106]: missing lifetime specifiers
 --> src/lib.rs:4:37
  |
4 | fn foo(_borrowed: &mut Borrowed) -> &mut Transformed {}
  |                   -------------     ^    ^^^^^^^^^^^ expected named lifetime parameter
  |                                     |
  |                                     expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say which one of `_borrowed`'s 2 lifetimes it is borrowed from
help: consider introducing a named lifetime parameter
  |
4 | fn foo<'a>(_borrowed: &'a mut Borrowed<'a>) -> &'a mut Transformed<'a> {}
  |       ++++             ++             ++++      ++                ++++
```

### Desired output

```Shell
error[E0106]: missing lifetime specifiers
 --> src/lib.rs:4:37
  |
4 | fn foo(_borrowed: &mut Borrowed) -> &mut Transformed {}
  |                   -------------     ^    ^^^^^^^^^^^ expected named lifetime parameter
  |                                     |
  |                                     expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but the signature does not say which one of `_borrowed`'s 2 lifetimes it is borrowed from
help: consider introducing two named lifetime parameters
  |
4 | fn foo<'short, 'long>(_borrowed: &'short mut Borrowed<'long>) -> &'short mut Transformed<'long> {}
  |       +++++++++++++++             ++++++             +++++++      ++++++                +++++++
```

### Rationale and extra context

This error trips up many new Rustaceans, and the suggestion creates [unusable references](https://quinedot.github.io/rust-learning/pf-borrow-forever.html) which just leads to errors that cannot be resolved.

Recent example in the wild: https://users.rust-lang.org/t/how-to-reuse-a-mutably-borrowed-variable-in-rust-after-passing-it-to-a-function/122153

### Other cases

```Rust

```

### Rust Version

```Shell
$ rustc --version --verbose
rustc 1.85.0-nightly (c94848c04 2024-12-05)
binary: rustc
commit-hash: c94848c046d29f9a80c09aae758e27e418a289f2
commit-date: 2024-12-05
host: aarch64-apple-darwin
release: 1.85.0-nightly
LLVM version: 19.1.5
```

### Anything else?

The erroneous suggestion is the same on the current latest stable, 1.83.0.