sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Python 3.8 Windows JIT test failure
Labels: oncall: jit,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

Error text:
```pytb
======================================================================
FAIL: test_unmatched_type_annotation (__main__.TestScript)
----------------------------------------------------------------------
RuntimeError: 
Number of type annotations (2) did not match the number of function parameters (1):
  File "test_jit.py", line 4302
            @torch.jit.script
            def invalid2(a):
                         ~~~...  <--- HERE
                # type: (Int, Int) -> Int
                return a + 2


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test_jit.py", line 4302, in test_unmatched_type_annotation
    def invalid2(a):
AssertionError: "def\ invalid2\(a\):\
\ \ \ \ \ \ \ \ \ \ \ \ \~\~\~\~\~\~\~\~\~\~\~\~\~\~\ <\-\-\-\ HERE\
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \#\ type:\ \(Int,\ Int\)\ \->\ Int\
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ return\ a\ \+\ 2" does not match "
Number of type annotations (2) did not match the number of function parameters (1):
  File "test_jit.py", line 4302
            @torch.jit.script
            def invalid2(a):
                         ~~~...  <--- HERE
                # type: (Int, Int) -> Int
                return a + 2
"
```
See https://app.circleci.com/jobs/github/pytorch/pytorch/4269821.

## To Reproduce

Steps to reproduce the behavior:

1. python test_jit.py
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

<!-- A clear and concise description of what you expected to happen. -->
Test pass

## Environment

Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```

 - PyTorch Version (e.g., 1.0): 8a5e21a
 - OS (e.g., Linux): Windows
 - How you installed PyTorch (`conda`, `pip`, source): source
 - Build command you used (if compiling from source): python setup.py build
 - Python version: 3.8
 - CUDA/cuDNN version: N/A
 - GPU models and configuration: N/A
 - Any other relevant information:

## Additional context

<!-- Add any other context about the problem here. -->


cc @suo
Repository: scrcpy
Issue: Change and listen to Window Position, Title, and Size while running
Labels: feature request

I would really like to know if there is a way to change window position, title, and size while the scrcpy already running (and/or connected to a device), and probably event listener based on console log.
For example:
console log output
```
event window-shown <x> <y> <width> <height> <is borderless>
event window-moved 90 90
event window-resized 800-600
event window-minimized
event window-maximized
event window-focused
event window-lost-focus
```
and console input during run time
```
--window-size 800 600
--window-position 0 0
--window-position auto
--window-title "Example Title"
--home
--back
--app-switch
--window-focus
--window-maximize
--window-minimize
--window-setborderless
--android get-battery-level
```
and probably some features that are executable while scrcpy already running
```
--fullscreen
--record "file.mp4"
```
Thank you.
Repository: pytorch
Issue: Allow range in dim argument of reducing operations such as sum
Labels: triaged,module: ux,function request,module: reductions

I am trying to sum a tensor over its first `n` axes, where `n` is a parameter I may not know in advance. Why something like the following doesn’t work?

```
v = torch.randn(100, 20, 10)
torch.sum(v, range(2))  # I would write range(n) here.
```

This gives an error:

```
TypeError: sum() received an invalid combination of arguments - got (Tensor, range), but expected one of:
 * (Tensor input, torch.dtype dtype)
      didn't match because some of the arguments have invalid types: (Tensor, range)
 * (Tensor input, tuple of names dim, bool keepdim, torch.dtype dtype, Tensor out)
 * (Tensor input, tuple of ints dim, bool keepdim, torch.dtype dtype, Tensor out)
