sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: "The task is already active" button "Restart Task" doesn't re-read tasks.json
Labels: bug,help wanted,tasks

<!-- ⚠️⚠️ 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.74.1
- OS Version: Windows

Steps to Reproduce:

1. Create a task in tasks.json and run it from "Run Task" in Command Palette
2. Use "Run Task" in Command Palette, open the Terminal panel and go to the task.
3. While the task is running, edit the task in tasks.json and save.
4. Warning message appears, The task '..' is already active.
5. Click "Restart Task". The task restarts with the old task definition instead of the new one.
Repository: opencv
Issue: It fails to build OpenCV if the source directory paths contain a Glob wildcard.
Labels: bug,priority: low,category: build/install

# Version

OpenCV 4.6.0


# Bug

 In order to locate available module subdirectories, OpenCV’s CMake scripts make a Glob expression by appending “`/*`” to the absolute paths of the source directories (`OpenCV_SOURCE_DIR` or `OPENCV_EXTRA_MODULES_PATH`).

https://github.com/opencv/opencv/blob/ac6fb1778433e9c4d27148443b3d9eb848c53d3b/cmake/OpenCVModule.cmake#L262-L263

 If the source directory paths contain a [Glob wildcard](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax) (e.g. `[…]`), it is parsed as per [the Glob syntax](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax), the Glob expression matches nothing, and OpenCV fails to locate available modules.

```
CMake Error at cmake/OpenCVModule.cmake:276 (message):
  No modules has been found:
  B:/…/[…]/…/opencv-4.6.0/modules
```
```
CMake Error at cmake/OpenCVModule.cmake:276 (message):
  No modules has been found:
  B:/…/[…]/…/opencv_contrib-4.6.0/modules
```

## How to produce this error again

Let the absolute paths of the source directories (`OpenCV_SOURCE_DIR` or `OPENCV_EXTRA_MODULES_PATH`) contain a [Glob wildcard](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax). For instance, try building `C:/!a/b [c/d] e/[f]/opencv-4.6.0/` with CMake.

# A minor grammar correction

https://github.com/opencv/opencv/blob/ac6fb1778433e9c4d27148443b3d9eb848c53d3b/cmake/OpenCVModule.cmake#L274

```CMake
message(SEND_ERROR "No modules has been found: ${path}") 
```

should be “_No modules **have**_….”

-----

### Issue submission checklist

- [X] I report the issue, it's not a question
- [X] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [X] I updated to the latest OpenCV version and the issue is still there
- [X] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: flutter
Issue: Unexpected opening keyboard in TextField on dragging the selection toolbar
Labels: a: text input,framework,f: material design,has reproducible steps,found in release: 3.3,found in release: 3.7,team-design,triaged-design

Having a long text in a TextField and trying to select a big portion of this is not possible by dragging.
Use the simple app in my sample code, then try to select a large portion of the text by drag.
Once the cursor reaches the bottom of the screen or the top of the keyboard, then the scroll jumps back to the start position and doesn't let you complete your selection.

Steps to reproduce:
1. Run the sample code below on DartPad.dev
2. try to select **from** the line ending with **"4" to** the line ending with **"200" By dragging**.

Expected:
Continue selecting the text smoothly by dragging.

Actual:
Showing the keyboard up (on Mobile) at the same time with dragging, and jumping scroll back to the start position of the selection.

<details>
<summary>Sample code</summary>

```
import 'package:flutter/material.dart';

void main() =>
  runApp(MaterialApp(
    home: Scaffold(
      appBar: AppBar(title: const Text('a: TextField')),
      body: SingleChildScrollView(
        child: TextField(
          controller: TextEditingController(
            text: List.generate(300, (e)=> 'this is the text to be selected by dragging $e').join('\n')
          ),
          maxLines: null,
        ),
      ),
    ),
  ));
```
</details>
Repository: pytorch
Issue: dynamo.optimizations.training.aot_autograd does not trace correct overload
Labels: triaged,has workaround,months,oncall: pt2,module: aotdispatch,oncall: export,module: pt2-dispatcher

### 🐛 Describe the bug

