sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Compile bug with isin assume_unique=True
Labels: triaged,oncall: pt2,module: aotdispatch,module: pt2-dispatcher

### 🐛 Describe the bug

I have the following strange compile bug with isin and assume_unique=True.

Without compiling, the code runs fine for any `n` and `assume_unique` value.

When compiling, the code runs fine for any `n` when `assume_unique=False`. When `assume_unique=True`, the code runs fine for `n < 12`, and errors for `n >= 12`.

```python
import torch
from torch import nn, Tensor

symbols = 2
bars = 3

all_false = torch.full((symbols, bars), False, device="cuda")  # (symbols, bars)

@torch.compile
class MyModel(nn.Module):
    def __init__(self, n: int, assume_unique: bool) -> None:
        super().__init__()
        self.ignored_symbols = torch.arange(n, device="cuda")
        self.assume_unique = assume_unique

    def forward(
        self,
        symbol_ids: Tensor,  # (symbols, 1)
    ) -> Tensor:
        mask_ignored_symbols = torch.isin(
            symbol_ids, self.ignored_symbols, assume_unique=self.assume_unique
        )  # (symbols, 1)

        return all_false | mask_ignored_symbols

# +50 to avoid the ignored symbols, not important
symbol_ids = torch.arange(symbols, device="cuda").unsqueeze(1) + 50
print(symbol_ids)

model = MyModel(n=12, assume_unique=True).cuda()

output: Tensor = model(symbol_ids)
```

In terms of ablation, the code compiles fine for `backend="eager"` and `backend="aot_eager"`, but fails with `backend="aot_eager_decomp_partition"`.

### Error logs

The following error is what appears, after the long stack trace.

```
torch._dynamo.exc.BackendCompilerFailed: backend='inductor' raised:
RuntimeError: Attempting to broadcast a dimension of length 2 at -1! Mismatching argument at index 1 had torch.Size([2]); but expected shape should be broadcastable to [2, 3]

While executing %or_ : [num_users=1] = call_function[target=operator.or_](args = (%g_all_false_, %mask_ignored_symbols), kwargs = {})
Original traceback:
  File "/home/ilan/monorepo/src/Ayin3/foo.py", line 34, in forward
    return all_false | mask_ignored_symbols
```

### Versions

Manual versions:
OS: Arch Linux
Python 3.12.7 (also reproduced on 3.13)
Torch version: 2.6.0.dev20241209+cu126 (also reproduced on latest stable 2.5)

---
The automatic script gives me the following error:
```
...
  File "/home/ilan/monorepo/collect_env.py", line 470, in run_with_pip
    line for line in out.splitlines() if any(name in line for name in patterns)
                     ^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'splitlines'
```

cc @chauhang @penguinwu @zou3519 @bdhirsh @yf225
Repository: rust
Issue: BTreeMap documentation has confusing wording about binary search tree performance issues
Labels: A-docs,C-bug,T-libs

### Location

https://github.com/rust-lang/rust/blob/f6cb952dc115fd1311b02b694933e31d8dc8b002/library/alloc/src/collections/btree/map.rs#L48-L49

### Summary

In the discussion of performance issues of binary search trees, it is written that `[...] every single comparison should be a cache-miss.`

I think this is confusing in the following ways:
- Comparisons are not cache misses. They operate on values which are already loaded into registers. Of course, the nodes need to be loaded in order to perform the comparisons, but that is not what is written in the relevant sentence.
- The use of `should` could be understood as a value judgement. I doubt it was intended as one, but rather to express that a cache miss is expected. However,  even this interpretations is not fully accurate, since the next node for the tree traversal might be cached (because it was recently accessed or close enough in memory to something recently accessed that it was cached alongside).

I suggest replacing the last two sentences of the paragraph with something like `This means that every single insertion triggers a heap-allocation, and for every comparison a node needs to be loaded, which could result in a cache miss. Since both heap-allocations and cache-misses are notably expensive in practise, we are forced to, at the very least, reconsider the BST strategy.`
Repository: pytorch
Issue: User-defined way to hook into Inductor autotuning
Labels: feature,triaged,module: custom-operators,oncall: pt2,module: inductor,module: pt2-dispatcher

We've seen some use cases for this:
1) A user has a user-defined triton kernel vs a sequence of PyTorch operations. They want inductor to select the "best" one in the situation.
2) A custom operators has some knobs that are exposed to inductor (some tunable parameters).