```

However if I instantiate the range:

```
v = torch.randn(100, 20, 10)
torch.sum(v, list(range(2)))
```

Then it works. Typing `list(range(n))` everytime is inconvenient compared to just `range(n)`.

So please allow `range` arguments to `dim` parameter of reducing operations such as `sum`.

cc @heitorschueroff
Repository: godot
Issue: GI Probe Broken when using procedural meshes
Labels: bug,topic:rendering,confirmed,topic:3d

**Godot version:**
3.2b5

**OS/device including version:**
Windoze 10 / Ryzen 5 2600 / RX 5700 XT

**Issue description:**
GI probe is not properly calculating lighting for surfaces from an omni-light source (perhaps others, I've only tested the OmniLight) and is dependent on the orientation of the GI probe. It appears that the GI probe is baking incorrectly, causing lighting to be calculated wrong for the GI volume.

![brokengiprobe](https://user-images.githubusercontent.com/11559157/72530610-9059be00-3824-11ea-84a2-a76e0a0d065b.jpg)


Note that only half of the ceiling and the opposite half of the floor have light in the reflections of the sphere and capsule in this GIF as I move the light left/right: https://imgur.com/a/akCR71U

If I rotate the GI probe 45 degrees and re-bake then the issue occurs but at a 45-degree angle on the ceiling/floor, so it would appear to be specific to the GI probe baking. I'm surprised nobody has even noticed this because I first noticed it with beta 4 and just downloaded beta 5 to see if it was fixed yet.

The surfaces also appear to be depicting the incorrect GI probe lighting back onto themselves in tandem with the illumination from the OmniLight source, but this behavior seems normal - just not the lighting being gathered from the GI Probe itself.


**Steps to reproduce:**
Create GLES3 project, make a room out of cube MeshInstances with basic SpatialMaterials for walls/ceiling to have unique albedo color, set the MeshInstances to be used in baked lighting, create sphere MeshInstance with full metalic and zero roughness SpatialMaterial, add OmniLight, create GI probe encompassing entire room and bake, observe wrong room lighting reflected in sphere.

**Minimal reproduction project:**
Project is attached. Open the Spatial.tscn scene in the project and select the OmniLight, move it left/right and observe the incorrect ceiling/floor lighting reflecting in the sphere.
[BrokenGIProbeReflections.zip](https://github.com/godotengine/godot/files/4071609/BrokenGIProbeReflections.zip)
Repository: terminal
Issue: Open a new pane with the environment vars of the parent
Labels: Area-Settings,Product-Terminal,Issue-Task,Priority-3

> 
> > Just chiming in;
> > > _ (profile,working dir, environment var, etc)._
> > 
> > 
> > Anything about the _actual process_ on the other end is, in the general case, impossible to replicate. The connected process could be `ssh.exe`, whose environment variables and working directory have no bearing on the detectable environment and working directory from the terminal side. The same actually, weirdly enough, applies to WSL. It doesn't use "working directory" and it doesn't expose its environment variables to interested Windows processes in any way.
> > Powershell doesn't even _set_ the current working directory, so its directory can't be detected (!) either.
> 
> Was interested in this but seems like it's not going to happen. Just curious if something like 'start' in cmd can't work in terminal. Is this the case ?


> @zadjii-msft I'm trying to clone the current terminal into a new pane. I need the same environment var's etc carried over similar to how 'start' does it in cmd. I know it isn't currently possible but is there a temporary workaround?

_Originally posted by @Surya-06 in https://github.com/microsoft/terminal/issues/1756#issuecomment-575134471_
Repository: TypeScript
Issue: Using Array and Boolean in condition does not trigger a warning
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  3.8.0-dev.20200115

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** overlap boolean vs array condition

**Code**

```ts
function isAllowed() {
  const myCondition = false;
  if (myCondition === false) {
    return [];
  }

  return true;
}

