sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: powerMonitor.getSystemIdleTime() reports user idle on linux when using only keyboard (on Wayland)
Labels: platform/linux,bug :beetle:,10-x-y,wayland

<!--  As an open source project with a dedicated but small maintainer team, it can sometimes take a long time for issues to be addressed so please be patient and we will get back to you as soon as we can.
-->

### Preflight Checklist
<!-- Please ensure you've completed the following steps by replacing [ ] with [x]-->

* [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 an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:**
10.0.2
https://github.com/johannesjo/super-productivity/blob/master/package.json#L145

* **Operating System:**
Ubuntu 20.10 x64 Wayland

* **Last Known Working Electron version:**
N/A

### Expected Behavior
When user is using only a keyboard (eg: editing files in Vim in running in a terminal emulator) `powerMonitor.getSystemIdleTime()` API does not detect this as idle time.

### Actual Behavior
`powerMonitor.getSystemIdleTime()` detects the user is idle when user is using keyboard only in Vim

### To Reproduce
Found this while using `Super-Productivity` app on latest release version `6.4.0` from Snap store. Bug filed here:
https://github.com/johannesjo/super-productivity/issues/922

This app is using the `powerMonitor` API to detect when a user is idle to notify them after X number of minutes:
https://github.com/johannesjo/super-productivity/blob/03ff2fb0086225b9b56832e308b2751e2afc0f52/electron/main.ts#L146

Using the app I get this idle detection whenever I'm using the keyboard only in Vim for X number of minutes.

### Screenshots
<!-- If applicable, add screenshots to help explain your problem. -->

### Additional Information
<!-- Add any other context about the problem here. -->
Repository: flutter
Issue: Android: local debug engine doesn't have debugging symbols
Labels: platform-android,tool,P2,team-android,triaged-android

**Steps to reproduce:**
1) `flutter/tools/gn --android --runtime-mode debug --unoptimized`
1) `autoninja -C out/android_debug_unopt`
1) `cd $FLUTTER_PROJECT`
1) `flutter --local-engine-src-path ~/dev/engine/src --local-engine=android_debug_unopt run`
1) In Android Studio attach to the process with LLDB
1) Do something that causes a crash in the native code, notice that Android Studio can't symbolicate the crash.

**Expected result:**
The stacktrace is valid inside of the lldb instance in Android Studio.

**Speculation on problem:**
When building a debug engine it creates 2 variants of libflutter.so.  One that is stripped of symbols, one that isn't.

```bash
$ find out/android_debug_unopt -name "libflutter.so"
out/android_debug_unopt/libflutter.so
out/android_debug_unopt/lib.stripped/libflutter.so
```

I suspect we are using the stripped one in the tooling for some reason to build the app.  That stripped library  shouldn't even be built for a debug engine.
Repository: godot
Issue: Filtering gives redundant node results in CreateNewNode Dialog
Labels: enhancement,discussion,topic:editor,usability

<!-- 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.3, 3.2.4rc3

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Linux

**Issue description:**
<!-- What happened, and what was expected. -->
Filtering gives redundant node results in `CreateNewNode` Dialog

