sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Add tests to https://github.com/flutter/engine/pull/20980
Labels: a: tests,team,platform-ios,P3,team-ios,triaged-ios

https://github.com/flutter/engine/pull/20980 didn't have tests. Merged since it was a blocker for iOS 14 release. Backfill test.
Repository: electron
Issue: Remove command line parameters consumed by Electron
Labels: enhancement :sparkles:

### Preflight Checklist
* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

### Problem Description
In contrast to Node, Electron does not remove the command line parameters it consumes from `process.argv`. This makes it harder to parse command line parameters specific to the application.

Example:

test.js:
```
console.log(process.argv)
```

Node vs Electron:
```
> node --inspect=9999 test.js 
Debugger listening on ws://127.0.0.1:9999/3dbbba51-683a-49e9-a098-48fc6898c154
For help, see: https://nodejs.org/en/docs/inspector
[
  '/home/bspot/.nvm/versions/node/v12.14.1/bin/node',
  '/home/bspot/test.js'
]

> electron --inspect=9999 test.js 
Debugger listening on ws://127.0.0.1:9999/59eb07a2-eed1-479d-aa91-cea83df6c590
For help, see: https://nodejs.org/en/docs/inspector
[
  '/home/bspot/.nvm/versions/node/v12.14.1/lib/node_modules/electron/dist/electron',
  '--inspect=9999',
  'test.js'
]
```

### Proposed Solution
Remove command line parameters consumed by Electron from `process.argv`.

### Alternatives Considered
My current workaround is searching for the main script file name in `process.argv` and only parsing parameters following it, which is a potential source of bugs in case the main script's file name or relative path change.
Repository: rust
Issue: Tuple-struct constructor visibility leads to inconsistency in pattern matching
Labels: A-visibility,T-compiler,C-bug

The following code:

```rust
mod foo {
    pub struct NamedStruct {
        field: u8
    }
    pub struct TupleStruct(u8);
}

use foo::*;

fn test_it(named: NamedStruct, tuple: TupleStruct) {
    if let NamedStruct { .. } = named {}
    if let TupleStruct(..) = tuple {}
}
```

produces the following error:

```
error[E0532]: expected tuple struct or tuple variant, found struct `TupleStruct`
  --> src/lib.rs:12:12
   |
12 |     if let TupleStruct(..) = tuple {}
   |            ^^^^^^^^^^^ constructor is not visible here due to private fields
```

This is caused by the fact that tuple structs have their 'constructor' visibility set to their most restrictive field visibility:

https://github.com/rust-lang/rust/blob/08deb863bdebfcbbb71c18acf903eca84f1df4e7/compiler/rustc_resolve/src/build_reduced_graph.rs#L799-L809

This behavior seems quite inconsistent. As a user, I would expect that tuple structs and named structs are just two different ways of naming the fields of a struct, and behave identically w.r.t privacy.

Is there a reason for this difference in behavior, or is this just a historical quirk of the resolver?

Thanks to @guswynn for bringing this to my attention.
Repository: TypeScript
Issue: Probable bug: Functional properties don't get inferred with circular type parameter constraints like `T extends M<T>`
Labels: Needs Investigation

**TypeScript Version:**
4.0.2

**Search Terms:**
Circular type parameter constraint, functional property inference, function parameter inference, function argument inference

**Code:**
```typescript
declare const m: <T extends M<T>>(m: T) => T
type M<Self, K = Exclude<keyof Self, "k" | "t">> =
  { a?: number
  , b?: number
  , c?: number
  , d?: number
  , k?: K
  , t?: (k: K) => void
  }

// :)
// Case 1
m({
  a: 1,
  b: 2,
  k: "a"
})

// :)
// Case 2
m({
  a: 1,
  b: "x", // expected error
  k: "c" // expected error
})

// :(
// Case 3
m({ // type parameter becomes `unknown` (probably because t's first parameter is `any` initially kinda?)
  a: 1,
  b: 2,
  k: "a", 
  t: k => {} // k is inferred as `never` (instead of `"a" | "b"`)
})

// :|
// Case 4
m({
  a: 1,
  b: 2,
  k: "a", 
  t: (k: "a" | "b") => {} // have to explicitly type `k` which could have been inferred :(
})
```

**Expected behavior:**
The parameter `k` of `t` should be inferred as `"a" | "b"`. As property `k` already gets inferred in Case 1 & 2, so why not the `k` parameter of `t`

