sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: remove DropdownButton's minimum itemHeight on web
Labels: framework,f: material design,c: proposal,a: desktop,P2,team-design,triaged-design

<!-- Thank you for using Flutter!

     If you are looking for support, please check out our documentation
     or consider asking a question on Stack Overflow:
      * https://flutter.dev/
      * https://api.flutter.dev/
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     If you have found a bug or if our documentation doesn't have an answer
     to what you're looking for, then fill out the template below. Please read
     our guide to filing a bug first: https://flutter.dev/docs/resources/bug-reports
-->

## Use case
Flutter's Material `DropdownButton` has required minimum item height of `kMinInteractiveDimension`. It's impossible to set it to lower value, as the widget will crash due to `assert(itemHeight == null || itemHeight >=  kMinInteractiveDimension)` 

While this makes some sense on touchscreen devices (to prevent creating areas which would be hard to interact with), it makes absolutely no sense on the web.  

<!--
     Please tell us the problem you are running into that led to you wanting
     a new feature.

     Is your feature request related to a problem? Please give a clear and
     concise description of what the problem is.

     Describe the alternative solutions you've considered. Is there a package
     on pub.dev/flutter that already solves this?
-->

## Proposal
I propose to use `kIsWeb` to detect platform and remove the forementioned assert when runnting on the web platform. This would allow us to create dropdowns which look much more natural on this platform.

<!--
     Briefly but precisely describe what you would like Flutter to be able to do.

     Consider attaching images showing what you are imagining.

     Does this have to be provided by Flutter directly, or can it be provided
     by a package on pub.dev/flutter? If so, maybe consider implementing and
     publishing such a package rather than filing a bug.
-->
Repository: flutter
Issue: ExpansionTile doesn't allow maintaining the rotation on a custom trailing widget
Labels: framework,f: material design,a: quality,c: proposal,team-design,triaged-design

## Use case
I have custom icon assets in my project. I want to use one as a trailing for my ExpansionTile, but I want it to rotate on tap as the default one does.