**Steps to reproduce:**
![3 2 4rc3](https://user-images.githubusercontent.com/16458555/109224226-7a674c80-77dd-11eb-8168-e541819c96f3.png)


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: go
Issue: cmd/compile: open-coded defers keep pointer arguments alive past the deferred call
Labels: NeedsFix,compiler/runtime

It looks like open-coded defers are keeping their arguments alive past the deferred call:

Failing test case using open-coded defer: https://play.golang.org/p/9SEiOeaLmCS

Passing test case using heap-allocated defer: https://play.golang.org/p/BWEQuC5EowK

In these tests, there are two deferred function calls. The first call needs `p` kept alive, but the second does not. We should be able to collect `p` (and run its finalizer) as soon as the first deferred function call returns. The heap-allocated defer does this, but the open-coded one does not.

/cc @danscales
Repository: TypeScript
Issue: nested destructured tuple value is `string | undefined` when second tuple item is not accessed
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

When using `noUncheckedIndexedAccess`, the type inferred by my code is affected by whether I access the second item in a tuple or not.

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

tuple, undefined, type, omit, noUncheckedIndexedAccess, error, index, array, infer, nested

### 🕗 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 `noUncheckedIndexedAccess`
- I was unable to test this on prior versions because `--noUncheckedIndexedAccess` didn't exist before those versions

### ⏯ 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?noUncheckedIndexedAccess=true&ts=4.2.0-beta#code/CYUwxgNghgTiAEYD2A7AzgF3gMxQLngB4AVeEADwxBWDXkxgEsUBzAbQF0A+ACgwOIBKeAF4u8NsQA09DE1acOAbgCwAKHXJ0WNm3IcOonCh5sA5AEYzHQao1qtaJBBAA6CEhY9yrjEgAySADuIDAAwlBoIDyCtkA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
declare const fn: <T extends string[]>(t: T) => [T, string[]];

const [[x]] = fn(['1']);

console.log(x.toLowerCase());
```

It seems that the inferred type for `fn` is:

```
const fn: <string[]>(t: string[]) => [string[], string[]]
```

Since the first item is an array rather than a tuple, items in that array have type `string | undefined`.

If I change the assignment to be:

```
const [[x], []] = fn(['1']);
```

It gets inferred as:

```
const fn: <[string]>(t: [string]) => [[string], string[]]
```

Since the first item is a tuple rather than an array, items in that tuple have type `string`.

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
`x` has type `string | undefined`

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->
`x` has type `string`.
Repository: react
Issue: Bug: React DevTools fails when using React Native + Hermes
Labels: Type: Bug,Component: Developer Tools

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: 16.13.1
React DevTools version: 4.10.1-3a8c04e3b2

## Steps To Reproduce

1. `npx react-native init MyApp --template react-native-template-typescript`
2. set `enableHermes: true` in `android/app/build.gradle`
3. start Metro bundler via `yarn start`
4. launch app in Android emulator via `yarn android`
5. launch React DevTools
6. reload Metro bundler
7. click on any element in the React DevTools components view
8. right React DevTools panel is stuck on "Loading..." and Metro bundler logs `ERROR [TypeError: undefined is not a function]`:
<img width="297" alt="Screen Shot 2021-02-25 at 5 56 13 PM" src="https://user-images.githubusercontent.com/440230/109231116-f76dd400-7793-11eb-8b7c-4c40a7eaee3a.png">


<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example:
https://github.com/helixbass/HermesDevToolsIssueExample

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

## The current behavior

React DevTools fails to load element props, styles etc


## The expected behavior

React DevTools should load element props, styles etc
Repository: TypeScript
Issue: JS and TS language service die on template literal expression
Labels: Bug,Rescheduled


Issue Type: <b>Bug</b>

1. Open VS Code, create a blank file, and set the language for the file to TypeScript.
2. Paste in the following code which contains the problematic template literal expression (`&$filter=${string}`):
```
export abstract class RecordStore<T> {
    
    constructor() {}

    async RetrieveMultiple(filter?: `&$filter=${string}` /* this template literal causes TS lang service to crash */) {
        if (this.LogicalName === "optionset") {
            debugger; // not valid
            return [];
        }

        let options = [
            `?$select=${this.QuerySelect}`,
            this.QueryExpand ? `&$expand=${this.QueryExpand}` : '',
            filter ?? "",
            this.QueryOrderBy ? `&$orderby=${this.QueryOrderBy}` : ''
        ].join('');
        
        return Xrm.WebApi.retrieveMultipleRecords(this.LogicalName, options).then(
            (results) => {
                let storedRecords = this.StoreDatabaseRecords(results.entities);
                return storedRecords;
            },
            (error) => {
                Controls.Messages.NotifyUser(error.message, "ERROR",
                    this.LogicalName + "_retrieveMultipleError");
                //Xrm.Utility.alertDialog(error.messages, <any>null);
                console.log(error);
                return [];
            }
        );
    }
}
```
3. Eventually VS shows error: "The TypeScript language service died 5 times right after it got started.  The service will not be restarted."

VS Code version: Code 1.53.2 (622cb03f7e070a9670c94bae1a45d78d7181fbd4, 2021-02-11T11:48:20.056Z)
OS version: Windows_NT ia32 10.0.18363

<details><summary>Extensions (7)</summary>

Extension|Author (truncated)|Version
---|---|---
Bookmarks|ale|13.0.1
vscode-eslint|dba|2.1.14
prettier-vscode|esb|5.9.2
vscode-todo-plus|fab|4.18.2
csharp|ms-|1.23.9
vs-keybindings|ms-|0.2.0
vscode-todo-highlight|way|1.0.4

(4 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vsreu685:30147344
python383:30185418
vspyt653:30253241
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstry244:30256636
pythonvsdeb440:30248342
pythonvsded773:30248341
pythonvspyt600cf:30251589

```

</details>

<!-- generated by issue reporter -->
Repository: vscode
Issue: Feedback on folding UX for notebook
Labels: feature-request,notebook-folding

For the example notebook:

<img width="698" alt="Screen Shot 2021-02-25 at 5 51 45 PM" src="https://user-images.githubusercontent.com/12821956/109243658-2d11bd80-7792-11eb-9602-d716566fa238.png">

I find that I always have trouble understanding how folding works. Here are a few notes on what confused me:

- The fold indicators on all the cells have the same indentation.
 
    To me, it look like all the cells are at the same level, but really folding `verification` folds the `verifiable ...` and `unreleased ...` cells too. Is there some way we could express the hierarchy better?

- There is no preview of what will be folded.

    For code, the indent guides sort of offer a preview of the range that will be folded. When you hover over a fold indicator,  could we preview the range of cells that will be folded?

- It is easy to miss that a cell has been folded

    In code, we have both line numbers and the folding highlighting that makes folded regions more obvious
Repository: rust
Issue: Crate whose `dev-dependencies` depend on it produces confusing "is not implemented for" errors
Labels: A-diagnostics,T-compiler

Short explanation: If I have a crate `a` which has a dev dependency on crate `b`, which has a normal dependency on crate `a`, then `cargo test` in `a` can produce hard-to-understand errors.

# Full reproduction case (2 crates)

`a/Cargo.toml`:

```toml
[package]
name = "a"
version = "0.1.0"
edition = "2018"

[dev-dependencies]
b = { path = "../b" }
```

`a/src/lib.rs`:

```rust
pub trait Foo { fn foo(); }

#[test]
fn dep_impl() {
    <b::Bar as Foo>::foo();
}
```

`b/Cargo.toml`:

```toml
[package]
name = "b"
version = "0.1.0"
edition = "2018"

[dependencies]
a = { path = "../a" }
```

`b/src/lib.rs`:

```rust
pub struct Bar;
impl a::Foo for Bar { fn foo() {} }
```

# Output

The output of `cargo test` in `a/` is:

```
   Compiling a v0.1.0 (/home/jrvanwhy/cargo_test/a)
   Compiling b v0.1.0 (/home/jrvanwhy/cargo_test/b)
error[E0277]: the trait bound `b::Bar: Foo` is not satisfied
 --> src/lib.rs:5:5
  |
1 | pub trait Foo { fn foo(); }
  |                 --------- required by `Foo::foo`
...
5 |     <b::Bar as Foo>::foo();
  |     ^^^^^^^^^^^^^^^^^^^^ the trait `Foo` is not implemented for `b::Bar`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `a`.

To learn more, run the command again with --verbose.
```

This is confusing, because it is obvious that `b::Bar` implements `a::Foo`, yet the compiler tells you it doesn't.

My understanding is that the error occurs because there are two versions of `a`: `a` without `cfg(test)` and `a` with `cfg(test)`. `b` depends on `a` without `cfg(test)`, and implements that version of `Foo`, while `a`'s tests depend on the `cfg(test)` version of `Foo`.

I have confirmed this error message is the same in the latest stable and current nightly (`2021-02-25`) compilers.
Repository: go
Issue: cmd/go: consider matching newly added _goos.go, _goarch.go or _goos_goarch.go suffixes based on go.mod go version (rather than Go toolchain version only)
Labels: Unfortunate,NeedsInvestigation,GoCommand


### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.16 darwin/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>
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/conrad/Library/Caches/go-build"
GOENV="/Users/conrad/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/conrad/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/conrad/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.16/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.16/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/conrad/superhuman/backend/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/vm/zrl4q9b56y76b3y_d7zspppr0000gn/T/go-build3563792657=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

### What did you do?

I upgraded to `go1.16` and ran `go test`.

### What did you expect to see?

No failures

### What did you see instead?

My build failed because I had a file called `send_log_ios.go`. In go before 1.16, this file was included in the build (because there was no ios build tag). In go 1.16 this file is excluded from the build because it assumed to match the `ios` build tag.

My `go.mod` still lists `go 1.15`.

This is not a problem for me (I can just rename the file), but I do think this is surprising and a breakage of the go1 compatibility promise – a program that used to build no longer builds because I upgraded my version of go.

I would propose that this change should only happen in module mode if I change the version in `go.mod`.
Repository: opencv
Issue: Green strip artifact on the frame by VideoCapture through Gstreamer applink
Labels: bug,category: videoio,category: 3rdparty

##### System information (version)
- OpenCV 4.5.1 
- Operating System / Platform => Ubuntu 18.04
- GStreamer 1.16.2


##### Detailed description
This issue is reported by [DL Streamer issue #155](https://github.com/openvinotoolkit/dlstreamer_gst/issues/155), customer uses applink with VideoCapture() to convert his video frame to his test code in Python, he got an green strip on top of the frame.

Since he uses GST VAAPI plugin as input, he also post an issue to gstreamer-vaapi
https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/issues/286

##### Steps to reproduce
Here is his test code:
https://hackmd.io/@b04505009/HyRj9qFID
https://hackmd.io/@b04505009/H1j-zUb5P

Mark
Repository: godot
Issue: New Lightmapper renders black textures with PanoramaSky EXR in GLES 2. Godot_v3.2.4-rc3_win64
Labels: bug,topic:rendering,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
Godot_v3.2.4-rc3_win64


**Issue description:**
New Lightmapper renders black textures when the Environment Background is set to PanoramaSky EXR. 

Issue appears to maybe only be present in GLES 2.

Setting LightMapper Environment to Custom Sky and loading the same PanoramaSky yields same result.

**Steps to reproduce:**
- Create project with GLES2
- Set Environment Background to PanoramaSky
- Set EXR as Image
- Set Environment in LightMapper to Scene.
- Bake :)

![bake_bug](https://user-images.githubusercontent.com/79685520/109271871-76761180-7853-11eb-8102-62008727b504.png)

 
**Minimal reproduction project:**
[BUG_Bake.zip](https://github.com/godotengine/godot/files/6048176/BUG_Bake.zip)
Repository: pytorch
Issue: LR Scheduler load_state_dict does not properly update scaling
Labels: module: optimizer,triaged

## 🐛 Bug

When using `load_state_dict` to update gamma in a LR scheduler, the LR scaling doesn't actually change, even though the state dict shows the new gamma.

## To Reproduce

```
from torch.optim.lr_scheduler import CyclicLR
scheduler1 = CyclicLR(optimizer, base_lr=0.01, max_lr=0.1, gamma=0.9)

scheduler2 = CyclicLR(optimizer, base_lr=0.01, max_lr=0.1, gamma=1)
scheduler2.load_state_dict(scheduler1.state_dict())

optimizer.step()
scheduler2.step()
print(scheduler2.__dict__)
optimizer.step()
scheduler2.step()
print(scheduler2.__dict__)
```

## Expected behavior
Each step of scheduler2 should show lr values approach a decay of 0.9 with each cycle. However, no decay occurs. Somehow, the gamma=1 value is retained in the scaling function, even though `scheduler2.state_dict()` shows the correct gamma=0.9 value. Switch the gamma values, and the 0.9x decay happens, when there should be no decay, demonstrating that it's a problem with `load_state_dict`, not just a gamma=1 default.

## Environment

 - PyTorch Version (e.g., 1.0): 1.7.1
 - OS (e.g., Linux): Ubuntu 20.04
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source): N/A
 - Python version: 3.8.6
 - CUDA/cuDNN version: N/A
 - GPU models and configuration: N/A
 - Any other relevant information:



cc @vincentqb
Repository: deno
Issue: Permissions checks should use canonical paths
Labels: permissions,suggestion

Currently permission checks only look at the paths they were provided which may be a symbolic link.
This allows you to escape the sandbox with symlinks which were just stabilized in https://github.com/denoland/deno/pull/9226

Most of the filesystem ops that deal with paths should *always* use the canonical path when checking permissions within the ops, the exception would be stat since there is an lstat and the link won't be followed later in the actual syscall.

There are other ways to we can go about it (capability based preopens with openat for example ala WASI), but not with our current permission model resolving to the true path is the way to go forward imho.

Related but without an actionable item https://github.com/denoland/deno/issues/2318.
Repository: go
Issue: cmd/compile: avoid unnecessary allocations for consecutive appends
Labels: Performance,NeedsInvestigation,compiler/runtime

go1.16

The following function will often incur two allocations, one for each `append` call.
However the compiler could potentially know the length of the extra data in advance
(len(f) + 4) and hence allocate at most once.

```
func appendFoo(x []byte, f string) []byte {
	x = append(x, "aggf"...)
	x = append(x, f...)
	return x
}
```

Working around this is awkward because to do that properly requires duplication of the `append` capacity-growing algorithm so that the slice will grow by a multiplicative rather than a constant factor. When generics arrive, I'd love to see a function like this in the standard library (that would be useful for #14325 amongst others), but the above optimization would still be useful to avoid using that.

```
// Grow returns ts with its capacity grown enough to accommodate n more items.
func Grow[T any](ts []T, n int) []T
```

Related issues:

- #14325 - this kind of optimization but with loops
- #25828 - when several append calls can be fused into one (not the case here)
- #37694 - relates specifically to arrays
Repository: flutter
Issue: [integration_test] mocking - Provide dataHandler/requestData
Labels: a: tests,c: new feature,framework,c: proposal,f: integration_test,P3,team-framework,triaged-framework

I could add mock data to my driver test, as described in this article https://medium.com/stuart-engineering/mocking-integration-tests-with-flutter-af3b6ba846c7
But in `integration_test` I use `tester` (WidgetTester) instead of `driver`, which doesn't have dataHandler. So how could I mock the test in this case?