sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Exported Projects with References to EditorPlugin Crash
Labels: bug,topic:editor,topic:plugin,crash

**Godot version:**
3.2.2.stable.official


**OS/device including version:**
Windows 7, 64-bit.


**Issue description:**
Exporting a project that references EditorPlugin, even if that code branch isn't used, will fail to run.


**Steps to reproduce:**
Create a project which references an EditorPlugin via GDScript in any capacity. Export a Windows Desktop release EXE. It will fail with, `Parse Error: The identifier "EditorPlugin" isn't declared in the current scope.`

**Minimal reproduction project:**
[Example.zip](https://github.com/godotengine/godot/files/4976658/Example.zip)
Repository: TypeScript
Issue: Specialize JSX error messages for missing properties
Labels: Help Wanted,Effort: Moderate,Domain: JSX/TSX,Domain: Error Messages,Experience Enhancement,Fix Available,Rescheduled

```tsx
import React from "react";

function Foo(props: { count: number }) {
    return <div>{props.count}</div>;
}

<Foo />

function Bar(props: { a: any, b: any }) {
    return <div />;
}

<Bar />

function Baz(props: { a: any, b: any, c: any, d: any, e: any, f: any }) {
    return <div />
}

<Baz />
```


Current

```
Property 'count' is missing in type '{}' but required in type '{ count: number; }'.
Type '{}' is missing the following properties from type '{ a: any; b: any; }': a, b
Type '{}' is missing the following properties from type '{ a: any; b: any; c: any; d: any; e: any; f: any; }': a, b, c, d, and 2 more.
```

Proposed

```
The 'count' attribute is missing, but is required for this 'Foo' tag.
This 'Bar' tag is missing the following attributes: a, b.
This 'Baz' tag is missing the following attributes: a, b, c, d, and 2 more.
```

[Playground Link](https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAMTnAFABwE50wZwC5EBvRCOcKYsEAWwCMBTbRAXwEpSAoRPxbEyghsSADwATGADcAfCQpU2YgPRS53NkA)
Repository: rust
Issue: Filter out `Debug` note on E0277 in type context
Labels: C-enhancement,A-diagnostics,P-low,T-compiler,F-on_unimplemented,D-papercut

[Given](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4d5d66cff30ed477af01f69b11d42115)

```rust
trait T {
    type A: Display;
}

impl T for () {
    type A = ();
}
```

we shouldn't include the last `note` as that is only useful when dealing with expressions:

```
error[E0277]: `()` doesn't implement `std::fmt::Display`
 --> src/lib.rs:8:14
  |
3 | trait T {
  |       - required by a bound in this
4 |     type A: Display;
  |             ------- required by this bound in `T`
...
8 |     type A = ();
  |              ^^ `()` cannot be formatted with the default formatter
  |
  = help: the trait `std::fmt::Display` is not implemented for `()`
  = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
```
Repository: rust
Issue: Proposal: Mismatching parameter name lint
Labels: A-lints,A-trait-system,T-compiler,C-feature-request,T-types

This lint detects when the implementation of a trait names a function parameter differently from the name in the source declaration.  Exceptions to this are prefixing the name with `_` or replacing the name with `_` to suppress the `unused-variable` lint. Some example code that triggers this lint:

```
trait Foo {
    fn foo(my_foo: &Foo);
}

struct Bar;
impl Foo for Bar {
    fn foo(your_foo: &Foo) {
        // ...
    }
}
```

This will produce:

```
warning: the parameter `your_bar` has a different name than the trait definition
  --> src/main.rs:7:16
   |
7  |         fn foo(your_foo: &Foo) {,
   |                ^^^^^^^^
   |                |
   |                help: consider renaming this parameter to `my_foo`
   |
```
Repository: vscode
Issue: Extension API: QuickPick fuzzy search not finding results
Labels: feature-request,quick-pick

Hi,

I use QuickPick component for opening daily notes in [my extension](https://github.com/svsool/vscode-memo/).

Example:
![image](https://user-images.githubusercontent.com/1452141/88474541-3141d800-cf30-11ea-9371-7f7937dfe3d0.png)

When I type `-2d` or `-2 d` I expect `-2 days | Friday, July 24, 2020 Exists` (see screenshot above) to appear in the results, but  I see this instead:

![image](https://user-images.githubusercontent.com/1452141/88474560-5fbfb300-cf30-11ea-95b7-fc9c28d86e94.png)

Sorting is also wrong as `-25 days` item comes last in the results. In the order I provide it to QuickPick `-25` comes before `-172`, `-235`, `-263`. Is it configurable?

Another example:

![image](https://user-images.githubusercontent.com/1452141/88474771-7e26ae00-cf32-11ea-8ec8-aab0f562dfb0.png)

When I type `+m` I expect all Mondays with leading `+n days` to appear from previous screenshot, but I see this instead:

![image](https://user-images.githubusercontent.com/1452141/88474781-90a0e780-cf32-11ea-8b5c-29dfa5dc42d4.png)

What could be the problem with it or am I missing something?

Thanks!
Repository: godot
Issue: part of import panel area turn black when switching position in dock
Labels: bug,topic:editor

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
Godot 3.2.3 RC1


**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
2013 MacBook Pro 13 inch, MacOS 10.13.6


**Issue description:**
<!-- What happened, and what was expected. -->
when I switched the position of import panel, part of area turn black, and if you select some resource like .png, it will return to normal color, this issue appears in both of GLES2 and GLES3
<a data-flickr-embed="true" href="https://www.flickr.com/photos/189186320@N08/50154466107/in/dateposted-public/" title="屏幕快照 2020-07-26 16.18.51"><img src="https://live.staticflickr.com/65535/50154466107_b33e7383f0_o.png" width="351" height="485" alt="屏幕快照 2020-07-26 16.18.51"></a>
Repository: ant-design
Issue: Transfer component need to custom props like loading of operations
Labels: help wanted,Inactive

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
to display the progress of handling onChange func

### What does the proposed API look like?
operationsProps={[{ loading: loadingLeft } as ButtonProps, { loading: loadingRight } as ButtonProps]}


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: To have single cuda context across multiple processes
Labels: module: cuda,triaged

Presently, as far I have digged around, pytorch doesn't seem to use single cuda context across multiple processes. If training the network in multiple processes the 557 MB per cuda context in each process is quite expensive. It would be nice to enable pytorch to use single cuda context.

FYI: 
- The multiple process training requirement could be mitigated using `torch.multiprocessing` but it would be good to have it for legacy processes too.
- I tried using cuda Multi Process Service (MPS) which should by default use single cuda context no matter where you are spawning the different processes. But even then for every new process spawned the GPU memory used is almost equivalent.

It would be nice if someone could point me in the right direction or in the source code of pytorch, where torch spawns cuda contexts and I could change the context creation to get the present cuda context and use it if available. (given it would be a minor change)

cc @ngimel
Repository: TypeScript
Issue: Mixin abstract class: union of abstract propeties is not abstract. 
Labels: Bug

**TypeScript Version:**  3.9.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** mixin abstract union

**Expected behavior:**
Union of abstract propeties is abstract property.

**Actual behavior:**
Union of abstract propeties is not abstract.

<!-- Did you find other bugs that looked similar? -->
**Related Issues:**

**Code**
```ts
type Constructor = new (...args: any[]) => {};

class BaseClass {}

function AB<TBase extends Constructor>(Base: TBase) {
  abstract class AB extends Base {
    abstract a: number
    abstract b: number
  };
  return AB
}
function AC<TBase extends Constructor>(Base: TBase) {
  abstract class AC extends Base {
    abstract a: number
    abstract c: number
  };
  return AC
}

// should throw "Non-abstract class 'ShouldHavePropA' does not implement inherited abstract member 'a' from class ..."
class ShouldHavePropA extends AB(AC(BaseClass)) { 
    b = 1;
    c = 2;
}
```



<details><summary><b>Output</b></summary>

```ts
"use strict";
class BaseClass {
}
function AB(Base) {
    class AB extends Base {
    }
    ;
    return AB;
}
function AC(Base) {
    class AC extends Base {
    }
    ;
    return AC;
}
class ShouldHavePropA extends AB(AC(BaseClass)) {
    constructor() {
        super(...arguments);
        this.b = 1;
        this.c = 2;
    }
}

```


</details>


<details><summary><b>Compiler Options</b></summary>

```json
{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictBindCallApply": true,
    "noImplicitThis": true,
    "noImplicitReturns": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "declaration": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "moduleResolution": 2,
    "target": "ES2017",
    "jsx": "React",
    "module": "ESNext"
  }
}
```


</details>

**Playground Link:** [Provided](https://www.typescriptlang.org/play?ts=3.9.2#code/C4TwDgpgBAwg9gOwM7AE4FcDGw6qgXigQgHcoAKAOmoENUBzJALihoRAG0BdASgID4oAbwC+AbgBQEzABsaSJFABC8iDDkLhIqQDN0CbAEtEUAIJKAPABUVSaBAAewCAgAmi+MjRYcqfuVsIFhtVPiEJKFYAIxRUGmwoWXlFcyhHZzdFQOEIyOjY+OBWFgR0AFsoiFRcyJoYtEKoKJLyyurI8VzUCGB0VAQzJQltPQNgYwHTGGts9Jd3WERYn1x-QODAsNy6goSkzSm0p3ms1Ry8-IaEmhaKqprLuL3bttzOyO7e-rMYYal9xQAZQAFnB0DJXAAJGgANwgAAVUHAwKYjhkFuZyFMAqp1MkeFsLlECFAAIySC6YEkAJkkIiAA)
Repository: pytorch
Issue: Document optimizations enabled by JIT scripting and tracing (TorchScript)
Labels: oncall: jit,days

## 📚 Documentation

Current documentation is vague about what optimizations are possible with TorchScript. E.g.
- https://pytorch.org/docs/stable/jit.html?highlight=jit%20script#module-torch.jit
- https://pytorch.org/tutorials/beginner/Intro_to_TorchScript_tutorial.html

Documenting optimizations is risky business. But there should be a place where the usual or expected optimizations are briefly discussed, with a clear notice that they're not guaranteed. This will allow users to keep in mind the general high-level behavior of the JIT when writing and debugging code for it.


cc @suo @gmagogsfm
Repository: rust
Issue: sysroot spans still not printed, when remap-path-prefix is set with a custom path
Labels: A-testsuite,T-compiler,C-bug,A-reproducibility,A-path-remapping

The fix at the end of #53081 talks about `remap-debuginfo` in `config.toml` and `/rustc/$hash`, however in Debian we use `--remap-path-prefix` in `RUSTFLAGS` and `/usr/src/rustc-$VERSION`.

Results in 64 failing tests in `[ui]`, in [1.44.1](https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=amd64&ver=1.44.1%2Bdfsg1-1%7Eexp1&stamp=1594606550&raw=0)

@eddyb any ideas for a quick fix?
Repository: rust
Issue: `overflow evaluating the requirement` with `impl`s those seem to be right
Labels: A-associated-items,T-compiler,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
#![recursion_limit="5"] // without it the error is the same, but much bigger
struct Nil;
struct Cons<H, T>(H, T);

pub trait Map<F> {
    type Output;
}

impl<FH, FM, FT, H, M, T, R> Map<Cons<FH, Cons<FM, FT>>> for Cons<H, Cons<M, T>>
where
    FH: FnOnce(H) -> R,
    Cons<M, T>: Map<Cons<FM, FT>>,
{
    type Output = Cons<R, <Cons<M, T> as Map<Cons<FM, FT>>>::Output>;
}

impl<F, H, T, R> Map<F> for Cons<H, T>
where
    F: FnMut(H) -> R,
    T: Map<F>,
{
    type Output = Cons<R, T::Output>;
}
```

I expected this code to compile.

Instead, the compiler fails with a huge error:
```
error[E0275]: overflow evaluating the requirement `Cons<_, Cons<_, _>>: Map<Cons<_, Cons<_, _>>>`
  |
  = help: consider adding a `#![recursion_limit="10"]` attribute to your crate (`playground`)
  = note: required because of the requirements on the impl of `Map<Cons<_, Cons<_, Cons<_, _>>>>` for `Cons<_, Cons<_, Cons<_, _>>>`
  = note: required because of the requirements on the impl of `Map<Cons<_, Cons<_, Cons<_, Cons<_, _>>>>>` for `Cons<_, Cons<_, Cons<_, Cons<_, _>>>>`
  = note: required because of the requirements on the impl of `Map<Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, _>>>>>>` for `Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, _>>>>>`
  = note: required because of the requirements on the impl of `Map<Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, _>>>>>>>` for `Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, _>>>>>>`
  = note: required because of the requirements on the impl of `Map<Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, _>>>>>>>>` for `Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, Cons<_, _>>>>>>>`
```
([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=054fd0fc46b3845a47e0ae85d249169d))

Note that very similar code with a slightly different trait [works](https://github.com/WaffleLapkin/minihlist/blob/master/src/fold.rs#L74-L86), so I assume this is a bug (though, I may miss something)

Also, note that there is a **lot** of issues with `E0275`, however, I couldn't find one that fits my problem.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

Tested on `1.45.0` and `1.47.0-nightly (2020-07-25 d6953df14657f5932270)`
Repository: rust
Issue: CString does not preserve capacity
Labels: T-libs-api,C-bug

Simplest repro:
```rust
use std::ffi::CString;
let vec = Vec::with_capacity(87);
let cstring = CString::new(vec);
let vec = cstring.into_bytes();
assert_eq!(vec.capacity(), 87);
```

I expected `CString` to behave like `String`, preserving capacity from the `Vec` it was created. Instead, [the `CString` implementation shrinks-to-fit and stores a boxed slice][0], which is then converted back into `Vec` in `into_bytes`/`into_bytes_with_nul`, giving back as much capacity as there were elements, i.e. 1 which is the nul terminator.

I vaguely understand the reasoning for this — when `&CStr` becomes a narrow pointer, `Box<CStr>` would be a narrow pointer too, meaning that `CString` also will; in such a case, if `CString` was a `Vec` instead, it would be three pointers in size (pointer, size, capacity). This means, however, that there's no reason to use `CString` instead of `Box<CStr>`, making it essentially useless.

In other words, the only reason for `String`/`OsString`/`CString` to exist in parallel with `Box<str>`/`Box<OsStr>`/`Box<CStr>` is to provide the same safety guarantees for the contents while also providing `Vec`-like functionality (growing/shrinking and spare capacity). In reality, `CString` does not provide those at all, much like `OsString` (though it'd be considerably more complex to implement `push`/`pop` for `OsString` on Windows even if it's a `Vec`, since that'd mean that encoding and decoding the underlying WTF-8 would be required).

As an initial effort, `OsString` and `CString` can be transformed into `Vec`s transparently to their public APIs. Then, the `Vec` API can be integrated via the usual RFC process.

### Meta
`rustc --version --verbose`:
```
rustc 1.46.0-nightly (3503f565e 2020-07-02)
binary: rustc
commit-hash: 3503f565e1fb7296983757d2716346f48a4a262b
commit-date: 2020-07-02
host: x86_64-unknown-linux-gnu
release: 1.46.0-nightly
LLVM version: 10.0
```

[0]: https://doc.rust-lang.org/src/std/ffi/c_str.rs.html#382 " "
Repository: transformers
Issue: Test BART's memory  consumption
Labels: Help wanted,Tests,Benchmarks,WIP

- this can run on GPU only and be marked `@slow`
- check how much memory bart is using at `__init__`
- assert that it doesn't use more than 110% of that.
- check how much memory bart uses on a single forward pass. (optionally test this in fp16).
- assert that it doesn't use more than 110% of that.
- check how much memory bart uses on a single forward and backward pass.
- assert that it doesn't use more than 110% of that.

### Bonus:
- add similar asserts for timing! 
- let the test run and check memory on CPU (make sure that if pytest is run with `-n -8` the test still passes!
- add a test to `test_modeling_common.py` to make it easy for all models to test this.
- add a test to `test_modeling_common_tf.py` to make it easy for all TF models to test this.

The benchmarking utilities may help.
It may also help to use `torch.cuda.max_memory...`

@patrickvonplaten may have further thoughts!
Repository: godot
Issue: Progress bar incorrectly sets minimum vertical size to 14 when its position is modified from an external node
Labels: bug,confirmed,topic:gui

<!-- 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 using non-official build. -->
3.2.2 stable

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
manjaro linux

**Issue description:**
<!-- What happened, and what was expected. -->
A progress bar with two flat styleboxes ( so no rect minimum size ) with a child node that sets its position will never be able to have a vertical size below 14, even though in the editor it can be made to go below. 

**Steps to reproduce:**
1. Open the reproduction project
2. Make the progress bar's vertical size less than 14 using any means
3. Run the game

The size of the progress bar vertically will be 14 even if you set the size vertically to be less than 14

Now the progress bar will have a vertical size of 14 ( the bug )
**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[scaling-bug.zip](https://github.com/godotengine/godot/files/4978730/scaling-bug.zip)
Repository: flutter
Issue: [Web] Clickable cursor shown on video player when hovered from clickable items to the video_player
Labels: platform-web,p: video_player,package,has reproducible steps,P2,workaround available,found in release: 3.10,found in release: 3.11,team-web,triaged-web

I have a `Stack` with a `VideoPlayer` sitting behind various other UI elements. It appears that the `VideoPlayer` prevents the expected hand cursor for any button shown on top of the `VideoPlayer`. It also prevents direct usage of a `MouseRegion`, too. If I comment out the `VideoPlayer`, the buttons correctly show the hand cursor.

I assume this is the result of automatic decisions about what kind of web elements to use for this subtree?

Here is a simplified version of my widget tree for reproduction. I don't think my use of `SizedBox` and `FittedBox` are relevant, but I included them just in case.

```
Stack(
        children: [
          _videoController.value.initialized
              ? SizedBox.expand(
                  child: FittedBox(
                    fit: BoxFit.cover,
                    child: SizedBox(
                      width: _videoController.value.size?.width ?? 0,
                      height: _videoController.value.size?.height ?? 0,
                      child: VideoPlayer(
                        _videoController,
                      ),
                    ),
                  ),
                )
              : SizedBox(),
          Center(
            child: RaisedButton(
              child: Text('Click Me!'),
              onPressed: () {
                print('Pressed');
              },
            ),
          ),
      ]
),
```

------

Flutter 1.21.0-1.0.pre • channel master • https://github.com/flutter/flutter.git
Framework • revision 6eaaf1650e (2 weeks ago) • 2020-07-09 18:04:37 -0700
Engine • revision 9b3e3410f0
Tools • Dart 2.9.0 (build 2.9.0-20.0.dev 06cb010247)
Repository: rust
Issue: rustbuild: --no-fail-fast tries to compile rustc 40+ times (due to crossbeam-utils failure) before eventually failing
Labels: T-bootstrap,C-bug

See for example https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=amd64&ver=1.44.1%2Bdfsg1-1%7Eexp1&stamp=1594606550&raw=0 (warning, 30MB HTML), [raw text 25MB](https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=amd64&ver=1.44.1%2Bdfsg1-1%7Eexp1&stamp=1594606550&raw=1) where the error message "cannot find type `AtomicU128`" crops up 46 times.

Presumably this is because 46 things depend on crossbeam-utils. But then they should automatically fail when one of their dependencies has recorded a failure, instead of re-running the same command. (In other words --no-fail-fast should only move onto other targets *whose dependencies haven't failed*.)

It's hard to notice these failures, since the error messages quickly scroll out of view. I only noticed because I eventually realised the build really shouldn't be taking 3+ hours.
Repository: rust
Issue: Proposal: Split `unused-variables` lint into `unused-variables`, `unused-function-parameters`, and `unused-trait-function-parameters`
Labels: C-enhancement,A-lints,T-compiler

Per my own style preferences, I would like to disable `unused-variables` warnings on trait function implementations for unused parameters (related https://github.com/rust-lang/rust/issues/26487#issuecomment-169828205), while still being warned if non-trait functions have unused parameters, or if any of my function bodies have unused variables.

I propose splitting `unused-variables` lint into `unused-variables`, `unused-function-parameters`, and `unused-trait-function-parameters`.  I'd expect all three to be warn by default to match current behavior.  It seems like there's a little bit of precedent as there are already a variety of `unused-X` lints.