sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Issue with Power Toys Run
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

v0.85.1

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

Before update power toys run was working with both alt keys--  " left alt key + space "  and " right alt key + space " , but after update now it is only working with left alt kay . I would like you to solve this issue or bug. It was more convenient and efficient while using PC with one hand.
Power Toys Run is very useful feature and it makes very easy to search for file and any application. 



### ✔️ Expected Behavior

Before update power toys run was working with both alt keys--  " left alt key + space "  and " right alt key + space " , but after update now it is only working with left alt kay . I would like you to solve this issue or bug. It was more convenient and efficient while using PC with one hand.
Power Toys Run is very useful feature and it makes very easy to search for file and any application. 



### ❌ Actual Behavior

Before update power toys run was working with both alt keys--  " left alt key + space "  and " right alt key + space " , but after update now it is only working with left alt kay . I would like you to solve this issue or bug. It was more convenient and efficient while using PC with one hand.
Power Toys Run is very useful feature and it makes very easy to search for file and any application. 



### Other Software

_No response_
Repository: rust
Issue: impl Trait in return position implicitly captures non-`'static` type parameter despite `+ 'static`
Labels: A-diagnostics,T-compiler

### Code

```rust
trait MyTrait {}
struct MyStruct;
impl MyTrait for MyStruct {}

trait DeserTrait<'de> {}
struct DeserStruct;
impl<'de> DeserTrait<'de> for &'de DeserStruct {}

pub fn testfn<'de, D: DeserTrait<'de>>(_deserializer: D) -> impl MyTrait + 'static {
    MyStruct
}

fn test() -> impl Send {
    let deserializer = DeserStruct;
    let graph = testfn(&deserializer);
    graph
}
```

([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=90ce6dd9d1e329daf28feda317ba93ae))

### Current output

```
error[E0597]: `deserializer` does not live long enough
  --> src/lib.rs:15:24
   |
14 |     let deserializer = DeserStruct;
   |         ------------ binding `deserializer` declared here
15 |     let graph = testfn(&deserializer);
   |                 -------^^^^^^^^^^^^^-
   |                 |      |
   |                 |      borrowed value does not live long enough
   |                 argument requires that `deserializer` is borrowed for `'static`
16 |     graph
17 | }
   | - `deserializer` dropped here while still borrowed
```

### Desired output

I'm not sure, but adding `+ use<>` to the function's return type explains what the issue is actually that `impl Trait` implicitly captured the trait bound:

```
error: `impl Trait` must mention all type parameters in scope in `use<...>`
 --> src/lib.rs:9:61
  |
9 | pub fn testfn<'de, D: DeserTrait<'de>>(_deserializer: D) -> impl MyTrait + use<> + 'static {
  |                    -                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |                    |
  |                    type parameter is implicitly captured by this `impl Trait`
  |
  = note: currently, all type parameters are required to be mentioned in the precise captures list
```

### Rationale and extra context

It's impossible to debug (or google) otherwise, and I only figured it out because I remembered `+ use<>` from the stabilization blog post

### Other cases

_No response_

### Rust Version

rustc 1.82.0

### Anything else?

_No response_
Repository: TypeScript
Issue: Strange 2488 error involving overload resolution and this parameter type
Labels: Needs Investigation

### 🔎 Search Terms

yield ts2488 never iterator

### 🕗 Version & Regression Information

- This changed between versions 3.5.1 and 3.6.2

every-ts bisect gives: e8bf9584aa74aabfecb51a02edb13e3657508274 is the first bad commit

### ⏯ Playground Link

https://www.typescriptlang.org/play/?module=1&ts=5.7.0-dev.20241030#code/CYUwxgNghgTiAEAzArgOzAFwJYHtVNQB4AVAPgAoA3KCZEALnnIEp4BeU+Y5xgbyZ5d4AXwDcAKFCRYCFOmx4CJCtVoMuggJIYQMKACMIIQmgDWqHAHdUpCeJAAPAA44YGeNIDOn+AEF4vOLwwfBQ7ATkcpi4qABUTBgAFliejL6sgSFZ8ACeWCAQwPGIqOQAjMwSWcKV4kEh+uElkWjRePHkSSlpGfXZHnie7joAtk5NpRVV-bn5hfGjTtPBNRLC4kA

### 💻 Code

```ts
declare function fn<T>(value: () => T): { (): T };
declare function fn<T>(value: T): Iterable<unknown>;