Thoughts?

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @aakhundov @bdhirsh
Repository: deno
Issue: Object property not recognized in VSCode after cmd-clicking class until LSP restart
Labels: bug,lsp

Version: Deno 2.1.3

```ts
import { Spanner } from "npm:@google-cloud/spanner@^7.16.0";

const _spannerClient = new Spanner({
  projectId: "test",
});
```

When I open this file in VSCode (with the Deno extension and an empty "{}" deno.json file in the same directory), there are no errors and it appears to understand the types of each value in the code. However, if I cmd-click on `Spanner` on line 3 and then press escape to hide the pop-up, then a red error squiggle appears under `projectId`, showing the error "Object literal may only specify known properties, and 'projectId' does not exist in type 'SpannerOptions'. deno-ts(2353)". This error stays until I restart the Deno language server. I'm able to reproduce this every time on multiple (mac) machines.
Repository: pytorch
Issue: [Dynamo] Do an audit on skipfiles and mark more files as inline
Labels: triaged,oncall: pt2,module: dynamo

When someone adds a new file under `torch/*` it is included in SkipFiles by default. This is a pain point for people who are adding new features to work with torch.compile: they end up seeing a SkipFiles error, like in https://github.com/pytorch/pytorch/pull/138555. In fact, this is probably the most common error I run into. It's relatively easy to fix (just mark the file as inline) but not everyone knows to do this.

Pitch: the default for new files being added under `torch/*` is that we should inline them by default (instead of skipping them by default). We should also audit all files currently inside SkipFiles to see if they actually need to be in SkipFiles.

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @chauhang @amjames @yanboliang
Repository: angular
Issue: Remove support for non-null assertions from two-way bindings
Labels: breaking changes,area: compiler,compiler: template type-checking

In v20 we should drop support for expressions like `[(ngModel)]="someExpr!"`, because type checking is non-obvious. We can revive the migration from #54630 to migrate existing users.
Repository: vscode
Issue: Run Recent Command does not cover multi-line Python REPL commands
Labels: bug,terminal-shell-integration,python

On macOS or Linux or WSL,

1. Enable `python.terminal.shellIntegration.enabled`.
2. Run "Python: Clear Cache and Reload Window".
3. Open a terminal and start a Python REPL.
4. Type `for i in range(5):` and press Enter.
5. Type `  print(i)` (including the spaces) and press Enter.
6. Press Enter again.
7. The REPL should print integers from 0 to 4.
8. Run "Terminal: Run Recent Command..."
9. :bug: Only `print(i)` shows up in the quick pick.
Repository: terminal
Issue: A lone zero-width character in the first column occupies 1 column
Labels: Area-Output,Issue-Bug,Needs-Tag-Fix,Priority-3

### Windows Terminal version

1.23.3411.0

### Windows build number

_No response_

### Other Software

_No response_

### Steps to reproduce

In PowerShell:
```pwsh
"`r`u{200B}foo"
```

### Expected Behavior

```
foo
```

### Actual Behavior

```
 foo
```

> The reason it happens is because before inserting anything in our text buffer we check if it joins with the already existing character and then merge it together with the new input. For any other characters we clamp the width of each grapheme cluster to a value between 1 and 2. Since a zero-width character can't join with anything in the first column it will be measured as its own cluster which results in a width of 1.
> The reason we do this is primarily because of our architecture which assumes O(1) lookups in the text buffer. The only way to make that work is by assuming that each grapheme cluster has a width of 1-2. The secondary reason for that is because inserting the ZWSP there puts it in front of the first column, assigning it column -1, which is not something that should be possible. Put differently, if you're at column 1 and iterate to the previous grapheme cluster, you would end up at column 0 (the start of the line), but after the ZWSP. It's a problem I don't have a good solution for except "add a bunch of special conditions" which gave me the gut feeling of "the problem has not been fundamentally solved".

https://github.com/microsoft/terminal/issues/18267#issuecomment-2529077871
Repository: pytorch
Issue: Enable GradScaler for MPS devices
Labels: triaged,module: amp (automated mixed precision),module: mps

### 🚀 The feature, motivation and pitch

I'm currently experimenting with mixed precision on my M4 Pro MBP since support for autocasting to `float16` has been added for MPS in 2.5.0 (https://github.com/pytorch/pytorch/pull/99272).
When trying to apply gradient scaling however, the following exception occurs on calling `scaler.step(optimizer)`:

