sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Reparenting a bakedlightmap causes the engine to crash
Labels: bug,topic:rendering,confirmed,crash,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.1
6098a7f1914f64c77d689f54d5432095911b744f

<!-- Specify commit hash if non-official. -->

**OS/device including version:**
Windows 10 Pro 64-bit (10.0, Build 17134) (17134.rs4_release.180410-1804)
GeForce GTX 1070 with Max-Q Design/PCIe/SSE2
(plus Intel(R) UHD Graphics 630 which is disabled)
<!-- Specify GPU model and drivers if graphics-related. -->

**Issue description:**
<!-- What happened, and what was expected. -->
Generate a baked lightmap with baked textures and then try to move the lightmap into a spatial
```
	godot.windows.tools.64.exe!Object::call(const StringName & p_name, const Variant & p_arg1, const Variant & p_arg2, const Variant & p_arg3, const Variant & p_arg4, const Variant & p_arg5) Line 866	C++
 	godot.windows.tools.64.exe!BakedLightmap::_assign_lightmaps() Line 667	C++
 	godot.windows.tools.64.exe!BakedLightmap::_notification(int p_what) Line 645	C++
 	godot.windows.tools.64.exe!BakedLightmap::_notificationv(int p_notification, bool p_reversed) Line 91	C++
 	godot.windows.tools.64.exe!Object::notification(int p_notification, bool p_reversed) Line 954	C++
 	godot.windows.tools.64.exe!Node::_propagate_ready() Line 189	C++
 	godot.windows.tools.64.exe!Node::_set_tree(SceneTree * p_tree) Line 2557	C++
 	godot.windows.tools.64.exe!Node::_add_child_nocheck(Node * p_child, const StringName & p_name) Line 1154	C++
 	godot.windows.tools.64.exe!Node::add_child(Node * p_child, bool p_legible_unique_name) Line 1185	C++
 	godot.windows.tools.64.exe!MethodBind2<Node,Node *,bool>::call(Object * p_object, const Variant * * p_args, int p_arg_count, Variant::CallError & r_error) Line 1517	C++
 	godot.windows.tools.64.exe!Object::call(const StringName & p_method, const Variant * * p_args, int p_argcount, Variant::CallError & r_error) Line 942	C++
```
Tries to call `node->call("get_bake_mesh_instance")` when `node` is `NULL` (result of `get_node(light_data->get_user_path(i))`)
```
for (int i = 0; i < light_data->get_user_count(); i++) {
		Ref<Texture> lightmap = light_data->get_user_lightmap(i);
		ERR_CONTINUE(!lightmap.is_valid());

		Node *node = get_node(light_data->get_user_path(i)); // <- node is set to NULL here, i == 1

```
**Steps to reproduce:**
Open sample project, move `$BakedLightMap` node inside `$Spatial` 

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->

