sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: crypto: import fiat-crypto implementations
Labels: Proposal,Proposal-Accepted,Proposal-Crypto

The fiat-crypto project (https://github.com/mit-plv/fiat-crypto) generates formally-verified, high-performance modular arithmetic implementations, useful for crypto primitives like Curve25519, Poly1305, and the NIST ECC curves that are used within the Go standard library. They're currently working on a Go backend.

BoringSSL has imported their implementations for Curve25519 and P-256: https://boringssl.googlesource.com/boringssl/+/master/third_party/fiat/

At https://go-review.googlesource.com/c/crypto/+/242177, I've uploaded a WIP CL that imports their Curve25519 implementation (w/ minor tweaks), and demonstrates a significant performance improvement over the current "generic" implementation. (The existing amd64 assembly implementation is still considerably faster though.)

This proposal is to import and make use of those implementations.

Open questions:

1. Which algorithms should be imported? BoringSSL only imports two. Should we import more?

2. Do we import both 32-bit and 64-bit implementations? We could import just one implementation and still get a performance speedup (e.g., 386 sees a -10% performance boost with curve25519_fiat_64.go, and amd64 sees a -30% boost with curve25519_fiat_32.go), but they do better still with the CPU-appropriate implementations (-30% for 386 w/ 32-bit, and -61% for amd64 w/ 64-bit).

3. How should the code be imported? E.g., should it be separated into a third_party or vendor directory with its own LICENSE file like how BoringSSL does it?

/cc @agl @FiloSottile
Repository: go
Issue: x/image/webp: WebP decode contrast issue
Labels: NeedsInvestigation

# What version of Go are you using (`go version`)?
<pre>
go version go1.13.7 windows/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
set GO111MODULE=off
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Alpha\AppData\Local\go-build
set GOENV=C:\Users\Alpha\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Alpha\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\Alpha\AppData\Local\Temp\go-build034800510=/tmp/go-build -gno-record-gcc-switches
</pre></details>

### What did you do?

I opened up a webp using go, and saved it back to png, The output was different from the source. Other golang webp decoding packages parsed it correctly.

```go
package main

import (
	"image"
	"image/png"
	"os"

	// you can swap between these two libs, chai2010 is okay
	"golang.org/x/image/webp"
	//"github.com/chai2010/webp"
)

func main() {

	tileStream, _ := os.Open("full.webp")
	tile, _ := webp.Decode(tileStream)
	defer tileStream.Close()

	outputStream, _ := os.Create("full.png")
	png.Encode(outputStream, tile)

	defer outputStream.Close()
}
```

### What did you expect to see?

![b(1)](https://user-images.githubusercontent.com/8333794/87240839-924cb480-c436-11ea-97de-b0bf0f4566f9.png)

This is the source image, notice the details and the clarity.

### What did you see instead?

![full](https://user-images.githubusercontent.com/8333794/87240846-9c6eb300-c436-11ea-9299-20f99656d459.png)

This is the converted, the details are dimmed, the contrast is lower. Other webp decoding libs maintain the contrast.
Repository: material-ui
Issue: [theme] Remove hardcoded breakpoints
Labels: new feature,package: material-ui,design

<!-- Provide a general summary of the issue in the Title above -->
There are several places in the codebase where breakpoints are hardcoded.
Since we have the ability to override breakpoints, we should not have hardcoded values in the code
<!--
  Thank you very much for contributing to Material-UI by creating an issue! ❤️
  To avoid duplicate issues we ask you to check off the following list.
-->

<!-- Checked checkbox should look like this: [x] -->

- [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 😯

1. PropTypes
```javascript
PropTypes.oneOf(['xs', 'sm', 'md', 'lg', 'xl']),
PropTypes.arrayOf(PropTypes.oneOf(['xs', 'sm', 'md', 'lg', 'xl'])),
```
2. Styles
```javascript
[theme.breakpoints.only('xs')]: {
  ...
}
```
3. Functions in withWidth.js
```javascript
import { breakpointKeys } from '../styles/createBreakpoints';
function isWidthUp(...){ 
  return breakpointKeys.indexOf(...)
}
function isWidthDown(...){ 
  return breakpointKeys.indexOf(...)
}
```

## Expected Behavior 🤔
1. PropTypes
```javascript
PropTypes.string
PropTypes.arrayOf(PropTypes.string),
```
2. Styles

a) Use a media query only if there is such a breakpoint in the theme
```javascript
[theme.breakpoints.only(theme.breakpoints.keys['xs'] ?? 0)]: {
  ...
}
```

b) Add a new property `alias` to `createBreakpoints` function to match breakpoints
```javascript
createBreakpoints({
  values: {
      tablet: 640,
      laptop: 1024,
      desktop: 1280,
    },
    alias: {
      xs: 'tablet',
      sm: 'tablet',
    },
  }
})
```

3. Functions in withWidth.js
a) Show the necessity for breakpoints
Remove `import { breakpointKeys } from '../styles/createBreakpoints'`;
```javascript
function isWidthUp(breakpoints, breakpoint, width, inclusive = true){ .. }
```
b) Add breakpoints to options implicitly
```javascript
import { breakpointKeys } from '../styles/createBreakpoints'
function isWidthUp(breakpoint, width, opts = {}) {
  let {breakpoints = breakpointKeys, inclusive = true } = opts;
  ...
}
```