```
Traceback (most recent call last):
  ...
  File "<redacted>/src/train.py", line 105, in train_model
    scaler.step(optimizer)
  File "<redacted>/.venv/lib/python3.11/site-packages/torch/amp/grad_scaler.py", line 451, in step
    self.unscale_(optimizer)
  File "<redacted>/.venv/lib/python3.11/site-packages/torch/amp/grad_scaler.py", line 335, in unscale_
    inv_scale = self._scale.double().reciprocal().float()
                ^^^^^^^^^^^^^^^^^^^^
TypeError: Cannot convert a MPS Tensor to float64 dtype as the MPS framework doesn't support float64. Please use float32 instead.
```

Since autocast works, it would be fantastic to also have working support for `GradScaler` with MPS.

### Alternatives

_No response_

### Additional context

The same issue has recently also been raised [in the forum](https://discuss.pytorch.org/t/gradscaler-typeerror-cannot-convert-a-mps-tensor-to-float64-dtype-as-the-mps-framework-doesnt-support-float64-please-use-float32-instead/213206). There, code for reproduction is also referenced.

cc @mcarilli @ptrblck @leslie-fang-intel @jgong5 @kulinseth @albanD @malfet @DenisVieriu97 @jhavukainen
Repository: rust
Issue: Expected/Found does not point to point where type parameter was inferred
Labels: A-diagnostics,T-compiler,D-terse

### Code

```Rust
fn foo<'a, T>(b: &'a T) -> &'a T { b }

fn main() {
    let f = foo;
    
    f(&String::new());
    f(&Vec::new());
}
```

### Current output

```Shell
error[E0308]: mismatched types
 --> src/main.rs:7:7
  |
7 |     f(&Vec::new());
  |     - ^^^^^^^^^^^ expected `&String`, found `&Vec<_>`
  |     |
  |     arguments to this function are incorrect
  |
  = note: expected reference `&String`
             found reference `&Vec<_>`
note: function defined here
 --> src/main.rs:1:4
  |
1 | fn foo<'a, T>(b: &'a T) -> &'a T { b }
  |    ^^^        --------
```

### Desired output

```Shell
error[E0308]: mismatched types
 --> src/main.rs:7:7
  |
7 |     f(&Vec::new());
  |     - ^^^^^^^^^^^ expected `&String`, found `&Vec<_>`
  |     |
  |     arguments to this function are incorrect
  |
  = note: expected reference `&String`
             found reference `&Vec<_>`
note: function defined here
 --> src/main.rs:1:4
  |
1 | fn foo<'a, T>(b: &'a T) -> &'a T { b }
  |    ^^^        --------
note: generic argument was inferred to `String` here
 --> src/main.rs:6:7
  |
6 | f(&String::new());
  |    ^^^^^^^^^^^^^
```

### Rationale and extra context

_No response_

### Other cases

```Rust

```

### Rust Version

```Shell
playground version:

Build using the Nightly version: 1.85.0-nightly
(2024-12-08 4d669fb34e7db6f3825d)
```

### Anything else?

_No response_
Repository: PowerToys
Issue: PowerToys Run Program: making the search paths and ignore patterns configurable
Labels: Product-PowerToys Run,Needs-Triage,Run-Results (Programs)

### Description of the new feature / enhancement

The "Program" plugin of PowerToys Run doesn't allow the user to configure the search paths and set ignore patterns. I request to add these configurations to fix usability problems of PowerToys Run (see the next paragraph). Here is the UI for these configurations in Wox:

![Image](https://github.com/user-attachments/assets/df95cbf7-d0b2-4dd6-94e1-9a377ffa8486)

### Scenario when this would be used?

I recently switched from Wox to PowerToys Run, and found two usability problems in the "Program" plugin of PowerToys Run.

The first problem is that the plugin searches for programs in both Start Menu and Desktop recursively. Therefore, if the user stores a large amount of files (e.g., cloned a large dataset) on desktop, it will be scanned recursively, and all `.exe` and `.lnk` files will be indexed as programs. This causes performance problem and unwanted search results.

Demo:
![Image](https://github.com/user-attachments/assets/f86d61b3-d8c1-4c57-b219-99e31a71abe0)

The other problem is that the plugin will index unrelated shortcuts in Start Menu (e.g., the uninstaller) and sometimes place it before the real application. It is easy to accidentally launch the uninstaller.

Demo:
![Image](https://github.com/user-attachments/assets/33a659ea-14d5-40b0-ac05-34468c03d685)

These two problems can be fixed by making the search paths and ignore patterns configurable, so that I can:

- Remove desktop from the search paths
- Ignore programs with name `*unins*`, `*help*`, or `*website*`

### Supporting information

Current search paths: https://github.com/microsoft/PowerToys/blob/main/src/modules/launcher/Plugins/Microsoft.Plugin.Program/Storage/Win32ProgramFileSystemWatchers.cs#L35
Repository: deno
Issue: Node Compatibility: Crypto RSA encryption
Labels: bug,crypto

Version: Deno 2.1.3

The node crypto implementation is lacking support for KeyObjects.

This is currently breaking cross-platform support and subsequently breaking the npm library [OpenPGP](https://www.npmjs.com/package/openpgp), where I was originally experiencing this [issue](https://github.com/openpgpjs/openpgpjs/issues/1813) <- More information can be found there
Repository: deno
Issue: Implicit dependency on `deno_net` extension from within `deno_fetch` extension
Labels: embedder

I will preface this by stating that I don't know much about deno and I'm learning as I'm going, so this is entirely possibly user error.

I'm attempting to initialize a `deno_core::JsRuntime` with the `deno_fetch` extension.  According to [the documentation](https://github.com/denoland/deno/blob/v2.1.3/ext/fetch/README.md) and the [dependency list](https://github.com/denoland/deno/blob/7f9b1ff30f7d9880b7c825c2b5f2de3137343d76/ext/fetch/lib.rs#L138) `deno_net` is not a dependency of `deno_fetch` (in fact, it appears it's the other way around!).  However attempting to use only `deno_fetch` results in this error at runtime: 

```
thread '<unnamed>' panicked at /Users/houndie/.cargo/registry/src/index.crates.io-6f17d22bba15001f/deno_core-0.324.0/runtime/jsruntime.rs:745:9:
Failed to initialize a JsRuntime: Specifier "ext:deno_net/02_tls.js" was not passed as an extension module and was not included in the snapshot.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

I browsing the source I find [this suspect import](https://github.com/denoland/deno/blob/7f9b1ff30f7d9880b7c825c2b5f2de3137343d76/ext/fetch/22_http_client.js#L17) potentially causing this?

Would love advice on how I can fix this on my side.  I tried including `deno_net` and dependencies, which does seem to solve the problem, but [it seems there's also a dependency on `telemetry`](https://github.com/denoland/deno/blob/883abfa1bfeb4eded1ebdb8cc7364c254dcaad2e/ext/fetch/26_fetch.js#L67) which requires typescript transpilation to use that extension so I thought I'd take a pause before following that rabbit hole.
Repository: pytorch
Issue: [dynamo] Tracking issue for multiple inheritance support
Labels: triaged,oncall: pt2,module: dynamo

### 🐛 Describe the bug

During Dynamo symbolic interpretation of user code, we model python objects as `VariableTracker`. When a pre-existing python object is used, we [wrap](https://github.com/pytorch/pytorch/blob/0052943bee624c06d8c36a371efdf7b56972ad9e/torch/_dynamo/variables/builder.py#L387) it with a subclass of `VariableTracker`, [based on its type](https://github.com/pytorch/pytorch/blob/0052943bee624c06d8c36a371efdf7b56972ad9e/torch/_dynamo/variables/builder.py#L694-L744).

This doesn't play well with multiple inheritance, as shown in #141118. In general, the reason is the combination of:
1. When Dynamo creates a `VariableTracker` from a user python object, it often dispatches to a very specific type, e.g., `UnspecializedNNModuleVariable`, with a single `isinstance` check [without checking for multiple inheritance](https://github.com/pytorch/pytorch/blob/0052943bee624c06d8c36a371efdf7b56972ad9e/torch/_dynamo/variables/builder.py#L669-L670).
2. In Dynamo, we have [logic that depends on the type of a `VariableTracker`](https://github.com/pytorch/pytorch/blob/0052943bee624c06d8c36a371efdf7b56972ad9e/torch/_dynamo/variables/builtin.py#L1377-L1397), but due to (1), the multiple inheritance information isn't directly represented at the `VariableTracker`'s type level, resulting in "I know this value is both an `nn.Module` and `MutableMapping`, but Dynamo generally treats it as an `nn.Module`".

As #142416 shows, we could apply local fixes since the multiple inheritance information is still accessible in the `value` field of most `VariableTracker` instances, but it's unclear how far that could approach can take us and how it'll complicate Dynamo logic, given how often the aforementioned (2) happens. On the other hand, we also don't know how big of an issue multiple inheritance is in practice, so I'm creating this tracking issue to gather information and help us lazily evaluate the problem.

### Error logs

_No response_

### Versions

main 7101dcfb98b

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames
Repository: TypeScript
Issue: Typescript type hint problem
Labels: Needs More Info


Type: <b>Bug</b>

使用一段时间后，鼠标移到变量或者typescript类型上面，会有以下问题：
- 没有类型提示，没有任何反应，此时按住command同时点击鼠标左键可以正常跳到实现

正常会有浮层提示类型，重启VS Code之后正常，但是使用一段时间之后还会出现

After using it for a while, when you move the mouse over a variable or typescript type, the following problems will occur:

- No type hint, no response, at this time, hold down command and click the left mouse button to jump to the implementation

Normally, there will be a floating layer prompt type, it will be normal after restarting VS Code, but it will still appear after using it for a while


- Normal display
The mouse pointer is at the arrow position
![Image](https://github.com/user-attachments/assets/953055c3-f5f0-443b-8bfe-91dc1734aed2)

- problem
The mouse pointer is at the arrow position

> Version: 1.96.0-insider (Universal)
Commit: 91bf2f3b96a337c05fdd30dbfe609ae780b74706
Date: 2024-11-19T05:04:26.087Z
Electron: 32.2.3
ElectronBuildId: 10561341
Chromium: 128.0.6613.186
Node.js: 20.18.0
V8: 12.8.374.38-electron.0
OS: Darwin x64 22.6.0

![Image](https://github.com/user-attachments/assets/a99eae3f-057e-4656-8518-3ff308119570)


VS Code version: Code 1.95.1 (65edc4939843c90c34d61f4ce11704f09d3e5cb6, 2024-10-31T05:14:54.222Z)
OS version: Darwin x64 22.6.0
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz (16 x 2300)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: disabled_off<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|4, 3, 2|
|Memory (System)|16.00GB (1.19GB free)|
|Process Argv|--crash-reporter-id df018b86-dcb3-4093-a0fe-1df1f758d245|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (7)</summary>

Extension|Author (truncated)|Version
---|---|---
markdown-mermaid|bie|1.26.0
vscode-eslint|dba|3.0.13
prettier-vscode|esb|11.0.0
githd|hui|2.5.3
vscode-language-pack-zh-hans|MS-|1.95.2024103009
volar|Vue|2.1.10
material-theme|zhu|3.17.5


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
vscaat:30438848
c4g48928:30535728
azure-dev_surveyone:30548225
vscrpc:30673769
962ge761:30959799
pythongtdpath:30769146
pythonnoceb:30805159
asynctok:30898717
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
jg8ic977:31013176
dvdeprecation:31068756
dwnewjupytercf:31046870
impr_priority:31102340
nativerepl1:31139838
refactort:31108082
pythonrstrctxt:31112756
cf971741:31144450
iacca1:31171482
notype1cf:31157160
5fd0e150:31155592
dwcopilot:31170013

```

</details>

<!-- generated by issue reporter -->
Repository: go
Issue: x/build/cmd/watchflakes: periodically restarts
Labels: Builders,NeedsInvestigation

Watchflakes is periodically being restarted.

Command `kubectl get pods` produces: 
`watchflakes-deployment-679f9fbf8c-zp9ld           1/1     Running   47 (26m ago)   27d`

@golang/release
Repository: vscode
Issue: Reconsider auto vacuuming sqlite state.vscdb files? It saved 776MB on my install.
Labels: feature-request,workbench-state

Hello, I found large state.vscdb files in VSCode workspaceStorage folder using an app to analyse disk usage, which triggered my curiosity and when opening I couldn't find anything big in the ItemTable file. Finally found I could VACUUM it, which brought the biggest state.vscdb file from 298MB to 639kB, and the total workspaceStorage folder size from 995MB to 219MB (VACUUMing all vscdb files as shown below).

Considering the significant size saving, could you reconsider auto vacuuming the files regularly? I found #189352 and #146280 already talking about it but there is not much details on which tests failed. Thanks!

Vacuuming files:
```sh
❯ pwd
/Users/me/Library/Application Support/Code/User
❯ fd vscdb --exec sqlite3 {} vacuum
```