sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Allow not automatically saving files when running a test
Labels: feature-request,testing



<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

When a user invokes tests in VSCode that have been added through the VSCode testing API, VSCode will save some or all of the users unsaved files. For the extension I'm developing, this is undesired behavior. Our LSP server is extended with testing APIs, and it doesn't need files to be saved in order to run tests. Secondly, saving a file can trigger some heavyweight operations, and I'd only like saving to occur when our users explicitly choose to save the file.

Here's the location where VSCode tries to save files when testing: https://github.com/microsoft/vscode/blob/2857051bb4e1bd7177c0d48b468b665c5a53b3c1/src/vs/workbench/contrib/testing/common/testServiceImpl.ts#L216

Could you make it so that in the [TestRunProfile](https://code.visualstudio.com/api/references/vscode-api#TestRunProfile), I can configure whether to automatically save files when this profile is run? Thanks!
Repository: pytorch
Issue:  Build and Run QNNPACK on X86
Labels: module: build,triaged

### 🚀 The feature, motivation and pitch

Hi Pytorch team,

I want to build and run QNNPACK on X86 CPU and there are not many references to do the same. It would be great if I can get the references to build and execute QNNPACK on the X86 platform.

Thank you!






### Alternatives

_No response_

### Additional context

_No response_

cc @malfet @seemethere @dhruvbird @ljk53
Repository: terminal
Issue: UIA: support movement by page
Labels: Issue-Feature,Product-Conhost,Area-Accessibility,Product-Terminal,In-PR,HCL-E+D,A11yWCAG,HCL-WindowsTerminal,A11ySev3,InclusionBacklog,InclusionBacklog-Windows TerminalWin32,A11yMAS,Disability-All

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement
In https://github.com/nvaccess/nvda/pull/13671#issuecomment-1138862155 @carlos-zamora thought that wt and conhost should implement movement, expansion, etc. by the UIA "page" unit. This would help NVDA to solve nvaccess/nvda#13157 and improve the UX for other UIA clients.

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)
The "page" unit should represent one visible screen of text, and behave similar to Microsoft Word's implementation. In other words:

1. Run the "less" command, or anything else that paginates output.
2. Jump to the end of the text. For iinstance, create a document range and "collapse" it by moving its start to its end, creating a degenerate range.
3. Move this new degenerate range back one page. It should now be a degenerate range at the start of the currently visible screen of output.
4. Expand to enclosing unit. The range should now span the visible output.
5. Move to the previous page. The range should now contain the last visible screen of output.

<!-- 
A clear and concise description of what you want to happen.
-->
Repository: pytorch
Issue: Cdist backward dependent on compute_mode
Labels: module: autograd,triaged,actionable

### 🐛 Describe the bug