export class A {
    a = fn(function* (this: A) {
        yield* fn(1); // error
    });

    b = fn(function* (this: A) {
        const temp = fn(1); // ok
        yield* temp;
    });
}

```


### 🙁 Actual behavior

```text
src/error.ts:6:16 - error TS2488: Type 'never' must have a '[Symbol.iterator]()' method that returns an iterator.

6         yield* fn(1);
                 ~~~~~
```

### 🙂 Expected behavior

No error, as in `A.b`

### Additional information about the issue

_No response_
Repository: pytorch
Issue: [ONNX][RFC] Migrate torchlib from onnxscript
Labels: module: onnx,triaged

Now that the torchlib translation library is close to stable in onnxscript, it is ready to be migrated into PyTorch so that

1. It can evolve with aten operators without having to worry about backward compatibility for different PyTorch versions
2. We can use newer opsets by default, again without having to worry about BC. The proposal is upgrade to use opset 22 for torch 2.6 or torch 2.7. This makes easier for us and users to leverage new dtypes and the corrected GroupNormalization.

## Considerations

1. We should still allow implementations in onnxscript to override those in PyTorch so we can continue to add new implementations after a torch version is released. This will be part of the stable framework apis in onnxscript.
2. We can update the default opset version for each torch version. 
3. The opinfo unit tests should be migrated as well.
Repository: three.js
Issue: Potential security issues in GitHub Actions workflows
Labels: Suggestion

# Potential security issues in GitHub Actions workflows
Hi! We are a research team from Radboud University in the Netherlands, currently working on security vulnerability analysis on GitHub Actions workflows. During our study, we found some potential issues in the workflow files of your repository and would like to bring them to your attention to help enhance security.
## Detailed Findings: 
Please find the detected potential security issues below:

## Issues Analysis: 
- **No job permissions specified** 
 This is a risk because you are not setting `permissions` key in your job to modify the default permissions granted to the `GITHUB_TOKEN` for this job, limiting access to only the minimum required level. We recommend adhering to the principle of least privilege by setting `permissions` key to declare only necessary permissions at both workflow and job levels. Check [details](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#permissions). 

## Feedback Request:
We greatly appreciate your attention to this matter. If you are willing to provide feedback, please consider completing a brief anonymous survey (google form): [Developer Perspectives on GitHub Actions workflow Security](https://forms.gle/McpgwRaqLRkKrGeW6), which will take around 3 minutes. Your feedback is invaluable in helping us gain insights on how to improve the security of the GitHub ecosystem.

**Thank you!**
Repository: go
Issue: cmd/go,x/telemetry/config: collect the set of OS versions on which the go command is run
Labels: NeedsInvestigation,GoCommand,Telemetry-Proposal,Telemetry-Accepted

When deciding to drop support for an OS version (e.g. #69839) it is useful to know how many people still use it. We can collect this information through telemetry. I propose that we do.

@findleyr
Repository: go
Issue: iter:iter: TestPull2/3 failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "iter:iter" && test == "TestPull2/3"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8735173623505772561)):

    === RUN   TestPull2/3
        pull_test.go:108: have -1 extra goroutines, want 0
        pull_test.go:108: have -1 extra goroutines, want 0
        pull_test.go:110: have -1 extra goroutines, want 0
        pull_test.go:115: have -1 extra goroutines, want 0
    --- FAIL: TestPull2/3 (0.00s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: rust
Issue: Document `compile_fail,E1234` syntax for marking compile_fail tests as failing with a particular error
Labels: T-rustdoc,A-docs,A-doctests


It's possible to mark tests as failing with a particular error. This largely seems to be used [within rustc itself](https://github.com/search?q=repo%3Arust-lang%2Frust%20compile_fail%2CE&type=code).

`````rust
/// ```compile_fail,E0425
///  let x = x;
/// ```
`````


Ought we document this in the rustdoc book somewhere? It currently [does not appear to be](https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html).
Repository: vscode
Issue: vscode.dev asking for Settings Sync sign in again after enabling Cloud Changes
Labels: bug,settings-sync,vscode.dev,microsoft-authentication

From @sandy081 originally

- Opened a new insiders.vscode.dev window enabled settings sync 
- Opened a remote github repo in that window and turned on cloud changes feature
- Opened new insiders.vscode.dev window to connect to tunnels using MSFT account.
🐛 I was asked to sign in to sync settings
- In the first window, I connected to azure repo
🐛 I was asked to sign in to sync settings

I can repro this. The interesting thing is that it seems like we do return a valid Settings Sync token... so I wonder if this is maybe something similar to https://github.com/microsoft/vscode/issues/229456
Repository: next.js
Issue: Page with ISR (generateStaticParams() and dynamicParams=true) is taking too long for not generated content
Labels: bug,Runtime

### Link to the code that reproduces this issue

https://github.com/vojtechmares/next-isr-bug

### To Reproduce

1. Deploy Next.js in Docker to Kubernetes
2. Use ISR route with generateStaticParams() to pregenerate paths
3. Use `dynamicParams=true`
4. Try navigating to a page that has not been pregenerated (504 on Ingress-NGINX)

- Next cache (`.next/cache`) is Kubernetes "emptyDir" ephemeral volume (not persistent between deployments or different instances)

My `Dockerfile`:

```dockerfile
# syntax=docker/dockerfile:1
FROM node:22-alpine AS base

