sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Gizmo x-ray mode only works for last selected node
Labels: enhancement,topic:editor,usability

**Godot version:**
Tested in
v4.0.dev.custom_build.b6f381475
v.3.2.3.stable

**OS/device including version:**
Windows 10, tried on both GLES3 and Vulkan

**Issue description:**
Turning on x-ray mode for gizmos only works for the last selected node. It's tooltip says "Half-open eye: Gizmo is also visible through opaque surfaces ("x-ray").", so it doesn't sound like it's the intended behavior. If it is the intended behavior, it should probably be documented better.

**Steps to reproduce:**
Turn on x-ray mode for a gizmo, in the View->Gizmos menu. x-ray mode will only work properly (showing above other objects) for the node selected last.

https://user-images.githubusercontent.com/12120644/119562374-41a32900-bd74-11eb-84f8-f39b7dc3fa8a.mp4

**Minimal reproduction project:**
[TestingGizmoXRayMode.zip](https://github.com/godotengine/godot/files/6542141/TestingGizmoXRayMode.zip)
Repository: go
Issue: cgo: use of libc's backtrace from a C++ signal handler invoked for Go code crashes on ppc64le
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
tip

</pre>

### Does this issue reproduce with the latest release?
yes



This original failure is documented here https://github.com/cockroachdb/cockroach/issues/62979

I'm opening this issue to get some feedback on this problem and possible solutions. I know there have been other problems reported in the community related to cgo stack unwinding and this falls into that category. 

In this case there is a problem because there is a C++ signal handler which calls backtrace from libc, and the interrupt can happen in Go or non-Go code. The code where this feature was added can be found here https://github.com/cockroachdb/cockroach/commit/957b4bdf2f41b3889b7730405e7986e23d74d103.

The call to backtrace gets a SEGV on ppc64le which is not unexpected since backtrace expects the stackframe to contain the backchain pointer (according to the PPC64 ABI). But since Go doesn't maintain the backchain pointer, when backtrace tries to unwind the stack it eventually tries to use something as a pointer which is not a pointer and SEGVs.

I've seen several other issues related to unwinding stacks with cgo, and in particular one that mentions the use of cgosymbolizer by as a solution. It seems like cgosymbolizer could be used in this case from within a signal handler to give the desired stack information when Go code is involved.

@ianlancetaylor @cherrymui Does this seem like a possible solution, to create a Go signal handler which could then use cgosymbolizer to dump the stacks? 
@pmur
Repository: pytorch
Issue: Use PYTHONHASHSEED during pytorch build to avoid nondeterminism
Labels: module: build,triaged,enhancement,module: determinism,module: codegen

In a recent commit, I inadvertently introduced a bit of non-determinism into the codegen output, which [caused ccache to stop working effectively during builds](https://github.com/pytorch/pytorch/issues/58796) - the output of the codegen was slightly different each time, so `ccache` required that the entirely build be re-run.

Another line of defense to shield against non-determinism in the codegen (and the build in general) is to use python's [supported PYTHONHASHSEED env variable](https://docs.python.org/3.3/using/cmdline.html#envvar-PYTHONHASHSEED) during builds, which ensure that things like string hashes in python always give a deterministic value during the build process. That probably won't prevent 100% of non-determinism bugs, but it would have stopped the specific issue above. See the discussion [here](https://github.com/pytorch/pytorch/pull/58889#issuecomment-848177669).


cc @malfet @seemethere @walterddr @mruberry @kurtamohler
Repository: excalidraw
Issue: Wrap shape menu items on mobile
Labels: discussion

On mobile the shape menu is super-vertical taking up most of the screen (1). I suggest we wrap the items (2) to make the menu take less space so that you can interact with the canvas more easily.

![image](https://user-images.githubusercontent.com/5153846/119565949-dfb1e600-bdaa-11eb-84ae-b5c98fec9d29.png)
Repository: material-ui
Issue: Added non-passive event listener to a scroll-blocking 'touchstart' event
Labels: new feature,component: slider

Maybe there is some chrome update but I started seeing this warning in chrome for slider.

- [x] The issue is present in the latest release.
- [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.

## Current Behavior 😯

Well I see this warning on pages with slider, even on docs slide page:
https://material-ui.com/components/slider/

## Expected Behavior 🤔

Do not want see it, it makes me nervous. Filtering Verbose level out from chrome console will not help - I will know it's still there, just hidden.
Actually I suspect some more related to slider issues, but cannot proof it's not my fault yet.

## Steps to Reproduce 🕹

Steps:

1. Open [components/slider](https://material-ui.com/components/slider/) docs
2. Open browser console
3. See this:
![image](https://user-images.githubusercontent.com/6861317/119565864-c7da6200-bdaa-11eb-9dab-b27f6112680c.png)

## Context 🔦

In my case I am trying to use slider+input field combination same as one of examples in the docs
I am having strange issues but they probably not related, not sure yet, so fixing this chrome warning itself is already good thing.

## Your Environment 🌎

<details>
  <summary>`npx @material-ui/envinfo`</summary>
  
```
  System:
    OS: Linux 5.11 Ubuntu 21.04 (Hirsute Hippo)
  Binaries:
    Node: 14.17.0 - ~/.nvm/versions/node/v14.17.0/bin/node
    Yarn: Not Found
    npm: 6.14.13 - ~/.nvm/versions/node/v14.17.0/bin/npm
  Browsers:
    Chrome: 90.0.4430.212
    Firefox: 88.0.1
  npmPackages:
    @material-ui/core: ^4.11.4 => 4.11.4 
    @material-ui/lab: ^4.0.0-alpha.58 => 4.0.0-alpha.58 
    @material-ui/styles:  4.11.4 
    @material-ui/system:  4.11.3 
    @material-ui/types:  5.1.0 
    @material-ui/utils:  4.11.2 
    @types/react:  17.0.2 
    react: ^17.0.1 => 17.0.1 
    react-dom: ^17.0.1 => 17.0.1 
    
```
</details>
Repository: youtube-dl
Issue: Use existing files for merging
Labels: request

When one of the files (315 or 251) were downloaded before this command returns an error:
```
youtube-dl -f 315+251 https...
...has already been downloaded and merged
```
It would be nice if `youtube-dl` used existing files for merging.
Repository: bitcoin
Issue: Fuzzer enhancement: Explicitly check output for uninitialized memory
Labels: Brainstorming,Tests

**Is your feature request related to a problem? Please describe.**

Both MemorySanitizer and Valgrind will only detect uninitialized memory if it is used for branching or IO.

E.g. the following program performs a computation using an uninitialized variable (`a`) but this won't trigger MSAN/Valgrind:

```c
int main(void)
{
    int a; int b = a + 10;
    return 0;
}
```

**Describe the solution you'd like**

Call 

```c
extern "C" void __msan_check_mem_is_initialized(const volatile void *x, size_t size);
```

on the data to make MSAN evaluate it.

**Describe alternatives you've considered**

Alternative solution that also works with Valgrind: write the data to `/dev/null`:

```c
#include <stdio.h>

int main(void)
{
    int a; int b = a + 10;
    FILE* fp = fopen("/dev/null", "wb");
    fwrite(&b, sizeof(b), 1, fp);
    fclose(fp);
    return 0;
}
```

**Additional context**

Proposal: Create a wrapper for `__msan_check_mem_is_initialized` (as a C++ method), e.g.:

```cpp
void TestMsan(const void* data, const size_t size) {
   __msan_check_mem_is_initialized(x, size);
}
```

And use overloaded methods for special types, e.g.

```cpp
void TestMsan(const std::string& s) {
   TestMsan(s.data(), s.size());
}
```

Then edit all fuzzer harnesses and call `TestMsan` with the output of each non-void method.

E.g. the [parse_script harness](https://github.com/bitcoin/bitcoin/blob/860093401840d7aad7b439aeba0d1598933bc9c6/src/test/fuzz/parse_script.cpp) would become:

```cpp
// Copyright (c) 2009-2020 The Bitcoin Core developers
// Distributed under the MIT software license, see the accompanying
// file COPYING or http://www.opensource.org/licenses/mit-license.php.

#include <core_io.h>
#include <script/script.h>
#include <test/fuzz/fuzz.h>

FUZZ_TARGET(parse_script)
{
    const std::string script_string(buffer.begin(), buffer.end());
    try {
        TestMsan(ParseScript(script_string));
    } catch (const std::runtime_error&) {
    }
}
```

The same concept can be applied to the unit tests.
Repository: TypeScript
Issue: Harden response delivery to ensure services is consistent with server
Labels: Infrastructure,Domain: TSServer,Rescheduled

Spoke with @andrewbranch 

> If you \[add] a member to any `protocol.*Response`, there's a significant chance that your fourslash tests \[will] work but it \[won't] actually work over the TS Server because `session.ts` picked apart the response in the process of converting positions to line/character and didn't know to put it back

How could we fix it?

> Destructuring with an object rest instead of requiring session.ts to name every property it wants to preserve
Repository: terminal
Issue: SetConsoleWindowInfo doesn't scroll visible region in Terminal
Labels: Area-Input,Issue-Bug,Product-Terminal,Priority-2

### Windows Terminal version (or Windows build number)

1.9.1445.0

### Other Software

Yori (but only as a means to disable quickedit and call ReadConsoleInput, you might have something better)

### Steps to reproduce

1. Ensure quickedit is disabled, so mouse events are processed by the application.
2. Attempt to scroll the viewport with the mouse wheel.

### Expected Behavior

In conhost, using the mouse wheel when quickedit is disabled still moves the viewport transparently to the application.

This means that any TUI application wanting to implement mouse wheel logic itself is essentially forced to use CreateConsoleScreenBuffer/SetConsoleActiveScreenBuffer to ensure that the viewport has nothing to scroll.

### Actual Behavior

In Terminal, using the mouse wheel when quickedit is disabled notifies the program and does not move the viewport.

This means that any CLI application is forced to handle mouse wheel notifications and call SetConsoleWindowInfo as needed.  I don't even know if this works on Terminal (the documentation suggests it might not.)
Repository: pytorch
Issue: Improper use of quantization API for MHA should fail fast
Labels: oncall: quantization,triaged

Currently, direct quantization of a torch.nn.MultiheadAttention module is not supported via `torch.quantization.quantize_dynamic()` - a conversion must be performed first ([reference](https://gist.github.com/bhosmer/ef517d0774f2f10336b8140116fd6b62)). However, an erroneous attempt to quantize directly does not produce an error - instead, there's a silent failure to quantize certain layers, but the returned model is callable. There's no overt sign that something has gone wrong. See #58727 for full details.

A recent cleanup of `torch.nn` introduced a downstream error when scripting such an improperly quantized module, by rationalizing module names in a way that allowed the problematic quantization to go forward. The error is a vanilla TorchScript type error due to a naming collision and has no clues that would lead one back to the original problem without nontrivial sleuthing. Also, the error was reported by users, meaning the quantization API is in fact being inadvertently misused in this way. [Repro used to track down the issue here, derived from a bug report.](https://gist.github.com/bhosmer/ef517d0774f2f10336b8140116fd6b62)

In the short term we've reinstated the name difference that defeats quantization when the API is used improperly, restoring the original behavior. But a proper fix would be for `quantize_dynamic` (or something in the quantization API) to give the caller signal that an unsupported model has been specified.

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo
Repository: go
Issue: x/mobile: javac encoding error during build
Labels: NeedsInvestigation,mobile

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
1.14
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env

</pre></details>

### What did you do?

```
PWD=$WORK\java javac -d $WORK\javac-output -source 1.7 -target 1.7 -bootclasspath $ANDROID_HOME\platforms\android-30\android.jar common\Common.java common\Context.java common\DaqContext.java common\User.java go\Seq.java go\Universe.
java go\error.java
警告: [options] 源值7已过时, 将在未来所有发行版中删除
警告: [options] 目标值7已过时, 将在未来所有发行版中删除
警告: [options] 要隐藏有关已过时选项的警告, 请使用 -Xlint:-options。
common\User.java:36: 错误: 编码 GBK 的不可映射字符 (0xB9)
         * 鐢ㄦ埛鍚嶏紝鍙慨鏀?
                     ^
common\User.java:40: 错误: 编码 GBK 的不可映射字符 (0xB9)
         * 鐢ㄦ埛鍚嶏紝鍙慨鏀?
                     ^
```
<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
Repository: nvm
Issue: nvm_get_os return nothing on cygwin
Labels: OS: windows

After installing nvm in Cygwin successfully, I find that whenever I call `nvm install 14.0.0`, it will always download the source instead of the pre-build binary package.

I find that when I call `nvm_get_os` in Cygwin, it will return nothing while on my Mac it will return darwin. I think that's the reason why it fails on Cygwin.

However, by creating the following script to test
```bash
set -x

nvm_echo() {
  command printf %s\\n "$*" 2>/dev/null
}

nvm_get_os() {
  local NVM_UNAME
  NVM_UNAME="$(command uname -a)"
  local NVM_OS
  case "${NVM_UNAME}" in
    Linux\ *) NVM_OS=linux ;;
    Darwin\ *) NVM_OS=darwin ;;
    SunOS\ *) NVM_OS=sunos ;;
    FreeBSD\ *) NVM_OS=freebsd ;;
    OpenBSD\ *) NVM_OS=openbsd ;;
    AIX\ *) NVM_OS=aix ;;
    CYGWIN* | MSYS* | MINGW*) NVM_OS=win ;;
  esac
  nvm_echo "${NVM_OS-}"
}

nvm_get_os
```
It returns the right value. 

I am not sure if it is the problem of Cygwin or the nvm scirpt.

Software:
uname -a
CYGWIN_NT-10.0 XMN160 3.1.2(0.340/5/3) 2019-12-21 15:25 x86_64 Cygwin

nvm -v
0.38.0
Repository: rust
Issue: Properly handle cross-crate `SyntaxContext::root` and `ExpnId::root`
Labels: A-metadata,A-macros,T-compiler

I've started a discussion on Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Cross.20crate-hygiene.20roots) - there are some unresolved questions about how we want the general solution ('correct' cross-crate decoding of  and ) to work. However, it should be possible to make a hack that just fixes the problems for macros: when we're checking the span of a token for a foreign macro, fall back to the edition of that foreign crate if the  is  .

_Originally posted by @Aaron1011 in https://github.com/rust-lang/rust/issues/84429#issuecomment-847386966_
Repository: pytorch
Issue: First-class Java API
Labels: feature,triaged,oncall: java

## 🚀 Feature
Provide a first-class Java API that exposes PyTorch functionality in a Java-eque manner.

## Motivation

The Java ecosystem is huge. There are many developers clamoring to integrate PyTorch pipelines into their workflow but they are unable to do so due to the lack of an official Java API. 

## Pitch

https://github.com/bytedeco/javacpp-presets/tree/master/pytorch contains a quickly maturing Java binding that is easy to maintain. The author would be more than happy to work with you if you could offer some official backing.

## Alternatives

Use a generic python-java bridge (e.g. jpype) to interact with PyTorch. This isn't a good option because many Java developers do not code in Python nor are they interested in doing so.
Repository: terminal
Issue: Exclude Quake window from FancyZones
Labels: Help Wanted,Issue-Bug,Area-UserInterface,Product-Terminal,Issue-Task,Priority-3,Area-Windowing

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement

When I summon quake window while using FancyZones it snaps to the same zone where main terminal window is located.

### Started fresh terminal instance:
![image](https://user-images.githubusercontent.com/38136135/119612712-69eb6000-be26-11eb-8845-8bdd323538b9.png)

### Summoned quake window:
![image](https://user-images.githubusercontent.com/38136135/119612916-ad45ce80-be26-11eb-87b7-8682509da2b1.png)

To solve this problem I can exclude WindowsTerminal.exe from FancyZones, but this way I won't be able to manage regular terminal windows with FancyZones. It would be better if we could exclude only the quake window, but not the other ones.

# Proposed technical implementation details

As I understand, FancyZones uses application executable name for its Exclude rules (might be wrong, tho), thus it could be possible to create a separate executable for quake window, so we could exclude only this one. It's a dirty fix, but it can do the job if there is no other option.
Repository: TypeScript
Issue: Type inference for async generators
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

It would be amazing if typescript could infer types from async generators.
The following is valid javascript, thus, I think, it should be valid typescript and type of `x` should be inferred.
Today it fails with `Parameter 'x' implicitly has 'any' type.`

```
async function forever(x) {
  for await (const unused of x) {
    void unused;
  }
}

async function* test() {
  for (;;) {
    await something();
    yield;
  }
}

forever(test());
```

## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

async generator, async iterator, type inference, infer types

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

Treat type of `x` as "any async iterator would do" thus including any async generator function. 

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

My own use... forever/background (async) processes/

## 💻 Use Cases

Today, I need to type this explicitly, which is unnecessarily verbose.

In the long run, it would allow **composing** async functions same as type inference helps composing plain functions today.

I get it that type inference for async iterables/iterators/generators opens a huge can of worms, like:
* type narrowing, like #36687 or in this vein
* yield expression return type #36967
* generator yielded type #32523
Repository: vscode
Issue: Improve widget documentation
Labels: engineering

I should do a pass over our base widgets and document their public API:

- [x] Sash
- [x] Splitview
- [x] Gridview
- [x] Grid
- [ ] Listview
- [ ] List
- [ ] Index tree
- [ ] Object tree
- [ ] Data tree
- [ ] Async data tree
- [ ] Table
- [x] Highlighted label

cc @Tyriar