sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: deno
Issue: deno test `--require` or `--import` (setup file)
Labels: suggestion,testing

I can't really figure how to do some browser mocking in deno.

I'm using the node command like this, which works:

`node --experimental-strip-types --test --import ./test/mock-browser.ts` ([link to code](https://github.com/birkskyum/maplibre-gl-draw/blob/01cc0dcecea8e280b9d931ca27727da812639f27/package.json#L31))

But with deno i get:

`deno test --no-check`:

```
error: ReferenceError: document is not defined
      container: document.createElement("div"),
```

I have in my deno.json

```
    "lib": [
      "deno.window",
      "dom"
    ]
```


The mock-browser.ts being:
```ts
import MockBrowser from "mock-browser";
const mock = new MockBrowser.mocks.MockBrowser();

global.document = mock.getDocument();
global.window = {};

// Polyfill based on https://gist.github.com/paulirish/1579671
let lastTime = 0;
global.requestAnimationFrame = function (fn) {
  const now = Date.now();
  const nextTime = Math.max(lastTime + 16, now);
  setTimeout(() => fn(lastTime = nextTime), nextTime - now);
};
```

For node compat, I believe I need a way to do a similar `--import` in deno test, or another way to give a setup file, which I believe [vitest calls it](https://vitest.dev/config/#setupfiles)
Repository: pytorch
Issue: MPS operator coverage tracking issue (2.6+ version)
Labels: feature,triaged,tracker,module: mps

### 🐛 Describe the bug

### This issue is to have a centralized place to list and track work on adding support to new ops for the MPS backend.

[**PyTorch MPS Ops Project**](https://github.com/users/kulinseth/projects/1/views/1) : Project to track all the ops for MPS backend. There are a very large number of operators in pytorch and so they are not all yet implemented. We will be prioritizing adding new operators based on user feedback. If possible, please also provide link to the network or use-case where this op is getting used.

As Ops are requested we will add " *To Triage*" pool. If we have 3+ requests for an operation and given its complexity/need the operation will be moved "*To be implemented*" pool. If you want to work on adding support for such op, feel free to comment below to get assigned one. Please avoid pickup up an op that is already being worked on tracked in "*In progress*" pool. 

[Link to the wiki for details](https://github.com/pytorch/pytorch/wiki/MPS-Backend) on how to add these ops and example PRs.

[**MPS operators coverage matrix**](https://qqaatw.github.io/pytorch-mps-ops-coverage/) - The matrix covers most of the supported operators but is not exhaustive. **Please look at the `In vx.x.x` column, if the box is green, it means that the op implementation is included in the latest release; on the other hand, if the box is yellow, it means the op implementation is in the nightly and has not yet included in the latest release.** Before you comment below, please take a look at this matrix to make sure the operator you're requesting has not been implemented in nightly.  More details can be found on the [readme](https://github.com/qqaatw/pytorch-mps-ops-coverage).



This is a spiritual successor of https://github.com/pytorch/pytorch/issues/77764, but hopefully it will not receive requests for the OPs that has been added already since 1.13 but until 2.6

cc @kulinseth @albanD @DenisVieriu97 @jhavukainen
Repository: pytorch
Issue: Enhancement Request: improve this error message
Labels: module: nn,triaged

### 🚀 The feature, motivation and pitch

Currently this error message confuses me, and the comment said I could submit an enhancement request

ERROR 2024-11-21T21:14:00.063730401Z [resource.labels.containerName: pytorch] [rank14]: File "/usr/local/lib/python3.10/dist-packages/torch/nn/functional.py", line 4047, in interpolate
ERROR 2024-11-21T21:14:00.063732261Z [resource.labels.containerName: pytorch] [rank14]: return torch._C._nn.upsample_nearest3d(input, output_size, scale_factors)
ERROR 2024-11-21T21:14:00.063734879Z [resource.labels.containerName: pytorch] [rank14]: RuntimeError: Expected output.numel() <= std::numeric_limits<int32_t>::max() to be true, but got false. (Could this error message be improved? If so, please report an enhancement request to PyTorch.)



### Alternatives

i mean not the end of the world if no one changes this, it's a "nice-to-have"

### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: flutter
Issue: [in_app_purchase_storekit] Audit import headers to prevent unneeded headers from being public
Labels: P2,team-ios,triaged-ios

See here: https://github.com/flutter/packages/pull/7912#discussion_r1814265121

> https://github.com/flutter/packages/blob/a87eddf0c281d5d017093125c1a8d9161257741f/packages/in_app_purchase/in_app_purchase_storekit/darwin/in_app_purchase_storekit.podspec#L21
> 
> https://guides.cocoapods.org/syntax/podspec.html#public_header_files
> 
> Public headers should not use file (quote) imports, but should use angle brackets. https://developer.apple.com/documentation/xcode/build-settings-reference#Quoted-Include-In-Framework-Header
> 
> Also the [import order](https://google.github.io/styleguide/objcguide.html#order-of-includes) should be
> 
> ```
> #import <Foundation/Foundation.h>
> #import <StoreKit/StoreKit.h>
> ```
> 
> then
> 
> When in doubt, open up an Apple header and copy their pattern. For example, this is StoreKit's `SKAdImpression` header:
> 
> ```objc
> //
> //  SKAdImpression.h
> //  StoreKit
> //
> //  Copyright © 2020 Apple Inc. All rights reserved.
> //
> 
> #import <Foundation/Foundation.h>
> #import <StoreKit/StoreKitDefines.h>
> ```
>
Repository: electron
Issue: Ability to set ELECTRON_NO_ATTACH_CONSOLE  from app
Labels: enhancement :sparkles:

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

I previous post https://github.com/electron/electron/issues/20266 incorrectly posted this as an Issue and not a Feature Request

So here it is!

Im about to launch an Electron app, although i've just discovered that when you run the app from the command line in Windows the terminal session attaches to the log output from the Electron app. You can't quit the terminal session because it will kill the app.

I need my app to be launched on startup of Windows, without having the ugly terminal screen there. I would also like people to be able to script it's start without needing the terminal to stay alive.

I know I can do this with the ELECTRON_NO_ATTACH_CONSOLE env var, but there doesn't seem to be a way to force this to be always on. I don't want to tell people they need to set ELECTRON_NO_ATTACH_CONSOLE=true before running the app, thats ugly.

Using Electron builder to build the production app. Have tried forcing env.ELECTRON_NO_ATTACH_CONSOLE=true at the top of my main file, before anything else loads, but that seems to do nothing.

As far as I can tell, it's not possible right now (really happy if someone can prove me wrong).



### Proposed Solution

Have the ability to configure this option (ELECTRON_NO_ATTACH_CONSOLE) from within the app without the need for environment variable.

### Alternatives Considered

The alternative is to have the user 

set ELECTRON_NO_ATTACH_CONSOLE=true in their batch files before running the app

This is not intuitive and I've never seen any other apps besides electron do this.

The end user should not have to make changes for a production app if they use batch files in their workflow.


### Additional Information

It is currently an env variable, if more then one electron app are in the the batch file, then this affects the others as well, so the user must be mindful of which app needs to attach to the console and others that don't.
Repository: pytorch
Issue: DISABLED test_linear_backward_memory_usage_cuda_float32 (__main__.TestNestedTensorSubclassCUDA)
Labels: triaged,module: flaky-tests,module: nestedtensor,skipped

Platforms: rocm, linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_linear_backward_memory_usage_cuda_float32&suite=TestNestedTensorSubclassCUDA&limit=100) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/33336917353).

Over the past 3 hours, it has been determined flaky in 4 workflow(s) with 8 failures and 4 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_linear_backward_memory_usage_cuda_float32`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.



<details><summary>Sample error message</summary>

```
Traceback (most recent call last):
  File "/var/lib/jenkins/pytorch/test/test_nestedtensor.py", line 3819, in test_linear_backward_memory_usage
    self.assertEqual(max_after_gb, 0)
  File "/opt/conda/envs/py_3.10/lib/python3.10/site-packages/torch/testing/_internal/common_utils.py", line 3999, in assertEqual
    raise error_metas.pop()[0].to_error(
AssertionError: Scalars are not equal!

Expected 0 but got 1.
Absolute difference: 1
Relative difference: inf

To execute this test, run the following from the base repo dir:
    PYTORCH_TEST_WITH_ROCM=1 python test/test_nestedtensor.py TestNestedTensorSubclassCUDA.test_linear_backward_memory_usage_cuda_float32

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

</details>


Test file path: `test_nestedtensor.py`

cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang @naromero77amd @clee2000 @wdvr @cpuhrsch @jbschlosser @bhosmer @drisspg @soulitzer @davidberard98 @YuqingJ
Repository: pytorch
Issue: Memory efficient reshape for stride-0 tensors
Labels: triaged,enhancement,module: python frontend

### 🚀 The feature, motivation and pitch

We have many tensors with large shape, but several stride=0 dimensions, i.e. expanded/broadcasted dimensions.
If a reshape that cannot be done as a view is performed, the whole tensor is made full sized and contiguous, resulting in a huge allocation.
IT would be nice if the expanded dimensions could be kept if possible.

Example:
```python
import torch

a=torch.rand(1,2,1).expand(100,2,2)
print("a", a.shape, "stride:", a.stride())
print("storage a", a.untyped_storage().nbytes(), "bytes")

b=a.reshape(-1,4)
print("b", b.shape, "stride:", b.stride())
print("storage b", b.untyped_storage().nbytes(), "bytes")

c=a[:1].reshape(-1,4).expand(100,-1)
print("c", c.shape, "stride:", c.stride())
print("storage c", c.untyped_storage().nbytes(), "bytes")

torch.testing.assert_close(b,c)
```
```
a torch.Size([100, 2, 2]) stride: (0, 1, 0)
storage a 8 bytes
b torch.Size([100, 4]) stride: (4, 1)
storage b 1600 bytes
c torch.Size([100, 4]) stride: (0, 1)
storage c 16 bytes
```

similarly, if a were non-contiguous in some dimensions involved in the reshape.

Is there a smart way to do the reshape? 

### Alternatives

We can manually figure out which axes will be joined or split in the reshape and undo the expand in all other stride-0 dimensions before the reshape, and expand after the reshape.
It would be nice to have this as an efficient C function available.

Unfortunatly, I think changing the default reshape behaviour might be considered a breaking change -- as it would then return non contiguous tensors where it previously did not.

### Additional context

_No response_

cc @albanD
Repository: flutter
Issue: iOS simulator test have confusing logspam.
Labels: a: tests,engine,P3,team-ios,triaged-ios

The following logs are emitted constantly but the results seem to be benign:
```
2024-11-21 14:23:13.025619-0800 IosUnitTests[79897:22772182] [ERROR:flutter/runtime/isolate_configuration.cc(223)] application_kernel_asset or application_kernel_list_asset must be set
2024-11-21 14:23:13.025783-0800 IosUnitTests[79897:22772182] [ERROR:flutter/shell/common/engine.cc(215)] Engine run configuration was invalid.
2024-11-21 14:23:13.025912-0800 IosUnitTests[79897:22772182] [ERROR:flutter/shell/common/shell.cc(675)] Could not launch engine with configuration.
```
Invocation:
```
./flutter/testing/run_tests.py --type objc --variant host_debug_unopt_arm64 --ios-variant ios_debug_sim_unopt_arm64
```
Repository: pytorch
Issue: Pytorch notifications
Labels: feature,triaged,module: devx

### 🚀 The feature, motivation and pitch


**Note: this feature is under review, this is a first rough proposal, looking for user feedback right now whether this is needed or not.**

Developers within the PyTorch ecosystem have quite some signal to deal with:

- Github notifications for cc'ed issues
- failing CI tests on HUD / monitoring for successful tests to merge
- PR reverts
- Infra failures (infra teams)
- oncall health for some repos (TTR for issues/reviews), regression for i.e. daily benchmarks

This leads to delays in merging, late response times, frustration with the build and test system.
Additionally, some PRs fall off peoples review list, and developers end up using Dev Infra Office Hours to request reviews.

Some people rely on e-mail notifications and custom mail rules to triage their signals, some people use the Github notifications, others rely on manual pings in slack/other chat tools from colleagues. 

The proposal here is to look into a general purpose notification system that users can subscribe to, that can ping either oncalls for certain metrics (TTR too long, regression detected, infra down), or individuals (your PR is ready to merge, you have failing tests to look into).


### Alternatives

- we could stick to Github notitfications, ccbot, [probot]([pytorch-probot](https://github.com/pytorch/test-infra/torchci)) that subscribes people to labels
- We could split this up in multiple use cases, and make a 'stale PR' dashboard per repo, develop an infra-failure solution, and write a simple @notify bot for benchmark regressions

### Additional context

right now we're looking to interview developers on how they deal with this workflow, how they experience developing PyTorch and how they deal with the above mentioned challenges. If you're interested in giving feedback, feel free to do so as a comment to this issue, or contact @wdvr.

cc @ZainRizvi @kit1980 @huydhn @clee2000
Repository: rust
Issue: Unexpected error when resolving bounds involving associated types
Labels: A-trait-system,T-compiler,A-impl-trait,C-bug,fixed-by-next-solver

<!--
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 am trying to compile the following code

```rust
struct MyBlock;

trait Block {
    type Header;
}
impl Block for MyBlock {
    type Header = ();
}

trait Header {}
impl Header for () {}

trait FullBlock: Block<Header: Header> {}
impl<T> FullBlock for T where T: Block<Header: Header> {}

trait Primitives {
    type Block;
}

trait FullPrimitives: Primitives<Block: FullBlock<Header = Self::Header>> {
    type Header;
}

impl<T> FullPrimitives for T where T: Primitives<Block: FullBlock> {
    type Header = <<T as Primitives>::Block as Block>::Header;
}

fn test<P: FullPrimitives<Block = MyBlock>>() {}

```

The compilation is failing with:
```
error[E0283]: type annotations needed: cannot satisfy `MyBlock: FullBlock`
  --> src/main.rs:30:12
   |
30 | fn test<P: FullPrimitives<Block = MyBlock>>() {}
   |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: cannot satisfy `MyBlock: FullBlock`
note: required by a bound in `FullPrimitives`
  --> src/main.rs:22:41
   |
22 | trait FullPrimitives: Primitives<Block: FullBlock<Header = Self::Header>> {
   |                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `FullPrimitives`

For more information about this error, try `rustc --explain E0283`.
error: could not compile `my_project` (bin "my") due to 1 previous error
```

However, if I relax the `FullBlock` trait requirements it compiles fine
```diff
-trait FullBlock: Block<Header: Header> {}
-impl<T> FullBlock for T where T: Block<Header: Header> {}
+trait FullBlock: Block {}
+impl<T> FullBlock for T where T: Block {}
```

### 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.84.0-nightly (c1db4dc24 2024-10-25)
binary: rustc
commit-hash: c1db4dc24267a707409c9bf2e67cf3c7323975c8
commit-date: 2024-10-25
host: aarch64-apple-darwin
release: 1.84.0-nightly
LLVM version: 19.1.1
```

</p>
</details>
Repository: rust
Issue: `if` and `else` have incompatible types in a `let` statement, where `else` block's evaluation will never be assigned
Labels: A-diagnostics,T-compiler,D-confusing,D-terse,A-control-flow

<!--
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 apologize if this was already reported in a separate issue, or if this is a known issue - I wasn't sure how to best search for previous issues like this.

I also realize this might not be a "bug" per se, but the other issue templates didn't seem to quite fit either.

I tried this code:

```rust
enum Cause { Cause1, Cause2 }
struct MyErr { x: Cause }

fn main() {
    _ = f();
}

fn f() -> Result<i32, MyErr> {
    let res = could_fail();
    let x = if let Ok(x) = res {
        x
    } else if let Err(e) = res {
        cleanup();
        return Err(e);
    };
    Ok(x)
}

fn could_fail() -> Result<i32, MyErr> {
    // ... code that could fail and return an Err ...
    Ok(0)
}

fn cleanup() {
    // ... cleanup code ...
}
```
Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=60acf4e59e3c6403104e01aa409aa395

I expected the code to compile successfully, since the `else if` branch unconditionally returns. Because the `else if` branch always returns, `x` will always be an `i32`.

Instead, I get this compiler error:
```
error[E0308]: `if` and `else` have incompatible types
  --> src/main.rs:12:12
   |
10 |        let x = if let Ok(x) = res {
   |  ______________-
11 | |          x
   | |          - expected because of this
12 | |      } else if let Err(e) = res {
   | | ____________^
13 | ||         cleanup();
14 | ||         return Err(e);
15 | ||     };
   | ||     ^
   | ||_____|
   |  |_____`if` and `else` have incompatible types
   |        expected `i32`, found `()`
```

### 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 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-unknown-linux-gnu
release: 1.82.0
LLVM version: 19.1.1
```
Repository: rustdesk
Issue: Online status indicator doesn't work for remotes added via `id@server/r`
Labels: bug,Fund

### Bug Description

I have a remote client that I usually connect to. The remote client is using a relay server and an ID server on its end. When I want to connect to that specific remote via its pure `<id>`, I have to change the networking settings on my client to add that relay and ID server globally. When I do that, everything works just fine and the online status indicator for that remote updates correctly.

Since the adding and deleting of relay and ID servers on my client for connecting to that remote client was becoming cumbersome, I researched this repository and found out that [an alternative method has been added in v1.3.0](https://github.com/rustdesk/rustdesk/issues/6198#issuecomment-1794694273) that allows connecting to remotes behind an ID and a relay server without having to change these settings globally.

Therefore, I gave it a shot and am now able to connect to my remote client via `<id>@<server>/r` without having to set the relay and ID servers globally on my client. Although this works great, the issue I'm experiencing with this method is that it no longer updates the small online status indicator for that remote correctly and it always stays orange, even though I'm able to connect to it just fine and if I use the old method it is able to detect when the remote is online and shows it as green.

### How to Reproduce

1. Install RustDesk on 2 machines (I tested on 2 Windows machines).
2. Open up the settings on machine 1 and go to networking and assign it to a custom (public) ID and relay server.
3. Now try connecting to machine 1 from machine 2 via `<id>@<server>/r` without changing the global networking settings on machine 2.
4. You should be able to connect to machine 1 but the online status indicator won't work and it'll stay orange.

### Expected Behavior

The online status indicator should turn green when the remote behind the ID and relay server is ready to receive connections.

### Operating system(s) on local (controlling) side and remote (controlled) side

Windows 11 -> Windows 11

### RustDesk Version(s) on local (controlling) side and remote (controlled) side

1.3.0 -> 1.3.0

### Screenshots

![image](https://github.com/user-attachments/assets/df2d3012-f879-437f-9df4-54990b919908)

![image](https://github.com/user-attachments/assets/bd7f761c-5576-44f9-8272-9809b81d6017)


### Additional Context

_No response_

<!-- POLAR PLEDGE BADGE START -->
## Upvote & Fund

- We're using [Polar.sh](https://polar.sh/rustdesk) so you can upvote and help fund this issue.
- We receive the funding once the issue is completed & confirmed by you.
- Thank you in advance for helping prioritize & fund our backlog.

<a href="https://polar.sh/rustdesk/rustdesk/issues/10005">
<picture>
  <source media="(prefers-color-scheme: dark)" srcset="https://polar.sh/api/github/rustdesk/rustdesk/issues/10005/pledge.svg?darkmode=1">
  <img alt="Fund with Polar" src="https://polar.sh/api/github/rustdesk/rustdesk/issues/10005/pledge.svg">
</picture>
</a>
<!-- POLAR PLEDGE BADGE END -->