sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Overhead of core::sync::atomic::* primitives in dev builds
Labels: C-enhancement,T-compiler,WG-embedded,I-heavy,C-optimization

The primitives provided by `core::sync::atomic` come with a binary overhead in dev builds which also partly contradicts the documentation, e.g. `compiler_fence` states: 

> compiler_fence does not emit any machine code

However when we compile trivial program for an embedded target:
```
#![no_main]
#![no_std]

use panic_halt as _;
use cortex_m_rt::entry;

#[entry]
fn main() -> ! {
    loop {
        continue;
    }
}
```

e.g. for `thumbv6m-none-eabi` we can observe that we not only get one but two `compiler_fence` instances:

```
Analyzing target/thumbv6m-none-eabi/debug/examples/empty

File  .text Size       Crate Name
0.1%  11.3%  74B cortex_m_rt r0::init_data
0.0%   9.8%  64B cortex_m_rt core::sync::atomic::compiler_fence
0.0%   9.8%  64B  panic_halt core::sync::atomic::compiler_fence
0.0%   8.6%  56B cortex_m_rt r0::zero_bss
0.0%   7.3%  48B cortex_m_rt Reset
0.0%   6.4%  42B cortex_m_rt core::ptr::read
0.0%   5.5%  36B         std core::panicking::panic
0.0%   4.3%  28B   [Unknown] __aeabi_memcpy4
0.0%   4.3%  28B         std core::panicking::panic_fmt
0.0%   4.0%  26B cortex_m_rt core::intrinsics::copy_nonoverlapping
0.0%   3.4%  22B cortex_m_rt core::ptr::<impl *const T>::offset
0.0%   3.4%  22B cortex_m_rt core::ptr::<impl *mut T>::offset
0.0%   3.1%  20B cortex_m_rt HardFault_
0.0%   3.1%  20B  panic_halt rust_begin_unwind
0.0%   2.8%  18B cortex_m_rt DefaultHandler_
0.0%   2.8%  18B   [Unknown] __aeabi_memcpy
0.0%   2.4%  16B cortex_m_rt core::ptr::write
0.0%   2.4%  16B cortex_m_rt core::ptr::write_volatile
0.0%   2.4%  16B         std <T as core::any::Any>::type_id
0.0%   1.8%  12B cortex_m_rt core::mem::zeroed
0.0%   0.6%   4B   [Unknown] main
0.0%   0.3%   2B cortex_m_rt DefaultPreInit
0.0%   0.3%   2B         std core::ptr::real_drop_in_place
0.5% 100.0% 654B             .text section size, the file size is 127.6KiB
```

which amount to nearly 20% of the code size plus two instances of the panic message plus the formatting machinery which would not be needed otherwise.

In #68155 I've tried to coerce the compiler into fully inlining the code, especially since the argument (as I would imagine is pretty much always the case) is a constant. But as suspected by @rkruppe and @jonas-schievink, this does not have the intended effect.

As noted in the PR replacing the `panic!` by a unit type helps somewhat (and one could argue that a "lazy" compiler fence is pretty much equal to doing nothing and should not panic at runtime) but it would be better if we could somehow insure that the `compiler_fence` really only turns into a compiler hint and not a function call.

If we cannot ensure that a `compiler_fence` actually turns into nothing, would it be acceptable to also expose the various fence types directly via functions?
Repository: go
Issue: x/text/currency: supported currency codes need an update (MRO->MRU, VEF->VES)
Labels: NeedsFix

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?
<pre>
$ go version
go version go1.13.4 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes.

### What operating system and processor architecture are you using (`go env`)?
Any.

### What did you do?
https://play.golang.org/p/GoUe1pIAVjo

### What did you expect to see?
VES and MRU must be parsed.

### What did you see instead?
currency: tag is not a recognized currency

### Additional info
Since 2018 VEF->VES and MRO->MRU but currency lib supports old currency names.
https://www.iso.org/iso-4217-currency-codes.html
https://en.wikipedia.org/wiki/List_of_circulating_currencies
Repository: TypeScript
Issue: Allow augmentation of the async function prototype
Labels: Suggestion,Awaiting More Feedback

