sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Support `dependsOn` programmatically in the vscode.Task API
Labels: feature-request,api,tasks

<!-- ⚠️⚠️ 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. -->

<!-- Describe the feature you'd like. -->
When defining a task programmatically via the `new vscode.Task()` API, I would like to be able to set the `dependsOn` and `dependsOrder` configurations.

Here's an example some tasks in a tasks.json that I'd like to be able to generate programmatically:
```
{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "workload",
      "action": "apply",
      "args": ["-f", "config/java.yaml", "--yes"],
      "problemMatcher": [],
      "label": "applyWorkload"
    },
    {
      "type": "workload",
      "action": "connect",
      "args": ["9005"],
      "problemMatcher": ["$portForward"],
      "label": "portForward",
      "dependsOn": ["applyWorkload", "someOtherTask"],
      "dependsOrder": "sequence",
      "isBackground": true
    }
  ]
}
```
Repository: rust
Issue: Port non_fmt_panic help and suggestions to the format error diagnostic
Labels: A-diagnostics,T-compiler

The `non_fmt_panic` *lint* looks at the type of argument to suggest something that will most likely work:

Removing a redundant `format!()`:
```
warning: panic message is not a string literal
 --> src/main.rs:2:20
  |
2 |     assert!(false, format!("{} {}", 1, 2));
  |                    ^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: the assert!() macro supports formatting, so there's no need for the format!() macro here
help: remove the `format!(..)` macro call
  |
2 -     assert!(false, format!("{} {}", 1, 2));
2 +     assert!(false, "{} {}", 1, 2);
  | 
```
Suggest `"{}"` only if the thing implements `Display`:
```
warning: panic message is not a string literal
 --> src/main.rs:4:12
  |
4 |     panic!(123);
  |            ^^^
  |
help: add a "{}" format string to Display the message
  |
4 |     panic!("{}", 123);
  |            +++++
```
Suggest `"{:?}"` if the thing impements Debug:
```
warning: panic message is not a string literal
 --> src/main.rs:3:12
  |
3 |     panic!(Some((1, 2)));
  |            ^^^^^^^^^^^^
  |
help: add a "{:?}" format string to use the Debug implementation of `Option<(i32, i32)>`
  |
3 |     panic!("{:?}", Some((1, 2)));
  |            +++++++
```

---

However, the this-is-not-a-format-string-literal *error* doesn't do that at all:

```
error: format argument must be a string literal
 --> src/main.rs:2:14
  |
2 |     println!(format!("{} {}", 1, 2));
  |              ^^^^^^^^^^^^^^^^^^^^^^
  |
help: you might be missing a string literal to format with
  |
2 |     println!("{}", format!("{} {}", 1, 2));
  |              +++++
```
```
error: format argument must be a string literal
 --> src/main.rs:4:14
  |
4 |     println!(123);
  |              ^^^
  |
help: you might be missing a string literal to format with
  |
4 |     println!("{}", 123);
  |              +++++
```
```
error: format argument must be a string literal
 --> src/main.rs:3:14
  |
3 |     println!(Some((1, 2)));
  |              ^^^^^^^^^^^^
  |
help: you might be missing a string literal to format with
  |
3 |     println!("{}", Some((1, 2)));
  |              +++++
```
---
This is especially relevant for Rust 2021, where `panic!(123)` will no longer trigger the lint, and instead triggers the error.

We should make sure the error gives the same suggestions.
Repository: vscode
Issue: Display 2 spaces instead of 4 without changing the code or project settings
Labels: feature-request,editor-rendering

<!-- ⚠️⚠️ 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. -->

<!-- Describe the feature you'd like. -->
Hi, I'm working on projects that requires 4 space indentation, but I find this rule is a bit irritating. Is it possible to have an option to change the displaying/rendering behavior to show 4 spaces as 2 space without actually changing the spaces in the code. Such functionality would also need to work when I want to create a new file with projects indentation requirements, but would still render 4 spaces as 2.
Repository: go
Issue: go/types, types2: error messages don't distinguish between different types with the same names
Labels: NeedsInvestigation

```Go
package p

type T int

func _() {
	type GlobalT = T
	type T int
	var _ T = GlobalT(0)
}
```
produces:
```
x.go:8:12: incompatible type: cannot use GlobalT(0) (constant 0 of type T) as T value
```
The error message reports the same type (`T`) for the variable and the constant, which is confusing.

Maybe we can detect cases like these and provide additional information, such as where the types are declared.

Not urgent as this is a rare scenario.
Repository: flutter
Issue: Establish cost of frame timing API 
Labels: engine,c: performance,perf: speed,P2,team-engine,triaged-engine

