sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: x/crypto/ssh: allow the client to automatically detect host key algorithms
Labels: Proposal,Proposal-Crypto

### Proposal Details

If `ClientConfig.HostKeyAlgorithms` is not set, a reasonable default is set for acceptable host key type, which may be one for which you do not have a matching host key provided using `ClientConfig.HostKeyCallback`.

If our users don't set `ClientConfig.HostKeyAlgorithms` we should try to obtain the expected algorithms from the configured `ClientConfig.HostKeyCallback`.

To enable this automatic detection, I propose to add a new error that `HostKeyCallback` implementations can return to inform about supported algorithms:

```
// HostKeyCallbackError may be returned from [HostKeyCallback] implementations
// to inform about supported host key algorithms. If no [ClientConfig]
// HostKeyAlgorithms are set, the [Client] will execute the callback with a
// non-existent key type to discover and use the expected algorithms. For
// ssh-rsa key format we suggest returning sha-2 variants of the algorithms.
type HostKeyCallbackError struct {
	// HostKeyAlgorithms lists the public key algorithms that the callback will
	// accept.
	HostKeyAlgorithms []string
}
```

It is preferable to return `HostKeyAlgorithms` and not the key formats because this way implementations can decide, for example, to return only the sha-2 variants for the `ssh-rsa` key format.

if `ClientConfig.HostKeyAlgorithms` is not set, our client will execute the callback passing a sentinel, non-existent, key type and, if the error returned is an `HostKeyCallbackError`, the returned host key algorithms are used.

We should return `HostKeyCallbackError` in our internal `HostKeyCallback` implementations:

- ssh.FixedHostKey
- knownhosts.New
Repository: ui
Issue: [bug]: Checking the checkbox in data table increases height of rows.
Labels: bug

### Describe the bug

### Issue
On checking the `CheckBox` component in the `Data Table`, the height of rows increases.

### My Solution
The `Checkbox` component contains the following code:
```typescript
"use client"

import * as React from "react"
import * as CheckboxPrimitive from "@radix-ui/react-checkbox"
import { Check } from "lucide-react"

import { cn } from "@/lib/utils"

const Checkbox = React.forwardRef<
  React.ElementRef<typeof CheckboxPrimitive.Root>,
  React.ComponentPropsWithoutRef<typeof CheckboxPrimitive.Root>
>(({ className, ...props }, ref) => (
  <CheckboxPrimitive.Root
    ref={ref}
    className={cn(
      "peer h-4 w-4 shrink-0 rounded-sm border border-primary ring-offset-background focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-primary data-[state=checked]:text-primary-foreground",
      className,
    )}
    {...props}
  >
    <CheckboxPrimitive.Indicator
      className={cn("flex items-center justify-center text-current")}
    >
      <Check className="h-4 w-4" />
    </CheckboxPrimitive.Indicator>
  </CheckboxPrimitive.Root>
))
Checkbox.displayName = CheckboxPrimitive.Root.displayName

export { Checkbox }

```
Changing the following line
```typescript
  <Check className="h-4 w-4" />
```
to
```typescript
  <Check className="h-3 w-3" />
```
fixes the issue.

I don't know if this solution messes up the implementation of `Checkbox` in any other case. If this seems an acceptable solution, I would like to be assigned this issue. I would create a PR with the above-mentioned solution.

### Affected component/components

Data Table

### How to reproduce

Implement the demo table on https://ui.shadcn.com/docs/components/data-table.
OR
Check out the StackBlitz link provided.

### Codesandbox/StackBlitz link

https://stackblitz.com/edit/stackblitz-starters-rx7yav?file=app%2Fpage.tsx

### Logs

_No response_

### System Info

```bash
System: Macbook M1
Issue is seen in the following browsers: Chrome, Brave, Safari, Firefox
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: rust
Issue: Tracking Issue for `nonzero_bitwise`
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(nonzero_bitwise)]`
ACP: https://github.com/rust-lang/libs-team/issues/413

This is a tracking issue for bitwise and bytewise methods on `NonZero`. When used on a non-zero integer, these methods result in a non-zero integer, so can take the form `fn(self) -> Self`.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::num

