sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Refactor/codefix: find missing variable in destructured object
Labels: Suggestion,In Discussion,Experimentation Needed,Domain: Auto-import

## Search Terms

refactor
codefix
auto import
destructuring
parameter

## Suggestion

There is a feature in VSCode today where you can type the name of a function and the editor suggests automatically importing that function, which is very useful.

![auto-import](https://user-images.githubusercontent.com/464152/94782444-859f8300-03cb-11eb-8791-d5bca87a875f.gif)

It would be useful to have a similar feature for finding variables in objects that have been destructured, for example in the `props` parameters of react functions. It should be possible for typescript to find out that a variable is available in a destructured object in the current closure, for example:

![image](https://user-images.githubusercontent.com/464152/94782638-cdbea580-03cb-11eb-9146-f524aa47209a.png)

In the above example the first option should suggest to add `name` to the destructuring of `Props` in the parameters of the function, since there is a `name: string` as part of `Props`. 

## Use Cases

Using destructuring is very common in for example functional react components. The props object can grow very large and it is annoying and repetitive to type out the name of all the destructured properties.

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: godot
Issue: Some settings don't use "Find file/directory" dialog
Labels: discussion,topic:editor,usability

**Godot version:**
3.2.3 on Windows 7

**Issue description:**
There's some degree of inconsistency in the use of "Find file"/"Find Directory" helper dialog when setting settings for Project Settings. Many settings use these (good), but the following do not (bad):

Project settings -> General
* Application/Config -> "Custom User Dir Name"
* Application/Config -> "Project Settings Override"
* Logging/FileLogging -> Log Path (This one is also wrongly named - it's a Log File, not a Log Path).

I believe that's all of the missing ones for the General Tab.

Project settings -> Plugins
* Create -> "SubFolder" and possibly "Script Name".

---

The Editor Settings all seem to be fine.
Repository: go
Issue: x/tools/cmd/present: incorrect left alignement with .code -numbers
Labels: NeedsInvestigation,Tools

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.2 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?

This is the latest release.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env | sort
AR="ar"
CC="clang"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_ENABLED="1"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
CXX="clang++"
GCCGO="gccgo"
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/fgm/Library/Caches/go-build"
GOENV="/Users/fgm/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/0g/p780bc554njc4qj110_8rmbr0000gn/T/go-build163305665=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMOD=""
GOMODCACHE="/Users/fgm/src/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/fgm/src/go"
GOPRIVATE=""
GOPROXY="http://localhost:3000,https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
PKG_CONFIG="pkg-config"
</pre></details>

### What did you do?

- Create a Go program longer than 9 lines, e.g. https://play.golang.org/p/3sx9qAl_gJa
- Create a slide deck referencing that file with the `-numbers` option, e.g. https://play.golang.org/p/LZRH88YHMyu

### What did you expect to see?

On slide 2, the Go code is correctly formatted from a left margin, and uses the official Go listing font from the Go [brand guide, page 10](https://storage.googleapis.com/golang-assets/Go-brand-book-v1.9.5.pdf) i.e.  (font "Go")

### What did you see instead?

On slide 2, the width of the line numbers varies, increasing at line 10 because it now has two digits, breaking the alignment of the code.

The font used for the listing is `Droid Sans Mono`.

### Suggested fix

- Adjust the font-family for the `pre` selector to start by `Go` instead of `Droid Sans Mono` and add a `@font-face` to load it.
- Adjust `cmd/present/static/styles.css` by modifying the rules for the `pre.numbers span:before` selector.
Assuming listings on slides and blogs are always less than 100 lines long, just adding `width: 1.5em` if enough to fix the issue. A completely correct fix would need to adjust column width based on the actual numbers, probably changing the markup.
Repository: PowerToys
Issue: [FancyZones] Pressing ESC key while moving to a zone doesn't cancel.
Labels: Idea-Enhancement,FancyZones-Dragging&UI,Product-FancyZones

So Fancy Zones itself works awesomely these days.
But the thing is when Moving a Small window from anywhere and Snap it to a Zone, then midway change your mind and not want to snap it pressing the seconday Mouse button again works for stopping. But here bad habbits kick in and i always press Escape.
Then the window still gets snapped to the Zone instantly releasing my Mouse button.

Shouldn't after pressing Escape the Zone be cancelled?


Using v23.0
Build 18363.1082
Repository: vue
Issue: Build warnings in Mac OS and Node v12 (development)
Labels: contribution welcome

### Version
2.6.11

### Reproduction link
[https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup](https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup)







### Steps to reproduce
On Mac OS Catalina (and probably prior versions), with Node v12 installed, follow the developer build instructions: 

* Clone the repository
* Run `yarn`

### What is expected?
Successful report from `yarn` that all dependencies have been installed, with no warnings or errors

### What is actually happening?
The following warning, followed by a slew of details (errors) concerning `fsevents` and one of its dependencies, `nan`

`warning Error running install script for optional dependency: "/Users/mark/dev/vue/node_modules/fsevents: Command failed.`

---
Dev dependency installation works fine with Node v10. I think I understand the problem and am curious about the right solution. 
Vue currently specifies `webpack` 4.x and `karma` 3.x as devDependencies, both of which ultimately bring in `chokidar` 2.x, which lists `fsevents` 1.2.x as an optional dependency. 

Old `fsevents` is really the problem, in two ways:
* It references entities that have been removed in Node 12.x (e.g. v8::Handle; see https://github.com/fsevents/fsevents/blob/v1.2.2/fsevents.cc#L89) 
* It relies on `nan` 2.9.x, which also references deprecated/removed entities from the v8 API (e.g. `isNearDeath`). Newer versions of `nan` have addressed this issue. 

I imagine the easiest solution, assuming nothing else breaks, would be to update the `karma` and `webpack` dependencies to some minimal viable version that does away with reliance on these older libs without breaking other expectations. In the meantime, we could also put a note in the build instructions for Mac users noting that they may need to move down to Node v10 if they want to avoid this problem. I understand that this might be obvious to some audience that intends to pitch in with Vue development in the first place, but it might help some.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: [ER] Int::RANGE constants
Labels: T-libs-api,C-feature-request

This is a small enhancement request, that (as it usually happens) I am not sure about, but I like it.

Like u32::BITS I'd like another constant for all Rust integral numbers XX (i8, u8, i16, u16, etc):

```rust
XX::RANGE: RangeInclusive<XX> = XX::MIN ..= XX::MAX;
```

So you can write:

```rust
for i in u8::RANGE { ... }
```

That's shorter, is more DRY and avoids mistakes like (that is forgetting that a signed number doesn't start at zero, and missing the last number of the range):

```rust
for i in 0 ..= i8::MAX {}
for i in i8::MIN .. i8::MAX {}
```

I think this could be useful now, but it will become even more handy if/when Rust adds ranged integers as in Ada, see:

https://en.wikibooks.org/wiki/Ada_Programming/Attributes/%27Range

~~I think it's better not to define char::RANGE.~~
Repository: flutter
Issue: Only serve index.html for path patterns known to match route paths
Labels: c: new feature,tool,platform-web,P3,team-web,triaged-web

Using current master:

- flutter create foo
- cd foo
- flutter run -d chrome
- when the browser opens, delete the `#` from the URL and add `/missing`

The response returns a 200 status with HTML for the app, but I'd expect a 404.

![Screenshot 2020-10-01 at 15 39 35](https://user-images.githubusercontent.com/1078012/94823919-50f7ef80-03fc-11eb-9b44-fde2de6f69a5.png)
Repository: rust
Issue: Tracking Issue for feature(iter_advance_by)
Labels: T-libs-api,C-tracking-issue,A-iterators,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.
-->

This is a tracking issue for the methods `Iterator::advance_by` and `DoubleEndedIterator::advance_back_by`.
The feature gate for the issue is `#![feature(iter_advance_by)]`.

---

Previously the recommendation was to implement `nth` and `nth_back` on your iterators to efficiently advance them by multiple elements at once (useful for `.skip(n)` and `.step_by(n)`). After this feature is stabilized the recommendation will/should be to implement `advance_by` and `advance_back_by` instead, because they compose better and are often simpler to implement.

Iterators in libcore that wrap another iterator (possibly from elsewhere than libcore) will need to keep their `nth` and `nth_back` implementations for the foreseeable future and perhaps indefinitely, because the inner iterator may have an efficient `nth` implementation without implementing `advance_by` as well.

### 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] Implementation (#76909)
- [x] (?) #92284
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr

### Implementation history

- Implementation (#76909)
- Add tracking issue (#77405)
- Implement for `Chain` (#77594)
- implement for `slice::{Iter, IterMut}` (#87387, #87736)
- implement for `vec::IntoIter, ops::Range, iter::{Cycle, Skip, Take, Copied, Flatten}` (#87091)
- Change advance(_back)_by to return the remainder instead of the number of processed elements (https://github.com/rust-lang/rust/pull/92284)
Repository: angular
Issue: TestBed overridden providers always registered in NgModule injector
Labels: area: testing,hotlist: google,core: di,P3

# 🐞 bug report

### Affected Package
The issue is caused by package @angular/core/testing

### Is this a regression?
Sort of; changed behavior in Ivy compared to VE.

### Description

In #28737 the following testcase was added to exercise `ngOnDestroy` logic registered for component-level provided providers that have been overridden:

```ts
   it('should call ngOnDestroy for a service that was overridden with useFactory', () => {
     const logs: string[] = [];

     @Injectable()
     class MyService {
       public name = 'MyService';
       ngOnDestroy() {
         logs.push('MyService.ngOnDestroy');
       }
     }

     class FakeService {
       name = 'FakeService';
       ngOnDestroy() {
         logs.push('FakeService.ngOnDestroy');
       }
     }

     @Component({
       selector: 'my-comp',
       template: `{{ myService.name }}`,
       providers: [MyService],
     })
     class MyComponent {
       constructor(public myService: MyService) {}
     }

     TestBed.configureTestingModule({
      declarations: [MyComponent],
     });

     TestBed.overrideProvider(MyService, {
       useFactory: () => new FakeService(),
     });

     const fixture = TestBed.createComponent(MyComponent);
     fixture.detectChanges();

     const service = TestBed.inject(MyService);
     expect(service.name).toBe('FakeService');

     fixture.destroy();

     expect(logs).toEqual(['FakeService.ngOnDestroy']);
   });
```

In this test, the `MyService` token is provided by the component and overridden using `TestBed.overriddeProvider`. In Ivy, the `TestBed.inject(MyService);` call succeeds and returns an instance of `FakeService`. In VE, this call fails as there is no `MyService` token registered in the NgModule injector.

The VE behavior seems logical to me, as the service wasn't originally provided in the NgModule injector and only registering an override should not register it at the NgModule level.

In Ivy, all provider overrides are registered in the NgModule injector:

https://github.com/angular/angular/blob/44bb85ade456a8223851b3b376fe7f5c8fe0864a/packages/core/testing/src/r3_test_bed_compiler.ts#L660-L665

## 🔬 Minimal Reproduction
See testcase above.

## 🌍  Your Environment

**Angular Version:**
Latest master, 11.0.0-next.4
Repository: godot
Issue: Parameter section in .import files can be large for some resource types
Labels: discussion,topic:import

**Godot version:**
v3.2.3.stable.official up to current master

**OS/device including version:**
N/A

**Issue description:**
This report was requested by @akien-mga. I personally don't have an issue with the following being the case _for the development file system_.

Due to the way import parameters need to be stored in `someth.ing.import` files, these files contain a lot of keys. For some resource types, this can lead to situations in which the `.import` file is in fact larger than either the source or imported files. The degree varies by resource type, the attached repro project is the most extreme case I have observed: PackedScene-Imports have a basically fixed size of ~32kb, the whole scene (either glTF or scn) is just 4kb. While this does not look like much with today's hardware, it does add up quite quickly, especially in games that use vertex-shaded art style and don't have large textures that would offset the ratio. Additionally, these large configs have to be parsed every time the resource is loaded, which doesn't seem to be a critical issue right now but nevertheless takes time.


**See also:**
For an explanation why even unchanged params must be stored somewhere, see [godot-proposals-1060](https://github.com/godotengine/godot-proposals/issues/1060#issuecomment-697559163)


**Minimal reproduction project:**
[bug-largeimport.zip](https://github.com/godotengine/godot/files/5313283/bug-largeimport.zip)
(Using grass.glb by [Kenney](https://kenney.nl/assets/hexagon-kit))
Repository: rust
Issue: Add a tidy check for acceptable rustdoc header
Labels: T-bootstrap,A-docs,C-feature-request

I saw quite a few headers and I think it would be nice for tidy to keep track of them for consistency, maybe even do suggestion. For example, `# Example` and `# Examples`, we may accidentally use `# Example` sometimes which is not consistent with the rest of the documentation.

I also saw that sometimes there are `# Safety:` rather than `# Safety`. Maybe we could suggest them based on edit distance on the possible choices for headers we specified in tidy?

CC @rust-lang/docs
Repository: TypeScript
Issue: Nested JSON makes tsc throw RangeError with no culprit
Labels: Bug

<!-- 🚨 STOP 🚨 STOP 🚨 STOP 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  4.1.0-dev.20201001

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** RangeError JSON deep nested

**Code**

```json5
// test.json
{
"c":[{
  "c":[{
    "c":[{
// ~150 more levels of nesting
      }]
    }]
  }]
}
```

```ts
// @resolveJsonModule: true
// @declaration: true
export { default } from "./test.json";
```

**Expected behavior:**

A regular TypeScript error saying `"ts1234: Can't type-check file 'foo.json', nesting is too deep"`.  The key is that it should indicate where the problem comes from.

**Actual behavior:**

TypeScript itself blows up and does **not** tell you which of your source files is at fault.

```
C:\dev\temp\deep-json>tsc
C:\Users\u\AppData\Roaming\npm\node_modules\typescript\lib\tsc.js:81155
                throw e;
                ^

RangeError: Maximum call stack size exceeded
    at commitPendingMapping (C:\Users\u\AppData\Roaming\npm\node_modules\typescript\lib\tsc.js:62604:29)
    at Object.addMapping (C:\Users\u\AppData\Roaming\npm\node_modules\typescript\lib\tsc.js:62502:17)
```

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

[Browser repro](https://www.typescriptlang.org/play?ts=4.1.0-dev.20201001#code/N4KARAxmBcDaKkjeipweNLPI09quhBOJ+25eWVRpF1x9tljNZDdbT7zHLnrQQOH9Rfcb0k9p3WV3lCxUuYokyFItSs3KNS9at2GDOk-u3m9Wq0dMXrx+7cuObZh3bdP3zjy8+ugQHB-qF+4b6RPtHesV7xQWFRca4gALogAL7pWTnZGfm5BXklxWVFFYVVpZU11eX1tQ11Lc1tTR2NXa2dPd3t-b0DfSPDY0MTg1OjkzPT4-OzC3Mry2tLG4tbq5t1QA)

Please look into the browser console to see the error.

**Related Issues:** None

---

Whilst this error can happen in TS/JS files, I'd suggest this limit is most likely to be hit in JSON because they are often machine generated and so the user is not always in control of the format.

Our current workaround is to add a non-typechecked re-exporting wrapper .js + wrapper.d.ts in front of the JSON so the typechecker doesn't need to generate types for the JSON.
Repository: pytorch
Issue: [FX] Allow customization of the behavior of Proxy
Labels: triaged,module: fx

Some values are not `Tensor`-typed, but still would conceptually be traceable (e.g. dict with known structure). Build infrastructure to inform FX of this structure so it can use it in recording the program representation

cc @ezyang @SherlockNoMad
Repository: youtube-dl
Issue: Site support request: TASVideos
Labels: site-support-request

## Checklist

- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2020.09.20**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

- Single video: http://tasvideos.org/2397M.html
- Playlist: http://tasvideos.org/Movies-Windows-NoScreenshot-NoTier-NoFlags.html


## Description

I hope, that this might qualify as a website which could be supported. I do hope that, because you can't really play the videos on the website itself, but only download them directoy or follow a link to youtube.

Each movie has at least one mirror to archive.org where one can directly download the movie file. The file name is semi-shortened, like braid-tas-keylie.mkv
Difficulty: more often the movie is listed at least twice, with information like (MKV Modern HQ) or (MP4 Compatibility).

As Metadata it would be great to have the following:
- the title (probably with the system, e.g. "Windows Braid (World)")
- the creator (in the title of each movie e.g. "Windows Braid (World) in 22:15.28 by keylie" -> keylie)
- the description below the links
- the tags on the right side of the list (aka Best ending, Genre: Puzzle, Uses hardest difficulty etc.); maybe as its own tag or added to the description

"Playlists" are search results via the filters on the website. Each filter adds something to the URL, but all URLs always starts with "tasvideos.org/Movies-"

I kinda enjoy watching speedruns and hopefully others might as well and would be able to create an extractor.
Repository: flutter
Issue: The image cache can lose track of a live image that it probably shouldn't lose track of
Labels: framework,c: performance,a: images,perf: memory,P2,team-framework,triaged-framework

The following sequence would lead to this:

- Put an image into the cache and hold a listener
- Create a keepAlive handle on the completer once the image completes.
- Remove the listener. At this point, the "last listener" callback will fire and remove the live image tracker.

In fact, the image should still be considered live because the completer/image are actually still available somewhere. Some potential solutions:

1. Drop the whole listener callback, and just have the liveImage check if the completer is disposed or not when it's wanted. If it's disposed, drop the live listener from the cache. Need to make sure this doesn't accidentally retain the image, but I'm pretty sure it doesn't.
1. Only call the last listener callback if the stream is getting disposed. 

I started looking at doing this in #66688 but it was further complecting things and since this behavior existed already (e.g. add a listener, remove the last listener, add a listener again) I decided to leave it for a separate patch.
Repository: flutter
Issue: Add `debugDisposed` to `dart:ui` Images
Labels: c: new feature,framework,a: debugging,a: images,a: error message,P3,team-framework,triaged-framework

This would help framework code, e.g. `ImageInfo` could have some more helpful asserts once it has disposed its `Image`, and `RawImage` could do a better job of asserting.

This should be a simple change in dart:ui and then a few asserts added in the framework.