sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Improvable error when putting `mut` in front of argument in trait method
Labels: A-diagnostics,T-compiler

### Code

```Rust
trait Foo {
    fn foo(mut a: String);
}
```

### Current output

```Shell
error: patterns aren't allowed in functions without bodies
 --> src/lib.rs:3:12
  |
3 |     fn foo(mut a: String);
  |            ^^^^^ help: remove `mut` from the parameter: `a`
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #35203 <https://github.com/rust-lang/rust/issues/35203>
  = note: `#[deny(patterns_in_fns_without_body)]` on by default
```

### Desired output

```Shell
error: patterns aren't allowed in functions without bodies
 --> src/lib.rs:3:12
  |
3 |     fn foo(mut a: String);
  |            ^^^^^ help: remove `mut` from the parameter: `a`
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: mutability of arguments cannot be declared in trait functions, as they are not part of the actual function signature.
  = note: for more information, see issue #35203 <https://github.com/rust-lang/rust/issues/35203>
  = note: `#[deny(patterns_in_fns_without_body)]` on by default
```

### Rationale and extra context

Adding `mut` in front of an argument makes an owned value be mutable inside a function. This is a form of a pattern, so the current error message is not _wrong_. However, most people, especially beginners, don't intuitively understand this as pattern syntax, and might not understand that it does not at all affect the effective function signature.
Thus, adding a specific hint or maybe even a completely different, more specific error message, for this case could help avoid confusion, and might serve as a learning opportunity to beginners.

### Other cases

```Rust

```

### Rust Version

```Shell
rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1
```

### Anything else?

_No response_

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"mostafarezaei"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: neovim
Issue: nvim -l/-es/-Es should enable user config + plugins by default
Labels: enhancement,defaults,needs:discussion,startup

### Problem

- By default, `nvim -es` skips user config unless `-u` is given.
- By default, `nvim -l` skips user config *and* disables (builtin) plugins.

Overriding these defaults is clumsy: `-u path/to/config -c 'set loadplugins'`
whereas the inverse case is easy: `--clean`.

see discussion in https://github.com/neovim/neovim/pull/21723

### Expected behavior

- Change `nvim -es` to load user config.
- Change `nvim -l` to load user config and builtin plugins.
Repository: TypeScript
Issue: The `parseJsonConfigFileContent` function does not resolve relative JSON paths
Labels: Bug,Help Wanted

### 🔎 Search Terms

json, imports, files, allowJs, resolveJsonModule

### 🕗 Version & Regression Information

This is replicated in TypeScript version 5.7.2. It has not been tested on earlier versions.

### ⏯ Playground Link

_No response_

### 💻 Code

[![Open in StackBlitz](https://developer.stackblitz.com/img/open_in_stackblitz.svg)](https://stackblitz.com/edit/vanyauhalin-typescript-parsejsonconfigfilecontent-issue?file=main.js)

```sh
$ npm install
$ npm test
```

```ts
import path from 'node:path';
import { parseJsonConfigFileContent, readConfigFile, sys } from 'typescript';

function testAbsolute() {
  const f = path.join(process.cwd(), 'tsconfig.json');
  const d = path.dirname(f);

  const j = readConfigFile(f, sys.readFile.bind(sys));
  const r = parseJsonConfigFileContent(j.config, sys, d);

  return r.fileNames;
}

function testRelative() {
  const f = 'tsconfig.json';
  const d = path.dirname(f);

  const j = readConfigFile(f, sys.readFile.bind(sys));
  const r = parseJsonConfigFileContent(j.config, sys, d);

  return r.fileNames;
}