impl<T> NonZero<T> {
    pub fn reverse_bits(self)  -> Self;
    pub fn rotate_left(self) -> Self;
    pub fn rotate_right(self) -> Self;
    pub fn swap_bytes(self) -> Self;
    pub fn to_be(self) -> Self;
    pub fn to_le(self) -> Self;
    pub fn from_be(x: Self) -> Self;
    pub fn from_le(x: Self) -> Self;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #128282
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: rust
Issue: Effective breakage to `jiff` due to `ambiguous_negative_literals`
Labels: T-lang,C-discussion,I-lang-radar

We should discuss this bit of evidence that came in after the FCP completed on:

- https://github.com/rust-lang/rust/pull/121364

@BurntSushi [said](https://github.com/rust-lang/rust/issues/121364#issuecomment-2254136058):

> This completely broke Jiff once the change landed. Because it specifically supports negating spans like `-1.hour()`. [In the case of Jiff, there is no ambiguity because `-1.hour()` and `(-1).hour()` and `-(1.hour())` are all precisely equivalent.](https://docs.rs/jiff/latest/jiff/struct.Span.html#negative-spans)

cc @BurntSushi @rust-lang/lang

@rustbot labels +T-lang +I-lang-nominated
Repository: frp
Issue: [Feature Request] dedicated secrets file
Labels: todo,proposal

### Describe the feature request

Rather than only having the option for `auth.token = <value>` (e.g. `auth.token = "thisismysecret"`) in the config, it would be ideal to have the option to say `auth.token_file = <path>`. (e.g., `auth.token_file = /var/lib/secrets/frp_token`.) The token secrets can then be loaded from those files by frp during initialization.

Putting a secrets file in a dedicated location is a useful standard for segregating secrets in their own directory, thus reducing the likelihood of mistakes when configuring file system permissions & file scope. It also reduces the likelihood of leaks if, e.g., someone is committing their configuration into version control / git (such as is de facto necessary in some workflows, such as NixOS).

### Describe alternatives you've considered

_No response_

### Affected area

- [ ] Docs
- [ ] Installation
- [ ] Performance and Scalability
- [X] Security
- [ ] User Experience
- [ ] Test and Release
- [ ] Developer Infrastructure
- [ ] Client Plugin
- [ ] Server Plugin
- [ ] Extensions
- [ ] Others
Repository: rust
Issue: Tracking Issue for `float_semantics` RFC 3514
Labels: B-RFC-approved,T-lang,C-tracking-issue,F-float_semantics

This is a tracking issue for RFC 3514:

- https://github.com/rust-lang/rfcs/pull/3514

The feature gate for the issue is `#![feature(float_semantics)]`.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.  They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.  A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.  Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Accept an RFC.
  - https://github.com/rust-lang/rfcs/pull/3514
- [x] Update library documentation.
  - https://github.com/rust-lang/rust/pull/129559
- [ ] Add documentation to the [reference][].
  - See the [instructions][reference-instructions].
- N/A: Add formatting for new syntax to the [style guide][].
  - See the [nightly style procedure][].
- [ ] Stabilize.
  - https://github.com/rust-lang/rust/pull/128596

[dev guide]: https://github.com/rust-lang/rustc-dev-guide
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[edition guide]: https://github.com/rust-lang/edition-guide
[nightly style procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md
[reference]: https://github.com/rust-lang/reference
[reference-instructions]: https://github.com/rust-lang/reference/blob/master/CONTRIBUTING.md
[stabilization-instructions]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[style guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions

- [ ] Should we be concerned that LLVM does [not actually document](https://github.com/llvm/llvm-project/issues/60942) that it uses IEEE float semantics? It does assume IEEE semantics in its own optimization passes.
- [ ] Are there any other targets with floating-point trouble?
- [ ] What exactly is the set of "extra" NaNs for all remaining targets?
- [ ] To what extend does this specification apply to platform intrinsics? On the one hand, it seems reasonable to expect platform intrinsics to have the behavior of the platform instructions. On the other hand, we implement some platform intrinsics with the portable LLVM `simd` intrinsics, and those are subject to the NaN-non-determinism described above. So the current de-facto semantics of at least some platform intrinsics is that they do *not* match what the platform does.

### Related

TODO.

cc @RalfJung @rust-lang/lang
Repository: godot
Issue: iPhone autoload script _ready method should not be called until after main scene loaded
Labels: bug,platform:ios,needs testing

### Tested versions

Tested on v4.2.2.stable.official [15073afe3]

### System information

iOS 17.5.1 (21F90)

### Issue description

In trying to port my game that works fine on Linux (where originally developed) and Android (one of the target platforms) to IOS (iPhone in particular), I ran into a problem with my scene changing logic.  This logic was based on the example code in the Godot Docs.

This is what my _ready function looks like in Global.gd

```
func _ready():
	var root = get_tree().root
	current_scene = root.get_child(root.get_child_count() - 1)
	for i in range(0, root.get_child_count()):
		print("%d: scene name=%s" % [ i, root.get_child(i).name ])
```

Running on Mac produces the same load order as Linux or Android.
I have 4 autoloader scripts: Global, Scores, Music, and Tutorial
The main script is: start_menu

0: scene name=Global
1: scene name=Scores
2: scene name=Music
3: scene name=Tutorial
4: scene name=start_menu

The result on my test iPhone device is:

0: scene name=Global
0: scene name=Global

This is clearly inconsistent with the Docs which say that autoloaded scripts are before the main scene with the implication that the ready method is called after all autoloader and main scripts are in the tree.

### Steps to reproduce

1. Create an autoloader script and a main script.
2. Dump the names of the scenes in the get_tree().root in the _ready() method of the autoloader script

- Expected: main scene is the last entry in the list
- On IOS the _ready method of the autoloader called before the main script got added.
 



### Minimal reproduction project (MRP)

[a.zip](https://github.com/user-attachments/files/16401667/a.zip)
Repository: svelte
Issue: Svelte 5: only block root tags are checked for being closed
Labels: bug,awaiting submitter

### Describe the bug

~The error of the non-closed tag isn't emitted for the content of the implicit `children` snippet.~
Only block (component root or any `{#*}` block) root tags are checked for being closed, while nested tags aren't checked. Components seem to be excluded from the "block" definition here.

### Reproduction

[REPL](https://svelte-5-preview.vercel.app/#H4sIAAAAAAAAA41Qy07DMBD8lcXikIimj2tJIhCfQTgEZ9NadbyWvalAlv8du5ECiAuHlb07M-vxBDEqjV4cX4Mw_YTiKJ6tFRvBnzY3_oqaMfWeZifzpPbSKcttZzpWkyXH8ELpNGgYRkcTdGK7W0fbZUMnMj-XRgZJcyI3cO-5Zyz25WNCEjbORrIiA8pIh1OSFyWEm5IXzUMDh0zm2Jl6923F1OuLN2e1dXRy6D1M_Udz2MO11zM24bYltlDfVRUQWb-BkdyJGJhAavIIfE7Vn6Cqlk3vM3OyREZqJS9NWL3FNl3r3YK32c9PDymziQY1KhzEkd2McbNGvPL-G3QOLYA8Kz04NBBzdumH1hflrxzCU4IHdCu1KONfI2_xC2ToIJr3AQAA)

### Logs

_No response_

### System Info

```shell
Svelte 5
```


### Severity

annoyance
Repository: ollama
Issue: API returns 403 Forbidden when Origin http header is set
Labels: bug

### What is the issue?

When an API call with the Origin http header is made, ollama responds with 403 Forbidden. Applications such as [chatGPTBox](https://github.com/josStorer/chatGPTBox) use this header and thereby trigger the issue.

Example command that fails:

$ curl http://localhost:11434/v1/chat/completions \
    -H "Content-Type: application/json" -H "Origin: abc" \
    -d '{
        "model": "llama3.1",
        "messages": [
            {
                "role": "system",
                "content": "You are a helpful assistant."
            },
            {
                "role": "user",
                "content": "Hello!"
            }
        ]
    }'

### OS

Linux

### GPU

Nvidia

### CPU

AMD

### Ollama version

0.2.5
Repository: transformers
Issue: Support loading shard GGUF models
Labels: Feature request

### Feature request

- Support loading from sharded GGUF model files (For example, [legraphista/Meta-Llama-3.1-70B-Instruct-IMat-GGUF](https://huggingface.co/legraphista/Meta-Llama-3.1-70B-Instruct-IMat-GGUF/tree/main)).

### Motivation

- For some large models, the GGUF format model will be split into multiple shards during converting. 
- However, the GGUF integration in `transformers` only supports single file GGUF model currently.

### Your contribution

- This kind of GGUF model has been split into multiple shards, formatted as `<ShardNum>-of-<ShardTotal>`, just like sharded `safetensors`. 
- The header for config and tokenizer handing are kept in the first shard file (For example, [Meta-Llama-3.1-70B-Instruct.Q5_K-00001-of-00003.gguf](https://huggingface.co/legraphista/Meta-Llama-3.1-70B-Instruct-IMat-GGUF/blob/main/Meta-Llama-3.1-70B-Instruct.Q5_K/Meta-Llama-3.1-70B-Instruct.Q5_K-00001-of-00003.gguf)).
- For more details about sharded GGUF files, please refer to [gguf.md](https://github.com/ggerganov/ggml/blob/master/docs/gguf.md).
Repository: godot
Issue: Saving layout does not save state without distractions
Labels: discussion,topic:editor

### Tested versions

v4.3.rc1.official [e343dbbcc]

### System information

w10 64

### Issue description

Whenever I start godot I have to activate "distraction-free mode" in the scprit editor, godot does not save that when the layout is saved.
I have the "separate distraction mode" option activated.

### Steps to reproduce

Activate the "separate distraction mode" editor option.
Turn on distraction-free mode in the script editor
Close godot
open godot
Check that the script editor has distraction-free mode disabled again.
You will have to activate it again.

### Minimal reproduction project (MRP)

...
Repository: react
Issue: [Compiler Bug]: eslint-plugin-react-compiler reports "Hooks may not be referenced as normal values" if property begins "use"
Labels: Type: Bug,Status: Unconfirmed,Component: Optimizing Compiler

### What kind of issue is this?

- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhASwLYAcIwC4AEcEAdgGZoDmBZMEGBA5GPAPTHlWMDcAOifwQAPHPgIATBGQCGUADaEyUEnDxpSBALIBPAIJYsACix0sYAJQFg-AkVJhCYABbQ54gKpgEADQIBeO05KADppYKgvbz4SWxgEPFgY51cPSIIAfiYhRgJkJm0efgBffhAioA

### Repro steps

We have a config object with a property starting "use" - its a boolean.

It seems very restrictive that we cannot have any properties beginning "use".

I guess we could destructure outside the react component or make a abstracted function to get the boolean - is that the recommended solution? Or should react compiler be less restrictive in detecting hooks? It seems unlikely to be a hook if its a property name thats not on a import?

### How often does this bug happen?

Every time

### What version of React are you using?

0.0.0-experimental-9ed098e-20240725
Repository: vscode
Issue: When selecting a specific font (MonoLisa), weird symbols instead of characters on latest insiders build
Labels: bug,macos,font-rendering,regression,upstream-issue-fixed,chromium

<!-- ⚠️⚠️ 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: 
Version: 1.92.0-insider
Commit: 4d17e85cfd911fb6b116e08a4d7c37cd725a966a
Date: 2024-07-26T13:12:28.318Z (1 day ago)
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.5.0
- OS Version: MacOS Sonoma 14.5

Steps to Reproduce:
1. Select MonoLisa font
Example:
<img width="990" alt="Screenshot 2024-07-28 at 10 49 03" src="https://github.com/user-attachments/assets/e14f79f7-c8b4-4c2b-96d2-58541f37ab9d">
Repository: godot
Issue: Compatibility mode screen reading shader color mismatch
Labels: bug,topic:rendering,confirmed

### Tested versions

v4.2.2.stable.official [15073afe3]

### System information

Godot v4.2.2.stable - Debian GNU/Linux 12 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 3GB (nvidia) - AMD Ryzen 5 7600 6-Core Processor (12 Threads)

### Issue description

In compatibility render mode, a simple screen reading shader outputs incorrect color. Below an example.
![image](https://github.com/user-attachments/assets/b5585ead-1d76-40a4-917b-cbc41867bd01)
On the image a quad is shaded with a screen reading shader that should output whatever is behind it, and as such should, in theory, be invisible. Instead it has a subtle, color mismatch, allowing the viewer to see the seam where the quad begins.

This doesn't happen in forward+ render mode, so I assume it is a problem with compatibility render mode specifically.

### Steps to reproduce

Open the reproduction project enclosed, run the scene and observe the results.
Alternatively, create a project with compatibility render mode, have an omni light in a scene with some geometry, add a quad that is in front of said geometry, shade the quad with a shader code below:
```glsl
shader_type spatial;
render_mode unshaded;

uniform sampler2D SCREEN_TEXTURE : hint_screen_texture;

void fragment() {
	ALBEDO = texture(SCREEN_TEXTURE, SCREEN_UV).rgb;
}
```

### Minimal reproduction project (MRP)

[repro.zip](https://github.com/user-attachments/files/16402544/repro.zip)
Repository: node
Issue: Debugger docs: the expired parts ⚰🧹
Labels: doc,debugger

### Affected URL(s)

https://nodejs.org/docs/latest/api/debugger.html#v8-inspector-integration-for-nodejs

### Description of the problem

As of this writing, the final two sentences of the final subsection of the Debugger docs consist of [the following two statements](https://nodejs.org/docs/latest/api/debugger.html#v8-inspector-integration-for-nodejs):

1. `Chrome DevTools doesn't support debugging worker threads yet.`
   - Good intentions notwithstanding, [time phrases tied to the present](https://en.wikipedia.org/wiki/Template:When#Time_phrases_tied_to_the_present) (e.g: "yet") age like milk.
   - Even if the date of writing _**was**_ known, the assertion itself remains unsourced.
     - This unfortunate omission only makes the immediate next step (of Googling about to try and figure out if the purported lack of support is still the case) that much harder.
2. `ndb can be used to debug them.`
   - As of the 28th of July 2023, `ndb` [has been archived](https://github.com/GoogleChromeLabs/ndb).

# How to fix (🤷‍♂️)
Deleting the final two sentences could perhaps be enough?

On a side note: making the reader aware of the existence of [v8.dev](https://v8.dev) (which covers many advanced use cases) could perhaps be of partial service to the goal of documenting the aforementioned advanced use cases. 💡