Currently, `ExpansionTile` allows passing a widget to be used as trailing, which will replace the one that is created internally. The bad news is that there is no way to maintain the `RotationTransition` that the widget applies to the default widget. The transition cannot even be passed from the outside, as its implementation makes use of a private controller (see #27842). So it is either custom trailing or rotating default trailing.

## Proposal
Add an optional parameter of type `bool` to the widget, e.g. `rotateTrailing`, to request the rotation of the trailing. 

This decoupling of the widget from its rotation will allow creating an ExpansionTile with any of the following:
- a default trailing, rotating (previously supported);
- a default trailing, fixed (now supported);
- a custom trailing, fixed (previously supported);
- a default trailing, rotating (now supported).
Repository: TypeScript
Issue: Argument of type 'this' is not assignable to parameter of type 'NonNullable'?
Labels: Suggestion,Help Wanted,Effort: Difficult,Experimentation Needed

<!-- 🚨 STOP 🚨 STOP 🚨 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:**  4.0.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** 'this' is not assignable to 'NonNullable'


**Code**

```ts
abstract class TreeNode {
  parent: this | null = null; // polymorph this
  left: this | null = null;
  right: this | null = null;

  replaceChild(child: this, replacement: this | null = null) { // this - polymorph type
    this.left = child;
    this.right = replacement;
  }

  removeNode() {
    this.parent?.replaceChild(this, null); // ERROR
  }

  removeNode2Way() {
    if (this.parent) {
      this.parent.replaceChild(this, null); // OK
    }
  }
}

```

**Expected behavior:** 
Conditional call without errors.

**Actual behavior:** 
Error: Argument of type 'this' is not assignable to parameter of type 'NonNullable'

**Playground Link:** [Playground](https://www.typescriptlang.org/play?ts=4.0.3#code/IYIwzgLgTsDGEAJYBthjAgKlApjgcgPYAmOCA3gFAIIAOwuAdhAFwIQAWAlhgD4KMArsmQIAvAOHIA3AgD0c9twxo6hZAE8AtoSi0O7DbRzUEyHADNWSngn5CR4ySOmmoXAOYdrnW-alODjKUbji0qLA4AMLcyMQAFLCxxGy+YAA0CLjhcDhaOMypynbOohJBAJQUpjRpAHTmVk5JXHGyCjYqGLCCUEyIXIyQwIyRNZ117l6IEtkReQUQrjQAviE0uDoAbgQkOPFVVDS1ynX0-QD8k2HzMa0JaZmVywhrodu7pABMAOrAGgdqjQuBZ4vVzotDuNwQxFtccpE7nEwconlIKi81ljKEA)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: pytorch
Issue: ctx.save_for_backward doesn't save torch.Tensor subclasses fully
Labels: module: docs,module: autograd,triaged,enhancement,needs design,module: __torch_function__

## 🐛 Bug

Saving a torch.Tensor subclass with `ctx.save_for_backward` only saves the base Tensor. The subclass type and additional data is removed (object slicing in C++ terminology).

## To Reproduce

Following the [Extending PyTorch](https://pytorch.org/docs/stable/notes/extending.html) doc. `LoggingTensor` is copy-pasted from there.

```
import torch
import logging
class LoggingTensor(torch.Tensor):
    @classmethod
    def __torch_function__(cls, func, types, args=(), kwargs=None):
        # following line was changed from the documentation to avoid an infinite recursion because of __repr__
        logging.info(f"func: {func.__name__}")
        if kwargs is None:
            kwargs = {}
        return super().__torch_function__(func, types, args, kwargs)

class SquareFunction(torch.autograd.Function):
    @staticmethod
    def forward(ctx, x):
        print('forward x type',type(x),'x data_ptr',x.data_ptr())
        ctx.save_for_backward(x)
        y = torch.mul(x,x)
        return y

    @staticmethod
    def backward(ctx, grad_output):
        x, = ctx.saved_tensors
        print('backward x type',type(x),'x data_ptr',x.data_ptr())
        return 2*x*grad_output

lt = LoggingTensor(torch.rand((3,3)))
lt.requires_grad_(True)
y = SquareFunction.apply(lt)
y.backward(torch.ones_like(y))
assert(lt.grad is not None) # that works
```

## Expected behavior

I would expect the subclass type to be preserved.

Expected:
```
forward x type <class '__main__.LoggingTensor'> x data_ptr 1715819930816
backward x type <class '__main__.LoggingTensor'> x data_ptr 1715819930816
```

Current result:
```
forward x type <class '__main__.LoggingTensor'> x data_ptr 1715819930816
backward x type <class 'torch.Tensor'> x data_ptr 1715819930816
```

## Environment

```
Collecting environment information...
PyTorch version: 1.7.0
Is debug build: True
CUDA used to build PyTorch: 11.0
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 10 Enterprise
CMake version: version 3.18.0

Python version: 3.7 (64-bit runtime)
Is CUDA available: True

Versions of relevant libraries:
[pip] numpy==1.18.1
[pip] torch==1.7.0

[conda] blas                      1.0                         mkl
[conda] cudatoolkit               11.0.221             h74a9793_0
[conda] mkl                       2020.1                      216
[conda] mkl-service               2.3.0            py37hb782905_0
[conda] mkl_fft                   1.0.15           py37h14836fe_0
[conda] mkl_random                1.1.1            py37h47e9c7a_0
[conda] numpy                     1.18.1           py37h93ca92e_0
[conda] numpy-base                1.18.1           py37hc3f5095_1
[conda] pytorch                   1.7.0           py3.7_cuda110_cudnn8_0    pytorch
```


cc @hameerabbasi @rgommers @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @jlin27 @mruberry
Repository: create-react-app
Issue: Ability to override env vars from outside of application (container)
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

<!--
  Provide a clear and concise description of what the problem is.
  For example, "I'm always frustrated when..."
-->

I faced the issue that there is no standard way to override env vars which a react app uses on the Docker container startup a step. 
Example:
1. My app uses `REACT_APP_API_URI` env var which stores the path to back-end API. 
2. On CI pipeline I have a `build` step which builds my js code to a compressed production version.
3. After that in another CI step (let's say `docker-build`) I use compressed code from the previous step to build a lightweight Nginx-based docker container.
4. Now I have two environments`Staging` and `Production`. Of course, each environment has its own backend with a different API URI. So, I want to run two instances of the **same container** but with different REACT_APP_API_URI env var:
```
// On Staging env:
docker run -p 8080:8080 -e REACT_APP_API_URI =http://staging.api.example.com my-container:latest

// On Production env:
docker run -p 8080:8080 -e REACT_APP_API_URI =http://api.example.com my-container:latest
```

But it is will be impossible to do because JS code are already built.  

It's the only way to do a similar (but not the same) thing is to set `REACT_APP_API_URI` var on `build` CI step. But, in this case, the value will be `compiled` into docker container and I will not be able to override it by passing `-e` option to `docker run` command. 

To somehow deal with it I have to build two actually the same containers but with different `REACT_APP_API_URI ` values but it is not convenient and violates actually [12 factors app](http://12factor.net/) principles. 

I solved this problem by the way described in this article: https://www.freecodecamp.org/news/how-to-implement-runtime-environment-variables-with-create-react-app-docker-and-nginx-7f9d42a91d70/. 

The solution from the article gave me only **one** container and the possibility to override env variables by using `-e` option.


### Describe the solution you'd like

<!--
  Provide a clear and concise description of what you want to happen.
-->

Why you can't just add some similar functionality in form of a build option, plugin, or probably official tool which gives us a standard way to override env vars from outside?

### Additional context

<!--
  Is there anything else you can add about the proposal?
  You might want to link to related issues here, if you haven't already.
-->

I'm not a frontend developer, so sorry if I'm missing something
Repository: PowerToys
Issue: [Color Picker] if you scroll in on the edge of the display, half of the pixel window is not visible.
Labels: Issue-Bug,Needs-Repro,Priority-2,Product-Color Picker,Planning-Consideration

<!--
**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.
-->

## ℹ Computer information

- PowerToys version: 0.25.0
- PowerToy Utility: Color Picker
- Running PowerToys as Admin: No
- Windows build number: 1909 (Build 18363.1139)

## 📝 Provide detailed reproduction steps (if any)

1. Open the color picker PowerToy
2. Move the cursor to the edge of the display
3. Scroll to zoom in

### ✔️ Expected result

I would expect the edge of the window to be the constraint of the pixel window, like how the HEX text window does on the right edge of the display

### ❌ Actual result

Half of the pixel window goes off of the display

## 📷 Screenshots

_Are there any useful screenshots? WinKey+Shift+S and then just paste them directly into the form_

![image](https://user-images.githubusercontent.com/35050901/97723408-c1486e00-1a99-11eb-867a-57a450e55fbf.png)
Repository: create-react-app
Issue: Cannot read property 'range' of null
Labels: stale,needs triage,issue: bug report

<!--
    Please note that your issue will be fixed much faster if you spend about
    half an hour preparing it, including the exact reproduction steps and a demo.

    If you're in a hurry or don't feel confident, it's fine to report bugs with
    less details, but this makes it less likely they'll get fixed soon.

    In either case, please use this template and fill in as many fields below as you can.

    Note that we don't provide help for webpack questions after ejecting.
    You can find webpack docs at https://webpack.js.org/.
-->

After updating CRA to 4.0.0 **Can not read property 'range' of null error is thrown**, Could anyone help how to resolve this?
Thanks in advance
Repository: godot
Issue: Normals are incorrect when applying a blendshape to a skinned mesh
Labels: bug,topic:rendering,confirmed,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.2.3.Stable


**OS/device including version:**
Windows 10 Pro v.2004 / Inspiron 7373 Core i7-8550U / Intel(R) UHD Graphics 620


**Issue description:**
Normals are incorrect when applying a blendshape to a skinned mesh. This is a glTF imported model. I tried to compare to an fbx file to see if it was an import issue, but the blendshapes don't seem to affect the normals at all on fbx imported models.
![image](https://user-images.githubusercontent.com/4955051/97737352-c8d93880-1ad4-11eb-85b7-30b17d003a6b.png)


**Steps to reproduce:**
Open attached project and observe the normals when applying the blendshape


**Minimal reproduction project:**
[glTF_blendshape_normal.zip](https://github.com/godotengine/godot/files/5466650/glTF_blendshape_normal.zip)


**EDIT: I added details about this being a glTF model in description**
Repository: godot
Issue: Skinned meshes with blendshapes do not render on Android using GLES3
Labels: bug,platform:android,topic:rendering

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.2.3.Stable


**OS/device including version:**
Windows 10 Pro v.2004 / Inspiron 7373 Core i7-8550U / Intel(R) UHD Graphics 620


**Issue description:**
Skinned meshes with blendshapes do not render on Android. Issue was the same using glTF files and FBX files. I currently only have access to one android device. It is a Galaxy S6 running android 7.0. Using GLES3.
![image](https://user-images.githubusercontent.com/4955051/97739001-16ef3b80-1ad7-11eb-9bc4-0af4722a5a7a.png)
![image](https://user-images.githubusercontent.com/4955051/97738926-f626e600-1ad6-11eb-9cc1-190e2f0b7bd3.png)


**Steps to reproduce:**
Open the attached project and try to run it on an android device.


**Minimal reproduction project:**
[glTF_skinned_blendshape_no_render.zip](https://github.com/godotengine/godot/files/5466748/glTF_skinned_blendshape_no_render.zip)
Repository: pytorch
Issue: AMP doesn't gracefully handle optimizers for disabled regions
Labels: needs reproduction,triaged,module: amp (automated mixed precision)

## 🐛 Bug

When we have optimizers for multiple parts of the networks and one such part has the amp context disabled through     `@torch.cuda.amp.autocast(enabled=False)` the optimizer for that part will error out with `AssertionError: No inf checks were recorded for this optimizer.`

## To Reproduce

Create a VAE and have the code processor (where we split into mean and logvar, do the reparameterization trick, generate the z) set to `@torch.cuda.amp.autocast(enabled=False)` and dedicate an optimizer to it. If you follow the multi optimizer example the code will error out.

## Expected behavior

Allow the scaler to check if amp is active for those variables and if not, to not error out in regards to the inf checks.

## Environment
 - PyTorch Version (e.g., 1.0): 1.6
 - OS (e.g., Linux): Ubuntu 18.04
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source): N/A
 - Python version: 3.6
 - CUDA/cuDNN version: 11/7.6
 - GPU models and configuration: Titan V


cc @mcarilli @ptrblck @leslie-fang-intel @jgong5
Repository: create-react-app
Issue: npm run eject command run successfully completed, but when it complete i got some errors.
Labels: stale,needs triage


![e](https://user-images.githubusercontent.com/55888307/97746327-5ab46600-1b14-11eb-89d7-b3b9a6d81ec7.png)
Repository: flutter
Issue: Make tests compile and run faster
Labels: a: tests,framework,c: performance,c: proposal,perf: speed,P2,team-framework,triaged-framework

# Use case
According to [flutter.dev](https://flutter.dev/) one of the things flutter aims at is fast development. I think being able to develop in a TDD workflow contributes to this goal.

In our case, we have suite about 500 tests, consisting of unit and widget tests. In order to facilitate a real TDD workflow, all the tests should run very fast. There are some sources that suggest a maximum executing time of less than 10s: https://blog.ploeh.dk/2012/05/24/TDDtestsuitesshouldrunin10secondsorless/#:~:text=The%20test%20suite%20you%20work,be%20faster%20than%2010%20milliseconds.

Currently, our test suite is executing in about **2min**, which makes the TDD approach very hard, because it disrupts your workflow (better described in the article).

# Proposal

The aim of this ticket is more to collect all the tickets, that would contribute to a better TDD experience. So please add additional things that prevent you from a good TDD experience.

## Live Unit Testing
https://github.com/flutter/flutter/issues/4719
https://github.com/Dart-Code/Dart-Code/issues/2878

## Improve Performance of Tests
https://github.com/flutter/flutter/issues/17130
https://github.com/dart-lang/sdk/issues/32953

## Hot Reload for Unit Tests
https://github.com/flutter/flutter/issues/25973
https://github.com/szotp/hottie/

Please consider 👍 this and linked tickets if you thing this is important.
Repository: TypeScript
Issue: Typescript refactoring ignores contextual `this` in objects nested in classes
Labels: Bug,Domain: Refactorings

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->
vscode 1.50.1
ts4.0.3 & ts4.1.0-dev.20201029

```ts
class Foo {
	o: object;
	constructor() {
		this.o = {
			bar() {
				return 1 + 1;
			},
		};
	}
}
```
Refactoring options in `o.bar` include extraction into a method in `Foo`, which is not accessible through the contextual `this`
Expected refactoring options to not include solutions that break code

![Code_2020-10-30_17-45-02](https://user-images.githubusercontent.com/30108880/97733455-2458f580-1ad8-11eb-936c-7da8c59f4e87.png)

![Code_2020-10-30_17-45-13](https://user-images.githubusercontent.com/30108880/97733462-27ec7c80-1ad8-11eb-9cd5-acb141e58c10.png)
Repository: rust
Issue: repr(transparent) should not consider non_exhaustive types as 1-ZSTs outside their crate
Labels: T-lang,E-help-wanted,E-medium,C-bug,A-repr

In crate A:
```rust
#[non_exhaustive]
pub struct UnitType {}
```
In crate B:
```rust
#[repr(transparent)]
pub struct TransparentThing(i32, UnitType);
```

I expected that to fail in crate B, because the reason crate A put `#[non_exhaustive]` on the type was to allow it to get additional fields in the future, which would no longer allow it to work in `repr(transparent)`.

But this actually compiles today, creating what I would consider an accidental semver hazard.

https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Stability.20of.201-ZSTness/near/215120408

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: [Bullet] Box collision with Sphere not reported if sphere bounce is >0
Labels: bug,confirmed,topic:physics,topic:3d

**Godot version:**
3.2.3.stable

**OS/device including version:**
Manjaro 20.1.2

**Issue description:**
`body_entered` signal is not called when the box collides with the sphere. `continuous_cd=true`, `contacts_reported=999`, `contact_monitor=true` for both Player and Asteroid

![o](https://user-images.githubusercontent.com/14253836/97764649-60428980-1add-11eb-901f-8707554c7ab9.gif)


**Steps to reproduce:**
Run the MRP and watch the bodies collide, and note that nothing is printed in the console
Change Asteroid->physics_material_override->bounce to 0 and note that the body name is printed this time.

**Minimal reproduction project:**
[TestStable.zip](https://github.com/godotengine/godot/files/5468106/TestStable.zip)
Repository: godot
Issue: A KinematicBody2D can push another KinematicBody2D through a moving one-way collision platform
Labels: bug,confirmed,topic:physics

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
Godot 3.2.3-stable

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 8, Geforce 840M, GLES3

**Issue description:**
<!-- What happened, and what was expected. -->
A KB2D jumping over another KB2D that is on a moving platform with one-way collision as true causes the latter KB2D to falls off from the platform.

** The moving platform is also a KB2D.

** I confirm that https://github.com/godotengine/godot/pull/42574 does not fix this bug.

**The moving platform with one-way collision as true:**
On the right side the KB2D does not fall, cause it is over a StaticBody2D platform, even with one-way collision as true.

![one-way-movingPlatform1](https://user-images.githubusercontent.com/25422687/97768316-e7552900-1b00-11eb-93cf-bc0af3ee6867.gif)


**The moving platform with one-way collision as false:**

![one-way-movingPlatform2](https://user-images.githubusercontent.com/25422687/97768320-eb814680-1b00-11eb-9388-92e79e7bf4a3.gif)


**Steps to reproduce:**
Create a moving platform with one-way collision as true, put a KB2D to jump over another KB2D on that moving platform.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->

[KinematicMoving-one-way-movingPlatform.zip](https://github.com/godotengine/godot/files/5468353/KinematicMoving-one-way-movingPlatform.zip)