The function [torch.cdist](https://pytorch.org/docs/stable/generated/torch.cdist.html) raises a `NotImplementedError: the derivative for '_cdist_backward' is not implemented.` for default `compute_mode` during nested gradient calculation. 


Example:

```
import torch


def function(a, b):
    return torch.cdist(a, b)
    # return torch.cdist(a, b, compute_mode="use_mm_for_euclid_dist")  # works


# input data
a = torch.tensor([[1.0, 2.0], [3.0, 4.0]], requires_grad=True)
b = torch.tensor([[5.0, 6.0], [7.0, 8.0]])

# calculate forward pass
y = torch.nn.Linear(2, 1)(function(a, b))

# calculate gradient
gradient = torch.autograd.grad(
    y,
    a,
    grad_outputs=torch.ones_like(y),
    create_graph=True,
)[0]

# calc loss to reference
grad_ref = torch.tensor([[10.0, 11.0], [12.0, 13.0]])
loss = torch.nn.MSELoss(reduction="mean")(gradient, grad_ref)

loss.backward()  # NotImplementedError: the derivative for '_cdist_backward' is not implemented.
```

To us, this behavior is unclear from the documentation.
If this is not the supposed way to implement gradient based loss calculation, we are looking forward to your suggestions on alternative setups. 

Hence, suggestions on how to circumference this are welcome (aside from changing `compute_mode`).

If this were to be expected, perhaps the documentation could be improved?

### Versions

PyTorch version: 1.12.0

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Repository: vscode
Issue: Make `IMarkerService#read` ignore unsupported schemes by default
Labels: debt,languages-diagnostics

lgtm - tho, I believe we should consider always filtering these schemas on `read` on only return them when requested

_Originally posted by @jrieken in https://github.com/microsoft/vscode/pull/158176#pullrequestreview-1074038885_
Repository: go
Issue: runtime: scheduler testing controls
Labels: NeedsFix,compiler/runtime

Today, it is difficult to trigger specific conditions in the scheduler from a high level Go level. This is because certain behaviors or bugs only manifest via certain multi-threaded race conditions that are difficult or impossible to guarantee. As a result, fixes for bugs in the scheduler often either have strange probabilistic tests that try to entice the scheduler into a specific state (and likely degrade quickly), or they go untested entirely because they are too difficult to reproduce.

Scheduler maintainability could be greatly improved through some kind of testing framework that makes it possible to directly achieve some of these states. There are many forms this could take. e.g., the ability to construct a test scheduler with fake Ms, Ps, and Gs whose states can be explicitly transitioned.
Repository: TypeScript
Issue: Cannot use symbol as "index" for plain object property access
Labels: Bug

# Bug Report

`{ [prop]() { } }[prop]` fails with `Type 'symbol' cannot be used as an index type.` aka `ts(2538)` if `prop: string | symbol`. It works fine if `prop` is either `string` or `symbol`.

### 🔎 Search Terms

union type cannot be used as an index type

Found 2 somewhat relevant issues and a pull request, but they don't seem to directly apply. Please close if duplicate:
- https://github.com/microsoft/TypeScript/pull/44512
- https://github.com/microsoft/TypeScript/issues/24220
- https://github.com/microsoft/TypeScript/issues/47357

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about union and index types

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.7.4#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXygGdCQYMAKMPYLbPALgNQE8AaeAW0IHMB+RwhhhZU3AJSMiJMoXhVUNOqgDcAWABQGlOiXwA7jCgAHcgA9JLMfADeG+PfhwMyGPlQg98AAowcp5mbstuoOofDcIBQA+hiwERjsRuxwYCBYAG6kVsFhuY6RLvg5eSUA2kYAuuQAdLVxhBbMpRXZdiXt9lKkFBgAFliyALzD+akZWWohHe1OhfAASiCIEOAY1cZGEAGm5RXspuz1YpPTYQC+rG0dZ7tX55dTub1E5K2PMwWu8ELIICd5ZzuZ2OGkBmnUoEgsAQ8kE8CMviMAiEIm48AAPvBCMwOAAjHAQSYaWEYLG9HBkAASUAUADF8IMbPByoiqtl4GcOSycJVlEA)

### 💻 Code

```ts
declare function assert(condition: any, msg?: string): asserts condition;

function wrap(x: any) {
    return new Proxy(x, {
        get(_target, p, receiver) {
            return {
                [p](...args: any[]) {
                    assert(this === receiver);
                    return Reflect.apply(x[p], x, args);
                },
            }[p]
        },
        has() {
            return true;
        }
    });
}

declare const prop: string | symbol;

const shortHandFn = { [prop]() { } }[prop];
```

### 🙁 Actual behavior

Type 'symbol' cannot be used as an index type.

### 🙂 Expected behavior

No type error since both symbol and string are allowed index types.
Repository: create-react-app
Issue: Deploying to Github Pages 
Labels: needs triage

Hey guys, It should probably be something simple, but if anyone can help...

I'm trying to publish my first React project with Github Pages, with the index file inside the /src subdirectory. But Github Pages requires that the index file remains inside the main directory, so, as the page loads, it shows only this:  

![unknown](https://user-images.githubusercontent.com/86106757/184918393-7c23cb4d-8736-4095-9c6c-0bc39e95f398.png)

My file structures look like this:

![unknown (1)](https://user-images.githubusercontent.com/86106757/184919008-b4f3af18-708b-4a88-acb3-9a0199ca28b6.png)

With the index file located in the src folder:

![unknown (2)](https://user-images.githubusercontent.com/86106757/184919268-265fb2ca-b02d-4ad9-bf40-8fbc1ea576b6.png)
Repository: rust
Issue: Suggest valid reverse for loop if an invalid variant is used
Labels: A-diagnostics,T-compiler

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: [link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=49a30b4055a511f0d80fc147c410a71a)

```rust
fn main() {
    for i in 10..0 {
        println!("{i}");
    }
    
    for i in (10..0).rev() {
        println!("{i}");
    }
    
    for i in (10..0).step_by(-1) {
        println!("{i}");
    }
}
```

The current output is:

```
Compiling playground v0.0.1 (/playground)
error[[E0600]](https://doc.rust-lang.org/nightly/error-index.html#E0600): cannot apply unary operator `-` to type `usize`
  --> src/main.rs:10:30
   |
10 |     for i in (10..0).step_by(-1) {
   |                              ^^
   |                              |
   |                              cannot apply unary operator `-`
   |                              help: you may have meant the maximum value of `usize`: `usize::MAX`
   |
   = note: unsigned values cannot be negated

For more information about this error, try `rustc --explain E0600`.
error: could not compile `playground` due to previous error
```

<!-- The following is not always necessary. -->
Ideally the compiler should check if the range's start >= end and inform the user that its an empty iterator.

Then for the above few incorrect variants (and possibly more), suggest the correct way to write a reverse for loop.

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"obeis"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: deno
Issue: Ways to get the Deno configuration
Labels: public API,suggestion,config

I would like and have use cases for a function in the `Deno` namespace that gets the current configuration file.

I thought of 3 forms this could come in (suggest any other ideas you have here):
- `Deno.config` would return an object representation of the current configuration file.
- `Deno.configFile` would return the file path to the current configuration file.
- `Deno.beforeArgs`, `Deno.fullArgs` and `Deno.command` would all return info of how the code was run (see comment below with the explanation).

The last could be used in more situations than to find the configuration file, so I think we should add both.
Repository: godot
Issue: GPU Particles Sub Emittor Shape doesnt work.
Labels: topic:3d,topic:particles

### Godot version

Godot 4, alpha14 official [106b68050]

### System information

Windows 11

### Issue description

When setting the "Emission Shape" to Sphere on a subparticle it still just spawns at the position of the parent particle. Setting the Shape to Sphere I would expect it to randomize offset withint the radius of it's parent particle. 
Minimal project attched with setup.

### Steps to reproduce

1.) Create 2 GPU particles, one beeing the parent and one beeing the sub particles.
2.) setup so that the sub particles are beeing spawned from the parent and change the emission shape to sphere on the sub particles. 
3.) observe how they always spawn from the location of the parent particle instead of randomized ofset from parent position respecting the sphere shape.

### Minimal reproduction project

[sub_particles_emission_shape.zip](https://github.com/godotengine/godot/files/9352741/sub_particles_emission_shape.zip)
Repository: vscode
Issue: Multiselect selecting extra elements
Labels: bug,search,confirmed

> Something weird, maybe a disconnect between list focus and list selection. Do a multiselection, click Replace, then shift+click another element. It should select all elements between the selected and clicked element, but it selects extra elements (maybe from the focused to the clicked element)

https://github.com/microsoft/vscode/pull/156963#issuecomment-1215608144
Repository: pytorch
Issue: quantize_per_tensor/quantize_per_channel operators should honor the quant_min/quant_max from observer
Labels: oncall: quantization,triaged

### 🐛 Describe the bug

quantize_per_tensor/quantize_per_channel are operators that converts a floating point Tensor to a quantized (int8) Tensor based on some quantization parameters, the formula is:
```
quantized_Tensor = clamp(fp_Tensor / scale + zero_point, quant_min, quant_max)
```
Currently, since we don't take `quant_min`/`quant_max` as arguments, e.g. signature for `quantize_per_tensor` is 
```
quantize_per_tensor(Tensor self, float scale, int zero_point, ScalarType dtype) -> Tensor
```
the default quant_min/quant_max for the dtype is applied right now. but ideally we should take `quant_min`/`quant_max` from observers.

Currently there is a workaround in https://github.com/pytorch/pytorch/pull/83438 to clamp the weight in the utility function to get the quantized weight, which is shared by both eager mode quantization and fx graph mode quantization. But ideally we should add `quant_min`/`quant_max` arguments to these operators.



### Versions

master

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo
Repository: kubernetes
Issue: [FR] Support multi-NIC egress selection 
Labels: priority/backlog,sig/network,area/apiserver,sig/api-machinery,triage/accepted

To support cluster configurations where the control plane and worker nodes are hosted on different networks connected to different network interfaces (multi-NIC) on the apiserver host instance, `EgressSelector` should be able to select a different interface for egress for different network types.

This probably applies more to the `Direct` protocol. I'm not sure whether there is a use case to supporting konnectivity on different interfaces, but it might be trivial to include support for that once direct connections are supported.

/sig api-machinery network
/area apiserver
/milestone v1.26
Repository: go
Issue: x/text: needs maintainer
Labels: NeedsDecision

@mpvl is listed as [as owner](https://dev.golang.org/owners) of x/text, and appears to have been the main author, but doesn't appear to have worked on anything related to Go on GitHub or Gerrit for over a year. I am a big fan of mpvl's work in x/text but it's half finished and I don't know if any hand off was successful.

There are many Go programmers with an interest in localisation. Could an experienced maintainer coordinate a working group perhaps?

See also #12750.
Repository: rust
Issue: Rust bootstrap - x.py --dist using the wrong Cargo.toml location
Labels: T-bootstrap,C-bug,S-needs-repro

Whilst learning how to bootstrap rust for building on different architectures I ran into a strange bug where running `x.py --dist --build i686-unknown-linux-gnu --host i686-unknown-linux-gnu --target i686-unknown-linux-gnu` would pull the Cargo.toml file from the directory above the one I'm working in currently.

I feel this is a million to one bug I hit from a mistake in copy and pasting from my notes however it's always best to have someone with more knowledge look over what I found so someone else doesn't run into it some other way.

Steps to reduce:

1.  `git clone https://github.com/rust-lang/rust.git -b stable && cd rust`
2.  `git clone https://github.com/rust-lang/rust.git -b stable && cd rust`
3.  edit Config.toml for needs
4.  `/x.py dist --build i686-unknown-linux-gnu --host i686-unknown-linux-gnu --target i686-unknown-linux-gnu`

During the build process it would fail with the following tailed output:

`Compiling rust-demangler v0.0.1 (/usr/src/rust/rust/src/tools/rust-demangler)
Finished release [optimized] target(s) in 9.58s
Dist rust-demangler-1.63.0-i686-unknown-linux-gnu
finished in 0.724 seconds
Building stage1 tool cargo-clippy (i686-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.13s
Dist clippy-1.63.0-i686-unknown-linux-gnu
finished in 4.917 seconds
Dist llvm-tools-1.63.0-i686-unknown-linux-gnu
finished in 44.173 seconds
Dist rust-dev-1.63.0-i686-unknown-linux-gnu
finished in 49.951 seconds
Dist extended stage1 (i686-unknown-linux-gnu)
Dist rust-1.63.0-i686-unknown-linux-gnu
finished in 122.080 seconds
error: current package believes it's in a workspace when it's not:
current: /usr/src/rust/rust/./compiler/rustc_codegen_cranelift/Cargo.toml
workspace: /usr/src/rust/Cargo.toml

this may be fixable by adding `rust/./compiler/rustc_codegen_cranelift` to the `workspace.members` array of the manifest located at: /usr/src/rust/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
Build completed unsuccessfully in 0:16:30`

After being stumped at the message as my toml was fine I noticed that it was using /usr/src/rust/Cargo.toml rather than the one it should be using which should have been /usr/src/rust/rust/Cargo.toml. Simply deleting the /usr/src/rust/Cargo.toml file then rerunning x.py fixed all the issues and resulted in the desired outcome.

As I said I'm not completely sure what caused this but hopefully at least some good can come out of my mistake.

Machine tested on: Gentoo Linux chroot i686 inside a Gentoo Linux x86_64 host.
Repository: pytorch
Issue: Adding Levenberg-marquardt optimizer in PyTorch
Labels: feature,module: optimizer,triaged,needs research

### 🚀 The feature, motivation and pitch

### Feature
Adding levenberg-marquardt (LM) algorithm to Torch.Optim. 

### Motivation
Levenberg-Marquardt (LM), also known as damped least squares, is used to solve non-linear least squares. It converges much faster than gradient descent based methods (orders of magnitude faster). The algorithm needs access to the Jacobian matrix which makes it not suitable for problems with huge data. However, for many applications, like optical design, non-convex optimization, imaging systems design, the size of the network (or model) and data is manageable that LM algorithm provides much better solutions in a fraction of the time (seconds instead of hours). It will be extremely helpful to implement that in torch.optim.

### Alternatives

Two alternatives exist
1.  I can try implementing it myself by calculating the Jacobian. However, the functions that PyTorch provides to do that are extremely slow. 
2. Another method that I routinely use is a recently published paper called: "DeepLM: Large-scale Nonlinear Least Squares on Deep Learning Frameworks using Stochastic Domain Decomposition". This paper and GitHub uses PyTorch and provides an approximate way to implement LM algorithm. However, the structure of their optimizer is very different than the familiar torch.optim and the code needs to be changed significantly to use this paper. 


cc @vincentqb @jbschlosser @albanD
Repository: vscode
Issue: Git - Git error (Cannot fast-forward to multiple branches.) when syncing during autofetch
Labels: bug,git,perf

<!-- ⚠️⚠️ 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. -->
- VS Code Version: 1.70.1
- OS Version: Windows 10

Steps to Reproduce:

In a folder with Git working copy with multiple branches and valid remote:

1. `git config --local --add pull.ff only`
2. in VSCode settings "git.autofetch": true and, maybe "git.confirmSync": false, "git.autofetchPeriod": 10 (to increase chances)
2. click git sync in status bar, a couple of times

```
[2022-08-16T18:25:45.833Z] > git fetch [1557ms]
[2022-08-16T18:25:45.874Z] > git status -z -uall [38ms]
[2022-08-16T18:25:45.907Z] > git symbolic-ref --short HEAD [31ms]
[2022-08-16T18:25:45.943Z] > git for-each-ref --format=%(refname)%00%(upstream:short)%00%(objectname)%00%(upstream:track)%00%(upstream:remotename)%00%(upstream:remoteref) refs/heads/develop refs/remotes/develop [33ms]
[2022-08-16T18:25:45.979Z] > git remote --verbose [31ms]
[2022-08-16T18:25:45.980Z] > git for-each-ref --sort -committerdate --format %(refname) %(objectname) %(*objectname) [35ms]
[2022-08-16T18:25:46.014Z] > git config --get commit.template [31ms]
[2022-08-16T18:25:46.640Z] > git pull --tags origin develop [1606ms]
[2022-08-16T18:25:46.640Z] From ...
 * branch            develop    -> FETCH_HEAD
fatal: Cannot fast-forward to multiple branches.
```

Apparently, `git fetch` can run during `sync` (or the other way around). If this occurs, there might be an error, requesting to open Git log, which contains "Cannot fast-forward to multiple branches".