sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: "Cycle computing supertraits" error could be more helpful
Labels: C-enhancement,A-diagnostics,A-trait-system,T-compiler

Consider the following code:

```rust
trait Foo<F> {}

trait Bar: Foo<Self::F> {
    type F;
}
```

Trying to compile it, we get the following error:

```text
error[E0391]: cycle detected when computing the supertraits of `Bar`
 --> src/lib.rs:3:1
  |
3 | trait Bar: Foo<Self::F> {
  | ^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: ...which again requires computing the supertraits of `Bar`, completing the cycle
note: cycle used when collecting item types in top-level module
 --> src/lib.rs:3:1
  |
3 | trait Bar: Foo<Self::F> {
  | ^^^^^^^^^^^^^^^^^^^^^^^

```

To most programmers, this just looks like Rust won't let you have a trait bound which depends on an associated type in the trait being defined. That's what I thought for a long time. But that's not actually true - what's actually going on is that in order to figure out which `F` is being referred to in `Self::F`, the supertraits need to be computed. If we help the compiler out by disambiguating which `F` we mean, the error goes away:

```rust
trait Foo<F> {}

trait Bar: Foo<<Self as Bar>::F> {
    type F;
}
```

I suggest that we improve the error message in this case to suggest disambiguating any associated types in trait bounds in order to steer users towards this solution.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: material-ui
Issue: When customizing breakpoints with createMuiTheme, only a shallow merged value is created
Labels: new feature,package: material-ui

When customizing breakpoints with createMuiTheme, only a shallow merged value is created

- [x] This is not a v0.x issue. <!-- (v0.x is no longer maintained) -->
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Expected Behavior 🤔

When providing a customized theme object, `createMuiTheme` should deep merge it.

## Current Behavior 😯

`createMuiTheme` only shallow merges `breakpoints.value`.

## Steps to Reproduce 🕹

Link: https://codesandbox.io/s/jovial-thunder-hgw6u

## Context 🔦
I am sure this is not new in v4 - not sure if this is the intended behaviour, however, when I tried to custom breakpoints by providing a customized theme object to `createMuiTheme` like this:
```
const theme = createMuiTheme({
  breakpoints: {
    values: {
      lg: 1500,
      xl: 1300
    }
  }
});
```
I thought `createMuiTheme` will deep merge the customized theme object with the default values so I thought for the rest of the keys not provided it will fallback to use the default values of:
```
{
  xs: 0,
  sm: 600,
  md: 960
}
```

