sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Imports of legacy modules with numeric constants do not get flagged as unused when the corresponding type is used in the code
Labels: A-diagnostics,T-compiler

### Code

```Rust
use std::usize;

fn main() {
    let x: usize = 1;
    println!("{}", x);
}
```


### Current output

```Shell

```


### Desired output

```Shell
warning: unused import: `std::usize`
 --> src/main.rs:1:5
  |
1 | use std::usize;
  |     ^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default
```


### Rationale and extra context

_No response_

### Other cases

_No response_

### Rust Version

```Shell
$ rustc --version --verbose
rustc 1.79.0-beta.1 (6b544f5ff 2024-04-28)
binary: rustc
commit-hash: 6b544f5ff8d45221d61962651a5f5ab9fe535e16
commit-date: 2024-04-28
host: x86_64-unknown-linux-gnu
release: 1.79.0-beta.1
LLVM version: 18.1.4
```


### Anything else?

_No response_
Repository: flutter
Issue: implement the prominent style for labelLarge and labelMedium in the TextTheme - Material Design 3
Labels: c: new feature,framework,f: material design,a: fidelity,c: proposal,P2,team-design,triaged-design

### Use case

As described in the [documentation](https://m3.material.io/styles/typography/type-scale-tokens), in Material Design 3 there are three Label styles: 
- Label Large
- Label Medium
- Label Small.

For the Large and the Medium, Material Design provides two different type of weightness: normal and prominent.

But in the text_theme.dart there are only labelLarge and labelMedium, without the prominent style.

### Proposal

Implement the prominent style in the TextTheme for the labelLarge and labelMedium.
Repository: PowerToys
Issue: a button to move the window to the next virtual desktop (like Spaces in macos) and keyboard shortcuts
Labels: Needs-Triage

### Description of the new feature / enhancement

an additional button next to the function of minimizing the window for this task

### Scenario when this would be used?

it is very convenient for any job. especially with a virtual machine

### Supporting information

_No response_
Repository: rust
Issue: When using `Box<self>` in first method parameter, the error output provides the wrong type in help message
Labels: A-diagnostics,A-parser,T-compiler,A-suggestion-diagnostics,D-papercut,D-invalid-suggestion

### Code

```Rust
struct Foo {

}
impl Foo {
    fn invoke(Box<self>) -> i32 {
        0
    }
}

fn main() {}
```


### Current output

```Shell
error: expected one of `:`, `@`, or `|`, found `<`
 --> main.rs:5:18
  |
5 |     fn invoke(Box<self>) -> i32 {
  |                  ^ expected one of `:`, `@`, or `|`
  |
  = note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a `self` type, give it a parameter name
  |
5 |     fn invoke(self: Box<self>) -> i32 {
  |               +++++
help: if this is a type, explicitly ignore the parameter name
  |
5 |     fn invoke(_: Box<self>) -> i32 {
  |               ++

error: aborting due to 1 previous error
```


### Desired output

```Shell
error: expected one of `:`, `@`, or `|`, found `<`
 --> main.rs:5:18
  |
5 |     fn invoke(Box<self>) -> i32 {
  |                  ^ expected one of `:`, `@`, or `|`
  |
  = note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a `self` type, give it a parameter name
  |
5 |     fn invoke(self: Box<Self>) -> i32 {
  |               +++++
help: if this is a type, explicitly ignore the parameter name
  |
5 |     fn invoke(_: Box<Self>) -> i32 {
  |               ++

error: aborting due to 1 previous error
```


### Rationale and extra context

The type of the parameter in the error message should be uppercase, `Box<Self>`. However, a lowercase `Box<self>` is present.

### Other cases

_No response_

### Rust Version

```Shell
$ rustc --version --verbose
rustc 1.80.0-nightly (79734f1db 2024-05-02)
binary: rustc
commit-hash: 79734f1db8dbe322192dea32c0f6b80ab14c4c1d
commit-date: 2024-05-02
host: aarch64-apple-darwin
release: 1.80.0-nightly
LLVM version: 18.1.4
```


### Anything else?

_No response_
Repository: kubernetes
Issue: Kubelet should not add IPv6 entries to /etc/hosts on systems where IPv6 is disabled
Labels: kind/bug,sig/network,sig/node,triage/accepted

### What happened?

Kubelet unconditionally adds IPv6 entries to `/etc/hosts` even when system has IPv6 totally disabled. This results in strange errors due to "happy eyeballs" fallback behavior: when clients see both an IPv4 and an IPv6 address for a host, they first try IPv4 and then fall back to IPv6, but if IPv6 is disabled in the kernel, they then get an "Address family not supported by protocol" exception instead of "Connection refused".

This happens with standard HTTP clients, etc, but here's an example with netcat:
```
# nc -v 127.0.0.1 1111
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection refused.
```
vs
```
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection to 127.0.0.1 failed: Connection refused.
Ncat: Trying next address...
libnsock nsock_make_socket(): Socket trouble: Address family not supported by protocol
Ncat: Address family not supported by protocol.
```

That results in clients needing to handle a different exception. However, even if IPv6 were enabled on the system, it would still be invalid to put loopback addresses in `/etc/hosts` for localhost when they are not actually configured on the loopback interface.

Code here: https://github.com/kubernetes/kubernetes/blob/v1.29.4/pkg/kubelet/kubelet_pods.go#L373-L377

### What did you expect to happen?

Kubelet should not add localhost entries to `/etc/hosts` for addresses that do not actually exist on the pod's loopback interface.

### How can we reproduce it (as minimally and precisely as possible)?

I don't think you need a reproducer for this one since the code is just unconditionally doing this. However, if you're looking to test this on a system with ipv6 disabled such that you get the "Address family not supported by protocol" error, or guarantee that CNI does not add an IPv6 loopback address, you can boot your kernel with `ipv6.disable=1` on the kernel command line.

### Anything else we need to know?

_No response_

### Kubernetes version

N/A all versions impacted


### Cloud provider

N/A

### OS version

N/A

### Install tools

N/A

### Container runtime (CRI) and version (if applicable)

N/A

### Related plugins (CNI, CSI, ...) and versions (if applicable)

N/A
Repository: pytorch
Issue: Inaccurate filename due to test class metaprogramming that doesn't set __file__ and __name__
Labels: module: tests,triaged,module: devx

### 🐛 Describe the bug

I noticed that occasionally the "To execute this test" doesn't have complete information. For example:

```
2024-05-02T20:42:53.9094051Z To execute this test, run the following from the base repo dir:
2024-05-02T20:42:53.9094398Z      python test_compiled_autograd.py -k test_accumulate_grad_accuracy
```

but sometimes you just having testing.py, you don't even have a useful name.

This is usually always because the `__file__` on the test class is not set appropriately.

Here is a sample fix diff:

```
diff --git a/test/inductor/test_compiled_autograd.py b/test/inductor/test_compiled_autograd.py
index 2a94e4cee5b..14aa16c059b 100644
--- a/test/inductor/test_compiled_autograd.py
+++ b/test/inductor/test_compiled_autograd.py
@@ -1535,11 +1535,13 @@ def wrap_test_class(orig_cls):
         elif name.startswith("test_"):
             dct[name] = make_wrapped(fn)
 
-    return type(
+    cls = type(
         orig_cls.__name__ + "WithCompiledAutograd",
         orig_cls.__bases__,
         dct,
     )
+    cls.__file__ = __file__
+    return cls
 
 
 # These groups of tests aren't supported yet
```

we have to apply these to all test metaprograms. Maybe we can have a test to check `__file__` is actually set. Note that setting `__file__` to `__file__` is not always the right thing to do.

### Versions

main

cc @mruberry @ZainRizvi @kit1980 @huydhn @clee2000
Repository: godot
Issue: Can't find my animation player in godot in add nodes . 
Labels: discussion,topic:editor

### Tested versions

v4.2.2.stable.official [15073afe3]

### System information

windows 10 godot 4.2.2

### Issue description

i just downloaded godot as I was following a course and they opened Animation Player on Add nodes. I tried that as well but nothing came up besides animatedsprit 2D and animationbody 2D there was no animationplayer

![Screenshot (2)](https://github.com/godotengine/godot/assets/168837151/d59b1d03-2d02-424e-b730-669a2ce370f1)




### Steps to reproduce

i just opened add node and wrote animation player

### Minimal reproduction project (MRP)

v4.2.2.stable.official [15073afe3]
Repository: godot
Issue: Editor Unresponsive after adding a new display
Labels: bug,topic:rendering,needs testing

### Tested versions

4.2.2 stable

### System information

Windows 10, i711800H, Forward+ Vulkan, Laptop Display Resolution ‎3840 x 2160 px

### Issue description

When Godot is open in a project, then I attach a second display via e.g. hdmi or display port. I have the extension behavior specified in windows, then the Godot Editor gets placed on the new display. But it is in the wrong resolution and most importantly its unresponsive to mouse inputs. If I change the size of the window the editor scales everything as whole, but does not perform it's UI behaviors e.g. shrinking viewport, clipping inspector et cetera. It just scales everything as a whole.
see example image: 
![image](https://github.com/godotengine/godot/assets/74869542/c6da547f-b668-4ab3-9b7e-16d955807dc0)

My main display is 4k, the added display is 2K this could be a contributor to the problem


### Steps to reproduce

1. Open a Godot project on your single display, don't have a second display attached yet.
2. When open, attach the second display use projection extend display.

### Minimal reproduction project (MRP)

any empty godot project
Repository: rust
Issue: Type inference not working well with ptr mutability
Labels: T-compiler,A-inference,C-bug,S-has-mcve

<!--
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.
-->

I tried this code:

```rust
fn main() {
    let mut tmp: usize = 3;
    let immut_addr = &tmp as *const _;
    let addr = immut_addr.cast_mut();
}
```

I expected to see this happen: the code compiles successfully (but with unused warnings)

Instead, this happened: The compiler fails to infer the type of `addr` because it doesn't recognize that the type it inferred for immut_addr is always the same as the one cast_mut produces

On stable the compiler suggests to add `: *const _` to immut_addr as a type annotation, but after adding this, it errors the same way it did before.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
This happens both on stable (1.78) and on the latest nightly
```
rustc 1.80.0-nightly (1fffb2a35 2024-04-28)
binary: rustc
commit-hash: 1fffb2a355dfee65bf6aa5a9db35f33d3ee93aec
commit-date: 2024-04-28
host: x86_64-unknown-linux-gnu
release: 1.80.0-nightly
LLVM version: 18.1.4
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Output</summary>
<p>

```
error[E0699]: cannot call a method on a raw pointer with an unknown pointee type
 --> src/main.rs:6:27
  |
6 |     let addr = immut_addr.cast_mut();
  | 
```

</p>
</details>
Repository: next.js
Issue: _next/image post deployment throws "url parameter is required"
Labels: bug,Image (next/image)

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/exciting-shamir-7pnyjm

### To Reproduce

I have configured parts of my application to use the next/future/image component in Next.js version 12.3.4. In my next.config.js, I have set up the image loader with the following configuration:

```
images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: '*',
        port: '',
      },
    ],
  },