// Absolute: [ '/home/projects/vanyauhalin-typescript-parsejsonconfigfilecontent-issue/package.json' ]
// Relative: []
console.log('Absolute:', testAbsolute());
console.log('Relative:', testRelative());
```

```json
{
  "compilerOptions": {
    "allowJs": true,
    "resolveJsonModule": true
  },
  "include": ["package.json"]
}
```


### 🙁 Actual behavior

```txt
Absolute: [ '/home/projects/vanyauhalin-typescript-parsejsonconfigfilecontent-issue/package.json' ]
Relative: []
```

### 🙂 Expected behavior

```txt
Absolute: [ '/home/projects/vanyauhalin-typescript-parsejsonconfigfilecontent-issue/package.json' ]
Relative: [ './package.json' ]
```

### Additional information about the issue

I tried to find the reason and ended up [here](https://github.dev/microsoft/TypeScript/blob/56a08250f3516b3f5bc120d6c7ab4450a9a69352/src/compiler/commandLineParser.ts/#L3917). The pattern that is generated for subsequent path validation always starts with a slash. As a result, any relative path in the future will fail this check. An example of the generated pattern is below:

```js
/^\/(?!(node_modules|bower_components|jspm_packages)(\/|$))([^./]([^./]|(\.(?!min\.js$))?)*)?\.json$/
```
Repository: ui
Issue: [bug]: error: Cannot find package 'fast-glob'
Labels: bug,postpone: more info or changes requested

### Describe the bug

tried installing shadcn ui using bun but am get error: Cannot find package 'fast-glob' from 'C:\Users\tochu\AppData\Local\Temp\bunx-516282117-shadcn@latest\node_modules\shadcn\dist\index.js' instead

### Affected component/components

installation

### How to reproduce

seeing error

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
error: Cannot find package 'fast-glob' from 'C:\Users\tochu\AppData\Local\Temp\bunx-516282117-shadcn@latest\node_modules\shadcn\dist\index.js'
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: puppeteer
Issue: [Bug]: `BrowserContext.deleteCookie` call signature requires fully populated cookie?
Labels: bug,feature,confirmed,P2

### Minimal, reproducible example

```TypeScript
import { BrowserContext } from 'puppeteer';

let a: BrowserContext;

a.deleteCookie({
  name: 'session',
  domain: 'localhost',
});
```


### Background

You recently deprecated `page.deleteCookie` et al, it seems the new API is not ready and or brokenly designed.

### Expectation

`deleteCookie` does not require full cookie?

### Reality

`deleteCookie` requires full cookie.

### Puppeteer configuration file (if used)

_No response_

### Puppeteer version

23.11.1

### Node version

20.17.0

### Package manager

npm

### Package manager version

10.8.2

### Operating system

macOS
Repository: godot
Issue: (Documentation) TextEdit's get_version does not actually return something resembling a count of undo/redo operations
Labels: discussion,topic:gui

### Tested versions

4.3.beta2 (last version to not have a different bug I'm avoiding)

### System information

Godot v4.3.beta2 - Windows 10.0.19045 - GLES3 (Compatibility) - AMD Radeon RX 6800 (Advanced Micro Devices, Inc.; 32.0.12033.1030) - AMD Ryzen 5 7600X 6-Core Processor (12 Threads)

### Issue description

The docs here (https://docs.godotengine.org/en/stable/classes/class_textedit.html#class-textedit-method-get-version) say `The version is a count of recorded operations by the undo/redo history.` -- however this is not true and each keypresses that contributes to an undo/redo operation has its own version number.

"Operation" in the context of undo/redo is a jargon term that refers to the entire set of actions that make up a single undo/redo step, exemplified by other places on this docs page saying e.g. `Perform redo operation.`.

Example:

https://github.com/user-attachments/assets/13c4faac-aa3c-424f-ace4-eab93eeaa975

### Steps to reproduce

N/A

### Minimal reproduction project (MRP)

N/A
Repository: rust
Issue: Tracking Issue for std::net::hostname
Labels: T-libs-api,C-tracking-issue,A-io

<!--
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(gethostname)]`

This is a tracking issue for retrieving the device's hostname.

https://github.com/rust-lang/libs-team/issues/330 goes into far more detail; basically, "it seems to be a small but useful addition to `std::net`"