FROM base AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat

WORKDIR /app

RUN corepack enable pnpm

COPY package.json pnpm-lock.yaml* ./
RUN pnpm install


FROM base AS builder

WORKDIR /app

RUN corepack enable pnpm

COPY --from=deps /app/node_modules ./node_modules
COPY . .

ARG CMS_API_URL="https://cms.mareshq.com/api"
ARG CMS_API_TOKEN

# COPY .env.production.sample .env.production
RUN pnpm run build

FROM base AS runtime

WORKDIR /app

ENV NODE_ENV=production

RUN addgroup -g 1001 -S nodejs
RUN adduser -S nextjs -u 1001

COPY --from=builder /app/public ./public

# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
COPY --from=builder --chown=nextjs:nodejs /app/images ./images
COPY --from=builder --chown=nextjs:nodejs /app/content ./content

USER nextjs

EXPOSE 3000

ENV PORT=3000
ENV HOSTNAME=0.0.0.0

CMD ["node", "./server.js"]
```

### Current vs. Expected behavior

I expect the page to generate and save itself into cache for later use, instead the page is taking too long to load forcing ingress-nginx to return 504 - Gateway timeout

This is an issue only on Kubernetes, local development works as expected.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 22.8.0
  npm: 10.8.2
  Yarn: N/A
  pnpm: 9.12.2
Relevant Packages:
  next: 15.0.2 // Latest available version is detected (15.0.2).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 4.9.5
Next.js Config:
  output: standalone
```


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

Runtime

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

Other (Deployed)

### Additional context

_No response_
Repository: deno
Issue: Ability to require a file in the module graph without permissions
Labels: feat,permissions

Some work on this here, but not exactly done yet: https://github.com/denoland/deno/pull/26558

Maybe that involves moving stuff like `Module._findPath` to Rust.
Repository: pytorch
Issue: [RFC][Pipelining] RNG state communication, avoid seed checkpoint
Labels: oncall: distributed,triaged

### Background

During model initialization, each PP stage initializes their own portion of the model.  This is preferrable over initializing the model all in one place and then transferring it to each stage, due to the high memory requirements of initializing an entire large model in one place.

Ignoring random states, each PP stage would start from the same RNG seed and each model chunk could have similar or even identical weights.  This would likely lead to numerical issues during training.  It also makes loss-curves of PP training less comparable with loss-curves of non-PP training, which lowers confidence in PP training and adds obstacles to debugging. 

Currently, torchtitan implements a workaround where the whole model is initialized on CPU offline in one process, saved to disk, and then loaded by each pipeline stage.  (Loading does not require loading the whole model into ram, only the portion used locally).  This results in consistent model initialization but at a runtime and UX cost of generating and using the seed checkpoint.