```

Issue:

Locally, the images render correctly in both development and production modes, as well as when using a Docker container.
However, after deploying the application to a server, the images are not being rendered.
The error message "url parameter is required" is displayed, even though the URL clearly contains the necessary parameters. - This behavior seems inconsistent and suggests a potential bug in the image rendering logic.

### Current vs. Expected behavior

Current Behavior:

Locally, the images render correctly in both development and production modes, as well as when using a Docker container.
After deploying the application to a server, the images are not being rendered.
The error message "url parameter is required" is displayed, even though the URL clearly contains the necessary parameters.

Expected Behavior:

Images should render correctly both locally and after deployment to the server.
The error message "url parameter is required" should not be displayed, and images should load without any issues.

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:19:22 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8112
    Binaries:
      Node: 16.20.2
      npm: 8.19.4
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.3.4
      eslint-config-next: 11.1.4
      react: 17.0.2
      react-dom: 17.0.2
```


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

Image (next/image)

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

next build (local), Vercel (Deployed), Other (Deployed)

### Additional context

I have tested this using the version: 12.3.4
Repository: ollama
Issue: Normalization of output from embedding model
Labels: feature request

When I use Ollama Embedding together with Langchain Retriever's `get_relevant_documents`, I always get a score that around 200. However, when I use HuggingFaceEmbedding, this value is between 0 and 1.