## Search Terms

AsyncFunction

## Suggestion

In JavaScript, We can get constructor of async function via
```javascript
const AsyncFunction= (async()=>{}).constructor;
```
And we can do something interesting with it's prototype:
```javascript
AsyncFunction.prototype.callConcurrently = async function (concurrency,...args){
    return Promise.all(Array(concurrency).fill(this).map(f=>f(...args)));
}
```
Then we can do
```javascript
const af = async ()=>{};
af.callConcurrently(6, 'foo', 'bar');
```
But in TypeScript, we have no `AsyncFunction` interface to do the same thing.

We can add an `AsyncFunction` interface extends `Function` and let all functions start with `async` keyword implement it. And add an `AsyncFunctionConstructor` interface let `(async ()=>{}).constructor` implements it. The mode is now new but just like `GeneratorFunction` and `AsyncGeneratorFunction`.

## Use Cases and Example

```typescript
interface AsyncFunction
{
    callConcurrently(concurrency:Number, ...args:any[]):Promise<any[]>;
}

(async()=>{}).constructor.prototype.callConcurrently = async function (concurrency, ...args){
    return Promise.all(Array(concurrency).fill(this).map(f=>f(...args)));
}

const af = async ()=>{};
af.callConcurrently(6, 'foo', 'bar');
```

## Maybe Breaking Change