if (isAllowed()) {
  // boolean and array will results in a "true" condition
  console.log('allowed');
} else {
  // never reached
  console.log('not allowed');
}
```

**Expected behavior:**
- Seeing a message saying something like `This condition can produce unexpected results since the types 'boolean' and 'array' have no overlap` (not really good but you get the idea)

**Actual behavior:**
I won't say that it's a bug, but something that could be improved. I know that it's valid javascript but this a bug in the code that should/could be prevented by Typescript 

- Typescript does not complain that comparing boolean and array can results in bad condition

**Already fixable by**
- It does complain if you write `if (isAllowed() === true)` but it's easy to not do it.

**Playground Link:** http://www.typescriptlang.org/play/?ts=3.8.0-dev.20200115&ssl=1&ssc=1&pln=15&pc=1#code/GYVwdgxgLglg9mABDAzgQQDYbgdwKYAmAFAJSIDeAUIohAilIgLYCeAwggTLAogLyIoAJxB4A3NWTBERVhzBceSPisEi8ZKjRpC8UEEKQBtALoSaAX0qTd+w4mABDDCnGUrlGNKKpM2fMQkmpJ0YChwGHgAdNgA5kQA5M7+hAkkEhaIeC54FCH0EdFxiWBwjMm4qenulEA
Repository: pytorch
Issue: Truncated normal distribution
Labels: module: distributions,feature,triaged

## 🚀 Feature

Implement truncated normal distribution.

## Motivation

A truncated normal distribution is useful as initializer of weights or when sampling from ReLU potentials. This has been requested before (https://github.com/pytorch/pytorch/issues/2129, https://discuss.pytorch.org/t/implementing-truncated-normal-initializer/4778/15, etc.).

Many packages have this: [scipy](https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.truncnorm.html), [matlab](https://www.mathworks.com/help/stats/prob.normaldistribution.truncate.html), [R](https://cran.r-project.org/web/packages/truncnorm/truncnorm.pdf), [julia](https://juliastats.org/Distributions.jl/stable/truncate/#Distributions.TruncatedNormal), [tensorflow](https://www.tensorflow.org/probability/api_docs/python/tfp/distributions/TruncatedNormal), and others.

cc @vincentqb @fritzo @neerajprad @alicanb @vishwakftw

Related: https://github.com/pytorch/pytorch/issues/31945
Repository: flutter
Issue: Convert android devicelab tests to use --fast-start where disabled
Labels: team,tool,P2,team-tool,triaged-tool

Several devicelab tests will have fast-start disabled (https://github.com/flutter/flutter/pull/48851/files) due to the different log messages breaking stdout parsing or other test assumptions. The tests will need to be investigated to determine what the fix is to remove the `--no-fast-start`.
Repository: react
Issue: Bug: DevTools DOM highlighting gets stuck after a prolonged hover
Labels: Type: Bug,Component: Developer Tools

## Steps To Reproduce

1. Hover a component in DevTools
2. *Keep hovering it for a second or so*
3. Quickly move the cursor out of the DevTools without hovering anything else

Expected: DOM highlighting goes away.
Actual: DOM highlighting gets stuck.

![](https://d1sz9tkli0lfjq.cloudfront.net/items/2o2r240l0o3i1B0d1n3J/Screen%20Recording%202020-01-16%20at%2005.14%20PM.gif?v=e1a91e13)
Repository: pytorch
Issue: [jit] Various problems calling `@staticmethod`s in 1.4.0
Labels: oncall: jit,triaged

## 🐛 Bug

Calling `@staticmethod` on a plain class from a `@torch.jit.script` annotated function fails to compile. I suspect that I'm seeing two separate bugs, so I could split this report up and file two issues if that's better.

## To Reproduce

```Python3
class Foo:
  @staticmethod
  @torch.jit.script
  def bar():
    return Foo.whiz()

  @staticmethod
  def whiz():
    return 1
```

Fails to compile, giving:

```
undefined value Foo:
  File "<ipython-input-14-eb049bac4455>", line 6
  @torch.jit.script
  def bar():
    return Foo.whiz()
           ~~~ <--- HERE
```

Splitting this up over two classes gives the same result:

```Python3
class Foo:
  @staticmethod
  @torch.jit.script
  def foo():
    return Bar.bar()

class Bar:
  @staticmethod
  def bar():
    return 1
```

```
undefined value Bar:
  File "<ipython-input-18-128b94e38eb4>", line 16
  @torch.jit.script
  def foo():
    return Bar.bar()
           ~~~ <--- HERE