### Public API
```rust
// std::net

pub fn hostname() -> std::io::Result<OsString>
```

### Steps / History

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

- [ ] Implementation: #135141
- [ ] Final comment period (FCP)[^1]
- [x] Implementation on Windows
- [ ] Switch to String before stabilization, as the hostname is guaranteed to be valid ASCII (OsString is therefore unnecessary).
- [ ] 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.
-->

- Will using `netc` be fine for all targets that support `std`, or do we need to do more here? I think so, since any new targets without a libc can just expose the same function signature under `netc` (`gethostname(ptr, len)`)
- Is the structure of this (with functions being directly under std::net) fine, with things like gethostbyname in mind?

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: kubernetes
Issue: `matchLabelKeys` in PodTopologySpread should insert a labelSelector like PodAffinity's `matchLabelKeys`
Labels: sig/scheduling,kind/feature,needs-triage

follow up: https://github.com/kubernetes/enhancements/pull/4001#discussion_r1206841191

Currently, we have matchLabelKeys in two places, PodAffinity and PodTopologySpread.
Historically, PodTopologySpread's one was introduced first and then PodAffinity.

When we designed PodAffinity, we decided to take a different approach from PodTopologySpread.
PodTopologySpread handles `matchLabelKeys` within the plugin, internally merging the label selector made from `matchLabelKeys` and calculating the result. It's not that the plugin patches an actual label selector thru kube-apiserver, but it's just that the plugin internally merges the selector with matchLabelKeys before the calculation. Therefore, if you query the pod, the pod would not has the labelSelector coming from matchLabelKeys.

https://github.com/kubernetes/kubernetes/blob/3c229949f992d9f798bcfd9f79dab88c21500c36/pkg/scheduler/framework/plugins/podtopologyspread/common.go#L95-L106

But, PodAffinity's `matchLabelKeys` is handled at kube-apiserver; when a PodAffinity has `matchLabelKeys`, a label selector is computed from the pod's label, added additionally into `labelSelector`, and actually stored in the storage (etcd). i.e., if you query the pod after the creation, the pod would has the labelSelector that you didn't add on your own, but is made from `matchLabelKeys`. And the PodAffinity plugin doesn't directly look at `matchLabelKeys`, but just compute `labelSelector` which may or may not have the selector made from `matchLabelKeys`.

https://github.com/sanposhiho/kubernetes/blob/810e9e212ec5372d16b655f57b9231d8654a2179/pkg/registry/core/pod/strategy.go#L797-L817

We should make PodTopologySpread's `matchLabelKeys` behave the same as PodTopologySpread to reduce the users' confusion coming from the behavior difference.

/sig scheduling
/kind feature
/cc @alculquicondor @macsko @dom4ha
Repository: rust
Issue: Precise captures in ITIAT are not refining
Labels: A-lifetimes,A-trait-system,A-impl-trait,C-bug,requires-nightly,S-has-mcve,T-types,F-impl_trait_in_assoc_type

[I tried this code:](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=5c131dec691c82024576391dc589febe)

```rust
#![feature(impl_trait_in_assoc_type)]

pub trait Trait {}
impl<T> Trait for T {}
pub struct Context;

pub trait Component {
    type Creation<'a>: Trait;
    fn create(self, ctx: &Context) -> Self::Creation<'_>;
}

impl Component for String {
    // `+ use<>` is allowed without triggering this lint
    // #[allow(refining_impl_trait)]
    type Creation<'a> = impl Trait + use<>;
    fn create(self, _ctx: &Context) -> Self::Creation<'_> {
        self
    }
}

impl Component for &str {
    // `+ use<>` correctly rejects the defining use here
    type Creation<'a> = impl Trait /*+ use<>*/;
    fn create(self, ctx: &Context) -> Self::Creation<'_> {
        ctx
    }
}

// This should accept `T = String` and not `T = &str`, but it
// accepts neither
pub fn component<T, R>(prop: T)
where
    T: for<'a> Component<Creation<'a> = R>,
{
    move |ctx: &Context| prop.create(ctx);
}

fn main() {
    let but_does_it_work = component(String::new());
    // let but_does_it_work = component("");
}
```