[baked_light_map_crash.zip](https://github.com/godotengine/godot/files/3109227/baked_light_map_crash.zip)
Repository: pytorch
Issue: [jit] nn.LSTM errors in nn.ScriptModule
Labels: oncall: jit,triaged

## 🐛 Bug

Torch script errors on nn.LSTM due to return type mismatch.

## To Reproduce

run the following:

```python
from __future__ import print_function
import torch

class TestModule(torch.jit.ScriptModule):
    def __init__(self):
        super(TestModule, self).__init__()
        self.rnn = torch.nn.LSTM(10, 20, 2)

    @torch.jit.script_method
    def forward(self, x, seq_len):
        return self.rnn(x[:seq_len])

onnx_path = "test.onnx"
model = TestModule()
max_seq_len = 10
seq_len = 3
torch_in = (torch.randn(max_seq_len, 1, 10), torch.tensor(seq_len))
torch_out = model(*torch_in)
torch.onnx._export(model, torch_in, onnx_path,
    verbose=True,
    operator_export_type=torch.onnx.OperatorExportTypes.ONNX,
    example_outputs=torch_out)
```

Error msg:

```
RuntimeError:
 expected value of type Tensor for return value but instead got value of type tuple.
Value: (tensor([[[ 0.0131, -0.0189, -0.0382, -0.0485, -0.0530,  0.0576, -0.0215,
          -0.0476,  0.0310, -0.0649,  0.0208,  0.0090,  0.0506, -0.0437,
          -0.0655, -0.0741, -0.0753,  0.0451,  0.0434,  0.0034]],

        [[ 0.0340, -0.0401, -0.0431, -0.0574, -0.0925,  0.1075, -0.0670,
          -0.0510,  0.0298, -0.1264,  0.0319,  0.0326,  0.0778, -0.0714,
          -0.1181, -0.0624, -0.1227,  0.0611,  0.0881,  0.0121]],

        [[ 0.0505, -0.0539, -0.0696, -0.0169, -0.0946,  0.1010, -0.0840,
          -0.0454,  0.0468, -0.1656,  0.0414,  0.0265,  0.0885, -0.0955,
          -0.1255, -0.0831, -0.1381,  0.0460,  0.0934, -0.0063]]],
       grad_fn=<StackBackward>), (tensor([[[ 0.0751, -0.0792,  0.1354, -0.1189,  0.0777,  0.1595,  0.0664,
           0.0679, -0.0291, -0.0530,  0.0622,  0.1268,  0.0217,  0.3393,
           0.0827, -0.0393,  0.0058,  0.1860, -0.1476, -0.0161]],

        [[ 0.0505, -0.0539, -0.0696, -0.0169, -0.0946,  0.1010, -0.0840,
          -0.0454,  0.0468, -0.1656,  0.0414,  0.0265,  0.0885, -0.0955,
          -0.1255, -0.0831, -0.1381,  0.0460,  0.0934, -0.0063]]],
       grad_fn=<StackBackward>), tensor([[[ 0.1532, -0.1940,  0.2310, -0.2605,  0.1665,  0.2493,  0.1354,
           0.3215, -0.1180, -0.1350,  0.3478,  0.3017,  0.0412,  0.5556,
           0.2099, -0.0888,  0.0103,  0.5196, -0.3361, -0.0461]],

        [[ 0.1015, -0.1073, -0.1859, -0.0310, -0.1853,  0.2024, -0.1587,
          -0.1042,  0.1006, -0.3469,  0.0950,  0.0528,  0.2027, -0.1976,
          -0.2762, -0.2110, -0.3665,  0.0898,  0.1874, -0.0121]]],
       grad_fn=<StackBackward>))):
operation failed in interpreter:
@torch.jit.script_method
def forward(self, x, seq_len):
    return self.rnn(x[:seq_len])
           ~~~~~~~~ <--- HERE
```

## Environment

PyTorch version: 1.0.1.post2
Is debug build: No
CUDA used to build PyTorch: None

OS: Mac OSX 10.14.5
GCC version: Could not collect
CMake version: version 3.12.2

Python version: 3.7
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA


cc @suo
Repository: flutter
Issue: Document the relationships of markNeedsSematicsUpdate/Layout/Paint
Labels: framework,d: api docs,c: proposal,P2,team-framework,triaged-framework
Repository: rust
Issue: False positive 'type parameter is never used' with struct
Labels: T-lang

Consider the following code snippet [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f59a38d253ea423eecea6ae445f618c3)

```rust
trait MyTrait<I> {}
trait SecondTrait {}

fn bar<A: MyTrait<B>, B: SecondTrait>() {}

struct MyStruct<A: MyTrait<B>, B: SecondTrait> {
    field: A
}
```
This procudes the error:

```
error[E0392]: parameter `B` is never used
 --> src/lib.rs:6:32
  |
6 | struct MyStruct<A: MyTrait<B>, B: SecondTrait> {
  |                                ^ unused type parameter
  |
  = help: consider removing `B` or using a marker such as `std::marker::PhantomData`
```

However, the parameter `B` is used - it's part of how we bound `A`.

The function and struct are equivalent in terms of generic parameters - since the equalivalent function compiles, the struct should as well.

Though this can be worked around via `PhantomData`, there's no reason to require using it. The struct definition is perfectly valid and useful, and should be useable without any workarounds.
Repository: go
Issue: x/build: TryBots should check go.mod files are tidy
Labels: Builders,NeedsInvestigation,modules

[CL 172972](https://go-review.googlesource.com/c/tools/+/172972) added a dependency on `golang.org/x/sync` in `golang.org/x/tools`. The go.mod and go.sum files were not updated.

There's nothing wrong with this dependency, but it should have been more noticeable during code review. If unexpected requirement were added to go.mod, human reviewers would see it.

TryBots should report an error if go.mod and go.sum change with `go mod tidy`. This will make sure dependency changes are explicit, and it will keep builds deterministic.
Repository: pytorch
Issue: [jit] Traced {zeros,empty}()/{zeros,empty}_like() calls do not respect device args.
Labels: oncall: jit,triaged

## 🐛 Bug


Tracing a call to `torch.{zeros,empty}_like(x)` produces a script module where the resulting allocation is always made on the same device as `x` was in the trace, not at runtime.

If the call is made in a function/method annotated with `@th.jit.script{,_method}` then everything works as expected.

In the case of `zeros(sizes, device=device)`, this is understandable since I can see that the passed non-tensor args (the device) would be considered constants for tracing, but in the case of zeros_like it is not obvious.

(sorry, not 100% sure this is a bug but the behavior isn't entirely expected. Perhaps a warning is warranted for traced `..._like(x)`?)

## To Reproduce

Simple test:
```python
import torch as th

def make_zeros(x):
    return th.zeros_like(x)

x = th.zeros(3)
func = th.jit.trace(make_zeros, (x,))

print(func(x).device)
x = th.zeros(3).cuda(0)
print(func(x).device)
x = th.zeros(3).cuda(1)
print(func(x).device)
```

1. Run the script above on a machine with 2 GPUs (comment out the last 2 lines for a single-GPU machine).

## Expected behavior
Code prints
```
cpu
cuda:0
cuda:1
```

Actual behavior:
Code prints
```
cpu
cpu
cpu
```

## 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): Nightly 20190423
 - OS (e.g., Linux): Linux (Fedora 29)
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Python version: 3.7
 - CUDA/cuDNN version: 10.0.130 / 7.4.2
 - GPU models and configuration: 2x Titan RTX
Repository: rust
Issue: `impl {Div,Mul,DivAssign,MulAssign}<{u16, u8}> for Duration` should also exist
Labels: T-libs-api,C-feature-request

Currently only `impl {Div,Mul,DivAssign,MulAssign}<u32> for Duration` exist, and there is no functional reason why the other implementations should not exist.
Repository: kubernetes
Issue: Create an integration test suite for dry-run sub-resources
Labels: priority/important-soon,sig/api-machinery,sig/cli,lifecycle/frozen

There is currently no integration test for dry-run sub-resources, which for example led to #76943. We have a test that goes over all the resources, we should probably have one that goes over all sub-resources too and make sure that it works.
Repository: TypeScript
Issue: Weird inference bug where a union is expanded with "never" in the position of generics
Labels: Needs Investigation

**TypeScript Version:**  3.5.0-dev.20190423

This code works in 3.3.4000 and is broken in 3.4.5

**Code**

```ts
function MyComponent({a, b}: {a: number; b: number}) {
  return a + b;
}

function test<Props>(
  _getComponent: () => Promise<(props: Props) => number | string>,
) {}

test(() => Promise.resolve({MyComponent}).then(m => m.MyComponent));
```

Of course this is a simplified example. The code I found this in uses React and lazy loading with `import()`.

**Expected behavior:** This example should pass type checking without any problems.

**Actual behavior:**

```
test.ts:9:12 - error TS2322: Type 'Promise<(({ a, b }: { a: number; b: number; }) => number) | ((props: never) => string | number)>' is not assignable to type 'Promise<(props: { a: number; b: number; }) => string | number>'.
  Type '(({ a, b }: { a: number; b: number; }) => number) | ((props: never) => string | number)' is not assignable to type '(props: { a: number; b: number; }) => string | number'.
    Type '(props: never) => string | number' is not assignable to type '(props: { a: number; b: number; }) => string | number'.
      Types of parameters 'props' and 'props' are incompatible.
        Type '{ a: number; b: number; }' is not assignable to type 'never'.

9 test(() => Promise.resolve({MyComponent}).then(m => m.MyComponent));
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  test.ts:6:18
    6   _getComponent: () => Promise<(props: Props) => number | string>,
                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The expected type comes from the return type of this signature.
```

Notably here the _actual_ type is inferred to be…

```
Promise<(({ a, b }: { a: number; b: number; }) => number) | ((props: never) => string | number)>
```

…which has an extra union variant…

```
(props: never) => string | number
```

…coming out of nowhere.

**Playground Link:**

You need to enable `strictFunctionTypes`.

http://www.typescriptlang.org/play/index.html#src=function%20MyComponent(%7Ba%2C%20b%7D%3A%20%7Ba%3A%20number%3B%20b%3A%20number%7D)%20%7B%0A%20%20return%20a%20%2B%20b%3B%0A%7D%0A%0Afunction%20test%3CProps%3E(%0A%20%20_getComponent%3A%20()%20%3D%3E%20Promise%3C(props%3A%20Props)%20%3D%3E%20number%20%7C%20string%3E%2C%0A)%20%7B%7D%0A%0Atest(()%20%3D%3E%20Promise.resolve(%7BMyComponent%7D).then(m%20%3D%3E%20m.MyComponent))%3B%0A
Repository: rust
Issue: Mismatched order of lifetimes between declaration and usage causes confusing errors
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler,D-confusing

This code works fine:

```rust 
struct Parser<'c, 's> {
    context: &'c &'s str,
}

impl<'c, 's> Parser<'c, 's> {
    fn parse(&self) -> &'s str {
        self.context
    }
}

fn parse_context<'s>(context: &'s str) -> &'s str {
    Parser { context: &context }.parse()
}

fn main() {
    parse_context("Available?");
}
```

If you swap the declaration order of the lifetimes, it breaks:

```rust
struct Parser<'s, 'c> {
```

```
error[E0515]: cannot return value referencing function parameter `context`
  --> src/main.rs:12:5
   |
12 |     Parser { context: &context }.parse()
   |     ^^^^^^^^^^^^^^^^^^--------^^^^^^^^^^
   |     |                 |
   |     |                 `context` is borrowed here
   |     returns a value referencing data owned by the current function
```

This seems like nonsense to me, so I'm declaring it a bug.
Repository: godot
Issue: Cannot scroll/pan/zoom with mousepad/trackpad in TextureRegion panel
Labels: bug,topic:editor,confirmed,usability

**Godot version:**
3.1.stable.official

**OS/device including version:**
OSX 10.14, Macbook Pro

**Issue description:**
Scrolling or zooming in TextureRegion panel with trackpad is impossible.
(spacebar+mouse-movement) works for panning around as a last resort, but the spacebar input toggles off the panel back to its minimized state. It becomes essencially impossible to select big regions using only mousepad.
Repository: pytorch
Issue: [docs] torch.set_flush_denormal(...) to mention default mode
Labels: module: docs,triaged

Currently the [torch.set_flush_denormal docs](https://pytorch.org/docs/stable/torch.html?highlight=set_flush_denormal#torch.set_flush_denormal) do not mention what is the default mode.

It would also be nice if they mentioned the FTZ / DAZ flags and a link to some reference page (like [intel's](https://software.intel.com/en-us/cpp-compiler-developer-guide-and-reference-setting-the-ftz-and-daz-flags)?) - like that this method would show up for google queries like `pytorch ftz`.

Also, a note on whether denormals are flushed [on GPU](https://devblogs.nvidia.com/cuda-pro-tip-flush-denormals-confidence/) would be helpful.
Repository: ant-design
Issue: Ant Design currently generates inaccessible forms. Blind people cannot use forms made by Ant Design.
Labels: Inactive,⌨️ Accessibility

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
A substantial percentage of the internet relies on screen readers (e.g. all blind people, many old people, etc.) - and having forms be easily read by them is critical. People who use screen readers currently *cannot* use forms generated by Ant Design. 

Considering how widely adopted And Design is, many people are trying to access Ant Design forms with screen readers daily - and currently, they can't read them. AntD has been advertised as an accessible platform, and accordingly - I hope that it is updated to make forms accessible. 

Here is a post with a lot more info (including screenshots of current problems): https://github.com/ant-design/ant-design/issues/16268

### What does the proposed API look like?
The proposed API would be the same as it is currently. However, the output would be very slightly different. All that's needed is 2 extra attributes per `<Form.Item/>` - e.g. `for` in label, and `id` in input. That's really all that's needed for all the Ant Design forms to become accessible!!

As an alternative, perhaps the top level `<Form />` can have an extra prop available called `accessible` that is a boolean, and when set to `true`, forms are made accessible. (personally, however, i think they should be accessible by default always).

-----------------------------------------
* [ ] Select
* [ ] Checkboxes
* [ ] Radio Buttons
* [ ] Datepicker
* [ ] Modal
* [ ] Menu

description ref: [comment](#issuecomment-486393323)


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: opencv
Issue: OpenCV CocoaPod maintainer wanted
Labels: category: infrastructure,platform: ios/osx,community help requested

Hi,

I'm listed as the maintainer of the [OpenCV CocoaPod](https://cocoapods.org/pods/OpenCV), however, I'm not able to actively maintain the pod. Does the OpenCV project or someone in the community want to take over the responsibility of maintaining it?
Repository: go
Issue: x/tools/cmd/goimports: -local adds local packages before external packages
Labels: NeedsInvestigation,Tools

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.2 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>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/raywu/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/raywu/go:/Users/raywu"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.2/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/v8/q5brnv35699835dr_mt01t0m0000gn/T/go-build432413042=/tmp/go-build -gno-record-gcc-switches -fno-common"
</pre></details>

### What did you do?

Use `goimports` to add missing `timeutil` import, which is our local package.

```go
package main

import (
        "fmt"

        "github.com/cespare/wait"
)

func main() {
        fmt.Println("asdf")
        var wg wait.Group
        wg.Wait()
        timeutil.MustParseRFC3339("2019-01-01T00:00:00Z")
}
```

### What did you expect to see?

```go
▶ cat abc.go | ~/goimports -local liftoff/
package main

import (
	"fmt"

	"github.com/cespare/wait"

	"liftoff/go/timeutil"
)

func main() {
	fmt.Println("asdf")
	var wg wait.Group
	wg.Wait()
	timeutil.MustParseRFC3339("2019-01-01T00:00:00Z")
}
```

### What did you see instead?

```go
▶ cat abc.go | ~/goimports -local liftoff/
package main

import (
	"fmt"

	"liftoff/go/timeutil"

	"github.com/cespare/wait"
)

func main() {
	fmt.Println("asdf")
	var wg wait.Group
	wg.Wait()
	timeutil.MustParseRFC3339("2019-01-01T00:00:00Z")
}
```
Repository: godot
Issue: Low physics FPS makes mouse wheel scrolling in GDScript inoperable after restarting the Editor
Labels: bug,topic:editor,confirmed,topic:gui

<!-- 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 non-official. -->
Godot 3.1

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
NVIDIA GeForce GTX 1070

**Issue description:**
<!-- What happened, and what was expected. -->
Higher Physics (tested with 700, but the number may be lower) FPS makes mouse wheel scrolling in GDScript inoperable after restarting the Editor

**Steps to reproduce:**
Create a new project
Project Settings > Physics > Common >Physics Fps > 700
Restart the Editor
Create new GDScript
Move cursor down, so you can scroll the script with the mouse wheel
But actually, you can't

*Bugsquad edit (keywords for easier searching): mousewheel*
Repository: pytorch
Issue: Importing matlab.engine after torch causes bad_alloc
Labels: module: internals,triaged,module: assert failure

## 🐛 Bug

## Importing matlab.engine after torch causes bad_alloc.

## To reproduce:

\>\>\> import torch
\>\>\> import matlab.engine
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

## Environment (from collect_env.py)

PyTorch version: 1.0.0
Is debug build: No
CUDA used to build PyTorch: 9.0.176

OS: Ubuntu 16.04.5 LTS
GCC version: (Ubuntu 5.5.0-12ubuntu1~16.04) 5.5.0 20171010
CMake version: version 3.7.2

Python version: 3.5
Is CUDA available: Yes
CUDA runtime version: 9.0.176
GPU models and configuration: GPU 0: GeForce GTX 1070
Nvidia driver version: 390.87
cuDNN version: Could not collect

Versions of relevant libraries:
[pip3] numpy==1.13.3
[pip3] pytorch-fft==0.15
[pip3] torch==1.0.0
[pip3] torchsummary==1.1
[pip3] torchvision==0.2.1
[conda] blas                      1.0                         mkl  
[conda] mkl                       2018.0.2                      1  
[conda] mkl-service               1.1.2            py27hb2d42c5_4  
[conda] mkl_fft                   1.0.1            py27h3010b51_0  
[conda] mkl_random                1.0.1            py27h629b387_0


## Additional context

matlab version: R2018a
It works well if I import matlab.engine first...
Repository: material-ui
Issue: [material-ui][docs] Fade (and other transition helpers) fails silently when children aren't able to receive the style prop
Labels: docs,component: transitions

## Expected Behavior 🤔
That the `Fade` component complains if it gets `children` that doesnt take the style prop. 

## Current Behavior 😯
If you give `Fade` an element that doesnt take and apply the `style` prop the `Fade` component does nothing.

See this codesandbox: https://codesandbox.io/s/n3z26zp6n0 There you can see the the component that returns a `React.Fragment` the root never fades but the one with a `div` does.

Here are some suggestions/thoughts/options:

- Validate that the element that it receives takes the `style` prop (via typescript types and/or prop-types)
- Receive a `Component` prop and render that instead of receiving an element and doing [cloneElement](https://github.com/mui-org/material-ui/blob/next/packages/material-ui/src/Fade/Fade.js#L57-L67). I think there is some problems typing react elements, see [this](https://gist.github.com/karol-majewski/ccd0ddbf97864afdd837dd8b1ddc993f)
- Output its own element (default to div and make it overridable?) to ensure that the style prop is applied
- Take a render function that receives the style and have the user apply the style props (and other logic depending on the transition state it gets in its own callback function).