### Proposal
Instead, we can manage the RNG state automatically inside torch.pipelining, to avoid identical weights.

**Option 1. Use different seeds per stage**

We could simply re-seed the RNG on each PP stage, without worrying about actual initialization parity with non-PP training.

This option is potentially faster since it allows each stage to initialize in parallel.  It should also gaurantee 'safe' initializations, since each stage would have no chance of duplicate or similar init weights.  However, this initialization would not 'match' the initialization values for non-PP training, leading to less comparability between loss curves.

**Option 2. Sequentially initialize**

After stage 0 initializes, it could summarize its own RNG states and send them to stage 1, which in turn loads the states and initializes, then saves new states and sends them to stage 2, etc.  This results in serializing initialization, which would lead to an observable slowdown at startup time, but also matches perfectly (bitwise) with the initialization values that would be observed in a non-PP training.

This option requires more complexity:
- virtual-stages means more than one round of communication across PP ranks is needed
- V-schedules means sometimes, neighboring stages exist on the same rank and thus seed communication should be skipped for those cases

Note: seed save/restore can be implemented like this: https://gist.github.com/wconstab/6bdea055eff9a7904fdae595c6cdac6e

It might be worth implementing both options and experimenting with the tradeoffs.  I suspect most users would prefer option 1 if its significantly faster, and we can prove it leads to equally accurate training. 

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @d4l3k @c-p-i-o @tianyu-l
Repository: angular
Issue: Ability to set environment/configuration values at runtime instead of buildtime
Labels: feature,area: core,core: bootstrap,feature: votes required

### Which @angular/* package(s) are relevant/related to the feature request?

_No response_

### Description

Angular should provide a common and supported mechanism for the setting of configuration values at runtime (or at least start up time).

Currently, there are multiple implementations / workarounds for this problem. 

**Can we get well-supported mechanism maintained by the Angular Team?**