## Your Environment 🌎

<!--
  Include as many relevant details about the environment with which you experienced the bug.
  If you encounter issues with typescript please include version and tsconfig.
-->

| Tech        | Version |
| ----------- | ------- |
| Material-UI | v4.11.0  |
Repository: opencv
Issue: Memory allocation in Win/MacOS
Labels: feature,category: features2d

Win 10, OpenCV e3d502310f6ae0cad79f3474b9ea2b25705985f9.
MacOS 10.14.6.

This
````
std::shared_ptr<SIFT> sift = SIFT::create();
````
code throw exception 
````
OpenCV(4.4.0-pre) E:\Lib_prebuild\opencv\source\opencv\modules\core\src\alloc.cpp:73: error: (-4:Insufficient memory) Failed to allocate 13107200000 bytes in function 'cv::OutOfMemoryError'
````
in Windows, but works fine on the same PC in MacOS VBox.

At the time of running this code in Windows about 30 Gb RAM was free, and Windows was rebooted before run (so I think RAM was not fragmented).
10 GB RAM was provided for the MacOS virtual machine.
Processed image size is 32000 x 26500.

This exception also throws with SURF.
Repository: rust
Issue: Tracking Issue for raw slice getters (slice_ptr_get)
Labels: T-libs-api,B-unstable,C-tracking-issue,A-slice,Libs-Tracked,Libs-Small,A-raw-pointers

This is a tracking issue for indexing methods on raw slices: `get_unchecked(_mut)` and `as_(mut_/non_null_)ptr` on raw slices (mutable and const raw pointers and `NonNull`).

The feature gate for the issue is `#![feature(slice_ptr_get)]`.

### Public API

```rust
impl<T> *mut [T] {
    pub const fn as_mut_ptr(self) -> *mut T {}
    pub unsafe fn get_unchecked_mut<I>(self, index: I) -> *mut I::Output where I: SliceIndex<[T]>;
}

impl<T> *const [T] {
    pub const fn as_ptr(self) -> *const T {}
    pub unsafe fn get_unchecked<I>(self, index: I) -> *const I::Output where I: SliceIndex<[T]>;
}

impl<T> NonNull<[T]> {
    pub const fn as_non_null_ptr(self) -> NonNull<T> {}
    pub const fn as_mut_ptr(self) -> *mut T {}
    pub unsafe fn get_unchecked_mut<I>(self, index: I) -> NonNull<I::Output> where I: SliceIndex<[T]>;
}
```

### History / Steps

- [x] Initial PR: https://github.com/rust-lang/rust/pull/73986
- [x] Add `NonNull::as_mut_ptr`: https://github.com/rust-lang/rust/pull/75248
- [ ] Final commenting period (FCP)
- [ ] Stabilization PR

### Open questions