```

My hypothesis in the second example is that it's trying to compile and resolve `Bar` immediately when `Foo` is defined, and unable to because `Bar` is defined after. That's inconvenient but makes sense, perhaps that's unfixable. Fixing it would appear to require some form of lazy compilation.

Presumably the first case is a subtler form of the same issue, where `Foo` isn't defined until after its methods are.

To test this hypothesis and attempt to work around this restriction, I tried manually deferring the compilation.

```Python3
class Foo:
  @staticmethod
  # @torch.jit.script
  def bar():
    return Foo.whiz()

  @staticmethod
  def whiz():
    return 1

torch.jit.script(Foo.bar)
```

This does avoid that error as expected, but gives another one. It gives back a long stack trace ending with a `TypeError: <module '__main__'> is a built-in class` in `inspect`.

To test this in another way, I tried swapping the class definition order of `Foo` and `Bar` in the second example above.

```Python3
class Bar:
  @staticmethod
  def bar():
    return 1

class Foo:
  @staticmethod
  @torch.jit.script
  def foo():
    return Bar.bar()
```

As `Bar` is now defined first I expected this to have the same result as manually deferring compilation and it does. It gives the same `inspect` `TypeError`.


These may be two completely separate issues, so let me know if you'd like me to split the `TypeError` off into a separate issue.

## Environment

`1.4.0`. Specifically, Google Colab with a fresh GPU runtime on which `!pip install -q torch==1.4.0 torchvision` has been run.

This might be related to #30755 [[jit] `@staticmethod`s retrieved from `self` don't work](https://github.com/pytorch/pytorch/issues/30755), so cc @suo @driazati, @suo
Repository: go
Issue: runtime: sysUsed often called on non-scavenged memory
Labels: Performance,NeedsFix,compiler/runtime

In working on #36507, I noticed that one source of regression on Darwin was that `sysUsed`, as of Go 1.14, is now called on the whole memory allocation, even if just one page of that is actually scavenged. This behavior was already present in Go 1.11, went away in Go 1.12, and is now back.

On systems where `sysUsed` is a no-op and we rely on the first access "unscavenging" the page, this has no effect, because we're already only unscavenging exactly what's needed. On systems like Darwin and Windows where the "recommit" step is explicit (i.e. `sysUsed` is not a no-op) this can have a non-trivial impact on performance, since the kernel probably walks over the unscavenged pages for nothing.

This contributed very slightly to the performance regression in #36218, but not enough to cause it to block the 1.14 release.

The fix here is straight-forward: we just need to lower the call of `sysUsed` in the page allocator where we have complete information over exactly which pages are scavenged. If a given allocation has >50% of its pages scavenged then we can probably just `sysUsed` the whole thing to save a bit on syscall overheads. This change also makes sense because we already do `sysUnused` at a fairly low-level part of the page allocator, so bringing `sysUsed` down there makes sense.
Repository: pytorch
Issue: [FR] histc should (optionally) return a long tensor
Labels: triaged,module: sorting and selection,function request

It always returns integral values. Similar op `bincount` also returns a long tensor (when no `weights` is given).

cc @heitorschueroff
Repository: pytorch
Issue: [FR] bincount along arbitrary dimension
Labels: triaged,module: sorting and selection,function request

It currently only accepts a 1D tensor. We should make it work along any dimension.

cc @heitorschueroff
Repository: terminal
Issue: Investigate include order issue with `InputBuffer`, `readData`
Labels: Product-Conhost,Help Wanted,Issue-Task,Area-CodeHealth,Priority-3

Found in #4213.

I had to fwddecl `InputBuffer`, because I _think_ there's a include order problem with in `InputBuffer.hpp` and `readData.hpp`.

`readData.hpp` uses `InputBuffer` in a bunch of places, but doesn't include it first

`InputBuffer.hpp` includes `readData.hpp` before it defines `InputBuffer`

So if you try to 
```c++
#include ".../host/inputBuffer.hpp"
```

You'll get a compilation error, because it'll include `readData`, which will assume `InputBuffer` is defined, which it isn't yet.
Repository: flutter
Issue: Include a keyboard dismissal callback in TextField
Labels: a: text input,c: new feature,framework,f: material design,c: proposal,P3,team-text-input,triaged-text-input

## Use case

When using `TextField`s in Flutter to prompt users for text input, I want to easily detect and react to the user dismissing the keyboard for the current field, via the dismissal button.

Though it is possible to write a wrapper around `TextField` that provides a new callback, based on listening directly to the keyboard dismissal, it would be more-convenient if Flutter provided this functionality out-of-the-box.

## Proposals

* Augment `TextField.onEditingComplete` to also be called whenever the user selects the dismissal button on the keyboard.
* Provide a new method, e.g. `TextField.onEditingStopped` to be called whenever the user selects the dismissal button on the keyboard.  This option would not be a breaking change.
Repository: TypeScript
Issue: Infer non returning function to be returning `undefined`, not `void`
Labels: Suggestion,In Discussion

## Search Terms
non returning, undefined instead of void, undefined or unknown instead of void
<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion
- Change return of non returning functions to `undefined` instead of `void`
- Accept `unknown` as a type of non returning functions
examples:
```ts
const f = () => {} // this gets inferred as () => void