[Multiple releases using the same, but configurable, Angular Standalone Application build](https://timdeschryver.dev/blog/multiple-releases-using-the-same-but-configurable-angular-standalone-application-build#)

[Compile-time vs. Runtime configuration of your Angular App](https://juri.dev/blog/2018/01/ng-app-runtime-config/)

[Angular, Docker & Nginx: Build once, Deploy anywhere.](https://medium.com/@fabiozuin/build-once-deploy-anywhere-with-angular-17-bf477c49668f)

https://www.npmjs.com/package/@ngx-env/builder

https://www.npmjs.com/package/angular-runtime-config

https://www.npmjs.com/package/@igorissen/angular-env-builder

There was a request: 

https://github.com/angular/angular/issues/52994
ability to use/change environment files after build

to allow the setting of environment-level values at runtime instead of build time.  I believe that was mistakenly marked as a duplicate of:

https://github.com/angular/angular-cli/issues/4318
Request: Method to pass environment variables during build vs file.




### Proposed solution

Include one of the existing user-created implementations described above in Angular with suitable documentation.

Or, at least, pick one of the above and link to it from the Angular documentation.

### Alternatives considered

Use one of the existing user-created implementations.
Repository: ollama
Issue: Reporting for not working models, uploaded by users
Labels: feature request,ollama.com

Hi, can you add in your library on the side, option for reporting not working models? For example, one of them is this model:

https://ollama.com/leeplenty/lumimaid-v0.2:12b 

It just spouts nonsense.
Repository: excalidraw
Issue: Arrow navigation through flow chart is not intuitive
Labels: UX/UI,keyboard

While the next flowchart node is created where the user points with the arrow, navigating the flowchart tree does not respect this, which is not very intuitive.

Instead, consider navigating to the closest node in the given direction by the pressed arrow (i.e. based on distance from/to the center).

Note that this also might not be constrained only to the flowchart itself, but could enable keyboard nav for any elements in the scene.
Repository: pytorch
Issue: Plan to support “discrete” dynamic dimension on torch.export
Labels: triaged,oncall: pt2,module: dynamic shapes,export-triaged,oncall: export

### 🚀 The feature, motivation and pitch

Is there any plan for the `torch.export` team to support the set-based dynamism in addition to range-based dynamism?

Below is a small repro code for discrete `Dim` failure mode. The `torch._check` is supposed to work within discrete sets, but it fails.

```python
import torch

class Model(torch.nn.Module):
    def forward(self, x):
        # torch._check(2 <= x.shape[0] <= 3)  # this works
        torch._check(x.shape[0] in {2, 3})
        return x

torch.export.export(
    Model(),
    (torch.zeros(2),),
    dynamic_shapes={
        "x": {
            0: torch.export.Dim("discrete", min=2, max=3)
        }
    }
)
```

### Alternatives

_No response_

### Additional context

The conventional use of the dynamic dimension on `torch.export` is to use the continuum of the variables like `Dim(min=3, max=12)`, which is suited for accepting dynamic batch size for example.

Our team is trying to support some level of “discrete” dynamism on the neural network, for providing “image” mode and “video” mode for the vision transformer.

To show some idea behind this, here is a pseudocode for doing the operation. The specifics are not same in detail.

```python
import torch

class ImgVideoModel(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.emb_dim = 8
        self.vid_len = 12
        self.img_pos_embed = torch.nn.Parameter(torch.zeros(1, 1, self.emb_dim))
        self.vis_pos_embed = torch.nn.Parameter(torch.zeros(1, self.vid_len, self.emb_dim))
        self.projector = TransformerWithLargeParameters(...)
    def forward(self, x):
        # x: [B, 1, C] or [B, 12, C]
        B, T, C = x.size()
        x = torch.cond(T == 1, lambda t: t + self.img_pos_embed, lambda t: t + self.vis_pos_embed, (x,))
        # This is the intended behavior of the model.
        # if T == 1:
        #     x = x + self.img_pos_embed
        # else:
        #     assert T == 12
        #     x = x + self.vis_pos_embed
        x = self.projector(x)
        return x

inp = torch.rand(2, 12, 8)
bs = torch.export.Dim("bs")
seq_len = torch.export.Dim("seq_len", min=1, max=12)
ep = torch.export.export(ImgVideoModel(), (inp,), dynamic_shapes={"x": {0: bs, 1: seq_len}})
print(ep)
```

The `torch.export` immediately fails, because the second `lambda` function inside `torch.cond` is not compatible with the length other than 12.

Since there is no way to enforce the model to accept the “set” based constraints other than the continuum of the shapes, our team has no way other than exporting two almost-identical models with sharing large sets of common transformer weights.

cc @ezyang @chauhang @penguinwu @bobrenjc93 @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4
Repository: kubernetes
Issue: Default Scheduler's node_name Plugin Doesn't Filter Out Any Nodes
Labels: sig/scheduling,needs-kind,needs-triage

### What happened?

Hello, 
We observed that the ```node_name``` scheduler plugin might not be functioning as expected.

In the current [implementation](https://github.com/kubernetes/kubernetes/blob/16f9fdc7057e1f69ff1a44e3dbbcf7b994c3cd29/pkg/scheduler/framework/plugins/nodename/node_name.go#L70C2-L77C2), this plugin’s ```Filter``` function checks if a given node’s ```name``` matches the scheduling pod’s ```spec.nodeName```. So this plugin is expected to filter out any node whose ```name``` does not match at the ```Filter``` stage,

However, according to the Kubernetes [documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodename) and our tests, any pod with a non-empty ```spec.nodeName``` will bypass the default scheduler. 

This leads to a case: whenever the ```node_name``` plugin is invoked (at the ```Filter``` stage), the pod’s ```spec.nodeName``` must be empty. Then the plugin won't filter out any nodes, making it not functioning.

We're a bit confused about this and want to clarify: is this the correct behavior of the ```node_name``` plugin, or are there scenarios that it would behave differently and meaningful? Thanks for your answer!

### What did you expect to happen?

If our understanding is correct, 
then we think this plugin should be removed, as it does not filter out any nodes.

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

1. By creating a pod with a non-empty ```spec.nodeName```, the scheduler will ignore this pod.
2. Only when creating a pod with an empty ```spec.nodeName```, the scheduler will schedule this pod.

### Anything else we need to know?

/sig scheduling 

### Kubernetes version

1.31

### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


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

<details>

</details>


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

<details>

</details>