sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Light2D's mask borders passes through objects above it
Labels: bug,topic:rendering,confirmed,topic:2d

**Godot version:**
`3.2.3` (`master` doesn't have this function)
GLES3 only


**OS/device including version:**
Manjaro 20.2.1
Intel i5 - Integrated Graphics


**Issue description:**
Whive having a `Light2D` in mask mode, the mask's borders between transparent and solid will appear through anything above it that's not affect by it as well:
![Screenshot_20210123_162705](https://user-images.githubusercontent.com/30739239/105612025-fde1e800-5db0-11eb-82ee-8f3bc041d78f.png)


**Minimal reproduction project:**
[light2d_mask_bug.zip](https://github.com/godotengine/godot/files/5860921/light2d_mask_bug.zip)
Repository: rust
Issue: Test rustc output blocks in src/doc/rustdoc/src/ documentation
Labels: A-testsuite,C-enhancement,T-bootstrap,A-docs

Per discussion with @jyn514 on Zulip: this and other rustdoc documentation files should have the output they contain tested. https://github.com/rust-lang/rust/pull/80527 turned up a case where the output didn't match the compiler behavior.
Repository: rust
Issue: Test `#[stable]` versions in CI
Labels: A-testsuite,C-enhancement,T-infra

Maybe this is an argument for testing `since =` in CI, I've seen people get it wrong by accident a lot.

_Originally posted by @jyn514 in https://github.com/rust-lang/rustc-dev-guide/pull/1036#discussion_r563197196_

-----

`tidy` is probably the right place to do it.
Repository: create-react-app
Issue: Medium Severity: Regular Expression Denial of Service (ReDoS)
Labels: stale

Medium Severity Regular Expression Denial of Service (ReDoS) issue reported by Synk here due to the glob-parent package:

https://app.snyk.io/vuln/SNYK-JS-GLOBPARENT-1016905
Repository: deno
Issue: Non-deterministic source builds
Labels: bug,build

We struggled with updating deno at Homebrew for a while (cf. https://github.com/Homebrew/homebrew-core/pull/66920) and it seems that part of the reason is that the build is non-deterministic. The exact same build configuration can succeed now and fail (edit: with the same version!) later and vice-versa.

This is partly summarized in the table at https://github.com/Homebrew/homebrew-core/pull/66920#issuecomment-765711570. These are all attempts at building deno 1.7.0.

In particular, note that the build configuration is the same between https://github.com/Homebrew/homebrew-core/commit/54c027e24f0ba91816ff906af17efe05d1b5d663 and https://github.com/Homebrew/homebrew-core/commit/77e4ad870875fb3666c56650622bafc01e7401e2 (the first two commits in the table), but the two commits have starkly different build outcomes.

The last three commits in that table are also the same, with differing results.
Repository: rust
Issue: rustdoc: link to the source of the re-export if the original definition wasn't documented
Labels: T-rustdoc,C-enhancement,E-mentor,E-medium

Type aliases don't seem to have [src] links currently; see for example [`rustc_data_structures::fx::FxHashMap`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/fx/type.FxHashMap.html):

![image](https://user-images.githubusercontent.com/37223377/105615048-58178480-5d82-11eb-9950-ae291caedee0.png)


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: neovim
Issue: Splits are unstable and sometimes break
Labels: bug,needs:repro

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`:
```
NVIM v0.5.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-jFWXVv/neovim-0.5.0+ubuntu2+git202101230621-24b60322a-d569569c9=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/build/neovim-jFWXVv/neovim-0.5.0+ubuntu2+git202101230621-24b60322a-d569569c9/build/config -I/build/neovim-jFWXVv/neovim-0.5.0+ubuntu2+git202101230621-24b60322a-d569569c9/src -I/build/neovim-jFWXVv/neovim-0.5.0+ubuntu2+git202101230621-24b60322a-d569569c9/.deps/usr/include -I/usr/include -I/build/neovim-jFWXVv/neovim-0.5.0+ubuntu2+git202101230621-24b60322a-d569569c9/build/src/nvim/auto -I/build/neovim-jFWXVv/neovim-0.5.0+ubuntu2+git202101230621-24b60322a-d569569c9/build/include
Compiled by buildd@lcy01-amd64-018

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info
```
- `vim -u DEFAULTS` (version: 8.1) behaves differently?
vim does not experience this bug.
- Operating system/version:
WSL2 Ubuntu (no version name)
`uname -ovr`:
`5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 GNU/Linux`
- Terminal name/version: Windows Terminal Preview Version 1.5.3242.0
- `$TERM`: `xterm-256color`

### Steps to reproduce using `nvim -u NORC`
one example, there are a number of ways to cause this, most happen randomly without being reproducable (as far as i know).
Other reproducible ones are setting the 16 ANSI colors in init.vim and going into visual line mode and using neovim inside of tmux.
```
nvim -u NORC
:e <any file>
:vs
:vs
C-w w
C-w w
:term
i
C-\ C-n
C-w w
C-w w
(hold down j until the buffer scrolls)
```

### Actual behaviour
text breaks between the splits, the complete layout breaks
![image](https://user-images.githubusercontent.com/24958536/105616812-d4898200-5dd9-11eb-922f-bfbb1c59d7e1.png)


### Expected behaviour
the buffer scrolls normally without the layout breaking.
Repository: TypeScript
Issue: Enum declarations should consistently disallow computed keys
Labels: Bug,Domain: Error Messages

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

- `Computed property names are not allowed in enums`
- `enum declaration computed`

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about enums

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?#code/DYUwLgBAnhC8ECIoINwFgBQYoAcQQC85EDVNMQA7AVwFsIAxAeyYgG9MIuIBtAcgAefALoAaTtx5sAvmIlceUORm68CwzNKA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
let y = "y";
type z = "z";

enum Foo {
    ['x'],
    [{}],
    [y],
    [z]
}
```

### 🙁 Actual behavior

TS reports `Computed property names are not allowed in enums.` for `[{}]`, `[y]` and `[z]`, while it allows `['x']` (in contraddiction with the error message).

### 🙂 Expected behavior

All of them should be an error, for the reason reported by the error.

<!-- What you expected to happen instead, and why -->

### :books: Context

This came up at https://github.com/babel/babel/issues/12683: we can implement the current TS behavior in Babel, but I'd first like to check if TS is expected to report an error for `['x']`.
Repository: godot
Issue: ScrollContainer with a deadzone suddenly snaps/flickers on touch
Labels: bug,topic:input,topic:gui

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 
Tested on 3.2.3, 3.2.4, and a build of 'latest' (4.0) made today.
<!-- Specify commit hash if using non-official build. -->


**OS/device including version:** 
Issue is only present on mobile. Device tested was a Samsung Galaxy S8 US with a Snapdragon 835 SOC. Tested with GLES3 for 3.2.3, 3.2.4 and Vulkan for 4.0/'latest'
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->


**Issue description:**
Issue occurs on actual touch screens only, when interacting with a ScrollContainer node that has a deadzone.
_Expected behavior:_
When passing the deadzone, the container will scroll starting from its current position and continuing smoothly from there. The expected behavior can be observed when using a mouse and enabling 'Emulate touch from mouse' in the project's settings.
_Problematic behavior:_
When passing the deadzone, the container will instantly scroll a large and unpredictable amount for one frame. If the drag motion continues, the scroll will typically snap back to the expected position. However, with slow finger movement, it will flicker between scroll positions.
<!-- What happened, and what was expected. -->


**Steps to reproduce:**

1. Create a ScrollContainer node, and give it content that is large enough to allow scrolling.
2. Set the deadzone of the ScrollContainer to a value above zero. (The snapping behavior is more noticeable with large values, while the flickering is more noticeable with smaller values)
3. Run the project on a touch screen device and attempt to scroll the container with your finger. (Slower movement cause more noticeable effects) (This _does not_ occur with emulated touch, only on an actual touch screen)

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[ScrollTest.zip](https://github.com/godotengine/godot/files/5861387/ScrollTest.zip)

**_I have already found the cause of this issue and will submit a pull request fixing it shortly!_**
Repository: rust
Issue: Type can no longer be inferred in 1.49
Labels: E-needs-test,T-compiler,regression-from-stable-to-stable,A-inference,T-types

<!--
Thank you for filing a regression report! 🐛 A regression is something that changed between versions of Rust but was not supposed to.

Please provide a short summary of the regression, along with any information you feel is relevant to replicate it.
-->

### Code

I tried this code: [Johni0702/rtp on the dtls-srtp Branch](https://github.com/Johni0702/rtp/tree/6c0223d8a43ea5251574c541e72461b5d18a3906)

I expected to see this happen: Compiles successfully as in 1.48

Instead, this happened: Error E0282 in `src/rfc3711.rs`

```
error[E0282]: type annotations needed
   --> src/rfc3711.rs:477:19
    |
476 |         let iv = iv ^ (BigUint::from(1_u8) << (context.session_encr_key.len() * 8));
    |             -- consider giving `iv` a type
477 |         let iv = &iv.to_bytes_be()[1..context.session_encr_key.len() + 1];
    |                   ^^ cannot infer type
    |
    = note: type must be known at this point

error[E0282]: type annotations needed
   --> src/rfc3711.rs:511:19
    |
510 |         let iv = iv ^ (BigUint::from(1_u8) << (context.session_encr_key.len() * 8));
    |             -- consider giving `iv` a type
511 |         let iv = &iv.to_bytes_be()[1..context.session_encr_key.len() + 1];
    |                   ^^ cannot infer type
    |
    = note: type must be known at this point

error: aborting due to 2 previous errors
```

### Version it worked on

<!--
Provide the most recent version this worked on, for example:

It most recently worked on: Rust 1.48
-->

It most recently worked on: 1.48

### Version with regression

<!--
Provide the version you are using that has the regression.
-->

`rustc --version --verbose`:
```
rustc 1.49.0 (e1884a8e3 2020-12-29)
binary: rustc
commit-hash: e1884a8e3c3e813aada8254edfa120e85bf5ffca
commit-date: 2020-12-29
host: x86_64-unknown-linux-gnu
release: 1.49.0
```

</details>

<!--
If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-stable-to-{channel}-regression-untriaged
-->


I tried to minimize the code necessary for reproduction and I got it down to:

```rust
//file: src/lib.rs
use num::BigUint; // Cargo.toml: num = "0.1"

pub trait Protocol {
    type PacketIndex: Into<u64> + Into<BigUint>;
}

fn from_nothing<T>() -> T {
    todo!()
}

pub fn decrypt_portion<P: Protocol>(index: P::PacketIndex) {
    let iv: BigUint = from_nothing();
    let len: usize = from_nothing();
    let iv = iv ^ (index.into() << 16);
    let iv = iv ^ (BigUint::from(1_u8) << (len * 8));
    let _iv: &[u8] = &iv.to_bytes_be()[1..len + 1];
}
```
Repository: PowerToys
Issue: Weather plugin for PT Run
Labels: Idea-Enhancement,Run-Plugin

## PowerToys Run should support looking for the latest weather with orders. 

_What is the expected behavior of the proposed feature?  What is the scenario this would be used?_

As an example, when I type `weather`, it should directly tell me the weather.

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: tensorflow
Issue: Missing GPU op for zeros_like for RaggedTensorVariant, error occurs when Ragged Tensor fed thru tf.map_fn
Labels: type:bug,comp:keras,comp:gpu,TF 2.4,TF 2.16

**System information**

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes, included below
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Ubuntu 20.10
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: n/a
TensorFlow installed from (source or binary): pip binary
TensorFlow version (use command below): v1.12.1-49539-g18d8bcbe72b 2.5.0-dev20210123
Python version: '3.8.6 | packaged by conda-forge | (default, Nov 27 2020, 19:31:52) \n[GCC 9.3.0]'
Bazel version (if compiling from source): n/a
GCC/Compiler version (if compiling from source): n/a
CUDA/cuDNN version: 11.0 / 8
GPU model and memory: TITAN X (Pascal) computeCapability: 6.1

**Describe the current behavior**

I have a keras layer `RescaleB` that accepts a ragged tensor with shape [batch, (time), in_dim]. The layer calls `map_fn` to process each example in the batch separately, scaling the values along the inner dimension by a trainable gain vector. (The details of the operation aren't critical, but the ragged tensor going into map_fn is.)

Using this layer fails with `No unary variant unary_op function found for unary variant op enum: 1 Variant type_name: RaggedTensorVariant for device type: GPU` on a node whose name ends with `rescale_b/map/while/TensorArrayV2Write/TensorListSetItem_grad/zeros_like` which suggests that the zeros_like operation 
isn't defined for Ragged Tensors on GPU?

In this simple example, i also include `RescaleA`, which accomplishes the same task using `tf.ragged.map_flat_values`, although in my real use case I need `map_fn`. This is a simplified example.

**Describe the expected behavior**

I'd expect `RescaleB` and `RescaleA` to function identically.


**Standalone code to reproduce the issue**

https://colab.research.google.com/drive/1mHycCXJL94VuCGkXIJ0bIXtbYamyZo78

I've reproduced the issue locally with tf-nightly-gpu TF 2.5, but I can't seem to get the nightly version to see the GPU on Colab. The Colab notebook is using TF 2.4, but the issue remains in TF 2.5 nightly.

**Other info / logs** Include any logs or source code that would be helpful to
diagnose the problem. If including tracebacks, please include the full
traceback. Large logs and files should be attached.

This may be the same issue as #44231 but hopefully the additional detail here is helpful.
Repository: pytorch
Issue: Consider adding context manager support for torch.set_printoptions
Labels: module: printing,triaged,enhancement

so that the below would work:
```
with torch.set_printoptions(precision=2):
    print(aTensor)
```
similarly to this in numpy:
```
with np.printoptions(precision=2, suppress=True):
    print(x)
```
thanks
Repository: pytorch
Issue: Proposing new features: Developing Echo State Network layers
Labels: new-layer,feature,triaged,shadow review,module: embedding

Hello,

I would like to contribute to PyTorch with a new feature. I am currently working on research using ESNs and have written some ESN models in PyTorch for the GPU and CPU. I think these could be useful to the community.

I would initially propose a leaky-Integrator based ESN layer. From this I believe it would be generalizable to other node types. This layer's functionality would include:
- initialize the input matrix using user chosen parameters
- initalize the reservoir matrix with user chosen parameters and a user chosen spectral radius.
- provide a novel ability to choose the number of 2-attractor resevoir nodes in the ESN when the spectral radius is greater than 1.
- a mechanism for passing gradients past this layer during backpropagation since the initialized reservoir and input matrices are constant after initialization.

ESNs can act as a dynamical system embedding in a network and I think this presents some interesting possibilites for the research community.  

Thank you for your time.
 


cc @ezyang
Repository: vscode
Issue: VIM mode like sublime
Labels: feature-request,VIM

Issue Type: <b>Feature Request</b>

Please add a VIM mode like sublime! I've tried many extentions and they don't behave like what im used to with sublime.

VS Code version: Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523, 2020-12-16T16:34:46.910Z)
OS version: Windows_NT x64 10.0.19041


<!-- generated by issue reporter -->
Repository: godot
Issue: Using `get_stack()` after `yield()` results in a incomplete stack trace
Labels: discussion,topic:gdscript

**Godot version:**
Godot Engine v3.2.3.stable.mono.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce GTX 980/PCIe/SSE2



**OS/device including version:**
Windows 10


**Issue description:**
Using  get_stack() after  yield results in a incomplete stack and makes get_stack() unusless.


**Steps to reproduce:**
* create a func like this
```
func test_get_stack_after_yield():
	prints("--Before--")
	print_stack()
	yield(get_tree().create_timer(0.100), "timeout")
	prints("--After--")
	print_stack()
```
The output is
```

--Before--
Frame 0 - res://addons/gdUnit/test/monitor/PushErrorMonitorTest.gd:45 in function 'test_get_stack_after_yield'
Frame 1 - res://addons/gdUnit/src/core/GdUnitExecutor.gd:155 in function 'execute_yielded'
--After--
Frame 0 - res://addons/gdUnit/test/monitor/PushErrorMonitorTest.gd:48 in function 'test_get_stack_after_yield'
```
The second print_stack`()' misses the frame 1



**Minimal reproduction project:**
see *Steps to reproduce:*
Repository: pytorch
Issue: Suggestion: Assimilate activation images to PyTorch brand color
Labels: module: docs,triaged

## 📚 Documentation

The activation functions (e.g. [ReLU](https://pytorch.org/docs/stable/generated/torch.nn.ReLU.html#torch.nn.ReLU)) are drawn with the default colorscheme of matplotlib.

It would be much more awesome to assimilate these colors to the beautiful [PyTorch Brand Guidelines](https://pytorch.org/assets/brand-guidelines/PyTorch-Brand-Guidelines.pdf).
(And in addition, why don't we increase dpi to, for example, `dpi=300` ?)
I attach the resulting image below.

I appreciate it if you could give it a kind consideration.
Thank you so much for an amazing project.

![ReLU](https://user-images.githubusercontent.com/24503967/105626799-a2c5f900-5e75-11eb-92fa-86fb8eca579a.png)

cc @jlin27 @mruberry
Repository: rust
Issue: Function works but non-capturing closure with identical signature fails with strange error
Labels: A-lifetimes,A-closures,T-compiler,C-bug,A-async-await,AsyncAwait-Triaged,WG-async,T-types

[Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=fa03b490468a535015d89f35303f5b81)

I'm trying to use the [solution suggested for a separate problem here](https://www.reddit.com/r/rust/comments/jilk5x/hrtb_take_async_callback_accepting_reference_as/).

The solution works with a coerced function item, but not a closure that is virtually identical.

---

```rust
use std::future::Future;

trait AsyncFn1Arg<'a, Arg: 'a, Ret: 'a> {
    type Fut: Future<Output=Ret> + 'a;
    fn call(&self, arg: Arg) -> Self::Fut;
}

impl<'a, Arg: 'a, Ret: 'a, Fut: Future<Output=Ret> + 'a, F: Fn(Arg) -> Fut> AsyncFn1Arg<'a, Arg, Ret> for F {
    type Fut = Fut;
    fn call(&self, arg: Arg) -> Fut {
        self(arg)
    }
}

async fn f(arg: &i32) {
}

async fn func<F>(f: F)
    where F: for<'a> AsyncFn1Arg<'a, &'a i32, ()>
    {
        let x: i32 = 0;
        f.call(&x).await;
}

fn main() {
    // works
    func(f);
    // fails
    func(|a| f(a));
}
```

produces

```
error[E0308]: mismatched types
  --> src/main.rs:29:5
   |
29 |     func(|a| f(a));
   |     ^^^^ lifetime mismatch
   |
   = note: expected type `FnOnce<(&'a i32,)>`
              found type `FnOnce<(&i32,)>`
note: this closure does not fulfill the lifetime requirements
  --> src/main.rs:29:10
   |
29 |     func(|a| f(a));
   |          ^^^^^^^^
note: the lifetime requirement is introduced here
  --> src/main.rs:19:14
   |
19 |     where F: for<'a> AsyncFn1Arg<'a, &'a i32, ()>
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error
```
Repository: flutter
Issue: [cupertino] ability to override long tap animation
Labels: framework,f: cupertino,c: proposal,team-design,triaged-design

## Use case
iOS Context menu from different places used different long tap scale and animation.
Here is the example how it behave with list view

![42d72429d50424a69d1ecddb7a7c91ce](https://user-images.githubusercontent.com/6917580/105628962-d2124100-5e48-11eb-927e-108757befb01.gif)

## Proposal

It would be great if there is some ability to override long tap animation to make it more like native
Repository: rust
Issue: [ER] Smarter error handling in struct destructuring assignment
Labels: E-hard,A-diagnostics,P-low,T-compiler,C-feature-request,A-suggestion-diagnostics,D-papercut

This is a diagnostic enhancement request. In this code there's a simple bug, the destructuring assignment is done by mistake on Bar (that is not defined) instead of Foo:

```rust
#![feature(destructuring_assignment)]
#![allow(unused_assignments, unused_variables, unused_mut)]
fn main() {
    struct Foo { x: u64, y: u64 }
    let f = Foo {x: 10, y: 20};
    let mut a;
    let mut b;
    Bar {x: a, y: b} = f;
}
```
rustc `1.51.0-nightly 4d0dd02ee 2021-01-23` gives:

```rust
error[E0422]: cannot find struct, variant or union type `Bar` in this scope
 --> C:\lavoro\bugs\test.rs:8:5
  |
8 |     Bar {x: a, y: b} = f;
  |     ^^^ not found in this scope

error: aborting due to previous error

For more information about this error, try `rustc --explain E0422`.
```

f is of type Foo so the compiler can infer that probably Bar should be replaced by a Foo (also because the fields on the left of the destructuring assignment match correctly with the fields of Foo), so I'd like rustc to suggest to replace Bar with Foo there.