**Actual behavior:**
The parameter of `t` is inferred as `never` and `T` in inferred as `unknown`. I assume first `T` gets resolved to `unknown` as `t` is initially inferred as `(k: any) => void` which does not satisfy the constraint of `m`.

[Playground](https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEYD2A7AzgF3gWwFzwB4AVeEADwxBWDXgFliA+RgCj3iIEp4BeRjgFAYAngAcEDAMogIAMwA08ANK94AUTKQArqAIBrEMKSz40uYoBEei-AA+8CxgvNeA+PADe8KAH58KLWwAIxAYN3hFIL94AODQ8MUwaNiQsPdFYGTA1IT4PWilXIxolj18JW4+eAA3JABLYHCAXwEBAHo2+FxOds6AYSg0BABGAWwWD3CofGH5cKD8ACY59zKHKAsBJp7erp6O+AGh+EWxiamZlfgFhzILRQPycTBKYFIYGCQ0vPwLMBtHmRnq93p8wttWgdcCxdkcEABmM5eA4icTwUSwKDYECUGDXcBIbG0AAGWhQehQSAA7ihifAWKJPkEoEEIMJ8WAoFpjhgAOS0WR1GCYdGY7G4+B1ElQFDCOl1FB1DB1KAQNl5BXAXw9dzTeCzeZLK5rCwbRThDD4PS8fgeJrwA7WqWSlCyUJwN6DeDElAgaqhOksBWYEBQN7Gb2mmz2CxBCzEnoQ3a4WywwYIAAsSIu+quN2W4RNZvgFvwpV+GzsDjjlVt9oOAAsoP74BgkKQgRA6mAlerUQhiXo6VSG92G4gkFoIG8my2QlQXW6PiA3tCtpwgA)
Repository: rust
Issue: Improve the rustc-side clippy development experience
Labels: A-testsuite,T-bootstrap,C-bug,A-contributor-roadblock,A-clippy

When working on https://github.com/rust-lang/rust/pull/75573, I ended up needing to modify Clippy (both a lint implementation and some UI tests). This process left a lot to be desired, and could be a significant roadblock to new contributors. I came up with some ideas for improving the process:

- [ ] Run Clippy tests on the PR builder (if we have the CI budget). My PR was initially [approved](https://github.com/rust-lang/rust/pull/75573#issuecomment-688364346), then [unapproved](https://github.com/rust-lang/rust/pull/75573#issuecomment-688400990) due to a (correct) suspicion that Clippy UI tests would be broken. However, this could easily be missed on other PRs, leading to wasted merge queue time and failed rollups. By running these tests on the PR builder, we could catch Clippy changes prior to PR approval.
- [ ] Allow running Clippy tests in-tree from stage1. Currently, running `./x.py test src/tools/clippy` requires a full compiler bootstrap (e.g. building a stage2 compiler). This takes a significant amount of time, and interacts badly with incremental compilation. For contributors with lower-end machines, this may make the contribution process incredibly frustrating. Attempting to build Clippy against a stage1 compiler (which requires running `./x.py test src/tools/clippy --stage 0` for some reason) works, but the tests fail with a confusing error about LLVM being missing.
- [x] Integrate Clippy UI tests with `./x.py test --bless`. Currently, blessing Clippy UI tests requires manually running scripts from inside `src/tools/clippy`. It would be nice if `./x.py test --bless` worked on all UI tests, allowing Clippy to be largely treated as 'just another directory'. 
- [ ] Document the interaction between `-D warnings` and Clippy lints. It seems as though denying a built-in lint with `-D warnings` prevents Clippy lints from being run. Since Clippy UI tests are run with `-D warnings`, adding a new builtin Rust lint can end up preventing Clippy UI tests from testing Clippy lints. Ideally, we would allow both sets of lints to run - if this is not possible, we should document the workaround (adding `#![allow(problematic_rustc_lint)]` to the affected Clippy UI tests).
Repository: flutter
Issue: package:integration_test and coverage
Labels: a: tests,framework,f: integration_test,P3,team-framework,triaged-framework

It should be feasible to collect coverage at the end of a package:integration_test by connecting to the observatory and getting coverage information, similar to how the timeline information is retrieved (see  https://github.com/flutter/plugins/pull/2947).
Repository: flutter
Issue: package:integration_test should be able to write data to somewhere Firebase TestLab can see it
Labels: a: tests,framework,d: api docs,c: proposal,f: integration_test,P3,team-framework,triaged-framework

For example, we may want to write screenshots, coverage or timeline information to the SD card.

We should make this easier to do in the plugin itself, and document how a user should use it.
Repository: TypeScript
Issue: "javascript.preferences.importModuleSpecifier" relative path, but with current directory prefix
Labels: Suggestion,Awaiting More Feedback

<!-- ⚠️⚠️ 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. -->

I'm not sure if there is a way to do this already, but I tried so many different setting combinations without any success, so it would be nice to have an option to prefix relative import paths with `./`, either as part of the `importModuleSpecifier` or somewhere else.

So it would go from this:
```js
import FML from '../components/FML'
```
To this (optional of course, not changing the default behaviour):
```js
import FML from './../components/FML'
```

---

I accidentally posted this in the TypeScript Repository first, so here's the original (now deleted) post explaining this further:

> I'm having trouble getting the autoimport feature to include `./` at the start of the path for local imports. I tried changing all the settings mentioned above and more to all the possible options and I tried setting it with `jsconfig.json` - tried pretty much all the possible combinations of these settings - but I just can't get it to work.
> 
> The closest I got was the default setting, which made the import paths like this `import FML from '../components/FML'`, but I still have to manually put the `./` before each import path to change it to this `import FML from './../components/FML'` :( Can anyone help me please (if so, you can send me a mail to not clutter up this post)?
Repository: pytorch
Issue: Consider cache effects in Timer
Labels: module: bootcamp,triaged,enhancement

## 🚀 Feature
When timing a statement, Timer should attempt to determine if the measurement is affected by CPU caching.

## Motivation

Consider the following measurements:
```
import torch
from torch.utils._benchmark import Timer

n = 1024
k = 2

m0 = Timer(
    "[torch.cat([x, y], 0, out=out) for _ in range(k)]",
    globals={"x": torch.ones((n, n)), "y": torch.ones((n, n)), "out": torch.empty((2 * n, n)), "k": k}
).blocked_autorange(min_run_time=5)

m1 = Timer(
    "[torch.cat([xi, yi], 0, out=outi) for xi, yi, outi in zip(x, y, out)]",
    globals={
        "x": [torch.ones((n, n)) for _ in range(k)],
        "y": [torch.ones((n, n)) for _ in range(k)],
        "out": [torch.empty((2 * n, n)) for _ in range(k)]
    }
).blocked_autorange(min_run_time=5)
    
print(m0, "\n")
print(m1)
```

```
<torch.utils._benchmark.utils.common.Measurement object at 0x7f0f1ca6e950>
[torch.cat([x, y], 0, out=out) for _ in range(k)]
  Median: 1.52 ms
  IQR:    0.10 ms (1.48 to 1.58)
  3229 measurements, 1 runs per measurement, 1 thread 

<torch.utils._benchmark.utils.common.Measurement object at 0x7f0f1ca6e8d0>
[torch.cat([xi, yi], 0, out=outi) for xi, yi, outi in zip(x, y, out)]
  Median: 3.07 ms
  IQR:    0.44 ms (2.87 to 3.31)
  1610 measurements, 1 runs per measurement, 1 thread
  WARNING: Interquartile range is 14.3% of the median measurement.
           This could indicate system fluctuation.
```

The second measurement is both slower and less stable; however it reflects a real use case where the Tensors are not already in CPU cache. In effect, we want to perform many independent measurements rather than many correlated ones.

## Pitch

We want to explore ways of preventing the use of cached data (such as through duplicating data or clearing the cache).

It's also not clear if the Timer should try to actively correct for cached data, or just warn if it is detected.
Repository: TypeScript
Issue: `null!` still has the type `null` outside of `strictNulllChecks`
Labels: Bug

```ts
// @strictNullChecks: false
let x = null!.yadda;
//      ~~~~~ Object is possibly 'null'.
```

Hmm

```ts
// @strictNullChecks: false

let x = null!!!!.yadda;
//      ~~~~~~~~ Object is possibly 'null'.
```

Is this working as intended @ahejlsberg?
Repository: go
Issue: x/tools/gopls: add log statement to indicate gopls is serving
Labels: gopls,Tools

Running `gopls` on the command-line directly currently defaults to `serve` mode, which is unhelpful for users of the CLI and unintuitive. We should add a log message indicating that `gopls` is serving and how to get help text.
Repository: pytorch
Issue: Libtorch CMakeList.txt config help
Labels: module: build,triaged

Whenever I try to build my CMakeLists.txt file, it says that "CMake Error at CMakeLists.txt:4 (find_package):
By not providing “FindTorch.cmake” in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by “Torch”, but
CMake did not find one.

Could not find a package configuration file provided by “Torch” with any of
the following names:

TorchConfig.cmake
torch-config.cmake
Add the installation prefix of “Torch” to CMAKE_PREFIX_PATH or set
“Torch_DIR” to a directory containing one of the above files. If “Torch”
provides a separate development package or SDK, be sure it has been
installed."

I do not know how to fix this. It would be really helpful if someone could help me.

cc @malfet @seemethere @walterddr
Repository: flutter
Issue: Support automatic integration of iOS App Clip
Labels: c: new feature,platform-ios,tool,P3,team-ios,triaged-ios

Extracting from https://github.com/flutter/flutter/issues/60029. 

Offer an automatic, rather than a manual, mechanism to add a Flutter App Clip target. Rough back-of-the-napkin approaches:

1- Take an arbitrary xcodeproj, point flutter_tools or a pub global activatable script to it, and add Flutter support to it. This approach is unlikely since machine manipulation of xcodeproj is very difficult and we'd have no idea how the project is structured. Especially for add-to-app. 
2- Have a flutter tool creation template that includes the App Clip target. For users already on the default flutter create template, simply delete the iOS directory and recreate. This has the advantage of a pre-hooked project. The challenge is that this calls for an combinatorial explosion of supported cases in the flutter tool to be tested and might be difficult to be accepted into flutter tools. Such as https://github.com/flutter/flutter/issues/18819. 
3- Have a sample project. This has the disadvantage that it's easier to become stale, isn't part of the flutter repository integration testing and doesn't clearly mark which parts of the project should be bespoke and overriden in the user project, such as the bundle id, the build version etc. 
4- Revisit this once we do #37910 :) then this is a simple add-to-app.
Repository: flutter
Issue: Flavors require build configurations `buildmode-targetname` (cannot run App Clip target as a flavor)
Labels: platform-ios,tool,t: xcode,a: build,P3,team-ios,triaged-ios

Extracting an optimization from https://github.com/flutter/flutter/issues/60029

I would have expected to be able to run

`flutter run --flavor <App Clip target>` directly. 

This would save the trouble of having to tell users to run `pod install` manually and opening Xcode to run. 

But rather `flutter run --flavor AppClip` makes it search specifically for:

`The Xcode project defines build configurations: Debug, Release, Profile
Flutter expects a build configuration named Debug-AppClip or similar.`

The target name is in the mapping search. Would be nice to let this connect somehow.
Repository: opencv
Issue: Memory leak Raspbian video encoder
Labels: category: videoio,incomplete,category: 3rdparty

##### System information (version)
<!-- Example
- OpenCV => 4.1, 4.2, 4.3
- Operating System / Platform => Raspbian  (Debian Jessie)
- Compiler => gcc 4.9.2
-->

- OpenCV => 4.1, 4.2, 4.3
- Operating System / Platform => Raspbian  (Debian Jessie)
- Compiler => gcc 4.9.2

##### Detailed description

When I add FFMpeg (libavcodec, libavformat etc. codecs), a memory leak occurs on program. Is there any known issue on raspbian hardware encoder?
Repository: terminal
Issue: Title bar has blurry buttons
Labels: Help Wanted,Issue-Bug,Area-UserInterface,Product-Terminal,Priority-3

IMO, the titlebar buttons of wt are not crisp, instead they look a bit fuzzy/blurry (atleast on my laptop).

Tested both on Intel HD 630 (screenshots in op) and Nvidia GTX 1050 (screenshot below) -
![Screenshot (452)](https://user-images.githubusercontent.com/71010204/92683137-bd2c8980-f34f-11ea-81b9-21e60844d5f8.png)


I see the (somewhat) melting text bug in 2x magnification and above (on both nvidia and intel).
2x Magnification
![2x](https://user-images.githubusercontent.com/71010204/92683080-94a48f80-f34f-11ea-9ca9-7f0ccb32087b.png)
4x Magnification
![4x](https://user-images.githubusercontent.com/71010204/92683076-92dacc00-f34f-11ea-9a97-ccd142b5760b.png)

(Without using the magnify tool, the text in wt looks good enough, so I can't tell if the melting text bug is present or not, however at 2x magnification and above, the text doesn't look so good, idk if that is expected or not.)
Repository: vue
Issue: transition-group with flex parent causes removed items to fly
Labels: transition

### Version
2.6.11

### Reproduction link
[https://codepen.io/turboSheep/pen/OJNQGEG](https://codepen.io/turboSheep/pen/OJNQGEG)







### Steps to reproduce
Click the 'Remove Multiple' or 'Remove First 2' buttons and observe the movement of the items.

### What is expected?
The rectangles being removed should fade out on the spot.

### What is actually happening?
The rectangles fade out and also move to various locations on the canvas.

---
Observe that if the items 1 and 2 are to be removed, then the events fired in the following order:

```
before-leave#1
leave#1
before-leave#2
leave#2
```

This means that `beforeLeave` for the second element is called after `leave` is called for the first element. So when `beforeLeave` is called for the second element, the first element already has `position: absolute`. This means that (while the DOM has not yet rendered the change) the position of the second element has moved to be where the first element used to be, meaning that `el.offsetLeft` is now 'incorrect'. The visual effect is that the first two elements both float to the same position. 

This can be shown clearly by clicking the 'Remove First 2' button.

<!-- generated by vue-issues. DO NOT REMOVE -->

Similar behaviour has been documented by issue #9713 but the issue was quickly closed in March 2019 with a workaround posted in Jan 2020.
Repository: go
Issue: cmd/asm: 386 assembler silently drops indices when indexing symbols
Labels: NeedsFix,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build142714031=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Create an assembly file with the following content, assemble it for 386:

<pre>
DATA bar<>(SB)/4, $0x0
GLOBL bar<>(SB), 0, $4

TEXT foo<>(SB), 4, $0
	MOVL bar<>(SB)(AX), AX
</pre>

Then, dump the resulting object file.

### What did you expect to see?

Something like

<pre>
TEXT foo<1>(SB) gofile../.../bug.s
  bug.s:5		0x142			8b0500000000		MOVL 0(AX), AX		[2:6]R_ADDR:bar		
</pre>

### What did you see instead?

<pre>
TEXT foo<1>(SB) gofile../.../bug.s
  bug.s:5		0x142			8b0500000000		MOVL 0, AX		[2:6]R_ADDR:bar		
</pre>

It appears that the index register has been dropped silently.  Please either fail this kind of code during assembly or add support for indexing into global symbols.
Repository: kubernetes
Issue: cluster-info dump test consume large amount of memory in large clusters
Labels: kind/bug,sig/scalability,sig/cli,lifecycle/frozen

**What happened**:
cluster-info dump test consumed large amount of memory in large clusters

ref: https://github.com/kubernetes/kubernetes/issues/93506, https://github.com/kubernetes/kubernetes/pull/93838

**What you expected to happen**:
it should eat less than 10GB of memory 

**How to reproduce it (as minimally and precisely as possible)**:
Run cluster-info dump in 5k node cluster

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`): 1.19+ (probably older as well)
- Cloud provider or hardware configuration: GCE/GKE
Repository: godot
Issue: Materials params copy paste not working
Labels: bug,topic:shaders

**Godot version:**
v3.2.2.stable (Mono version)

**OS/device including version:**
Windows 10 Pro
Intel i7 (Old Gen)
Nvidia 970GTX with 441.20 driver.


**Issue description:**
Copy paste params from materials panels from one material to other don't work, it copies even the material point name and return an error at paste it.


**Steps to reproduce:**
1.) Download the provided project.
2.) Copy the params in the material 1 to the material 2, from the materials panel top right.

**Minimal reproduction project:**
[ShowcaseIssues.zip](https://github.com/godotengine/godot/files/5195108/ShowcaseIssues.zip)
Repository: PowerToys
Issue: [FancyZones] Add the ability to use multiple template types together
Labels: Idea-Enhancement,FancyZones-Layouts,Product-FancyZones

## 📝 Add the ability to use multiple template types together

When creating a template there are 2 basic ways to go about it. Edit an existing template type and Edit the "Create new custom" template type. I believe the ability to combine multiple templates would be useful. This is because the largest barrier to entry to creating new templates is the process of creating the zones to start with. This can be time-consuming based on the number and placement of zones in the template.

My use case is using the "Focus" template in conjunction with one of the other templates. I am providing a screenshot of one of my custom templates. In the template, there are the "Focus" zones behind the "Columns" zones. This allows me to use the inherent functionality of the "Focus" zones with the benefit of being able to see multiple windows at the same time.
![image](https://user-images.githubusercontent.com/24377175/92601124-7325a400-f27a-11ea-8a90-34f368e3263c.png)
![image](https://user-images.githubusercontent.com/24377175/92601959-79685000-f27b-11ea-8c8b-8a5f53a152ab.png)
_In the example above, I have 2 Chrome Windows in the background that can be focused at any time. In the foreground, I have Slack and WinSCP. Obviously, the applications shown could be in any position but as an example, I simply added several applications together._

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.