const f1 = (): undefined => {} // doesn't work
// error: A function whose declared type is neither 'void' nor 'any' must return a value.(2355)

const f2 = (): unknown => {} // same error
```

https://www.typescriptlang.org/play/#code/MYewdgzgLgBAZjAvDAFASiQPhgbwL4CwAUMaJLHAIxKpoBcMArmACYCmcAlmGy1rjEIkiZaPABMNdA2YBrMCADuYfvmJA

## Motivations
`void` is an annoying type to deal with, has many inconsistencies and there's a ton of issues around it for its weird behavior like: #35850 , #35236 , #33420 ... etc
Non-returning functions actually return `undefined` which is a more predictable type to deal with and narrow disjunctions with and even use optional chaining with.

## Use Cases
Many use cases appear while using promises where there's a need to catch an error but at the same time not deal with `void`
```ts
const f = () => {}
async (p: Promise<A>) => {
  const a = await p.catch(f);
  // do stuff with a whose type is now A | void
};
```
<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Checklist

My suggestion meets these guidelines:

> * [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code

Not sure if this might break some code or not but I think any code that dealt with void should work while dealing with undefined?

* [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, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: terminal
Issue: Code Health: Consider disabling warning C26440
Labels: Product-Meta,Issue-Task,Area-CodeHealth

In one of the PRs I'm working on, I found I was getting errors from the audit mode build because it wanted me to declare certain methods as `noexcept` (warning [C26440](https://docs.microsoft.com/en-us/visualstudio/code-quality/c26440)). But the methods in question were calling the `std:array::at` method, which throws an exception, so I would have thought they couldn't be `noexcept`.

You can see an example of this in the `TerminalSettings::GetColorTableEntry` method:

https://github.com/microsoft/terminal/blob/a60ed520649920cc50167d58075e69302ccc5ce9/src/cascadia/TerminalSettings/TerminalSettings.cpp#L76-L79

It's calling `std:array::at`, so it clearly can throw an exception, but it's still declared as `noexcept`. And removing that `noexcept` will trigger above-mentioned error in the audit mode build.

So what is the recommended practice here? Do we just add `noexcept` to the method even though that's not actually true? Do we suppress the warning on a case by case basis? (Per function, or per compilation unit?) Or should we consider disabling the warning for the entire project, at least until it's more reliable?
Repository: flutter
Issue: [web] Improve api_conform_test.dart
Labels: engine,platform-web,c: proposal,P2,team-web,triaged-web

In the engine, we use [`web_sdk/test/api_conform_test.dart`](https://github.com/flutter/engine/blob/master/web_sdk/test/api_conform_test.dart) to keep the API surface of `dart:ui` implementations in sync (native and web).

Currently, we only check for classes, constructors, and public methods in classes. There are a few more things we should check for:

* Public top-level variables.
* Public top-level functions.
* Public enums and their values.

Also make sure in function signatures that we are checking for:
* Types of formal parameters.
* Default values of formal parameters.

cc @jonahwilliams @yjbanov did I miss anything?