In the following Python program, `x + 2` gets traced as `torch.ops.aten.add.Tensor` instead of `torch.ops.aten.add.Scalar` which would be more technically correct (and is the op that torch.jit.script gives). I noticed this because in Torch-MLIR we verify that the operands match the schema exactly. Is it possible to have aot_autograd trace the more technically correct overload? Or can you provide guidance about how to correctly emulate the promotion semantics in appropriate generality?

Also, to add onto that, `torch.ops.aten.add.Tensor` is missing an argument. I need special-case code in my importer to handle this (by querying the schema for the default value). One possibility could be that PyTorch provides a utility that normalizes the graph of aten ops to "typecheck" correctly against the schemas of the constituent ops including reifying all default values.

```python
from typing import List

import torch
import torch._dynamo as dynamo
from torch._dynamo.optimizations.training import aot_autograd


def my_backend(gm: torch.fx.GraphModule, example_inputs: List[torch.Tensor]):
    gm.print_readable()
    return gm


@dynamo.optimize(aot_autograd(fw_compiler=my_backend))
def f(x):
    return x + 2


example_inputs = (torch.randn(3, 4),)
f(*example_inputs)
```

Output:
```
class <lambda>(torch.nn.Module):
    def forward(self, arg0_1: f32[3, 4]):
        # File: /tmp/repro2.py:15, code: return x + 2
        add: f32[3, 4] = torch.ops.aten.add.Tensor(arg0_1, 2);  arg0_1 = None
        return (add,)     
```

### Versions

PyTorch version: 2.0.0.dev20221213+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Debian GNU/Linux rodete (x86_64)
GCC version: (Debian 12.2.0-3) 12.2.0
Clang version: 14.0.6-2
CMake version: version 3.25.0
Libc version: glibc-2.35

Python version: 3.10.8 (main, Nov  3 2022, 15:17:13) [GCC 12.2.0] (64-bit runtime)
Python platform: Linux-5.19.11-1rodete1-amd64-x86_64-with-glibc2.35
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.24.0rc2
[pip3] torch==2.0.0.dev20221213+cpu
[pip3] torchvision==0.15.0.dev20221213+cpu
[conda] Could not collect

cc @ezyang @bdhirsh @anijain2305 @chauhang @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4 @zou3519 @msaroufim @wconstab @soumith @ngimel
Repository: go
Issue: x/tools/gopls: consider avoiding the workspace/configuration request
Labels: NeedsInvestigation,gopls,Tools

Right now, gopls uses the `workspace/configuration` request to resolve configuration of workspace folders.

As described in https://github.com/golang/go/issues/54559#issuecomment-1350216715, it is odd to manage configuration server-side, when all other session state is managed client-side. Furthermore, as described in https://github.com/microsoft/language-server-protocol/issues/972, the `workspace/configuration` request poses problems for clients, as they need to specialize to various servers.

