sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Remote inspector doesn't show description of member variables added via ##
Labels: bug,topic:editor

### Tested versions

- Reproducible in 4.3-stable and 4.2.1-stable

### System information

Godot v4.3.stable - Ubuntu 22.04.5 LTS 22.04 - X11 - Vulkan (Forward+)

### Issue description

The code below creates description that appears when hovering with the mouse over a variable in a custom script, but shows "No description available" if you look at the **member** variable in the remote inspector while running a scene.

```gdscript
## My description here
@export var row:int
```

### regular inspector:
![Image](https://github.com/user-attachments/assets/fe65586a-d5e4-44d5-9159-749dab35e7af)

### **remote** inspector while debugging **(The problem)**:
![Image](https://github.com/user-attachments/assets/d296c28c-8f73-4f17-a94d-3f602ec694fa)

### **remote** inspector while debugging, scroll down to the script parameters:
![Image](https://github.com/user-attachments/assets/e4767355-068a-4542-a8c6-84eac7869b7f)

### Steps to reproduce

1. Add a script to a node
2. Add an exported variable with a " ## description " above it
example code:
```gdscript
## My description here
@export var row:int
```
3. Run the debugger with that node
4. Switch the inspector from "Local" to "Remote"
5. Inside the Members section, hover your mouse over the variable that you added a description for
6. Further down in the properties, inside the exported script variables, hover your mouse over the same variable

Expected result: both descriptions are the same
Actual result: the description in the Members section is missing

### Minimal reproduction project (MRP)

N/A
Repository: tauri
Issue: [bug] How to remove the top title bar of Android
Labels: type: bug,status: needs triage

### Describe the bug

How to remove the top title bar of Android，If it is horizontally displayed, there will be a title bar at the top，I feel very uncomfortable.

### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
npm run tauri info
```

### Stack trace

```text

```

### Additional context

_No response_
Repository: storybook
Issue: [Bug]: VTA failure gets lost in CLI noise
Labels: bug,addon: test,upgrade:8.5

### Describe the bug

When using both VTA and Addon Test and clicking on “run all tests”, VTA will fail with a message that is just completely lost in the CLI (image 1). Additionally, the tests will never complete, it will be in a hanging state forever. Same happens when the component tests succeed, but VTA command fails, leaving an even more misleading UI state that is also hanging (image 2).

Because the VTA item in the testing module already shows “Login required” from the start, the user might not connect that “Login required” is the cause for the tests to not have completed

![Image](https://github.com/user-attachments/assets/c8101d79-7561-4a90-9465-b5cee62b4311)
![Image](https://github.com/user-attachments/assets/68e8374e-7104-4d45-93e1-0677a1aa39bd)


### Reproduction link

-

### Reproduction steps

_No response_

### System

```bash
-
```

### Additional context

_No response_
Repository: storybook
Issue: [Bug]:  Addon-Test: tests’ timing out get the test module into a stuck state
Labels: bug,addon: test,upgrade:8.5

### Describe the bug

The message in the terminal is from Vitest but it’s not very clear. I can see how someone could be confused since there’s nowhere within the storybook they can set a timeout value.

![Image](https://github.com/user-attachments/assets/91a2a649-bac0-4cd1-bf2a-1707d23c4172)
![Image](https://github.com/user-attachments/assets/7cca4316-82c9-4bde-b8f3-c43bbe8d87dc)



### Reproduction link

-

### Reproduction steps

_No response_

### System

```bash
-
```

### Additional context

_No response_
Repository: tauri
Issue: [docs]
Labels: type: documentation

Hello,

I am new to tauri / npm. After cloning my tauri repo to a new machine, i did run into this

```
cargo tauri dev
    Running BeforeDevCommand (npm run dev)
    Info Watching [...]/src-tauri for changes...
npm error Missing script: "dev"
npm error
npm error To see a list of scripts, run:
npm error   npm run
npm error A complete log of this run can be found in: [...]/.npm/_logs/2025-01-21T00_06_36_866Z-debug-0.log
    Error The "beforeDevCommand" terminated with a non-zero status code.
```


the problem was that i had initialized npm in the src-tauri folder too. i.e. my folder structure was like this

```
ls *

frontend:
app.jsx    components  index.html  main.jsx  node_modules  package.json  package-lock.json     public  vite.config.js

src-tauri:
build.rs  capabilities  Cargo.lock  Cargo.toml  gen  icons  node_modules  package.json  package-lock.json  public  README.md  src  target  tauri.conf.json

``` 

The `cargo tauri build` apparently finds any subfolder with a `package.json`. It did hit the src-tauri one, which has no scripts defined. Hence the error.

It would be beginner friendly to have some more explicit error e.g. "tauri  found 2 package.json in subfolders and cannot choose which one. You should only have npm in frontend folder"
Repository: tauri
Issue: CI does not check for semver breaking changes
Labels: type: feature request,github_actions

~~#12461 suggested a major breaking change.~~ Automated checking of breaking changes would permit prioritizing PR merging and provide some immediate feedback to the PR without manual intervention by maintainers. This would also prevent mistakes in semver management.

A tool for this is [cargo-semver-checks](https://github.com/obi1kenobi/cargo-semver-checks).
Repository: node
Issue: util.debuglog callback argument behavior and purpose appears to be documented incorrectly
Labels: util,doc

### Affected URL(s)

https://nodejs.org/docs/latest/api/util.html#utildebuglogsection-callback

### Description of the problem

The usage example of the callback function for `util.debuglog` is not sufficiently documented imho.
Moreover, when looking at the code, it also seems to even work differently than described. 

The example for the callback does the following:
```javascript
const util = require('node:util');
let debuglog = util.debuglog('internals', (debug) => {
  // Replace with a logging function that optimizes out
  // testing if the section is enabled
  debuglog = debug;
});
```

What debuglog effectively does is:
```javascript
function debuglog(set, cb){
  realLogFunction = (...args){
     init() //sets up the set name and an enabled boolean value

     // creates a noop function when enabled=false
     realLogFunction = debugLogImpl(enabled) 
     if(typeof cb == "function"){
       // this is the part where the documentation is lacking
       cb(realLogFunction) //code depends on side-effects of the callback?
     }
     // this line is only effective the very first time, when still in the factory
     // likely to not 'swallow' the first log line that lazily inits the real logger
     realLogFunction(...args)
  }

  //left out for brewity, but works on the same principle as realLogFunction
  let innerEnabledCheck ()=>{...}
  
  logDelegate = (...) => {
    //some switch on argument length, but effectively always results in the next line, with a varying
    //amount of arguments passed on.
    realLogFunction(args)
  }
  logDelegate.enabled = innerEnabledCheck() //left out for brewity
  return logDelegate;
}
```

The first time `logDelegate` is called, the enabled test is already optimized out and `logDelegate` will call the now-changed `realLogFunction` generated from `debugLogImpl`.
What actually happens when the callback is used as in the documentation's example, is that the outside variable, (`debuglog` in the example) which points to `logDelegate`, will be replaced by `realLogFunction`.

Thus, what is 'optimized out' is the switch in `logDelegate` when the callback is used as shown in the example, but at the price of also losing the `enabled` getter. 'Testing if the section is enabled' is always automatically and implicitly optimized out in the inner factory method.
Repository: ant-design
Issue: The Range picker(with time) does not close on single click of 'Ok' button
Labels: unconfirmed

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/p/sandbox/v5xnzc)

### Steps to reproduce

1. Open-range picker
2. Select the start date and time
3. Click on 'ok'
4. It changes focus to end date 
5. Again click on the 'ok' button
6. Picker closes

### What is expected?

1. The picker should close when the user selects/updates the start date/time and clicks the 'ok' button.
2. The picker should close when the user selects/updates the end date/time and clicks the 'ok' button. 
3. The user should be able to update both the start date & end date/time and click on the 'ok' button, the picker should close. 

### What is actually happening?

1. When the user selects/updates the start date/time alone and clicks on the 'ok' button, the focus shifts to the end date and the picker remains open. Again clicking on the 'Ok' button closes it.
2. When the user selects/updates the end date/time alone and clicks on the 'ok' button, the focus shifts to the start date and the picker remains open. Again clicking on the 'Ok' button closes it.
3. The user cannot update both the start date & end date/time in a single go, without clicking the 'Ok' button.

| Environment | Info |
| --- | --- |
| antd | 5.23.0 |
| React | 18 |
| System | Windows 10 |
| Browser | Google Chrome |

---
This behavior of the range picker was working in version 5.11. Still, due to language translation support, we upgraded to the latest 5.23.0 version in which the range picker behavior is not as per our project requirement.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: crash when dlopen/dlclose rust-made *.so multi-times on android/ohos aarch64
Labels: C-bug,needs-triage


crash when dlopen/dlclose rust-made *.so multi-times on android/ohos aarch64

Senario:
1. Compile a Rust source file into a shared object (.so) file.
2. A C++ file uses dlopen to load the .so file and retrieve the target symbol.
3. Call the Rust function within the loaded .so.
4. Use dlclose to unload the .so file.

Related issues [#134820](https://github.com/rust-lang/rust/issues/134820)

[reproduction code](https://github.com/Rust401/c_cpp_dlopen_rust_so)

Here's the translation of the provided text:

Known Information:

1. There is no issue with regular arm64, but disassembly reveals differences involving the use of `TPIDR_EL0`.
2. The main difference between ohos/an and arm64 Linux options is `has_thread_local=true and tls-model=emulated`, but these two compilation options do not seem to take effect when compiling the shared object (suspected that the standard library needs to be recompiled with these options). The implementation of `printl` is part of the Rust standard library.
3. Upon reviewing the code, it was found that the `tls-model=emulated` option affects the rustc compilation behavior (either using `TPIDR_EL0` or emulated TLS, by affecting the LLVM backend).

This seems to be a bug in the rustc implementation. In the combination of Android and OHOS target platform options, during the println process, a thread-local variable is implicitly created, and the thread-local resources initialized through lazy_init are not properly released when dlclose is called.
Repository: transformers
Issue: [Feature Request] Support register customize quantization method out-of-tree
Labels: Feature request

### Feature request

Support register customize quantization method out-of-tree.

The usage would be as follows:

```python
from transformers.quantizers import HfQuantizer
from transformers.quantizers import regsiter_quantization_config, register_quantizer
from transformers.utils.quantization_config import QuantizationConfigMixin


@regsiter_quantization_config("custom")
class CustomFakeQuantizationConfig(QuantizationConfigMixin):
    """The custom fake quantization config."""


@register_quantizer("custom")
class CustomFakeQuantizer(HfQuantizer):
    """The custom fake quantizer."""
```
### Motivation

We would greatly appreciate it if HuggingFace could support registering custom quantization schemes externally. This would allow us to integrate the schemes of any LLM quantization tools and evaluate fake quantization models using the powerful combination of `lm_eval` + `huggingface`. Thank you for considering this!

Similar features have already been supported by vLLM, see:
- https://github.com/vllm-project/vllm/issues/11926
- https://github.com/vllm-project/vllm/pull/11969

### Your contribution

If this feature request is considered, I'd happily submit a PR to implement it.
Repository: pytorch
Issue: Missing create_graph arguments in torch.func apis
Labels: triaged,module: functorch

### 🐛 Describe the bug

Hi, I want replace `torch.autograd.functional.jvp`/`torch.autograd.functional.vjp` with `torch.func.jvp`/`torch.func.vjp`. Since `torch.func.jvp` is more efficient compared to autograd ops.

However, I notice these apis are not equivalent, since I calculate jvp to create a loss, thus second-order gradient is required, and we have to set `create_graph=True`. There is no `create_graph` argument in `torch.func` api, so is `torch.func` does not intent to use in my case or it support higher-order gradient by default?

### Versions

N/A

cc @zou3519 @Chillee @samdow @kshitij12345
Repository: bitcoin
Issue: ci: tidy task doesn't run on aarch64
Labels: Tests

```bash
time env -i HOME="$HOME" PATH="$PATH" USER="$USER" bash -c 'FILE_ENV="./ci/test/00_setup_env_native_tidy.sh" ./ci/test_run_all.sh'
<snip>
[  0%] Built target bitcoin_crypto_arm_shani
[100%] Built target bitcoin_crypto
gmake: *** No rule to make target 'bitcoin_crypto_x86_shani'.  Stop.
```

The script as written assumes that it will be run on `x86_64`:

https://github.com/bitcoin/bitcoin/blob/d7f56cc5d9e12ad31dd1ce8b34c3ff4ec5c1b70c/contrib/devtools/check-deps.sh#L11
Repository: vscode
Issue: Terminal sometimes randomly changes the font (or rather letter spacing)
Labels: terminal-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?: (unable to check because it doesn't happen often)
<!-- 🪓 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.96.3
- OS Version: Arch Linux x64 6.12.9-arch1-1

I don't know what causes this, this sometimes happens randomly after running a task. 
I normally develop in Dev Containers, and don't know if this happens without that extension or not.

Normally my terminal looks like this:

![a](https://github.com/user-attachments/assets/b608ca36-aeb5-452b-ada3-570cfcd7a2c4)

But sometimes it will randomly change to a different letter spacing, but only in a specific terminal instance:

![b](https://github.com/user-attachments/assets/30d35fc5-5af7-4d66-9373-a6cf8115040a)

If I create a new terminal, it'll have the correct style. And if I switch back to the old terminal tab, that one will still have the bad style.

This seens to be the same font. The line height is exactly the same, but everything is moved up by one pixel, and the letter spacing seems to increase by about one pixel.
Repository: bitcoin
Issue: contrib: Autoconf fragments left in test-*-check scripts
Labels: Scripts and tools

The [`test-security-check`](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/test-security-check.py) and [`test-symbol-check`](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/test-symbol-check.py) scripts still reference Autoconf and it's behaviour:
```python
def env_flags() -> list[str]:
    # This should behave the same as AC_TRY_LINK, so arrange well-known flags
    # in the same order as autoconf would.
    #
    # See the definitions for ac_link in autoconf's lib/autoconf/c.m4 file for
    # reference.
```

The also expect `CPPFLAGS` to be passed into them, but this isn't happening from CMake:

https://github.com/bitcoin/bitcoin/blob/d7f56cc5d9e12ad31dd1ce8b34c3ff4ec5c1b70c/cmake/module/Maintenance.cmake#L40
Repository: vscode
Issue: Hover - codicons shift in hover
Labels: bug,editor-hover,workbench-hover

Steps to Reproduce:

1. Launch VS Code Insiders and open a folder/workspace that contains a git repository
2. Enable git blame editor decoration and start bar item
3. Open a file and click on a line so that blame information is revealed
4. Hover over the editor decoration and see the hover load and then shift the codicons

https://github.com/user-attachments/assets/26eca974-0bb0-47d9-979f-f700571e8248
Repository: kubernetes
Issue: E2E: Allow to cleanup resources conditionally
Labels: kind/feature,sig/testing,needs-triage

### What would you like to be added?

The current e2e test framework does not provide an easy way to retain all resources created during a test in the event of a failure. The only existing option is to preserve only namespaces upon failure: [DeleteNamespaceOnFailure](https://github.com/kubernetes/kubernetes/blob/release-1.32/test/e2e/framework/framework.go#L358C50-L358C74).

The recommended approach for cleaning up resources is to use `ginkgo.DeferCleanup` directly after setting up something, as documented in:
- [E2E Testing Best Practices](https://www.kubernetes.dev/blog/2023/04/12/e2e-testing-best-practices-reloaded/#recovering-from-test-failures)
- [Writing Good e2e Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/writing-good-e2e-tests.md#recovering-from-test-failures)

However, there are several challenges with the current approach:
- There is no way to conditionally skip `ginkgo.DeferCleanup` in case of a test failure.
- Some tests do not use `ginkgo.DeferCleanup` consistently. For example:
    - StatefulSet tests clean up resources inside `ginkgo.AfterEach`: [StatefulSet Cleanup](https://github.com/kubernetes/kubernetes/blob/release-1.32/test/e2e/apps/statefulset.go#L139)
    - Webhook tests perform additional setup (waiting for the webhook to be ready) before calling `ginkgo.DeferCleanup`: [Webhook Test Example](https://github.com/kubernetes/kubernetes/blob/release-1.32/test/e2e/apimachinery/webhook.go#L1187).

It would be beneficial to introduce a wrapper over ginkgo.DeferCleanup in the [ginkgowrapper.go](https://github.com/kubernetes/kubernetes/blob/release-1.32/test/e2e/framework/ginkgowrapper.go) file.

This wrapper should:
- Be used consistently across all tests.
- Allow optional skipping of cleanup actions in case of a test failure.

### Why is this needed?

Kubernetes conformance tests are a very useful tool for testing custom Kubernetes configurations.
However, diagnosing issues in these tests can be challenging because misconfigurations may manifest during rare test runs only.
Retaining test resources after failure can provide crucial insights into the state of the cluster and help reproduce and debug such issues.
Repository: next.js
Issue: Predictably wrong CSS ordering when sharing components between different component types
Labels: Module Resolution,CSS

### Link to the code that reproduces this issue

https://codesandbox.io/p/live/a657211a-67d2-4c9a-a4bb-f061e9a08dd2

### To Reproduce

Next will mess up the ordering of your component styling under the following conditions (combined):
1. You have some sort of shared component, let's call it "ComponentLayout"
2. ComponentLayout is used in client, server, statically rendered, and dynamically imported components (basically everywhere)
3. ComponentLayout allows you to pass in a className to use with its own, allowing you to override its own styling

What is interesting is that it adds preload links in the correct order, but then messes up the actual stylesheet links.

### Current vs. Expected behavior

**Current:**
Observe as Next proceeds to mess up the ordering, leading to SharedLayout's styles overriding some of your components.

**Expected:**
Next should respect import and loading order regardless of usages.

### Provide environment information

```bash
All environments running Next>=14.2.0, regardless of OS and browser.
```

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

Module Resolution

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

next dev (local), next build (local), next start (local), Other (Deployed)

### Additional context

_No response_
Repository: PowerToys
Issue: Add dynamic naming to New+
Labels: Needs-Triage

### Description of the new feature / enhancement

I'm sorry for any wrong wording.

I would like adding a feature to New+ such that if I create a template with the name 'x', the files/folders inside it can also be named depending upon the name 'x'

Currently, I have created a template named Python Project:
```
Python Project/
├──.venv/
├──python-project/
├────python-project.py
└────main.py
```

If I use New+ to create this template and rename it foo-bar:
```
foo-bar/
├──.venv/
├──python-project/
├────python-project.py
└────main.py
```

If this were a thing, and I rename it foo-bar, then:
```
foo-bar/
├──.venv/
├──foo-bar/
├────foo-bar.py
└────main.py
```
Edit: Notice how the file `main.py` and `.venv` have not changed

It would also be great if the contents inside the files would be changed.

### Scenario when this would be used?

This would be great for those who have project templates like these, and they wouldn't have to rename everything manually

### Supporting information

No supporting information
Repository: rust
Issue: `-Ztranslate-additional-ftl` for a broken fluent bundle with stray interpolation argument unexpectedly ICEs
Labels: I-ICE,T-compiler,C-bug,A-translation,A-run-make

https://github.com/rust-lang/rust/blob/ebbe63891f1fae21734cb97f2f863b08b1d44bf8/tests/run-make/translation/Makefile has a test comment and test case:

https://github.com/rust-lang/rust/blob/ebbe63891f1fae21734cb97f2f863b08b1d44bf8/tests/run-make/translation/Makefile#L23-L26

Ignoring that this is using the wrong `.ftl` file (it should be using `broken.ftl` to correspond to the test comment, where `broken.ftl` contains a slug that has a stray fluent interpolation argument), this must have regressed over the years because

```rs
rustc test.rs -Ztranslate-additional-ftl=broken.ftl
```

actually ICEs locally due to

```
thread 'rustc' panicked at compiler/rustc_errors/src/emitter.rs:1465:84:
called `Result::unwrap()` on an `Err` value: failed while formatting fluent string `parse_struct_literal_body_without_path`:
the fluent string has an argument `foo` that was not found.
help: no arguments are available
```

Pinging back to #132181.

I assume this is not the intended behavor.