Currently `async()=>3` and `()=>Promise.resolve(3)` has the same type in TypeScript.
This proposal will make them different.
They are different in ECMAScript actually. See https://tc39.es/ecmascript-asyncawait/#async-function-constructor . So this breaking change actually fill the gap between TypeScript and ECMAScript.

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals 6](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals 11](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: rust
Issue: Infinite types not detected
Labels: T-compiler,I-compilemem,C-bug

Gentlemen,

The following code causes my computer to freeze when attempting compilation (variant: takes a long time to compile and errs with "...infinite size...").
It should have warned about the infinite size type.

```rust
    // /!\ DO NOT COMPILE THIS CODE FOR FUN /!\
fn main() {
    #[derive(Debug)]
    enum Atom<V, E> {
        Vertex(V),
        Edge(E),
    }

    #[derive(Debug)]
    struct Edge<E, V> {
        data: E,
        // atom: Option<&'a Atom<Vertex<'a, V, Self>, Self>>, // Variant
        atom: Option<Box<Atom<Vertex<V, Self>, Self>>>, // Bug here
    }

    #[derive(Debug)]
    struct Vertex<V, E> {
        data: V,
        // atom: Option<&'a Atom<Self, Edge<'a, E, Self>>>, // Variant
        atom: Option<Box<Atom<Self, Edge<E, Self>>>>,  // Bug here
    }

    let vertex = Vertex::<i8, i8> {
        data: 1,
        atom: None,
    };

    let edge = Edge::<i8, i8> {
        data: 1,
        atom: None,
    };

    println!("{:#?} {:#?}", vertex, edge);
}
```

Hope this helps.
Repository: pytorch
Issue: Serialization inconsistency with pickling tensors breaks caching
Labels: module: serialization,triaged

## 🐛 Bug
Serializing tensors with pickle yields inconsistent result.
**Expected:** IFF `tensorA == tensorB` then `serialize(tensorA) == serialize(tensorB)`

Additionally, I suspect this behavior breaks caching solutions: functools.lru_cache (see example below), redis (https://github.com/pytorch/pytorch/issues/19742).

## Environment

 - PyTorch Version (e.g., 1.0): v1.3.1
 - OS (e.g., Linux): Ubuntu 19.10
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Python version: 3.6 + 3.7
 - CUDA/cuDNN version: 10.1
 - GPU models and configuration: nvidia 1050
 - Any other relevant information:

## To Reproduce
I have tested the following scenario with both CPU and GPU tensors.

```
import torch, pickle

add11 = lambda: torch.Tensor([1]) + torch.Tensor([1])
add11() == add11()  # return tensor([True])
hash(add11()) == hash(add11())  # returns True
pickle.dumps(add11()) == pickle.dumps(add11())  # returns False [True exp.]
pickle.dumps(add11().data) == pickle.dumps(add11().data)  # returns False [True exp.]
pickle.dumps(torch.Tensor([1])) == pickle.dumps(torch.Tensor([1]))  # returns False [True exp.]
pickle.dumps(torch.Tensor([1])) == pickle.dumps(torch.Tensor([1]).data)  # surprisingly, returns True as it should
```

Example code: (LRU cache)
```
import functools

@functools.lru_cache(None)  # unlimited size
def add(x, y):
 return x + y

for _ in range(10):
 tmp = add(torch.Tensor([1]), torch.Tensor([1]))

add.cache_info().hits  # returns 0 hits [9 expected]
```
Repository: TypeScript
Issue: DOM suggestion: customisable `history.state` type
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

dom lib window state history any unknown

## Suggestion

Currently `window.history.state` has type `any`.  Could we provide a way for users to customise this type? Perhaps by making it generic or allowing the type to be changed through declaration merging.

Failing that, could we replace the `any` type with `unknown`, so we have type safety and users are forced to validate/widen the type?

Another possible solution: if TypeScript provided a way to override `any` types (https://github.com/microsoft/TypeScript/issues/4062, https://github.com/microsoft/TypeScript/issues/26188).

Also related:
- https://github.com/DefinitelyTyped/DefinitelyTyped/pull/41568
- https://github.com/DefinitelyTyped/DefinitelyTyped/pull/41580

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples

<!-- Show how this would be used and what the behavior would be -->

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code
* [ ] This could be implemented without emitting different JS based on the types of the expressions
* [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: C++ randint returns float32, python returns int64
Labels: module: cpp,triaged

## 🐛 Bug

This has come up before, issue #14079 and pr #11040

It looks like the python side was fixed to return longs (but documentation still has: "_dtype (torch.dtype, optional) – the desired data type of returned tensor. Default: if None, uses a global default_")

## To Reproduce

```
>>> import torch
>>> torch.randint(10,(3,)).dtype
torch.int64
```
```
std::cerr << torch::randint(10,{3}) << "\n";
 5
 0
 9
[ CPUFloatType{3} ]
```

## Expected behavior

Both behaviours are reasonable, but I guess I would expect the c++ implementation to match python.

cc @yf225
Repository: rust
Issue: The bounds information of associated types is not propagated correctly when used with trait aliases.
Labels: A-trait-system,T-lang,T-compiler,C-bug,F-trait_alias,requires-nightly

Hi! The following code does not compile, while it should. The functions `test1` and `test2` do the same thing, while `test1` compiles and `test2` does not:

```rust
#![feature(trait_alias)]

use std::marker::PhantomData;

pub struct X{}

pub trait T2 = where PhantomData<Self>: Into<X>;

pub trait T {
    type Item: T2;
    
    fn test1() -> X {
        PhantomData::<Self::Item>.into()
    }
}

fn test2<S:T>(s:S) -> X {
    PhantomData::<S::Item>.into()
}
```

Error:
```
error[E0277]: the trait bound `X: std::convert::From<std::marker::PhantomData<<S as T>::Item>>` is not satisfied
  --> src/lib.rs:18:28
   |
18 |     PhantomData::<S::Item>.into()
   |                            ^^^^ the trait `std::convert::From<std::marker::PhantomData<<S as T>::Item>>` is not implemented for `X`
   |
   = note: required because of the requirements on the impl of `std::convert::Into<X>` for `std::marker::PhantomData<<S as T>::Item>`

```
Repository: flutter
Issue: [Feature-Request] Delayed Animations with Built-in Animated Widgets
Labels: c: new feature,framework,P3,team-framework,triaged-framework

## Use case
Delayed Animations with Built-in Animated Widgets , like : 

```
   AnimatedOpacity(
        duration: const Duration(milliseconds: 250), // TODO : animate after backdrop opened
        delay: const Duration(milliseconds: 350), // REQUESTED FEATURE
        opacity: isBackDropOpen ? 1 : 0,
        child: myBackDrop(),
    ),
```

## Proposal

didn't find any pub.dev package to do this in the Widgets themselves,
and I'm not sure if it's possible.
but it's obvious how much easier and straight-forward it would become to animate with delays this way.

❤️ 

* by delay I mean the animation and changes (the **opacity** in this example) happen after this given **delay** has passed after changes in the code (**isBackDropOpen** in this example).
Repository: pytorch
Issue: Support in-place pinning of memory
Labels: module: serialization,triaged

## 🚀 Feature
Provide a `pin_memory_` method on tensors (note the trailing underscore) which operates in-place.

## Motivation
Pinning memory using the current `pin_memory` method creates a copy of the memory. This is problematic when the data that needs to be pinned is too large to hold two copies of it at once. Also, this doesn't allow to pin shared memory, because the "sharedness" of the memory is lost upon copying it.

## Pitch
My project, PyTorch-BigGraph, needs this feature for exactly the two reasons outlined above. In-place pinning is a primitive operation that is very easy to implement. The fact that it's missing appears to be an inconsistency in PyTorch's API.

## Alternatives
The function on the CUDA runtime that performs this can be called manually with ctypes:
```
import ctypes
torch.cuda.check_error(torch.cuda.cudart().cudaHostRegister(
        ctypes.c_void_p(tensor.data_ptr()),
        ctypes.c_size_t(tensor.numel() * x.element_size()),
        ctypes.c_uint(0),
))
assert tensor.is_pinned()
torch.cuda.check_error(torch.cuda.cudart().cudaHostUnregister(
        ctypes.c_void_p(tensor.data_ptr()),
))
```

## Additional context
In-place pinning is slow, typically as slow or slower than copying un-pinned memory to the GPU. It is thus an "investment" that makes sense only if the memory is long-lived, as it will be amortized only if the memory will be copied several times.

cc @mruberry @mikaylagawarecki @ezyang @gchanan @zou3519
Repository: godot
Issue: Gridmap doesn't update in parent scene when "Editable Children" is enabled
Labels: bug,topic:core,confirmed

**Godot version:**
Occurs in both 3.1.2 and the latest release of 3.2

**OS/device including version:**
Linux - Ubuntu 18.04

**Issue description:**
I have a gridmap in a child scene, which exists as an instanced scene in a parent scene. I have "Editable Children" set to true here. However, when I add or remove meshes to the gridmap and save, these changes do not appear in the parent scene. If I disable "Editable Children" and save the child scene again, all changes to the gridmap are reflected in the parent scene.

I just need to get the paths to nodes within the child scene so I haven't actually edited any of the nodes from the parent scene (especially not the gridmap). Also the properties of other nodes update even when Editable Children is set to true. Because of that I would expect these changes to sync between scenes even if the instanced scene is editable, but they don't.

**Steps to reproduce:**
Using the minimal reproduction project:
-From the child scene, add or remove meshes to the gridmap and save.
-Switch over to the parent scene; note how these changes to the gridmap don't appear here.
-Set "Editable Children" to false.
-Switch to the child scene and save.
-Switch over to the parent scene again; all changes to the gridmap will now appear.

**Minimal reproduction project:**
[gridmap-not-updating.zip](https://github.com/godotengine/godot/files/4059335/gridmap-not-updating.zip)
Repository: godot
Issue: Shader editor should be shown when shader compilation error is raised
Labels: enhancement,topic:editor,usability,topic:shaders

**Godot version:**
3.2 master (ea4c88f3)

**OS/device including version:**
Any

**Issue description:**
When a compilation error happens in a shader, the compilation error and problematic line are properly displayed in the shader text editor.

But it's not always visible when the error is raised, so the UX is not so good. If you're in the normal Output panel, you will see the full shader text dumped and error at the end, but not which shader is affected.

Moreoever, when running the project, the shader text is dumped in output, but the error is then not displayed there, but in the Debugger Errors tab.

The shader editor for the affected shader should be raised when this happens.

**Steps to reproduce:**
- Try MRP, see error in Output but no link to the actual shader code
- Open shader editor, see the proper error reporting

**Minimal reproduction project:**
[IsNanTangentShaderError.zip](https://github.com/godotengine/godot/files/2913023/IsNanTangentShaderError.zip) (from #26387).
Repository: rust
Issue: Don't render text from implementors file
Labels: T-rustdoc

Currently, we generate some HTML directly into the implementors file which is then used to add the missing implementors on some traits. This shouldn't be done this way, instead we should just provide the needed information and then generate the tag on the front-end to prevent some malicious insertions.
Repository: TypeScript
Issue: Mark function expressions differently from variables
Labels: Suggestion,Awaiting More Feedback

## Search Terms
Differentiate JS function vars from other vars, outline, breadcrumb, variable, function expression, arrow function expression

## Suggestion

With the addition of `outline.showVariables` setting in VS Code, I would like to have this issue reconsidered.

https://github.com/microsoft/vscode/issues/84359

![image](https://user-images.githubusercontent.com/2313018/72352620-e1fa2f80-36e2-11ea-91b0-8c528b1e9fdf.png)

![image](https://user-images.githubusercontent.com/2313018/72352727-140b9180-36e3-11ea-86a6-6768b708b9dc.png)

Use case and example as above.

Other internal mechanisms and userland extensions could possibly benefit from this change as well.

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## refs
https://github.com/microsoft/vscode/issues/84359
https://github.com/microsoft/TypeScript/issues/14830
https://github.com/microsoft/TypeScript/issues/29036
Repository: go
Issue: x/crypto/acme/autocert: Manager.RenewBefore must be >1hour
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.13.6 linux/amd64
$ go list -m golang.org/x/crypto
golang.org/x/crypto v0.0.0-20200109152110-61a87790db17
</pre>

### Does this issue reproduce with the latest release?
Yes

### What did you do?
Used a `Manager` with `RenewBefore` set to 5 minutes (as a part of a test while running my own boulder instance):
```
m := autocert.Manager{
    // ...
    RenewBefore: time.Minute * 5,
}
```

### What did you expect to see?
I expected that the manager actually used 5 minutes as `RenewBefore`, since [the documentation](https://github.com/golang/crypto/blob/61a87790db17894570dfb32dbaa0a4af9ce60cb4/acme/autocert/autocert.go#L135) states:
>    // RenewBefore optionally specifies how early certificates should
>    // be renewed before they expire.
>    //
>    // **If zero, they're renewed 30 days before expiration.**
>    RenewBefore time.Duration


### What did you see instead?
`RenewBefore` being set to 30 days.

There is a check that makes sure that the value specified is more than the `renewJitter` (1 hour):
https://github.com/golang/crypto/blob/61a87790db17894570dfb32dbaa0a4af9ce60cb4/acme/autocert/autocert.go#L1098

Either it should be allowed to use values less than one hour, or the documentation should reflect that values less than an hour is the same thing as "30 days".
Repository: vue
Issue: VSCode "auto import" of ESM module broken in 2.6.11 with umd namespace 
Labels: typescript

### Version
2.6.11

### Reproduction link
[https://imgur.com/a/RxJz6fT](https://imgur.com/a/RxJz6fT)







### Steps to reproduce
Since the 2.6.11 my IDE (VSCode) now suggest me import Vue from  the 'vue/types/umd' namespace instead of the ESModule 'vue'

I'm using 
Vue 2.6.11
Vue-CLI  4.1.0
VScode 1.41.1
Typescript 3.7.4

### What is expected?
Prior 2.6.11, VScode was suggesting to `import Vue from 'vue'` 

### What is actually happening?
VSCode is suggesting me to `import Vue from 'vue/types/umd'` see screenshot

---
maybe it's releated to https://github.com/vuejs/vue/pull/9912 ?

<!-- generated by vue-issues. DO NOT REMOVE -->