IIUC, the only reason gopls makes `workspace/configuration` requests is to support different settings for different workspace folders. In particular, this allows for different sets of build tags per folder, which is a workaround for lacking build tag support in gopls (#29202). I'm not sure whether anyone is actually using this workaround.

We should investigate if we can change gopls' configuration model to simply rely on initialization options and didChangeConfiguration payloads.
Repository: neovim
Issue: show news.txt diff on startup  (especially breaking changes)
Labels: enhancement,plugin,complexity:low,startup

# Problem

Currently people on development branch (master) must follow https://github.com/neovim/neovim/issues/14090 or manually read `:help news` to see recent changes.

# Proposal

1. On (interactive) startup, asynchronously (CursorHold?), store the contents of `news.txt` at `stdpath('state')`
    - also store the current Nvim version in a shada-stored variable like `g:NVIM_VERSION`
2. On (interactive) startup, compare the current Nvim version to `g:NVIM_VERSION`.
    - related: https://github.com/neovim/neovim/issues/20981
3. If current version is newer, store it in `g:NVIM_VERSION`.
4. If `g:NVIM_VERSION` was defined (and older than current version, _or if the versions are equal but the contents of `news.txt` are bigger_),
    - Diff the old news.txt with the current news.txt. If it contains breaking changes, show a modal prompt like:
        - `This version of Nvim has breaking changes since the previously used version (x.y.z-123). Show the diff of news.txt?`
    - Else: _do nothing_ if `g:NVIM_VERSION` was undefined / non-existant before this startup.

# Open questions

- Only do this for non-release versions?
Repository: deno
Issue: Add "engine" to config
Labels: suggestion

Make Deno exit with non zero when engine requirements are not met 

```json
{
  "engine": {
    "deno": ">=~1.29"
  }
}
```
Repository: rust
Issue: Too many `dyn Trait` is not `Sized` errors
Labels: A-diagnostics,P-low,T-compiler,D-verbose

When writing

```rust
trait T {}

fn foo() -> dyn T {
    todo!()
}

fn main() {
    let x = foo();
}
```

We emit three errors for `dyn T: Sized` not being fulfilled. We should likely only emit 1, in `foo`'s return type, but we certainly shouldn't be emitting both one for `x` and one for `foo`'s call.

```
error[E0746]: return type cannot have an unboxed trait object
 --> src/main.rs:3:13
  |
3 | fn foo() -> dyn T {
  |             ^^^^^ doesn't have a size known at compile-time
  |
help: use `impl T` as the return type if all return paths have the same type but you want to expose only the trait in the signature
  |
3 | fn foo() -> impl T {
  |             ~~~~~~
help: use a boxed trait object if all return paths implement trait `T`
  |
3 | fn foo() -> Box<dyn T> {
  |             ++++     +

error[E0277]: the size for values of type `dyn T` cannot be known at compilation time
 --> src/main.rs:8:9
  |
8 |     let x = foo();
  |         ^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `dyn T`
  = note: all local variables must have a statically known size
  = help: unsized locals are gated as an unstable feature

error[E0277]: the size for values of type `(dyn T + 'static)` cannot be known at compilation time
 --> src/main.rs:8:13
  |
8 |     let x = foo();
  |             ^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `(dyn T + 'static)`
  = note: the return type of a function must have a statically known size
```

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: vscode
Issue: Render quick input separators as individual items instead of applying border to list item
Labels: feature-request,quick-pick

Here's what the borders look like today. Note the gap on both sides that results from L/R padding used to get the spacing effect on list items.

<img width="658" alt="CleanShot 2022-12-15 at 09 44 09@2x" src="https://user-images.githubusercontent.com/25163139/207931312-57aab45d-e93b-4d72-864d-04c9101fbce2.png">

<img width="663" alt="CleanShot 2022-12-15 at 09 53 19@2x" src="https://user-images.githubusercontent.com/25163139/207932838-e03effa0-c93e-42a1-a694-57d554858b8e.png">


Because separators are rendered on the list items themselves, there are two problems:
- I can't render them to take up the full width of the quick pick as desired (see context menu example below)
- I can't change their height to better separate sections within a quick pick list
- Items are jammed up against the border when hovered/focused

## Prior art

<img width="324" alt="CleanShot 2022-12-15 at 09 44 24@2x" src="https://user-images.githubusercontent.com/25163139/207931804-dd666fa7-daf6-4000-b99a-8bebaa845f0d.png">
<img width="314" alt="CleanShot 2022-12-15 at 09 45 28@2x" src="https://user-images.githubusercontent.com/25163139/207931807-83137a9e-8df3-4f42-8c27-7bdba0bdf0f1.png">

## Example
<img width="974" alt="CleanShot 2022-12-15 at 09 53 42@2x" src="https://user-images.githubusercontent.com/25163139/207932803-a4cb9b9a-3457-49f7-9a4f-a3545e0b587c.png">
<img width="1013" alt="CleanShot 2022-12-15 at 09 53 47@2x" src="https://user-images.githubusercontent.com/25163139/207932820-d5a8f028-bb41-40d1-b23f-3a5df3bd7b35.png">
Repository: go
Issue: cmd/go: update "GOPATH environment variable" section to be module-mode first
Labels: Documentation,NeedsFix,GoCommand

Current version of [GOPATH_environment_variable](https://pkg.go.dev/cmd/go@go1.20rc1#hdr-GOPATH_environment_variabl) (as of go1.20rc1)
is still focusing more on the use/layout of GOPATH in GOPATH-mode and is a common source of confusion for users.

It is followed by a tiny section [GOPATH_and_Modules](https://pkg.go.dev/cmd/go@go1.20rc1#hdr-GOPATH_and_Modules) but this is really easy to miss.


cc @bcmills @matloob @rsc
Repository: go
Issue: runtime: reserve address space for large slice backing stores to make slice growth cheaper
Labels: NeedsInvestigation,FeatureRequest,compiler/runtime

When append() sees the underlying array is used to capacity, it allocates a bigger array, copies values, zeroes the rest, and returns.

This proposal will make this grow() logic cheaper:

If the OS offered an extend() then it would be possible to avoid the copy. However this is unlikely because the following virtual address space is often claimed already.

Q: In supported 64-bit OSes, what if all unbounded requests asked the OS for 1TB of reserved memory?
A: Then most all grow() calls could just claim and zero the next chunk of reserved memory. That's because extra reserved memory is just an address until it page-faults into existence.

In practical terms, I see 2 ways to go:
1) Expressing 1TB of capacity to the user would require either zeroing on exposure.
2) Expressing a much smaller capacity to the user would require the allocator to have a separate capacity concept that it would consult to determine if a new allocation is necessary (typically not). 

There's likely a refinement sweet-spot around the variables of:
 - at what growth size should we allocate a giant allocation?
 - how big is giant allocation (1TB in the example above)?
 - should we have a smaller "giant allocation" for initial slices, like initially 1MB then 1TB?
 - Does this upset the Linux OOM killer?
Repository: TypeScript
Issue: `super` constructor() promotion
Labels: Suggestion,Awaiting More Feedback

# Suggestion

## 🔍 Search Terms

super promotion

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code (_I don't know what it mean_)
* [ ] This could be implemented without emitting different JS based on the types of the expressions (_I don't know_)
* [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.) (_I belive so_)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## ⭐ Suggestion

The typescript is able to perform _property promotion_ in `constructor()`. That's really good. It would be interesting to take this same feature directly to `super()` as well. This would avoid duplicating names between parameters and the `super()`.

## 💻 Use Cases

```ts
class Animal {
    constructor (public name: string, 
                 public age: number, 
                 public weight: number) {}
}

// Currently:
class Dog extends Animal {
    constructor (public name: string, 
                 public age: number, 
                 public weight: number,
                 public breed: string) {
        super(name, age, weight)
    }
}

// Suggestion:
class Dog extends Animal {
    constructor (super name, 
                 super age,
                 super weight,
                 public breed: string) {
    }
}
```
Repository: angular
Issue: Component testing scenarios docs page outdated and advises harmful test practices
Labels: state: needs eng input,P2,area: docs

### Describe the problem that you experienced

We should review the content of the [component testing scenarios](https://angular.io/guide/testing-components-scenarios#component-testing-scenarios) page in full detail. Some (but not all) of the issues here are:

* Advice for creating test spies that do not implement the whole interface
```
const twainService = jasmine.createSpyObj('TwainService', ['getQuote']);
getQuoteSpy = twainService.getQuote.and.returnValue(of(testQuote));
...
providers: [{provide: TwainService, useValue: twainService}]
```
This is problematic on the whole. In this particular scenario, we should be using `HttpClientTestingModule` and _not_ providing a service fake.
* Component marble tests section - RxJS is a separate library. Documentation on testing RxJS specifics should not live in Angular docs. 
* Component inside a test host section - we now have [`setInput`](https://angular.io/api/core/ComponentRef#setInput), making host components less necessary
* Sections related to router - These sections should use `RouterTestingModule`. `ActivatedRoute` stubs are brittle and _do_ rely on Router navigations to be created appropriately.


Overall, this page has many test practices that our team would not recommend. It should be reviewed on the whole to ensure we are not leading developers down a path we wouldn't take ourselves.

### Enter the URL of the topic with the problem

https://angular.io/guide/testing-components-scenarios#component-testing-scenarios
Repository: rust
Issue: Cannot subtract dates before UNIX_EPOCH when targeting wasm32
Labels: O-wasm,C-bug,T-libs

I'm using a crate that calculates the Windows epoch (1601-01-01T00:00:00Z) from the `UNIX_EPOCH` (1970-01-01T00:00:00Z) but it panics when targeting wasm32-unknown-unknown because of a `checked_sub` against `u64`. This appears to be because, for wasm32 (references "unsupported" sources up a level in the source tree), `SystemTime` is a newtype of `Duration`, which uses unsigned integers. On (most?) other platforms, `SystemTime` is a `Timespec` which uses signed integers; thus, any arithmetic on said fields can produce negative results, which is desirable.

Given `Duration` represents a span of time instead of an absolute time like `SystemTime`, shouldn't any `SystemTime` use signed integers representing absolute time?

I tried this code:

```rust
/// Returns the epoch used for Windows `FILETIME` values.
fn filetime_epoch() -> SystemTime {
    // The epoch used by CFB files is Jan 1, 1601 UTC, which we can calculate
    // from the Unix epoch constant, which is Jan 1, 1970 UTC.
    UNIX_EPOCH - Duration::from_secs(11644473600)
}
```

I expected a `SystemTime` representing 1601-01-01T00:00:00.

Instead, a panic occurred in `<std::time::SystemTime as core::ops::arith::Sub<core::time::Duration>>::sub`:

```rust
fn sub(self, rhs: Duration) -> Duration {
    self.checked_sub(rhs).expect("overflow when subtracting durations")
}
```

### Meta

`rustc --version --verbose`:
```
rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: x86_64-unknown-linux-gnu
release: 1.64.0
LLVM version: 14.0.6
```

<details><summary>WASM backtrace</summary>
<p>
<code>wasm-pack</code> or something in the toolchain seems to ignore <code>RUST_BACKTRACE</code> but the browser is generating it's own, which I hope is helpful:

```
$core::option::expect_failed::ha758e0d1c5165b94 | @ | 7516d5d……odule.wasm:0x1318da
$<std::time::SystemTime as core::ops::arith::Sub<core::time::Duration>>::sub::h47beefa3c5880621 | @ | 7516d5d……odule.wasm:0x10e7c0
$msi::internal::time::filetime_epoch::h319c0984523cb136 | @ | 7516d5d….module.wasm:0xf247e
$msi::internal::time::system_time_from_filetime::hb7b59f8afe76e03c
```
</p>
</details>


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: vscode
Issue: Search editor context lines is ambiguous and doesn't appear to be accessible to screen readers
Labels: bug,confirmed,search-editor

![image](https://user-images.githubusercontent.com/2193314/207968078-ae7be7a8-26eb-4dcf-bfec-c26505bbde44.png)

![image](https://user-images.githubusercontent.com/2193314/207968089-b12f08b7-6917-45c2-ab87-434794203e42.png)

I expect to be able to hover it and see a `title` hover that explains that it's the context lines, and a `label` or `aria-label` that tells a screen reader what the input is.
Repository: vscode
Issue: Search editor can randomize the result order and also the file count(?) when changing the context lines
Labels: bug,confirmed,search-editor

![Recording 2022-12-15 at 13 14 37](https://user-images.githubusercontent.com/2193314/207968555-696c0c5c-c8bf-4ba4-86a5-916e97cc10e5.gif)
Repository: pytorch
Issue: [Composable] Enable setting state_dict_type
Labels: high priority,triage review,oncall: distributed,triaged,module: fsdp

### 🚀 The feature, motivation and pitch

There are a couple issues we need to fix to enable set_state_dict type for composable path, such as the issue of `fsdp_modules` which is an FSDP method being used in set_state_dict_type.

One suggestion is to use the common composable State APIs landed in https://github.com/pytorch/pytorch/pull/89147/files. 

### Alternatives

_No response_

### Additional context

_No response_

cc @ezyang @gchanan @zou3519 @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: vscode
Issue: Buttons are taller when theme defines `button.border`
Labels: bug,themes

![CleanShot 2022-12-15 at 13 48 11](https://user-images.githubusercontent.com/25163139/207975254-2fd59986-1b18-4e33-8d21-592a9ee92096.gif)