sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: `GNOME_LIBSECRET` chosen but libsecret isn't available in a fresh Debian install
Labels: bug,upstream,freeze-slow-crash-leak,linux,electron

A spin off of:
https://github.com/microsoft/vscode/issues/195800#event-13646500425

Based on some comments in there, and also @Tyriar saying that he tried to install `libsecret-1-dev` to no avail... it seems that these versions of Debian do not have libsecret installed.

As a result, they should not see this log:
```
[8562:0725/063027.080560:VERBOSE1:key_storage_util_linux.cc(51)] Password storage detected desktop environment: GNOME
[8562:0725/063027.080576:VERBOSE1:key_storage_linux.cc(118)] Selected backend for OSCrypt: GNOME_LIBSECRET
```

So it's fairly clear that our backend detection logic in the runtime has a bug because GNOME_LIBSECRET shouldn't be chosen if it's not available.
Repository: pytorch
Issue: FlopCounterMode requires `tabulate` dependency
Labels: triaged,module: python frontend

Error message is:
```
File ~/dev/opt-cuda4/pt-opt-cuda4/torch/utils/flop_counter.py:632, in FlopCounterMode.get_table(self, depth)
    629 if depth is None:
    630     depth = 999999
--> 632 import tabulate
    633 tabulate.PRESERVE_WHITESPACE = True
    634 header = ["Module", "FLOP", "% Total"]

ModuleNotFoundError: No module named 'tabulate'
```
We should make this better.

cc @albanD
Repository: pytorch
Issue: Default argument removal for python dispatch fails for pin_memory on factory functions
Labels: triaged,module: __torch_dispatch__,module: library

Factory function default argument parsing for torch_dispatch and python dispatch adds a pin_memory argument:

```python
import torch
from torch.library import _scoped_library

with _scoped_library("_", "IMPL") as my_lib:
    orig_args = ((2, 2),)
    orig_kwargs = {"device": torch.device("fpga"), "dtype": torch.float64}

    def my_fallback(op, *args, **kwargs):
        print(kwargs)
        assert "pin_memory" not in kwargs
        # Any return is fine here
        return torch.empty(*args)

    # Use PrivateUse1 here as there are no key-specific kernels
    # registered and so our fallback will always get called
    my_lib.fallback(my_fallback, "FPGA")

    torch.empty(*orig_args, **orig_kwargs)
```

cc @Chillee @ezyang @zou3519 @samdow @anjali411
Repository: go
Issue: mime: incorrect mime-type for .mjs files on windows (text/plain instead of application/javascript)
Labels: OS-Windows,NeedsInvestigation

### Go version

1.21

### What did you see happen?

This is identical to #32350 but .mjs instead of .js (I would have commented on the other thread, but it is locked to collaborators only). 