So I continued to explore the reason and, according to the official documentation, used OllamaEmbedding to vectorize both query and documents. I found that their dot product still exceeds 100:

```python
from langchain_community.embeddings import OllamaEmbeddings
import numpy as np

ollama_emb = OllamaEmbeddings(
    model="mxbai-embed-large:latest",
)
r1 = ollama_emb.embed_documents(
    [
        "Alpha is the first letter of Greek alphabet",
        "Beta is the second letter of Greek alphabet",
    ]
)
r2 = ollama_emb.embed_query(
    "What is the second letter of Greek alphabet"
)
print(np.dot(r1, r2))  
# Output: array([196.91232687, 198.68434774])
```

Therefore, I assume that they are not normalized. 

Some vector databases, such as Milvus, suggest normalizing the vectors before inserting them into the database. So, I wonder if OllamaEmbedding has plans to (or had already) support an option like HuggingFaceEmbedding's `encode_kwargs = {"normalize_embeddings": True}`, which allows the output vectors to be normalized without the need for me to manually implement this process.
Repository: material-ui
Issue: [material-ui][docs] codemods require certain version of nodejs otherwise fails with "Unexpected token ."
Labels: docs,package: material-ui,v5.x migration,support: docs-feedback

### Related page

https://mui.com/material-ui/migration/migration-v4/#run-codemods

### Kind of issue

Missing information

### Issue description

I've spent the last hour trying to run codemods but getting `Unexpected token .`. 

Eventually through trial and error I tried running older codemods and one of them told me that I need at least nodejs v12 (I was on v10). Sure enough after updating (I went to v20) the latest codemods get past the error.

### Context

Migrating from mui 4 to 5

**Search keywords**: codemod unexpected token
Repository: transformers
Issue: Add Prismatic VLMs to Transformers
Labels: New model

### Model description

Hi! I'm the author of ["Prismatic VLMs"](https://github.com/TRI-ML/prismatic-vlms), our upcoming ICML paper that introduces and ablates design choices of visually-conditioned language models that are similar to LLaVa or InstructBLIP, introducing ~50 new VLMs at the 3B/7B/13B scale that are trained with:

- Different Visual Representations (`CLIP`, `SigLIP`, `DINOv2`, fusions thereof like `SigLIP + DINOv2`)
- Different LLM Backbones (`LLaMa2`, `Vicuña v1.5`, `Mistral v0.1`, `Mistral v0.1 Instruct`, `Phi-2`, etc.)
- Different Data (e.g., the LLaVa v1.5 Data, LVIS-Instruct-4V, and more upcoming!)

Our best models outperform LLaVa v1.5 given the same data/same scale on a wide spectrum of different evaluation tasks; furthermore, we're seeing a lot of folks adopt our code for their research into new data mixtures, scaling to different LLM/Vision backbones, new projection mechanisms, and more. 