However I bumped into some bugs and after digging into the source code, I found out that when [`createMuiTheme` calls `createBreakpoints` ](https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/styles/createBreakpoints.js#L19) it overrides the `value` key inside `breakpoints` completely without merging the respective values.

Therefore, when the display size falls in an undefined value, the withWidth HOC returns some invalid value as well, thus breaking some features relying on `withWidth` such as `<Hidden />`.

Is a deep merge for `createBreakpoints` not implemented due to performance issues? If so, maybe it will be a good idea to document it better, instead of saying 
![image](https://user-images.githubusercontent.com/8017959/61019686-a5fdaf00-a3cd-11e9-9036-03e7ff006fce.png)
 because

>  Takes an incomplete theme object and adds the missing parts.

sounds like a deep merge of all keys to me. On top of that the implementation details inside `createMuiTheme` indeed [deepmerge some keys](https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/styles/createMuiTheme.js#L39), which makes it more confusing.


## Your Environment 🌎

| Tech         | Version |
|--------------|---------|
| Material-UI  | v4.1.3  |
| React        | v16.8.6 |
Repository: flutter
Issue: dependencies cost indicator
Labels: c: new feature,tool,c: performance,a: size,customer: hand,perf: app size,P3,team-tool,triaged-tool

## Use case

When I add a dependency I don't know how much of size it will add to my project

## Proposal

When I run flutter packages get I want to get these packages cost
For example Flutter web it will show to me js cost 14kb
For Flutter Android it will show to me 100kb the total of the package aar, jar, images, java files, and the total size after compiling.

I think it could be by some simple scripts to each platform
Repository: TypeScript
Issue: "Move to new file" breaks implicit index imports
Labels: Bug,Domain: Refactorings

<!-- 🚨 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 `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.5.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
// main.ts
import Component from './Component';
Component;
```

``` ts
// Component/index.ts
const Component = () => { };
export default Component;
```

Now highlight all code in `Component/index.ts`, and select "move to new file".

**Expected behavior:**
- New file `Component/Component.ts` is created
- Import in `main.ts` should still work

In order for the import to still work, TS should do either of the following (IMO):

- `Component/index.ts` re-exports the exports of the new file, so that the import in `main.ts` will work
  ``` ts
  // Component/index.ts
  export { default } from './Component';
  ```
- or, `Component/index.ts` is left empty, and the import in `main.ts` is updated
  ``` ts
  // main.ts
  import Component from './Component/Component';
  Component;
  ```

**Actual behavior:**

- New file `Component/Component.ts` is created
- Import in `main.ts` is broken

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: rust
Issue: improve documentation for AsRef/AsMut
Labels: C-enhancement,T-libs-api,A-docs

`AsRef`/`AsMut` is fairly common source of changes that result in breaking others' code. Most such changes occur by adding additional `AsRef`/`AsMut` impls, which in turn break type inference that users are unwittingly relying on. According to [Rust's API evolution](https://rust-lang.github.io/rfcs/1105-api-evolution.html), this is, strictly speaking, allowable breakage.

Almost all such instances of code breakage correspond to a _misuse_ of `AsRef`/`AsMut`, by using it situations where there are no constraints to help type inference. Idiomatic use of these traits is typically by specifying them in a context where the target type is known. For example:

```rust
fn foo<T: AsMut<[u8]>>(something: T) {
    // this will never fail, because the target type is unambiguous
    let my_mutable_slice = something.as_mut();
    // ...
}
```

Code like this is robust with respect to additional implementations of `AsMut`.

This issue is about improving the documentation of [`AsRef`](https://doc.rust-lang.org/std/convert/trait.AsRef.html)/[`AsMut`](https://doc.rust-lang.org/std/convert/trait.AsMut.html) to cover these important caveats. Currently, the docs include no mention of what incorrect usage actually is, or the fact that incorrectly using this trait can result in a new Rust compiler failing to compiler your code. (There is an example of correct usage, but no broader discussion of the intricacies of using this trait.) Additionally, the docs, IMO, don't do a good enough job differentiating `AsRef` from `Borrow`. The docs mention some specific differences, but don't cover high level concerns. It's very difficult, even for me, to take the noted differences in the docs and extrapolate that to a heuristic for when I should prefer one over the other.

This issue is motivated by the fallout from #60958, and my own recent experience in dealing with this in https://github.com/BurntSushi/rust-csv/issues/160 (which is particularly subtle).
Repository: vscode
Issue: Have a command that clears all problems that are from tasks.
Labels: feature-request,tasks,polish

When a user makes a change to a task and re-runs it, they could end up accumulating problems since the modified task counts as a new task.

One idea is to  clear all problems when the task config changes: https://github.com/microsoft/vscode/issues/76108
But that seems too aggressive and we'd be removing problems without telling the user why.

Instead, having a command to clear the task problems is clearer.
Repository: vscode
Issue: Git - Support for gitdir
Labels: help wanted,feature-request,git

I use two git repositories within project folder - one is `.git` and second is `.git_dev`. First is for project and second is to track my local config files. I used to work with second via alias `git dev` which stands for `git --git-dir=.git_dev`, but for now I explore ways to list changes within both repos in git sideview.

What I did: 
1. I create folder aside the main project folder(consider it `project`) and call it `project_dev`
2. Initialize new repo in new folder with `git init --separate-git-dir ../project/.git_dev`. It creates file `project_dev/.git` with related line.
3. Then create new file within `project_dev` folder and open it in Code. Now I'm able to view changes for both repos, but one called `project_dev` tracks the `project_dev` folder, not the `project`
4. So my next step is to add setting `worktree=/path/to/project` in `.git_dev/cofig`. Now git sideview perfectly represents current changes for `project_dev` aside to main `project`.

And here I run into two issues:
1. if I try to click on changed file in `project_dev` section of sideview, an error occurs with message: `Unable to open 'filename (Working Tree)': Unable to read file (Error: File not found (/path/to/project_dev/filename)).` like it doen't respect setting `worktree` at all.
2. If I reload Code, even if I open file from `project_dev` folder, second repo is not shown. If I remove `worktree` setting, `project_dev` repo is shown again and I have to add `worktree` setting again to get changes properly.

Example repo:
https://github.com/deitry/vscode-two-git-repos-issues

---
So, on the one hand I consider current behaviour as buggy. On the other hand, I make a request to add option to pass as many `--git-dir`s as I want by making it a list:
```
"git.gitdirs: [ ".git", ".git_dev"]
```
Repository: kubernetes
Issue: Node VM failure doesn't automatically recreate a pod with attached PV
Labels: kind/bug,priority/important-soon,lifecycle/frozen,area/provider/vmware,sig/cloud-provider

<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!

If the matter is security related, please disclose it privately via https://kubernetes.io/security/
-->


**What happened**:
After a deployment is created with PVC, a node hosting the pod shuts down. After 6 mins timeout, the replacement/new pod is created but cannot come up since the volume is attached to a terminating pod on a shutdown node. To work around this, the volume would be detached from the original pod when it's force deleted.

**What you expected to happen**:
According to the Node VM Failure scenario at https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/high-availability.html, the recovery mechanism is completely automatic. In reality, it requires manual intervention to force delete a pod.

**How to reproduce it (as minimally and precisely as possible)**:

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`): v1.12.7-gke.19
- Cloud provider or hardware configuration: vSphere Cloud Provider
- OS (e.g: `cat /etc/os-release`):
- Kernel (e.g. `uname -a`):
- Install tools:
- Network plugin and version (if this is a network-related bug):
- Others:

/sig vmware
Repository: godot
Issue: Github CodeQL Support
Labels: enhancement,usability,topic:thirdparty

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if non-official. -->
Any

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Any

**Issue description:**
<!-- What happened, and what was expected. -->
https://lgtm.com/projects/g/godotengine/godot/overview/
Shows some errors and warnings. It would be good if Godot had LGTM alert count icon too with AppVeyer, Travis, Triage and Weblate in README.
Ready to close this issue if it seems useless, irrelevant, duplicate or previously discussed.

**Steps to reproduce:**
Visit the links, checkout the errors and warnings.

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
Repository: react-native
Issue: TextInput prevent scroll on ScrollView
Labels: Component: TextInput,Platform: Linux,Component: ScrollView,Bug

In a too long form, scroll is only available if the touch start outside the `TextInput` fields

React Native version:
```
info Fetching system and libraries information...
System:
    OS: Linux 4.15 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
    Memory: 1.92 GB / 7.67 GB
    Shell: 5.4.2 - /usr/bin/zsh
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 3.5.2 - /usr/bin/npm
  SDKs:
    Android SDK:
      API Levels: 22, 23, 26, 27, 28
      Build Tools: 23.0.1, 27.0.3, 28.0.3
      System Images: android-27 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom
  npmPackages:
    react: 16.8.6 => 16.8.6 
    react-native: 0.60.0 => 0.60.0 
  npmGlobalPackages:
    react-native-cli: 2.0.1
    react-native-debugger: 1.1.0
    react-native: 0.59.3
```
## Steps To Reproduce

1. create a ScrollView with `flex: 1`
2. put more TextInputs than your screen can handle
3. try to scroll with your touch starting on a field

Describe what you expected to happen:

I expect the page to scroll

Snack, code example, or link to a repository:

```
     <ScrollView style={{ flex: 1, }}>
            <TextInput placeholder="test" textAlign='center'/>
            <TextInput placeholder="test" textAlign='center'/>
            <TextInput placeholder="test" textAlign='center'/>
            <TextInput placeholder="test" textAlign='center'/>
            <TextInput placeholder="test" textAlign='center'/>
            <View style={{ height: 150, }} />
            <TextInput placeholder="test" textAlign='center'/>
            <TextInput placeholder="test" textAlign='center'/>
            <TextInput placeholder="test" textAlign='center'/>
            <TextInput placeholder="test" textAlign='center'/>
        </ScrollView>
```
snack: https://snack.expo.io/@aiiros/react-native-issue-25594

this is a duplicate of https://github.com/facebook/react-native/issues/15962 which has not yet been answered.

Edit:
Turns out `textAlign='center'` is causing all of this
Repository: pytorch
Issue: [RFC] InstanceNorm default affine value
Labels: module: docs,triaged

TL;DR: the default `affine` value is different from the original paper and code, but is probably too old to change. Can we add a note in doc?

I happened to be looking through the original paper on [Instance Normalization](https://arxiv.org/pdf/1701.02096.pdf) and the accompanied [code](https://github.com/DmitryUlyanov/texture_nets/blob/aad2cc6f8a998fedc77b64bdcfe1e2884aa0fb3e/InstanceNormalization.lua#L16-L20). Both seem to indicate that the affine transform should be on **by default**. E.g., quote from the paper:

> Another similarity with BN is that each IN layer is followed by a scaling and bias operator sx+b.

However, since the very beginning of `nn.InstanceNorm*d`'s existence ([this PR](https://github.com/pytorch/pytorch/pull/1283)), `affine=False` is the default.

Is it worthwhile to add a `.. note::` to the doc about this behavior?

Also, cc @DmitryUlyanov , who is the first author of the paper, owner of the original lua code, and the contributor of the PyTorch module.
Repository: create-react-app
Issue: Request for more a-priori documentation for progressive web apps.
Labels: issue: proposal

### Is your proposal related to a problem?

It's difficult to gauge the benefit of how and what enabling a service worker will do to an application. For example, my react app that I'm building is looking to be a mobile progressive web app to get the impression of a regular browser app. The app is powered by a backend that is served via a reverse proxy. One feature of the app, a contact list, ideally will front-load all contacts ahead of time, and periodically sync them, allowing the app to be used offline to a certain capacity.

What's particularly difficult here is trying to figure out exactly what happens when a service worker is registered. Are my reverse proxy http requests captured in the traffic? Should I concern myself with building a solution that uses local storage or indexedDB as part of the overall design, or will it be covered by the service worker? How will a scrolling component that lazily loads elements behave if the user hasn't scrolled all the way 'to the bottom' and their app is offline?

It is difficult to answer these questions without having a good understanding of what create-react-app is doing here. After a bit of digging, I found that workbox is used. I've done quite a bit of research on progressive web apps in general; some of the issues that come up; the tooling that is provided by chrome's developer tools.

### Describe the solution you'd like

What I would like to see is a more comprehensive look at what is happening underneath the hood without having to dig around in every nook and cranny in the ecosystem. Particularly, it is difficult because many of the search results involve outdated examples or ejecting the app, which has long-term ramifications on the direction that a create-web-app project goes.

### Describe alternatives you've considered

As I'm in an evaluation period, I'm looking more for information. Ejecting the application and trying to sew technology together manually is currently the only viable-looking alternative. Which is fine, but not preferable. Having the information available to help make an educated and informed decision on whether or not the this is right to me is what's at question here.

Thanks for your time!
Repository: rust
Issue: Barely noticeable compiler suggestion
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,F-on_unimplemented

```
fn main() {
    let new_service = {
        hyper::service::service_fn_ok(unimplemented!())
    };
    hyper::Server::bind(unimplemented!())
        .serve(new_service);
}
```

Compiler error:
```
error[E0277]: expected a `std::ops::Fn<()>` closure, found `hyper::service::service::ServiceFnOk<_, _>`
 --> src/main.rs:6:10
  |
6 |         .serve(new_service);
  |          ^^^^^ expected an `Fn<()>` closure, found `hyper::service::service::ServiceFnOk<_, _>`
  |
  = help: the trait `std::ops::Fn<()>` is not implemented for `hyper::service::service::ServiceFnOk<_, _>`
  = note: wrap the `hyper::service::service::ServiceFnOk<_, _>` in a closure with no arguments: `|| { /* code */ }
  = note: required because of the requirements on the impl of `hyper::service::new_service::NewService` for `hyper::service::service::ServiceFnOk<_, _>`
  = note: required because of the requirements on the impl of `hyper::service::make_service::MakeServiceRef<hyper::server::tcp::addr_stream::AddrStream>` for `hyper::service::service::ServiceFnOk<_, _>`
```

I think it's better to improve this note
```
  = note: wrap the `hyper::service::service::ServiceFnOk<_, _>` in a closure with no arguments: `|| { /* code */ }
```
So it's more noticeable and readable.

[Playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7384234185f560e9c2e27f9566918f57)
Repository: pytorch
Issue: assert_no_internal_overlap should pass const char*
Labels: module: internals,triaged

Followup to #22729. Quoting @colesbury:

> For older versions of GCC (4.9), const char* is better since otherwise GCC will still construct a std::string for every call. (We ship OSS binaries using GCC 4.9)
https://gcc.godbolt.org/z/0NQtCC
Repository: rust
Issue: warn on running benchmarks in debug mode
Labels: A-lints,T-compiler,C-feature-request,A-libtest

libtest-generated benchmark code should issue a warning when benching code that was compiled in debug mode, as this is likely not the intended outcome. At worst the user will be like "gee thanks, Rust, I already know", but at best it will save a lot of time.

## How to reproduce

* Create a benchmark
* Compile with `rustc --test my_benchmark.rs`
* Run with `./my_benchmark --bench`

## Desired outcome

Before the benchmark runs, it should issue a note saying "This benchmark was compiled in debug mode.".

## Actual outcome

No such note is issued.
Repository: flutter
Issue: Document how to write UI tests that interact with native UI elements
Labels: a: tests,d: api docs,customer: crowd,p: maps,package,customer: vroom,team-ecosystem,P3,triaged-ecosystem

Since markers aren't widgets, what is the recommended way to write a widget test which taps a map marker and ensures that the onTap is executed? I didn't see any marker onTap tests in the google maps plugin tests 🙁 

Thanks!