.mjs is a fairly common javascript file extension for es modules (example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#aside_%E2%80%94_.mjs_versus_.js)

I'm wondering if it would be acceptable to implement the same workaround found [here](https://github.com/golang/go/blob/master/src/mime/type_windows.go#L40), but for .mjs?

i.e. I could submit a PR to do:
```
		// There is a long-standing problem on Windows: the
		// registry sometimes records that the ".js" extension
		// should be "text/plain". See issue #32350. While
		// normally local configuration should override
		// defaults, this problem is common enough that we
		// handle it here by ignoring that registry setting.
		if (name == ".js" || name == ".mjs") && (v == "text/plain" || v == "text/plain; charset=utf-8") {
			continue
		}
```

### What did you expect to see?

.mjs files should not be served with `text/plain` due to misconfigured registry
Repository: deno
Issue: Shell completions not working in VSCode 
Labels: needs info

Version: Deno 1.45.1

I followed this [guide](https://docs.deno.com/runtime/manual/getting_started/setup_your_environment/#zsh-example-with-ohmyzsh-and-antigen) to setup shell completions. They just work on my Warp external terminal, but not in the VSCode integrated one.
Repository: pytorch
Issue: low-latency, intra-node allreduce algorithms on ROCm
Labels: oncall: distributed,module: rocm,triaged

### 🚀 The feature, motivation and pitch

Porting over one-shot, two-shot kernels to ROCm MI300x similar to https://github.com/pytorch/pytorch/pull/114001

cc: @japarada @ianferreira

These are the results we see on H100, we would love to see these kernels on ROCm too. 

As discussed with slack, i am looking into the complexity of porting this over rn and seeing if i can implement this myself with a minimal amount of support from AMD.

# NCCL_RING vs one-shot h100 https://github.com/pytorch/pytorch/issues/131739#issuecomment-2251417189
![image](https://github.com/user-attachments/assets/33979cfc-04f8-422c-b8d9-53b7806fb244)
### Alternatives

_No response_

### Additional context

_No response_

cc @XilunWu @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Repository: ui
Issue: [bug]:  Label Component and FormLabel element in Form Component Does Not Support disabled Prop
Labels: bug

### Describe the bug

 In the Example code below the FormLabel component is used to label form fields. However, it does not currently support the disabled prop, which is causing inconsistencies in the UI when the form is in a loading state for example.

 And same issue with Label component dose not support the disable attribute 

```
        <FormField
          control={form.control}
          name="message"
          render={({ field }) => (
            <FormItem>
              <FormLabel disabled={loading}>Message</FormLabel>
              <FormControl>
                <Textarea placeholder="Your message" {...field} disabled={loading} />
              </FormControl>
              <FormMessage />
            </FormItem>
          )}
        />
```

Steps to Reproduce:



### Affected component/components

Label, Form, FormLabel

### How to reproduce

Add a `disabled ` attribute to Label element or FormLabel like this : 

<FormLabel disabled>Message</FormLabel>

or 

<Label disabled>Message</Label>

### Codesandbox/StackBlitz link

_No response_

### Logs

```bash
Type '{ children: string; disabled: boolean; }' is not assignable to type 'IntrinsicAttributes & Omit<LabelProps & RefAttributes<HTMLLabelElement>, "ref"> & RefAttributes<HTMLLabelElement>'. Property 'disabled' does not exist on type 'IntrinsicAttributes & Omit<LabelProps & RefAttributes<HTMLLabelElement>, "ref"> & RefAttributes<HTMLLabelElement>'.ts(2322)
(property) disabled: boolean
```


### System Info

```bash
Appeared in VsCode IDE
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: vscode
Issue: check for updates not working in vscode insider
Labels: bug,install-update,linux,snap

<!-- ⚠️⚠️ 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. -->
- Version: 1.92.0-insider
Commit: 50560b991207e2bb70a6e177f2c2e88949a01e6c
Date: 2024-07-25T05:04:21.378Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: 12.4.254.20-electron.0
OS: Linux x64 6.8.0-39-generic snap
- OS Version: Ubuntu 24.04

Steps to Reproduce:

1. Click on Check for Updates
2. no popup or anything related to update
Repository: pytorch
Issue: [torch.compile] Unused differentiable outputs lead to unnecessary gradient computation when compared to eager
Labels: triaged,oncall: pt2,module: aotdispatch,module: pt2-dispatcher

The following code:
```py
import torch

@torch.compile(backend="aot_eager")
def f(xs): # E: Function is missing a type annotation  [no-untyped-def]
    result = []
    for x in xs:
        result.append(x.sin())
    return result

xs = [torch.randn([], requires_grad=True) for _ in range(3)]
ys = f(xs)
ys[0].backward()
```
produces the following backward graph:
```
def forward(self, primals_1: "f32[][]cpu", primals_2: "f32[][]cpu", primals_3: "f32[][]cpu", tangents_1: "f32[][]cpu", tangents_2: "f32[][]cpu", tangents_3: "f32[][]cpu"):
     # File: /home/rzou/dev/debug-cpu0/pt-debug-cpu0/foo.py:7 in f, code: result.append(x.sin())
    cos: "f32[][]cpu" = torch.ops.aten.cos.default(primals_3);  primals_3 = None
    mul: "f32[][]cpu" = torch.ops.aten.mul.Tensor(tangents_3, cos);  tangents_3 = cos = None
    cos_1: "f32[][]cpu" = torch.ops.aten.cos.default(primals_2);  primals_2 = None
    mul_1: "f32[][]cpu" = torch.ops.aten.mul.Tensor(tangents_2, cos_1);  tangents_2 = cos_1 = None
    cos_2: "f32[][]cpu" = torch.ops.aten.cos.default(primals_1);  primals_1 = None
    mul_2: "f32[][]cpu" = torch.ops.aten.mul.Tensor(tangents_1, cos_2);  tangents_1 = cos_2 = None
    return [mul_2, mul_1, mul]
```
We're only differentiating through one output, so there should only be a single call to cos. Instead, AOTAutograd is materializing all of the None gradients as zeros.

cc @ezyang @chauhang @penguinwu @bdhirsh
Repository: godot
Issue: GDScript function calls have unexpected overhead
Labels: discussion,topic:gdscript,performance

### Tested versions

4.2.2 stable

### System information

Linux Vulkan API 1.3.277 Forward Mobile, Cpu Ryzen 4800

### Issue description

Hello, this is my first issue
the code with functions has low performance,
in other languages (rust, python), the same code gives better performance

When assembled, the performance increases, but not much (0,16s-0.17s and 0.6s-0.8s)

this behavior can be considered a bug because the difference is in other languages, but only 3-8% (for rust), 15-24% (for python)

need to be tested on different platforms

```gdscript

extends Node

var iter : int = 1_000_000
var test_strick : float = 0.0
var time : float = 0.0

func sqrt_v1(num:int) -> float:
	return num**0.5
	
func _ready() -> void:
	for d:int in range(5):
		time = Time.get_unix_time_from_system()
		for  i:int in range(iter):
			test_strick += sqrt_v1(i)
		print(Time.get_unix_time_from_system() - time, " =1= ",test_strick)
		time = Time.get_unix_time_from_system()
		for i:int in range(iter):
			test_strick+= i**0.5
		print(Time.get_unix_time_from_system() - time, " =2= ",test_strick)
``` 
output
0.22625708580017 =1= 666666166.458842
0.07334899902344 =2= 1333332332.91772
0.22873187065125 =1= 1999998499.37655
0.07424306869507 =2= 2666664665.8354
0.22937297821045 =1= 3333330832.29431
0.07326412200928 =2= 3999996998.75321
...

### Steps to reproduce

1) Create empty project with 1 node and 1 script
2) paste code
3) run 

### Minimal reproduction project (MRP)

N/A
Repository: pytorch
Issue: xpu: add check for supported devices to xpu initialization and torch.xpu.is_available()
Labels: triaged,module: intel,module: xpu

As of now, https://github.com/pytorch/pytorch/commit/bf6aae1468659d611959d94c314639e402edc3fe, XPU backend supports limited set of GPU devices, PVC, Meteor Lake. However, XPU backend does not check for supported device types and backend will be reported to be supported on a lot more Intel GPU devices, for example, on Alder Lake. However, trying to run backend on such devices will actually fail. On Alder Lake I get:
```
RuntimeError: Kernel is incompatible with all devices in devs
```

Can XPU backend, please, start to check whether it can actually run on the underlying Intel GPU, fail to initialize and report `False` in `torch.xpu.is_available()` if it can't? That's important because sometimes there are device agnostic use cases. For example - consider below Huggingface example which specifies just `device_map=auto`. User's intent might be to run on CPU or on CUDA, but it might get dispatched to unsupported Intel GPU and fail.

```
import transformers
import torch

model_id = "meta-llama/Meta-Llama-3-8B-Instruct"

pipeline = transformers.pipeline(
    "text-generation",
    model=model_id,
    model_kwargs={"torch_dtype": torch.bfloat16, "max_memory": {0: 1.0e+10}},
    device_map="auto",
)

messages = [
    {"role": "system", "content":
      "You are a pirate chatbot who always responds in pirate speak!"},
    {"role": "user", "content": "Who are you?"},
]

terminators = [
    pipeline.tokenizer.eos_token_id,
    pipeline.tokenizer.convert_tokens_to_ids("
")
]

outputs = pipeline(
    messages,
    max_new_tokens=256,
    eos_token_id=terminators,
    do_sample=True,
    temperature=0.6,
    top_p=0.9,
)
print(outputs[0]["generated_text"][-1])
```

CC: @gujinghui @EikanWang @fengyuan14 @guangyey @jgong5

cc @frank-wei @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @gujinghui @EikanWang @fengyuan14 @guangyey
Repository: pytorch
Issue: xpu: intel conda channel is not available
Labels: module: binaries,triaged,module: intel,module: xpu

### 📚 The doc issue

https://github.com/pytorch/pytorch/blob/fba24252bdeaba494c8f553c2980e73d5c2ab835/README.md?plain=1#L210

Intel channel on conda is not available: 

```
(my-pytorch) rscohn1@gkdse-dnp-23:pytorch$ conda install intel::mkl-static intel::mkl-include
Channels:
 - https://software.repos.intel.com/python/conda
 - conda-forge
 - intel
Platform: linux-64
Collecting package metadata (repodata.json): failed

UnavailableInvalidChannel: HTTP 403 FORBIDDEN for channel intel <https://conda.anaconda.org/intel>

The channel is not accessible or is invalid.

You will need to adjust your conda configuration to proceed.
Use `conda config --show channels` to view your configuration's current state,
and use `conda config --show-sources` to view config file locations.


(my-pytorch) rscohn1@gkdse-dnp-23:pytorch$
```



### Suggest a potential alternative/fix

It works if you add the intel repo:
```
conda config --add channels https://software.repos.intel.com/python/conda/
```

and omit the intel channel name:
```
(my-pytorch) rscohn1@gkdse-dnp-23:pytorch$ conda install mkl-static mkl-include
Channels:
 - https://software.repos.intel.com/python/conda
 - conda-forge
Platform: linux-64
Collecting package metadata (repodata.json): done
Solving environment: done

## Package Plan ##

  environment location: /shared/tpi0/users/rscohn1/miniforge3/envs/my-pytorch

  added / updated specs:
    - mkl-include
    - mkl-static


The following NEW packages will be INSTALLED:

  intel-cmplr-lib-ur python/conda/linux-64::intel-cmplr-lib-ur-2024.2.0-intel_981
  intel-openmp       python/conda/linux-64::intel-openmp-2024.2.0-intel_981
  mkl-include        python/conda/linux-64::mkl-include-2024.2.0-intel_663
  mkl-static         python/conda/linux-64::mkl-static-2024.2.0-intel_663
  tbb                python/conda/linux-64::tbb-2021.13.0-intel_628


Proceed ([y]/n)?
```

I also see some discussion of getting the packages from pip. Eliminating the use of conda would be less confusing: https://github.com/pytorch/pytorch/pull/130026


cc @seemethere @malfet @osalpekar @atalman @frank-wei @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10 @gujinghui @EikanWang @fengyuan14 @guangyey
Repository: kubernetes
Issue: Add automatic detection of custom CEL types added to Kubernetes, use to verify cost is computed
Labels: sig/api-machinery,triage/accepted

Per https://github.com/kubernetes/kubernetes/pull/126359#discussion_r1691976115 we should scan all our kubernetes libraries to find custom types and use that instead of a hard coded list in `cost_test.go`.
Repository: rust
Issue: Surprising behavior of `'label: for`
Labels: A-lints,A-diagnostics,C-bug

Consider the following code:

```rust
fn main() {
    let mut s = 0;
    'label: for i in 0..100 {
        println!("s: {s}, i: {i}");
        s += 1;

        if i == 3 {
            continue 'label;
        }
    }
}
```

The expectation was that it would work like the following C code:

```c
#include <stdio.h>
int main() {
    int s = 0;
    label: for (int i = 0; i < 100; i++) {
        printf("s: %d, i: %d\n", s++, i);
        if (i == 3) {
            goto label;
        }
    }
}
```

Instead, the continuation at the `for` just advances the loop counter of the `for`, running the expression inside it. This is surprising behavior to anyone who is familiar with this C idiom, as while `goto` is... not _exactly_ equal to `continue`, for many purposes we make `continue` and `break` a "controlled goto" exactly so that we can support these idioms. The code that achieves this idiom is, instead:

```rust
fn main() {
    let mut s = 0;
    'label: loop {
        for i in 0..100 {
            println!("{s}, {i}");
            s += 1;
    
            if i == 3 {
                continue 'label;
            }
        }
        break;
    }
}
```

This "`continue 'label` but it's equal to `continue`" pattern could be recognized and linted on as it is almost never what is wanted, much as we warn about other useless syntax.

### Meta
`rustc --version --verbose`:
```
rustc 1.82.0-nightly (cefe1dcef 2024-07-22)
binary: rustc
commit-hash: cefe1dcef0e21f4d0c8ea856ad61c1936dfb7913
commit-date: 2024-07-22
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 18.1.7
```
Repository: flutter
Issue: [embedder] Need a mechanism to configure microtasks to run on the platform thread.
Labels: P2,team-engine,triaged-engine

The iOS/Android embedders handle this by setting up fml::MessageLoop on the platform thread, but there is no equivalent API for embedders, which prevents us from making ui thread == platform thread on desktop.

See: https://github.com/flutter/engine/pull/53747

@chinmaygarde
Repository: go
Issue: proposal: syscall: support process sandboxing using Landlock on Linux
Labels: Proposal

### Proposal Details

This is a continuation of https://github.com/golang/go/issues/47049, which was retracted with the following comment:

>Treating this as retracted, but it seems like we reached a reasonable API change. What we don't know is whether it is good enough in practice or whether anyone needs it. If someone does need it, please feel free to open a new proposal and we can continue this discussion. Thanks.

I have a Golang binary that gets deployed once and then it `os/exec`'s the [`git`](https://git-scm.com/docs/git) binary with various arguments under the hood hundreds of thousands of times to process lots of untrusted repositories on the internet.

This `git` invocation ideally should only access a single temporary directory that we create for it and doesn't need anything else, yet the invoking Golang binary needs an access to much more files and directories, including the networking. So basically, I'm looking to exercise the least privilege principle here.

Unfortunately due to Go's runtime and the use of threads, it seems to be somewhat complicated to use [`fork(2)`](https://man7.org/linux/man-pages/man2/fork.2.html), and even if it would work, it would mean re-inventing the `os/exec`.

It'd be great if one could do something like this on instead:

```golang
cmd.SysProcAttr = &syscall.SysProcAttr{
    UseLandlock:     true,
    LandlockRuleset: fd,
}
```

There's a nice [`github.com/landlock-lsm/go-landlock`](github.com/landlock-lsm/go-landlock) package with a very ergonomic API that can be adapted to emit the ruleset file-descriptor instead of restricting the current process with a couple of line changes.

To get the `fd` for the `*syscall.SysProcAttr` above, the user might do something like this:

```golang
fd, err := landlock.V5.BestEffort().OnlyPaths().Ruleset(
    landlock.ROFiles("/usr"),
    landlock.RWFiles(tmpDir),
)
```

/cc @rsc
Repository: rust
Issue: `slice.iter().take_while(f).count()` produces suboptimal assembly code
Labels: A-LLVM,T-compiler,I-heavy,C-optimization

<!--
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:

(1)

```rust
pub fn trim_starting_odd_elems_while(slice: &[u32]) -> (usize, &[u32]) {
    let mut start_idx = 0;
    while start_idx < slice.len() {
        if slice[start_idx] % 2 != 0 {
            break;
        }
        start_idx += 1;
    }
    (start_idx, &slice[start_idx..])
}

pub fn trim_starting_odd_elems_iter(slice: &[u32]) -> (usize, &[u32]) {
    let start_idx = slice
        .iter()
        .position(|f| *f % 2 != 0)
        .unwrap_or(slice.len());
    (start_idx, &slice[start_idx..])
}

pub fn trim_starting_odd_elems_iter_count(slice: &[u32]) -> (usize, &[u32]) {
    let start_idx = slice
        .iter()
        .take_while(|f| *f % 2 != 0)
        .count();
    (start_idx, &slice[start_idx..])
}
```

(2)

```rust
pub fn trim_ending_odd_elems_while(slice: &[u32]) -> (usize, &[u32]) {
    let mut end_idx = slice.len();
    while end_idx > 0 {
        if slice[end_idx - 1] % 2 != 0 {
            break;
        }
        end_idx -= 1;
    }
    (end_idx, &slice[..end_idx])
}

pub fn trim_ending_odd_elems_iter(slice: &[u32]) -> (usize, &[u32]) {
    let end_idx = slice
        .iter()
        .rposition(|f| *f % 2 != 0)
        .map_or(0, |i| i + 1);
    (end_idx, &slice[..end_idx])
}

pub fn trim_ending_odd_elems_iter_count(slice: &[u32]) -> (usize, &[u32]) {
    let end_skip = slice
        .iter()
        .rev()
        .take_while(|f| *f % 2 != 0)
        .count();
    let end_idx = slice.len() - end_skip;
    (end_idx, &slice[..end_idx])
}
```

I expected to see this happen: All three of the functions in (1) or (2) should produce the same assembly.

Instead, this happened: In (1), `trim_starting_odd_elems_iter` produces the shortest (and probably fastest) assembly. In (2), `trim_ending_odd_elems_while` produces the shortest assembly. (See [playground link](https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=76883bd72397510d4044e5c0759dd08a))

### 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`:
```
rustc 1.82.0-nightly (cefe1dcef 2024-07-22)
binary: rustc
commit-hash: cefe1dcef0e21f4d0c8ea856ad61c1936dfb7913
commit-date: 2024-07-22
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 18.1.7

```

Also happens on rustc 1.79.0.

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
Backtrace: N/A