I think it'd be awesome to support these in `transformers` -- especially to tap into existing tooling for loading quantized versions of models, using `PEFT` and other tools in the HF ecosystem for adaptation/fine-tuning, and general usability of our trained models.

While we have 50+ checkpoints (all open-sourced, and loadable in our library), all currents models share a pretty common interface of using some pretrained visual extractor from `timm`, a `XXXForCausalLM` from `transformers`, and a lightweight `nn.Module` to project visual features into the LLM embedding space. As such, I'm hoping to contribute a general `modeling_prismatic.py` class that implements `PrismaticPretrainedModel` and `PrismaticForConditionalGeneration` that properly instantiates the appropriate VLM instance using the dependencies already in `transformers`.

---
I'm happy to get started with this, following the [instructions here](https://huggingface.co/docs/transformers/add_new_model#how-to-add-a-model-to--transformers), but would love help/advice on clean ways to support all the various image backbones / LLM backbones / preprocessing schemes, and verifying compatibility with existing HF tooling!

### Open source status

- [X] The model implementation is available
- [X] The model weights are available

### Provide useful links for the implementation

Prismatic Authors: @siddk, @ashwin-balakrishna96
(Potentially) Relevant Folks at HF: @merveenoyan @NielsRogge 

Useful Links: 
- [Loading Pretrained Models (in Prismatic)](https://github.com/TRI-ML/prismatic-vlms/blob/main/prismatic/models/load.py#L47)
- [Lightweight Generation REPL](https://github.com/TRI-ML/prismatic-vlms/blob/main/scripts/generate.py)
- [12 Task Evaluation Suite from Paper (for unit-testing, fully reproduces all results from our paper)](https://github.com/TRI-ML/vlm-evaluation)
- [Existing Checkpoints on HF Hub](https://huggingface.co/TRI-ML/prismatic-vlms/tree/main)
Repository: next.js
Issue: useReportWebVitals doesn't report attribution property (webVitalsAttribution experimental feature)
Labels: bug

### Link to the code that reproduces this issue

https://github.com/kirchnerto/nextjs-webvitalAttribution

### To Reproduce

1. Clone boilerplate repo under https://github.com/kirchnerto/nextjs-webvitalAttribution
2. Run npm run dev
3. Check console (webvitals will be reported but the attribution property is missing)

| Result of useReportWebVitals | Result using webvitals library attribution build directly |
|--------|--------|
| <img width="580" alt="Bildschirmfoto 2024-05-03 um 17 05 21" src="https://github.com/vercel/next.js/assets/12552012/52050f5e-2eff-4e6d-a457-f206b0b83f13"> | <img width="442" alt="Bildschirmfoto 2024-05-03 um 17 09 57" src="https://github.com/vercel/next.js/assets/12552012/911019d3-b0d8-4777-92ba-b8124021d8e8"> |

### Current vs. Expected behavior

- Using the webVitalsAttribution experimental feature (https://nextjs.org/docs/app/api-reference/next-config-js/webVitalsAttribution) should include the attribution property in the callback
- Currently the hook only reports the metric information from the base build (not the attribution build)

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 10
Binaries:
  Node: 21.7.3
  npm: 10.5.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: N/A
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed)

### Additional context

_No response_
Repository: vscode
Issue: Request to rename the tunnel that has been created
Labels: feature-request,remote-tunnel

<!-- ⚠️⚠️ 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. -->

Hi vscode team, thanks for providing such a useful feature as vscode remote tunnel. I've been using vscode remote tunnel on multiple machines recently, and two of them created tunnels with the same name (they both had names like node-*), which caused some confusion. Although I discovered that I can specify the name of the tunnel with the --name parameter, I found that there is no other place to change the name of the created tunnel, and I can only connect to the tunnel or unregister the tunnel in the Remote Explorer, can you please consider to add the function of renaming the tunnel in the future?

Thanks again for providing vscode remote tunnel, it's a great feature!