I expected to see this happen: successful compilation

Instead, this happened:
```rust

error[E0308]: mismatched types
  --> src/main.rs:39:28
   |
15 |     type Creation<'a> = impl Trait + use<>;
   |                         ------------------
   |                         |
   |                         the expected opaque type
   |                         the found opaque type
...
39 |     let but_does_it_work = component(String::new());
   |                            ^^^^^^^^^^^^^^^^^^^^^^^^ one type is more general than the other
   |
   = note: expected opaque type `<String as Component>::Creation<'a>`
              found opaque type `<String as Component>::Creation<'_>`
   = note: distinct uses of `impl Trait` result in different opaque types
note: the lifetime requirement is introduced here
  --> src/main.rs:33:26
   |
33 |     T: for<'a> Component<Creation<'a> = R>,
   |                          ^^^^^^^^^^^^^^^^
```

### Why the expectation

[The analogous refinement works with RPITIT and RTN.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=fe2d135278e8e2ab9a4c5b52edcf0633)

### Meta

Playground 1.86.0-nightly (2025-01-04 1891c28669863bf7ed3e)

@rustbot label +F-impl_trait_in_assoc_type +A-traits +T-types +requires-nightly
Repository: terminal
Issue: Open in Terminal option not initially appearing in the context menu
Labels: Issue-Bug,Needs-Triage

### Windows Terminal version

1.21.3231.0 and 1.22.3232.0

### Windows build number

10.0.22631.0

### Other Software

N/A

### Steps to reproduce

1. Reboot the computer or restart Windows Explorer from Task Manager.  Then, right click on the desktop background or a folder background.  The context menu does not show the "Open in Terminal" entry:
![Image](https://github.com/user-attachments/assets/743c3b89-633d-41c5-911e-0494e19a3e8a)


2.  Click on the desktop/folder background for a second time.  Now the entry appears:
![Image](https://github.com/user-attachments/assets/32ee0bb9-f8d2-4487-bcea-559357f95698)







### Expected Behavior

The Open in Terminal context menu entry should appear on the first right click after restarting Explorer or rebooting the computer.

### Actual Behavior

It takes opening the context menu twice in order for the Terminal context menu entry to appear.  It also does not have to be right clicking on the same element two times in a row.  For instance, after restarting Explorer, right clicking on a file and then right clicking on the desktop background will cause the Open in Terminal entry to appear.
Repository: godot
Issue: OneShots can't fade out StateMachine shots with no running animation
Labels: enhancement,topic:animation

### Tested versions

- Reproduceable in 4.3.stable

### System information

Windows 11, 4.3.stable, Vulkan 1.3.289, Forward+, Geforce 4080 RTX

### Issue description

When an `AnimationNodeOneShot` in an `AnimationNodeBlendTree` has its `shot` pin connected to an `AnimationNodeStateMachine` with no playing animation, `AnimationNodeOneShot.ONE_SHOT_REQUEST_FADE_OUT` doesn't work. 

The one shot should fade back to its input over *fadeout_time* seconds.

https://github.com/user-attachments/assets/03f99bfb-c7f0-4927-9861-f3d93509e35f


### Steps to reproduce

- Add an `AnimationTree` to your scene with a `AnimationNodeBlendTree` root. Add an `AnimationNodeOneShot` with 0.2s fadeout time and give it a looping animation input and state machine shot. 
![Image](https://github.com/user-attachments/assets/9164ea46-d2e7-4fbf-9ace-ba24b691fe79)

- Inside the state machine, add a non-looping animation and connect it to Start
![Image](https://github.com/user-attachments/assets/a440c778-efbf-4252-9bda-f7095d11b9fc)

Fire the one shot, wait for the state machines animation to complete then try fading out the one shot. Instead of fading back into the one shots input, it will do nothing.

### Minimal reproduction project (MRP)

MRP attached. [fadeoutissue.zip](https://github.com/user-attachments/files/18312722/fadeoutissue.zip)


Open the *character/character.tscn* scene, click its `AnimationTree`, fire and fade out the one shot.
Repository: transformers
Issue: Very slow to load deep seekv3 int4 model and device_map="auto" "sequential" bug
Labels: bug

### System Info

transforms 4.47.0

### Who can help?

_No response_


### Reproduction

please refer the code in model card https://huggingface.co/OPEA/DeepSeek-V3-int4-sym-gptq-inc

### Expected behavior

1 **Loading is very slow.** Loading the model (https://huggingface.co/OPEA/DeepSeek-V3-int4-sym-gptq-inc) on a DGX system with 2TB of memory and 7x80GB A100 GPUs is very slow, taking 30 minutes to 1 hour. 

**2 device_map bug.** Additionally, on a 7x80GB A100 GPUs, using device_map='auto' results in an OOM error, while switching to device_map='sequential' still causes an OOM error on card 0, even with max_memory configured.
Repository: transformers
Issue: How about adding a combined step and epoch feature to save_strategy?
Labels: Feature request

### Feature request

Add epoch+steps functionality to save_strategy

### Motivation

I often set save_strategy to epoch for saving, but sometimes I need to run experiments with steps. 
Recently, I had to compare checkpoints saved at both epoch and step intervals, which required running the experiment twice and was quite cumbersome. Having a combined feature would be really helpful. What do you think?

### Your contribution

I can add the epoch+steps functionality to save_strategy.
Repository: transformers
Issue: Warning 'The attention mask is not set'
Labels: bug

Having the same warning appearing in a closed pull request #33509 

### System Info

- `transformers` version: 4.47.1
- Platform: Linux-5.15.146.1-microsoft-standard-WSL2-x86_64-with-glibc2.39
- Python version: 3.12.3
- Huggingface_hub version: 0.27.0
- Safetensors version: 0.5.0
- Accelerate version: 1.2.1
- Accelerate config:    not found
- PyTorch version (GPU?): 2.5.1+cu124 (True)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using distributed or parallel set-up in script?: no
- Using GPU in script?: yes
- GPU type: NVIDIA RTX 4000 Ada Generation Laptop GPU

### Who can help?

@ylacombe 

### Information

- [ ] The official example scripts
- [X] My own modified scripts

### Tasks

- [X] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

code:
```python
        pipe = pipeline(
            "automatic-speech-recognition",
            model=self.model,
            torch_dtype=torch.float16,
            chunk_length_s=30,
            batch_size=24,
            return_timestamps=True,
            device=self.device,
            tokenizer=processor.tokenizer,
            feature_extractor=processor.feature_extractor,
            model_kwargs={"use_flash_attention_2": True},
            generate_kwargs={
                "max_new_tokens": 128,
            },
        )

```

warning:
```
The attention mask is not set and cannot be inferred from input because pad token is same as eos token. As a consequence, you may observe unexpected behavior. Please pass your input's `attention_mask` to obtain reliable results.
Whisper did not predict an ending timestamp, which can happen if audio is cut off in the middle of a word. Also make sure WhisperTimeStampLogitsProcessor was used during generation.
```

### Expected behavior

No warning
Repository: pytorch
Issue: Support LayerNorm2d
Labels: module: nn,triaged

### 🚀 The feature, motivation and pitch

Hi, I want to use a layernorm with BCHW features, where normalization applied to every pixel, see [this](https://github.com/huggingface/pytorch-image-models/blob/131518c15cef20aa6cfe3c6831af3a1d0637e3d1/timm/layers/norm.py#L71) for a reference. Currently, we have to use 2 `reshape` ops in order utilizing fast layernorm implementation of pytorch.

### Alternatives

_No response_

### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki