sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/tools/go/packages: use goroutine only for load-ready packages in (*loader).refine
Labels: NeedsInvestigation,Tools

(*loader).refine uses (*loader).loadRecursive internally, which may produce a large amount of goroutine as the import graph grows.

With code like following, you can use goroutine only for packages that are ready to load. ([existing code](https://github.com/golang/tools/blob/93eecc3576be04bf4c262289a280dfe13690c317/go/packages/packages.go#L696))

```
// Load type data and syntax if needed, starting at
// the initial packages (roots of the import DAG).
if ld.Mode&NeedTypes != 0 || ld.Mode&NeedSyntax != 0 {
	visited := make(map[*loaderPackage]bool, len(ld.pkgs))
	var visit func(pkg *loaderPackage)
	visit = func(pkg *loaderPackage) {
		for _, imp := range pkg.Imports {
			imp := ld.pkgs[imp.ID]
			if !visited[imp] {
				visited[imp] = true
				visit(imp)
			}
		}
	}
	for _, lpkg := range initial {
		visited[lpkg] = true
		visit(lpkg)
	}

	var wg sync.WaitGroup
	waitNum := make(map[*loaderPackage]*int32, len(visited))
	importedBy := make(map[*loaderPackage][]*loaderPackage, len(visited))

	for lpkg := range visited {
		if !visited[lpkg] {
			continue
		}
		l := int32(len(lpkg.Imports))
		waitNum[lpkg] = &l
		for _, imp := range lpkg.Imports {
			p := ld.pkgs[imp.ID]
			importedBy[p] = append(importedBy[p], lpkg)
		}
	}

	var loadRec func(*loaderPackage)
	loadRec = func(lpkg *loaderPackage) {
		lpkg.loadOnce.Do(func() {
			ld.loadPackage(lpkg)
			for _, lpkg2 := range importedBy[lpkg] {
				if atomic.AddInt32(waitNum[lpkg2], -1) == 0 {
					lpkg2 := lpkg2
					wg.Add(1)
					go func() {
						loadRec(lpkg2)
						wg.Done()
					}()
				}
			}
		})
	}

	for lpkg := range visited {
		if atomic.LoadInt32(waitNum[lpkg]) == 0 {
			lpkg := lpkg
			wg.Add(1)
			go func() {
				loadRec(lpkg)
				wg.Done()
			}()
		}
	}
	wg.Wait()
}
```
Repository: vscode
Issue: Provide an option for TextEdit to respect the indentation level
Labels: feature-request,api,suggest

When using `vscode.CompletionItem.additionalTextEdits` to perform additional textedits after a code completion, the textedits don't respect the indentation level at the point where the edits are made, unlike the autocompletion itself which, if it wraps to multiple lines, respects the current indentation level. This is particularly apparent for a `vscode.TextEdit.insert`.

Would it be possible for `vscode.TextEdit` to be given an option to retain the current indentation level for an edit? This would work just like `vscode.CompletionItem.keepWhitespace` but for backwards compatibility its default value would be `true`. Setting it to `false` would cause the edit to adjust the leading whitespace so it matches the surrounding lines.

Possibly related issues:

* #32158
* #101773
Repository: rust
Issue: Is rustc missing an optimisation in this short code sample?
Labels: I-slow,T-compiler

Here are two samples of source code - a [Rust sample](https://rust.godbolt.org/z/7er15d) compiled with Rust 1.46.0 using the `thumbv4m-none-eabi` target, and a [C sample](https://godbolt.org/z/nPqGaP) compiled using clang 10.0.0. (The results are identical using Rust nightly and clang trunk.) They are as far as I can tell functionally identical.
```rust
#![no_std]

#[repr(C)]
pub struct Color {
    pub red: u8,
    pub green: u8,
    pub blue: u8,
}

pub extern "C" fn convert(color: Color) -> u16 {
    ((((color.red >> 3) & 0x1F) as u16) << 0)
    | ((((color.green >> 3) & 0x1F) as u16) << 5)
    | ((((color.blue >> 3) & 0x1F) as u16) << 10)
}
```
```c
#include <stdint.h>

struct Color {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
};

uint16_t convert(struct Color color) {
    return (((color.red >> 3) & 0x1F) << 0)
        | (((color.green >> 3) & 0x1F) << 5)
        | (((color.blue >> 3) & 0x1F) << 10);
}
```
However, Rust is one instruction slower, and appears to be missing an optimisation - clang calculates `0x1F << 10` and delays adding together the intermediate values until the very end, whereas Rust starts with `0x1F << 5` and therefore has to perform an extra `mov`.
Repository: flutter
Issue: Possibility to disable drawer open gesture on certain condition
Labels: framework,f: material design,c: proposal,a: layout,P3,team-design,triaged-design

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case

A production Flutter app can be design to run on smartphones or tablets (or other different devices with different screen size). 
In my app every page/widget I create will manage the layout build due to the device screen type. 
What does it mean?
I don't have `home_page_mobile.dart`, `home_page_tablet.dart` and `home_page_desktop.dart` but I have only one file named `home_page.dart` and in this one I make some little things to adapt the layout.
Actually I'm facing with a problem due to the fact that on mobile I need to use `Drawer` widget but I don't need it on tablets. 
Flutter at the moment does not provide any type of instruction to disable drawer app wide (included gestures) on certain condition. There are some workaround but I need to change (or create new files) a lot of files/pages.

## Proposal
Create a method that we can use to disable `Drawer` for example when app is starting or a Drawer property that can simply disable it (or at least the gestures).
Something like
```dart
Drawer(
          child: MyChild(),
          // idea n.1
           disableGestures: true/false
          //OR
          disableWhen: (){....}
)
```

There is also [something similar](https://github.com/flutter/flutter/issues/31127) on this repo but it has been closed with no real solution. Pass all pages scaffold widgets to add a condition to hide Drawer in my opinion is not a good idea.
It will be beautiful to manage the visibility/gestures directly on `Drawer` widget that normally is reused on a lot of scaffold widgets (in my case a lot of pages).

Thank you
Repository: TypeScript
Issue: Proposal: Spread Interface Operator
Labels: Suggestion,Awaiting More Feedback

## Suggestion

When we want to extend a interface we use the "extends" keyword. So for example:

```javascript 

interface Foo {
   keyA: string,
   keyB: number,
}

interface ExtendsFoo extends Foo {
    keyC: any
}

```

My idea is to define the same interface ExtendsFoo but using what I would call the **Spread Interface Operator**.

The code mentioned above could be rewritten as:

```javascript 

interface Foo {
   keyA: string,
   keyB: number,
}

interface ExtendsFoo {
   ...Foo,
   keyC: any
}

```

I think this could be another way of expressing types that reminds spread operator syntax in Javascript.
Repository: flutter
Issue: Users can't tap menu items that haven't appeared yet.
Labels: framework,a: animation,f: material design,a: accessibility,a: fidelity,a: quality,has reproducible steps,P3,team-design,triaged-design,found in release: 3.19,found in release: 3.20

Users should be able to interact with UI elements before they have finished animating, otherwise the animations are an active hindrance to users who are familiar with the application.

For popup menus in particular, this means the user should be able to select a menu item before it's fully rendered. ~~We used to support this, though apparently we didn't test it because we have since regressed it. :-(~~

Steps to reproduce:
* Launch `dev/integration_tests/flutter_gallery`
* In the settings screen, select Slow Motion
* Run Material > Menus
* Tap the menu button in the toolbar, then immediately tap on top of where the third menu button is (the the one on the second list item). This should select "Hooray" from the menu.

Actual results: The menu gets canceled, nothing is selected.

Expected results: A snackbar saying that you selected hooray.

When fixing this, consider how to handle https://github.com/flutter/flutter/issues/804.
Repository: PowerToys
Issue: Thumbnails for flv, webp, and webm files
Labels: Idea-Enhancement,Product-File Explorer

A while back I suggested adding thumbnails for SVG files.  Can you add some for *.flv, *.webp, and *.webm files?
Repository: rust
Issue: Recursive Trait Hang in rustc
Labels: P-medium,T-compiler,regression-from-stable-to-stable,C-bug,I-hang

The code below, as the sole content of main.rs, should reproduce the error:

```rust
pub trait Indexed {
    type Index;
}

pub trait At<Address> {
    type AtItem;
    fn at(&self, address: Address`) -> &Self::AtItem;
}

impl <T, U> At<(T::Index,U)> for T
where
    Self: At<T::Index>,
    <T as At<T::Index>>::AtItem : At<U>,
    T : Indexed,
{
    type AtItem = <<T as At<T::Index>>::AtItem as At<U>>::AtItem;

    fn at(&self, address: (T::Index,U)) -> &<<T as At<T::Index>>::AtItem as At<U>>::AtItem {
        let (x,y) = address;
        At::<U>::at( self.at(x), y)
    }
}

fn main() {
    ().at(())
}
```
It pegs a CPU at 100%, and begins to consume progressively more memory (over 10 GB). It does not identify that Unit does not implement trait `At`

This issue is present in rustc 1.48.0-nightly (d006f5734 2020-08-28).
Repository: rust
Issue: Extremely confusing error around function pointers with inferred arguments
Labels: A-type-system,A-diagnostics,T-compiler,A-inference,D-confusing,T-types

Consider the following code ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f28baa0f92dd6719da86c30648e1894a)):

```rust
struct S<'a>(&'a str);

fn f(inner: fn(&str, &S)) {
}

#[allow(unreachable_code)]
fn main() {
    let inner: fn(_, _) = unimplemented!();
    f(inner);
}
```

Rustc gives an error:
```rust
error[E0308]: mismatched types
 --> src/main.rs:9:7
  |
9 |     f(inner);
  |       ^^^^^ one type is more general than the other
  |
  = note: expected fn pointer `for<'r, 's, 't0> fn(&'r str, &'s S<'t0>)`
             found fn pointer `fn(&str, &S<'_>)`
```

Here is the fixed code ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a76ab40d67ba8ed6f37d2a701dff699c)):

```rust
    let inner: fn(&str, &S<'_>) = unimplemented!();
    f(inner);
```
In particular, the only thing that changed was `fn(_, _)` -> `fn(&str, &S<'_>)`. But this is exactly the type that was printed in the diagnostic originally! What changed?

I don't understand why this error was emitted, but it would at least be nice to suggest the transformation that makes the code work.

Reduced from https://github.com/rust-lang/crater/pull/542.
Repository: rust
Issue: Does `[T]::array_chunks` really need to be an iterator?
Labels: T-libs-api,B-unstable,A-array

After bit after reviewing the code in https://github.com/rust-lang/rust/pull/75021 I had a thought: if this iterator is mostly just a wrapper on a slice iterator, does it even need to be an iterator at all?

The original `.chunks()` call does (as does `.windows`), because the slices it wants to return don't exist anywhere.

But the arrays returned by `array_chunks` are inline in the original slice allocation, so the API could just return the slice that the method is already creating, instead of hiding it in an iterator.

To be more concrete:
```rust
impl [T] { 
    pub fn array_chunks<const N: usize>(&self) -> (&[[T;N]], &[T]);
    pub fn array_chunks_mut<const N: usize>(&mut self) -> (&mut [[T;N]], &mut [T]);
}
```

Not only would this be more general (the `ArrayChunks` type doesn't currently expose the slice), but I think it would make it less likely that people would forget to correctly handle the `.remainder()`.  (While still being easy to ignore it with `.0` if they insist.)  And returning tuples like this has precedent with `split_*` and `align_to` and such.  (Many other names could work too, like `.as_chunks(_mut)`.)

Also, such a method would be nice to have as the inverse of a hypothetical `flatten: &[[T; N]] -> &[T]`.  (EDIT: No longer as hypothetical, #95629.)

`array_chunks` tracking issue https://github.com/rust-lang/rust/issues/74985
Repository: pytorch
Issue: torch.mv with sparse matrix gives internal assert on cuda
Labels: module: cuda,triaged,module: assert failure

## 🐛 Bug

torch.mv with sparse matrix gives internal assert on cuda, but works on cpu

## To Reproduce

device = "cuda"
vector = torch.tensor([0.1, 0.2], device=device)
indexes = torch.tensor([[0, 1], [0, 1]])
values = torch.rand(2)
tensor = torch.sparse.FloatTensor(indexes, values, torch.Size([2, 2]))
tensor.to(device=device)
result = torch.mv(tensor, vector)
print("result", result)

Traceback (most recent call last):
  File ""torch-bug-report.py", line 22, in <module>
    y = torch.mv(tensor, vector)
RuntimeError: !t.is_cuda() INTERNAL ASSERT FAILED at "..\\aten\\src\\ATen\\native\\sparse\\SparseTensorMath.cpp":822, please report a bug to PyTorch. 

This error appears only when running on "cuda" and works fine on "cpu".

## Expected behavior

Run without internal assert failure.

## Environment

PyTorch version: 1.6.0
Is debug build: False
CUDA used to build PyTorch: 10.2

OS: Microsoft Windows 10 Home
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect

Python version: 3.8 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy==1.18.5
[pip3] torch==1.6.0
[pip3] torchvision==0.7.0
[conda] Could not collect

 - How you installed PyTorch (`conda`, `pip`, source): pip
 - GPU models and configuration: RTX 2070S



cc @ngimel
Repository: pytorch
Issue: Additional clutter memory allocated on GPU 0 when training on GPU 1+
Labels: module: cuda,triaged

## 🐛 Bug

Might be related to https://discuss.pytorch.org/t/model-always-allocate-some-memories-on-gpu-0/58340/8

I get similar issue forking via multiprocessing and processing on seperate gpus in separate processes. Additional memory clutter is being allocated on GPU 0 (233mb in my case, seemingly independent of the model depth or breadth) during first training-mode (but not testing-mode) model forward execution.

I'm using a hack like
```
with torch.cuda.device(device):
	result 	= model(data)
```
to get around that. No such additional persistent memory allocation takes place if I use this (not on GPU 0 nor any other GPU) or simply in case that the device in question is GPU 0. So this memory allocation is purely unnecessary clutter. Model in question is pure and minimal, composed of nn.Sequential and conv, BN, linear and inplace ReLU activations, so it's internals are most likely not the cause.

This is not related to GPU 0 specifically, but to the current default GPU. If I change gpu context to other GPU that the model is not allocated on, this memory gets allocated on this other context-GPU. 

## Environment

PyTorch version: 1.7.0.dev20200811
Is debug build: False
CUDA used to build PyTorch: 10.2

OS: Ubuntu 20.04.1 LTS (x86_64)
GCC version: (Ubuntu 9.3.0-10ubuntu2) 9.3.0
Clang version: Could not collect
CMake version: version 3.16.3

Python version: 3.8 (64-bit runtime)
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: GeForce GTX 1080 Ti
GPU 1: GeForce GTX 1080 Ti
GPU 2: GeForce GTX 1080 Ti
GPU 3: GeForce GTX 1080 Ti

Nvidia driver version: 440.33.01
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] msgpack-numpy==0.4.6.post0
[pip3] numpy==1.19.1
[pip3] torch==1.7.0.dev20200811
[pip3] torchvision==0.8.0.dev20200811
[conda] Could not collect


cc @ngimel
Repository: TypeScript
Issue: Type narrowing fails when there is a break/return in loop
Labels: Bug

**TypeScript Version:**  4.0.2

**Search Terms:**
flow type narrowing loop

**Code**

```ts
for (let p: number | string = 1; p; p = p + 1) {
    // Just make sure for iterator is reachable
    if (p) {
        continue
    }
    // Actually unreachable here
    // Comment this line out, everything works correctly
	break
}
```

**Expected behavior:**
No errors. p is typed number in `p = p + 1`

**Actual behavior:**
p is number | string

**Playground Link:** https://www.typescriptlang.org/zh/play?target=1#code/GYewTgBAFANgpgFwgBwFwQHYFcC2AjOSAHwgGcEwBLDAcwgF4IBGAbhTeQZQgGpmBKCAG8AsACgIkiJWDRkg0RKnKAxiAwJqWOOOUBfXVID0RiAEEVCLAEMYMAJ4QsGMHGsqAFtbzwIHwjpiAJB4rtYA1uJ6QA
Repository: bitcoin
Issue: noban permission probably shouldn't give additional permissions implcitly
Labels: Brainstorming,Bug

"Ignore block request below NODE_NETWORK_LIMITED threshold" is skipped for `noban` permission in a manner which actually sends to requested block.

We should probably change it to use `download` permission, or simply ignore the request.

Ignoring requests could cause existing peer software to stall/timeout in theory, but I don't think any existing software will make such requests from a NODE_NETWORK_LIMITED peer in the first place?
Repository: rust
Issue: Get rid of `clean` in rustdoc
Labels: C-cleanup,T-rustdoc,E-hard,I-compiletime,I-compilemem,C-tracking-issue

Currently, rustdoc has its own data structure for basically everything in the compiler: [`librustdoc::clean::types`](https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/clean/types/index.html). Collecting these ahead of time is expensive (https://github.com/rust-lang/rust/pull/74590#issuecomment-674587005) and it would be better to instead calculate them on demand. This would reduce a ton of code duplication, speed up rustdoc, and hopefully fix bugs related to caching (https://github.com/rust-lang/rust/pull/74879) and get rid of hacks like fake IDs (#75355).

On the other hand, it's really hard.

The basic idea is to, instead of discarding the `TyCtxt` after `run_core`, instead pass in `TyCtxt` to `render`. Then `render` will calculate the info it needs as it comes up - possibly still with caching in `DocContext`, but because this is on-demand it will be like `cache.get().or_else(|| calculate_info())`, not `cache.get().unwrap()` which is what leads to the bugs.

cc @rust-lang/rustdoc - is this something you're interested in?
cc @RDambrosio016, @kixiron - this would break your idea to have `librustdoc_render` be a separate crate from `librustdoc`, because there would inherently be no stable interface: `DocContext` would be returning rustc types directly.
cc @P1n3appl3 - this would require rewriting large parts of the JSON backend.
Repository: neovim
Issue: :make should be async
Labels: enhancement,job-control,multiproc

### Actual behaviour
When I use the make command with makeprg set and compile with it the rest of nvim freezes.
### Expected behaviour
nvim shouldn't freeze since this reduces productivity
Repository: rust
Issue: Alternative help for missing min/max function
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics

```rust
fn main() {
    let x = 5;
    let y = 9;
    println!("{}", max(x, y));
}
```
With rustc (1.48.0-nightly 0d0f6b113 2020-09-03) gives:

```rust
error[E0425]: cannot find function `max` in this scope
 --> ...\test.rs:4:20
  |
4 |     println!("{}", max(x, y));
  |                    ^^^ not found in this scope
  |
help: consider importing one of these items
  |
1 | use core::cmp::max;
  |
1 | use std::cmp::max;
  |
```

But it could suggest instead to use:

```rust
x.max(y)
```
Repository: neovim
Issue: Add options for preview window opening
Labels: enhancement

According to [this line of code](https://github.com/neovim/neovim/blob/2bbbb34ce78ee30c1ee53a9cb3fd1e7608185716/src/nvim/ex_cmds.c#L4489), the tag preview window gets opened with a plain `win_split` function call. The `flags` parameter is fixed to `0`. So it is not even possible to say the preview should be opened at the bottom or vertically. After all it is not possible to change how the window gets opened in any way.
This is said. Therefore I propose two new options. One option to define the orientation for the window where to open. The second option should allow to define a custom function that opens the window instead. This should be the same principle as `tagfunc` for example. Such an option would allow the user to do more fancy things like opening a preview window in floating manner.

I'm curious what you think about this idea. Thanks for any feedback!
Repository: rust
Issue: Tracking Issue for slice_range
Labels: T-libs-api,C-tracking-issue,A-slice,Libs-Tracked

<!--
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.
-->

The feature gate for the issue is `#![feature(slice_range)]`.

This issue currently tracks the following API:

```rust
pub mod slice {
    pub fn range<R>(range: R, bounds: RangeTo<usize>) -> Range<usize>
    where
        R: RangeBounds<usize>;
}
```

### 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 feature (#75207)
- [x] Adjust documentation (#76395)
- [ ] 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.
-->

- ~~Should this method be defined on `RangeBounds` or `Range` instead?~~ (#76885)
- ~~Should a non-panicking version be added?~~
- [ ] Should this wait for `#[final]` methods in traits?
  - The main reason this isn't on `RangeBounds` is that today `unsafe` code can't trust any method on a not-unsafe trait to validate anything.  But if this was a final method, and thus not overridable, then `unsafe` code could trust it.

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

- Implemented in #75207
- #76395
- Changed type (taking only the length) in #76662
- #76885
- Renamed to `slice::range` in #81154
- #95274
- #121148
Repository: pytorch
Issue: Allow to use system zstd
Labels: feature,triaged

## 🚀 Feature
I want to be able to use my system's zstd lib instead of the static library built by pytorch.

## Motivation

It would allow for nicer integration into Linux distributions. Same reason for why there are so many use `USE_SYSTEM_` directives already.