The frame timing API involves grabbing a mutex at least once per frame, which itself impacts frame times. We should remove this for release, but we should also try to understand how much this costs in profile mode and whether there are cheaper alternatives.

/cc @iskakaushik
Repository: vscode
Issue: [folding] Newlines created by Insert Line Above command get sucked into previous code fold
Labels: bug,editor-folding

Issue Type: <b>Bug</b>

I'm using pug, but this happens with other indention based languages like python.

Using the following code block, fold the first `ul` and put the cursor in front of the second `ul`.
If you press enter a newline is added outside the fold, but if you use the Insert Line Above command(ctrl+shift+enter) the newline gets sucked into the fold.
```Pug
ul
  li 
ul
  li 
```

VS Code version: Code - Insiders 1.61.0-insider (aec6ee09fa1021cb59c7f4f4d000b027febc967d, 2021-09-03T05:15:18.823Z)
OS version: Linux x64 4.15.0-154-generic
Restricted Mode: No

Extensions: none
<!-- generated by issue reporter -->
Repository: pytorch
Issue: Ability to explicitly close/dispose a DataLoader
Labels: feature,module: dataloader,module: memory usage,triaged,module: data

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->

## Motivation

Per https://github.com/pytorch/pytorch/issues/64720#issuecomment-916159984 Windows limits memory allocation based on `Commit Size`, not the amount of available physical memory.

Per https://github.com/PyTorchLightning/pytorch-lightning/issues/9390 if a user creates multiple `DataLoader`s with `persistent_workers=True` then idle DataLoaders (eligible for garbage collection) may cause Windows to run out of memory. The memory used by sub-processes does not pressure the main process' garbage collector to invoke https://github.com/pytorch/pytorch/blob/e5ab0d1013072c26586b369536bccac648843958/torch/utils/data/dataloader.py#L1328

## Pitch

Expose a public method to close/dispose a `DataLoader`. This would allow users to release memory used by old DataLoaders before instantiating new ones.

## Alternatives

* Invoke `gc.collect()` but the performance impact is large (5-10 seconds per Optuna trial).
* Alternatively, you could provide a mechanism to shut down all idle sub-process without disposing the entire DataLoader.

cc @SsnL @VitalyFedyunin @ejguan
Repository: pytorch
Issue: [Efficiency] No shard + CPU offload in FSDP 
Labels: oncall: distributed,triaged,module: fsdp

We can add a mode to support no sharding strategy, if users do not specify CPU offload, it works like DDP; 

but if users specify CPU offload, then it works like DDP + CPU offload, which could potentially be a performant version to scale, as it does not need all_gather communication.  It is good to run experiments by comparing the performances btw 'fully_shard on GPUs' vs 'no shard + CPU offload' for the same large model like 175B transformer model. 

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @cbalioglu @gcramer23
Repository: go
Issue: encoding/json: add Decoder.DisallowDuplicateFields
Labels: Proposal,Proposal-Accepted

The presence of duplicate fields in JSON input is almost always a bug from the sender and the behavior across various implementations is highly inconsistent. It's too late to switch the current behavior to always reject duplicate fields in the current package, but we can provide an option to enforce stricter checks. As such, I propose adding a `Decoder.DisallowDuplicateFields` option.

---

**Background**