* Potential blockers: https://github.com/rust-lang/rust/issues/73987, https://github.com/rust-lang/rust/issues/74679
* Should this use `arbitrary_self_types` (https://github.com/rust-lang/rfcs/pull/3519)
Repository: godot
Issue: [Bullet] Bullet physics PhysicsDirectBodyState.get_total_gravity() returns Vector3(0, 0, 0) in the first physics frame.
Labels: bug,topic:physics

<!-- Please search existing issues for potential duplicates before filing yours:	
https://github.com/godotengine/godot/issues?q=is%3Aissue	
-->

**Godot version:**
Version 3.2.2 stable
<!-- Specify commit hash if using non-official build. -->


**OS/device including version:**
GPU: AMD RX 580 driver - 20.4.2
OS: Windows 10 10.0.18363
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->


**Issue description:**
This issue is physics related. In theory, adding a force equal to the weight of an object in the opposite direction of gravity should counteract the force of gravity, making it suspend in mid air.

However, in practice the objects gains a small but very noticeable upward velocity of 0.1633...
When this is done with using the `state.get_total_gravity()` to get the force to counteract gravity, everything works fine.

After printing both values (weight and total gravity's Y) their value is 9.8 and -9.8 respectively (for an object with mass 1)
The absolute values of these two variables are practically the same but they yield a different result.

<!-- What happened, and what was expected. -->


**Steps to reproduce:**
Create an object with a RigidBody call `add_central_force()` with it's weight as the Y value.
Notice how the objects gains a velocity of 0.1633...
Then do the same with but inside the `_integrate_forces()` call, using the negative of the `get_total_gravity()` as the counter force.
Notice how the object is stationary (as expected).


**Minimal reproduction project:**
[PhysicsExample.zip](https://github.com/godotengine/godot/files/4908366/PhysicsExample.zip)

<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: flutter
Issue: [google_maps_flutter] setMapStyle takes time to load, user is presented with blank map view 
Labels: p: maps,package,team-ecosystem,has reproducible steps,P2,found in release: 1.21,found in release: 2.0,found in release: 2.3,triaged-ecosystem

I'm using a custom map style for the Google Maps Flutter package.
Implemented with this code


```dart
  void _onMapCreated(GoogleMapController controller) {
    setState(() {
      _mapController = controller;
      _mapController.setMapStyle(_mapStyle).whenComplete(() {
        showMap = true;
      });
    });}
```

Current "problem" (more like an imperfection): the style is set after the map is loaded, so the user first gets a white screen, then the standard Google Maps style and after all that the custom style. This happens very fast, but there is a noticeable "flash". Especially when you're using a dark mode map style.

What I tried:
1. putting with Stack a black container on top of the google map widget (that' visible when showMap is set to false), so I can set the bool showMap to true if everything is loaded. Doesn't work because whenComplete get's fired when the setMapStyle is almost done (so there's still a flash). (tested in debug).


Solutions I could think of with the current possibilities:
loading the google maps widget in the background on another screen, so when the user taps on the screen that has the google map widget, the map is already fully loaded.

I tried an approach to this with the cupertinotabbar and a statefull widget (with the google maps widget inside, that has keepAliveClientMixin enabled) and stack but the map kept reloading. Are there other approaches to this?


A nice feature would be:

Possibility to set a map style before the map is created

Or if the above feature is really difficult / almost impossible to implement:

Possibility to set a background color when the map isn't loaded yet (currently this color is white and has a big contrast with custom map style's that are darker).
Repository: rust
Issue: MaybeUninit::assume_init optimizes poorly
Labels: I-slow,A-codegen,E-needs-test,T-compiler

In #74254 we observed that returning expr.assume_init() from a function unexpectedly inhibits the return value from being constructed in place up front.

https://rust.godbolt.org/z/hr77qM

```rust
#![allow(deprecated)]

use std::mem::{self, MaybeUninit};
use std::ptr;

type T = String;
const N: usize = 2;

// fast
pub fn a() -> [T; N] {
    Default::default()
}

// fast
pub fn b() -> [T; N] {
    unsafe {
        // ignore the UB for now
        let mut array: [T; N] = mem::uninitialized();
        for slot in &mut array {
            ptr::write(slot, T::default());
        }
        array
    }
}

// slow
pub fn c() -> [T; N] {
    let mut array: MaybeUninit<[T; N]> = MaybeUninit::uninit();
    unsafe {
        // ignore the UB for now
        // ordinarily would cast to &mut [MaybeUninit<T>; N]
        // but here we try to minimize difference from `b`
        let slots = &mut *array.as_mut_ptr();
        for slot in slots {
            ptr::write(slot, T::default());
        }
        array.assume_init()
    }
}
```

Notice that in the slow function the return value is constructed exactly the same as in both of the fast functions (6 instructions) except in the wrong place, then relocated from \[rsp-48\] to \[rdi\] :cry: (12 instructions).

```asm
example::a:
        mov     rax, rdi
        mov     qword ptr [rdi], 1
        vxorps  xmm0, xmm0, xmm0
        vmovups xmmword ptr [rdi + 8], xmm0
        mov     qword ptr [rdi + 24], 1
        vmovups xmmword ptr [rdi + 32], xmm0
        ret

example::b:
        mov     rax, rdi
        mov     qword ptr [rdi], 1
        vxorps  xmm0, xmm0, xmm0
        vmovups xmmword ptr [rdi + 8], xmm0
        mov     qword ptr [rdi + 24], 1
        vmovups xmmword ptr [rdi + 32], xmm0
        ret

example::c:
        sub     rsp, 48
        mov     rax, rdi
        mov     qword ptr [rsp], 1
        vxorps  xmm0, xmm0, xmm0
        vmovups xmmword ptr [rsp + 8], xmm0
        mov     qword ptr [rsp + 24], 1
        vmovups xmmword ptr [rsp + 32], xmm0
        mov     rcx, qword ptr [rsp]
        mov     qword ptr [rdi], rcx
        vmovups xmm0, xmmword ptr [rsp + 8]
        vmovups xmmword ptr [rdi + 8], xmm0
        mov     rcx, qword ptr [rsp + 24]
        mov     qword ptr [rdi + 24], rcx
        mov     rcx, qword ptr [rsp + 16]
        mov     qword ptr [rdi + 16], rcx
        mov     rcx, qword ptr [rsp + 24]
        mov     qword ptr [rdi + 24], rcx
        vmovups xmm0, xmmword ptr [rsp + 32]
        vmovups xmmword ptr [rdi + 32], xmm0
        add     rsp, 48
        ret
```
Repository: rust
Issue: Allow `unsafe` modifier before control flow blocks like `unsafe match`, `unsafe loop`, etc.
Labels: T-lang,C-feature-request

# Motivation

I don't know why we not yet allow unsafe before: `match`, `loop`, `while`, `for` (1).
I agree that `unsafe if` is ambiguous as we don't know for sure if the unsafe is applied to only the first `if` or all
other `else` clauses.

Not allowing `unsafe` modifier before (1) makes people have to indent the code for no other benefits.

```rust
unsafe fn foo<T>(t: T) -> T { unimplemented!() }

fn bar<T>(t: T, yes: bool) -> Option<T> {
    unsafe {
        match yes {
            true => Some(foo(t)),
            false => None,
        }
    }
}
```

With allowing `unsafe` modifier:
```rust
fn bar<T>(t: T, yes: bool) -> Option<T> {
    unsafe match yes {
        true => Some(foo(t)),
        false => None,
    }
}
```

# Downsides

* Allow `unsafe` modifier makes grepping for `unsafe {` is not enough
  for finding all unsafe blocks in functions/methods.
* This may be overused because when there are no need to indent code for too long,
people may not split unsafe blocks to smaller scope.

cc @RalfJung
Repository: storybook
Issue: addon-docs [6.0.0-rc3]: skip option in dynamic source rendering not doing anything 
Labels: bug,addon: docs,block: source

**Describe the bug**
Upgraded from an older beta version of storybook 6 to the latest rc, and found some issues related to the new dynamic source rendering feature, introduced in pull request #11332

My sb setup is somewhat complicated, using custom decorators to setup the company-internal framework neded to display my components in storybook. When viewing the source in docs, i would like to show only the code originating from the story and not the decorators. 
To this end, I looked around in the storybook source (jsxDecorator.ts) and found that there is an option 'skip' that does what i need. However, this option does not seem to have any effect on the 'show code' output in docs. It does seem to be running the related code though, as I can for example trigger a warning in the console if I set the skip option too high. Other options, like showFunctions, seem to be working fine.

**To Reproduce**
Steps to reproduce the behavior:
1. Use latest 6.0.0 storybook rc release
2. Set the skip-parameter as following

`export default {
  title: "Components/TestComponent",
  parameters: {
    jsx: { skip: 1 },
  },
};`

for any story where the story source is nested, for example

`<OuterComponent>
<InnerComponent>Test</InnerComponent>
</OuterComponent>
`

3. Open the story in docs mode and click view source
4. Source is the same regardless of skip-parameter.

**Expected behavior**
The output source should be stripped of its outermost containing element in the case of skip = 1.

**Screenshots**
If applicable, add screenshots to help explain your problem.

**Code snippets**
If applicable, add code samples to help explain your problem.

**System:**
Environment Info:

  System:
    OS: Windows 10 10.0.18363
    CPU: (8) x64 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
  Binaries:
    Node: 14.5.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.14.5 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: 44.18362.449.0
  npmPackages:
    @storybook/addon-controls: ^6.0.0-beta.29 => 6.0.0-rc.3
    @storybook/addon-docs: ^6.0.0-beta.23 => 6.0.0-rc.3
    @storybook/addon-jest: ^6.0.0-beta.23 => 6.0.0-rc.3
    @storybook/addon-knobs: ^6.0.0-beta.23 => 6.0.0-rc.3
    @storybook/addons: ^6.0.0-beta.23 => 6.0.0-rc.3
    @storybook/react: ^6.0.0-beta.23 => 6.0.0-rc.3

**Additional context**
Add any other context about the problem here.
Repository: storybook
Issue: addon-docs [6.0.0-rc3]: child render props not showing with dynamic source rendering
Labels: bug,has workaround,addon: docs,block: source

**Describe the bug**
In order to show my components in storybook, I use a custom decorator to setup an internal framework. A part of this internal framework is wrapping story code with a component utilizing child render props. However, this does not seem to work with dynamic source rendering, since the source output that I get cuts off at the component utilizing child render props.

**To Reproduce**
Steps to reproduce the behavior:
1. Wrap a story with a component utilizing child render props (more common in a decorator than an actual story i suppose)
2. Open the component in docs mode, and view source
3. Only the wrapping component is shown in output, not the containing elements.

**Expected behavior**
Both wrapping component and child components shown. At least this would be desirable when using a wrapper as I'm describing, not sure if there are cases when this is not desirable?

**Screenshots**
Story code:
![bild](https://user-images.githubusercontent.com/1229038/87247999-5544ea00-c457-11ea-90dc-94ed2affe475.png)
Output source:
![bild](https://user-images.githubusercontent.com/1229038/87248028-79083000-c457-11ea-8b13-c72ed558e406.png)

**Code snippets**
If applicable, add code samples to help explain your problem.

**System:**
Environment Info:

  System:
    OS: Windows 10 10.0.18363
    CPU: (8) x64 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
  Binaries:
    Node: 14.5.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.14.5 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: 44.18362.449.0
  npmPackages:
    @storybook/addon-controls: ^6.0.0-beta.29 => 6.0.0-rc.3
    @storybook/addon-docs: ^6.0.0-beta.23 => 6.0.0-rc.3
    @storybook/addon-jest: ^6.0.0-beta.23 => 6.0.0-rc.3
    @storybook/addon-knobs: ^6.0.0-beta.23 => 6.0.0-rc.3
    @storybook/addons: ^6.0.0-beta.23 => 6.0.0-rc.3
    @storybook/react: ^6.0.0-beta.23 => 6.0.0-rc.3

**Additional context**
Add any other context about the problem here.
Repository: pytorch
Issue: SGD documentatiuon detail on g_{t+1}
Labels: module: optimizer,triaged

## 📚 Documentation

In the docs https://pytorch.org/docs/master/optim.html#torch.optim.SGD and and inside the class https://pytorch.org/docs/stable/_modules/torch/optim/sgd.html#SGD I notice 

    v_{t+1} & = \mu * v_{t} + g_{t+1},
    p_{t+1} & = p_{t} - \text{lr} * v_{t+1},

But consulting the "On the importance of initialization and momentum in deep learning" by Sutskever et al the update rule for the `v_{t+1}` should be written in this way

    v_{t+1} & = \mu * v_{t} + g_{t},

that is the gradient `g` is taken at the moment `t` and not `t+1`. Am I wrong?

cc @vincentqb
Repository: pytorch
Issue: [discussion] Comparison operator chaining
Labels: triaged,enhancement,module: boolean tensor

This is not supported by NumPy, but maybe this could produce a BoolTensor instead.

It seems to me that Python  converts this code to an if statement, and hence the error about conversion to bool. If that's the case, then my proposal can't be implemented: https://www.python.org/dev/peps/pep-0535/, and probably there wouldn't be even any savings from fusion. But maybe someone from PyTorch could join the PEP discussion, if this is considered interesting.

```python
import torch, numpy

x = 0.3
print(0 < x < 0.5) # True

x = torch.rand(10)
print(0 < x < 0.5) # RuntimeError: bool value of Tensor with more than one value is ambiguous

x = numpy.random.rand(10)
print(0 < x < 0.5) # ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
```

cc @izdeby
Repository: rust
Issue: validate rust-analyzer licenses
Labels: T-core,A-meta,A-licensing

License validation (https://github.com/rust-lang/rust/blob/master/src/tools/tidy/src/deps.rs) for rust-analyzer is currently not being done. I think it would probably be good to include it in the license checks, just to double-check that something inappropriate doesn't slip in.

I manually checked them, and they seem ok at this point.  It would be helpful if the ra crates themselves included a license field in their Cargo.toml for automatic validation.

cc @matklad