Per [RFC 8259, section 4](https://datatracker.ietf.org/doc/html/rfc8259#section-4), the handling of duplicate names is left as undefined behavior. Rejecting such inputs is within the realm of valid behavior. Tim Bray, the author of RFC 8259, actually recommends going beyond [RFC 8259 and that implementations should instead target compliance with RFC 7493](https://www.tbray.org/ongoing/When/201x/2017/12/14/RFC-8259-STD-90). RFC 7493 is a fully compatible subset of RFC 8259, which makes strict decisions about behavior that RFC 8259 leaves undefined (including the rejection of duplicate names).

The lack of duplicate name rejection has correctness implications where roundtrip unmarshal/marshal does not result in semantically equivalent JSON, and surprising behavior for users when they accidentally send JSON objects with duplicate names. In such a case, the current behavior is actually somewhat inconsistent and difficult to explain.

The [lack of duplicate name rejection may have security implications](https://labs.bishopfox.com/tech-blog/an-exploration-of-json-interoperability-vulnerabilities) since it becomes difficult for a security tool to validate the semantic meaning of a JSON object since meaning is inherently undefined in the presence of duplicate names.

---

**Implementation**

A naive implementation can remember all seen names in a Go map. A more clever implementation can take advantage of the fact that we are almost always unmarshaling into a Go map or Go struct. In the case of a Go map, we can use the Go map itself as a means to detect duplicate names. In the case of a Go struct, we can convert a JSON name into an index (i.e., the field index in the Go struct), and then use a an efficient bitmap to detect whether we saw the name before.

In the common case, there would be no performance slow downs to enabling checks for duplicate names.

---

Aside: I'm not fond of the name `Fields` since JSON terminology calls this either a "name" or "member" (per RFC 8259, section 4). However, it is consistent with the existing `DisallowUnknownFields` option.

\cc @bradfitz @crawshaw @mvdan
Repository: terminal
Issue: Add links to the docs (and maybe the SUI) to infobars
Labels: Help Wanted,Area-UserInterface,Product-Terminal,Issue-Task

> How hard would it be to add a link to the docs (like, to https://docs.microsoft.com/en-us/windows/terminal/customize-settings/profile-advanced#profile-termination-behavior) to that infobar? We could generate the fwlink if needed

@zadjii-msft  - this is not very hard. We can do something like

![image](https://user-images.githubusercontent.com/4639110/132748223-529b0aca-d09a-4634-8e04-db02fac82b59.png)

 but we need to decide if we want to follow up by opening the settings :blush:.... or... we can do all of them:
![image](https://user-images.githubusercontent.com/4639110/132752228-e1acf7ed-92c8-4c68-83fc-cdd13fa0760b.png)

In any case suggest to do it in a follow up. I can open a ticket for it.. and proceed with it if the team is interested.

_Originally posted by @Don-Vito in https://github.com/microsoft/terminal/issues/11139#issuecomment-916385328_
Repository: rust
Issue: Diagnostics with collect used as slice
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](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=44f921afbdb26969b236d654b5f8da01): <!-- Please provide a link to play.rust-lang.org -->

```rust
fn main() {
    let range = 0..5u32;
    let res = sum(&range.collect());
    println!("{}", res);
}


fn sum(nums: &[u32]) -> u32 {
    let mut total = 0;
    for n in nums {
        total += n;
    }
    total
}
```

The current output is:

```
error[E0277]: a value of type `[u32]` cannot be built from an iterator over elements of type `u32`
 --> src/main.rs:3:19
  |
3 |     let res = sum(&range.collect());
  |                   ^^^^^^^^^^^^^^^^ value of type `[u32]` cannot be built from `std::iter::Iterator<Item=u32>`
  |
  = help: the trait `FromIterator<u32>` is not implemented for `[u32]`
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error: Type annotation required to select the correct collect() variant
help: based on context, I can only determine that it must be a type which can be borrowed as &[u32]
help: for example, you might want range.collect::<Vec<u32>>()
```

<!--
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.
-->
Repository: pytorch
Issue: [JIT] Canonicalize aten::rsub 
Labels: oncall: jit

## 🚀 Feature

Pytorch has [two](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/native_functions.yaml#L4844) [operators](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/native_functions.yaml#L4868) for rsub  which have the semantics `rsub(x, y) == y - x`. Generally, having two different operators that do the same thing in the your IR is not desirable because it means passes have to reason about both cases if they want to optimize the pattern. Additionally, optimizations like Common Subexpression Elimination will no trigger.

```
@torch.jit.script
def foo(x, y):
    return (x - y) + 1, (x - y) + 1

torch._C._jit_pass_cse(foo.graph)
torch._C._jit_pass_dce(foo.graph)
print(foo.graph)
```
Will give a graph with a single `aten::sub` node, where as the semantically equivalent 

```
@torch.jit.script
def foo(x: bool):
    return (x - y) + 1, torch.rsub(y, x) + 1

torch._C._jit_pass_cse(foo.graph)
torch._C._jit_pass_dce(foo.graph)
print(foo.graph)
```

Will have two different sub nodes. This is of particular interest because we have optimizations like [fusion](https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/tensorexpr_fuser.cpp#L70) which target `sub` but do not handle `rsub`. We already have an existing pass that runs whenever we emit IR to do similar normalization, we could add this pattern there. https://github.com/pytorch/pytorch/blob/master/torch/csrc/jit/passes/normalize_ops.cpp
Repository: rust
Issue: Tracking Issue for RFC 3123: Scrape code examples from `examples/` directory for Rustdoc
Labels: T-rustdoc,B-RFC-approved,C-tracking-issue,A-rustdoc-scrape-examples

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

This is a tracking issue for the RFC "Scrape code examples from `examples/` directory for Rustdoc" (rust-lang/rfcs#3123).

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [x] Implement the RFC (#85833 and rust-lang/cargo#9525)
- [x] Allow users to (unstably) enable on docs.rs (no changes needed)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

1. Is showing 1 example by default the best idea? Or should scraped examples be hidden by default? 
2. Is the ability to see the full file context worth the increase in page size?
3. How should the examples be ordered? Is there a way to determine the "best" examples to show first?

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

- #85833
- rust-lang/cargo#9525
Repository: TypeScript
Issue: No warning for a class implementing itself
Labels: Suggestion,Awaiting More Feedback

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

[implements itself, self implements]

### 🕗 Version & Regression Information

- This is the behavior in every version I tried from 3.3 on, and I reviewed the FAQ for entries about inheritance.

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.4.2#code/MYGwhgzhAEBiD29oEsC2AHEBTVWB2ALjAkgN4C+QA)

### 💻 Code

```ts
class Foo implements Foo {}
```

### 🙁 Actual behavior

This code passed typechecking.

### 🙂 Expected behavior

I expected the TypeScript compiler to emit an error on this code.

As far as I know, it's a no-op for a class to implement itself. The code author very likely intended to write something else.

This came up in the wild in TypeScript inside Google's repo. A file was trying to create a fake version of [`MediaSession`](https://developer.mozilla.org/en-US/docs/Web/API/MediaSession) with `export class MediaSession implements MediaSession {` for testing. The class accidentally implemented itself instead of the `MediaSession` interface from https://github.com/DefinitelyTyped/DefinitelyTyped/blob/c6f1fc8c0b7c2ebe8e099586af618b0a33cfef65/types/wicg-mediasession/index.d.ts#L20.

Another example found via Google: https://stackoverflow.com/questions/54306190/what-does-it-mean-when-a-class-implements-itself-in-typescript
Repository: flutter
Issue: [2.5]: Error message from the framework is not helpful to debug where the actual issue is.
Labels: tool,framework,t: hot reload,a: quality,a: debugging,c: proposal,P3,team-framework,triaged-framework


## Steps to Reproduce

Put a column with main axis size = max in a scrollable and run it on Android.

In VS Code this goes through no less than 11 breakpoints in the flutter sdk. The release notes say that it's supposed to make breaking into flutter sdk better and not obnoxious but it's WAY worse.

AND the gibberish it spews makes it all but impossible to tell what control actually has the issue in all but trial and error
AND if you change something after that, hot reload doesn't work and hangs and you have to stop debug and start it again.


## What it should do
Break on the actual line of code for the actual control that actually is causing the problem WITHOUT breaking into ANY of the flutter sdk.
Repository: go
Issue: go/parser: StructType.End() can overflow the File
Labels: NeedsInvestigation,gopls/parsing

As encountered in #48249, `StructType.End()` can overflow the file (such that `File.Offset` panics).

This is due to the error recovery here:
https://cs.opensource.google/go/go/+/master:src/go/parser/parser.go;l=675;drc=0406d3a8e5301bd5fd697018e6e8fbb9c75eeb42

Which will set the `StructType.Fields.Closing` to the end of the file, and then `StructType.Fields.End` overflows:
https://cs.opensource.google/go/go/+/master:src/go/ast/ast.go;l=252;drc=master

This is a low priority (the logic that gopls was using should have been more robust), but I feel like it should be an invariant of nodes that if `Pos()` or `End()` is not `token.NoPos`, they have a valid offset.

Are there counter-arguments or contradicting precedent?

CC @griesemer @stamblerre
Repository: go
Issue: testing: report line number for F.Add call with mismatched type
Labels: NeedsFix,fuzz

If `F.Add` is called with values with types that don't match the fuzz function's parameter types, `f.Fuzz` reports a fatal error and exits.

```
func Fuzz(f *testing.F) {
  f.Add("string not bytes")
  f.Fuzz(func(t *testing.T, b []byte) { ... })
}
```

The error message should point to the location where `F.Add` was called to make the error easy to correct.

A vet check (#46218) should report errors for these calls at build time.
Repository: go
Issue: internal/fuzz: deduplicate interesting inputs
Labels: NeedsInvestigation,fuzz

When the fuzzing engine starts, it runs inputs in the seed corpus and cached inputs to gather baseline coverage.

If two inputs provide the same coverage, we should prioritize one and ignore or deprioritize the other, perhaps deleting it if it was cached.

The [AFL whitepaper](https://lcamtuf.coredump.cx/afl/technical_details.txt) explains how they deduplicate inputs based on coverage. We might use a similar algorithm. We could also use size and duration as metrics: smaller, faster inputs are better.