sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Vtables not position independent for target thumbv7em-none-eabi
Labels: A-linkage,A-LLVM,O-Arm,T-compiler,C-feature-request

# Summary
I'm having trouble using dynamic dispatch for trait objects on a cortex-m4. 
The setup is rather complicated as relocated binaries only make sense for binaries which will actually be relocated. In this case I try to run a tock app created with libtock-rs.

The vtables in the binary get relocated, however the content of the vtables is not position independent but pointing to the load addresses of the function to be called.

I have written a "fixup-routine" in the following pull request, however uses a very rough heuristics to identify vtables in the .rodata section:
https://github.com/tock/libtock-rs/pull/56

# Description of the problem
I compile (using nightly-2018-08-16) the traitobj-Example in the PR using ropi-relocation model. Access to the vtable works just fine as the addresses of the vtables are access relatively to the position of the application in flash. However, the addresses in the vtables point to the static load address in the binary of the functions to call.

Currently, I solve the problem using a fixup routine which fixes the addresses in the vtables (and potentially destroys other elements of .rodata).

# Expected behavior
The addresses in the vtables should be accessed in a way which is position independent.
At least there should be a way to identify vtables in the .rodata segment such that at least theoretically the vtables could be fixed. However, recently the behavior of the Rust compiler changed so that it creates vtable-Symbols which don't carry names containing "vtable" anymore so for me it is impossible to find these symbols ( rust nightly 2018-06-14 stil creates symbols named *vtable*).

# Provide information
The description provided here is relatively rough. Please help me providing the information necessary to investigate the problem.
Repository: pytorch
Issue: torch.bmm doesn't support CUDA uint8 (byte) tensor
Labels: todo,module: bootcamp,module: cuda,triaged,enhancement,module: linear algebra

Hi,

It seem that byte type are not supported for the bmm operator on GPU.
The function batch_mm in file pytorch/torch/jit/batchop.py use it.
Applying the attached patch seem to solve the problem on GPU.
[patch_batchop.txt](https://github.com/pytorch/pytorch/files/2406035/patch_batchop.txt)

Have a nice day.


cc @ngimel @jianyuh @nikitaved @pearu @mruberry @heitorschueroff @walterddr @IvanYashchuk
Repository: go
Issue: runtime,cmd/compile: string concatenation specializations for performance
Labels: Performance,NeedsInvestigation,compiler/runtime

[CL123256](https://go-review.googlesource.com/c/go/+/123256) started a discussion on which strings concatenation specialization we should choose (if any).

String concatenation can be made faster if we specialize concatenation with escaping result and len(args)<=5 (N) arguments. Escaping result means that we can avoid passing `buf` that is always `nil` as well as use `rawstring` instead of `rawstringtmp`. Known N means that we can unroll loops.

There are several ways (and these are not all of them):
1. Specialize for N=2 `x+y`. Less code, seems like most frequent, the boost is maximal, but does not improve any other concatenation (like `x+y+z` which uses `concatstring3`).
2. Specialize for all N, but for marginal performance boost that may not even worth it.
3. Specialize for N={2,3,4,5}. More code.
4. Specialize for N={2,3} covers **most** concatenations. Speeds up concat2 and concat3 measurably.

I've started from (1) since it's the easiest change that requires less amount of changes and gives significant performance gain. But in order to have decision extra feedback is required.

Here is comparison of (1) against unoptimized concat:
```
name            old time/op    new time/op    delta
Concat2-8         74.2ns ± 0%    53.5ns ± 1%  -27.95%  (p=0.000 n=9+15)
Concat3-8         94.9ns ± 0%    94.8ns ± 0%     ~     (p=0.082 n=14+15)
Concat2Empty-8    21.4ns ± 1%    14.2ns ± 0%  -33.75%  (p=0.000 n=15+14)
Concat3Empty-8    23.9ns ± 1%    23.9ns ± 1%     ~     (p=0.756 n=15+15)
[Geo mean]        43.6ns         36.2ns       -16.88%
```
Comparison for (4) implementation against go tip:
```
name            old time/op    new time/op    delta
Concat2-8         74.2ns ± 0%    66.1ns ± 1%  -10.95%  (p=0.000 n=9+15)
Concat3-8         94.9ns ± 0%    71.9ns ± 1%  -24.22%  (p=0.000 n=14+15)
Concat2Empty-8    21.4ns ± 1%    21.1ns ± 0%   -1.56%  (p=0.000 n=15+15)
Concat3Empty-8    23.9ns ± 1%    16.6ns ± 1%  -30.63%  (p=0.000 n=15+12)
[Geo mean]        43.6ns         35.9ns       -17.61%
```

Note that these numbers represent overhead savings, not general case strings concatenation performance boost, since length of strings determine these timings significantly.

Benchmarks:
```go
package foo

import "testing"

//go:noinline
func concat2(x, y string) string {
	return x + y
}

//go:noinline
func concat3(x, y, z string) string {
	return x + y + z
}

var x = "foor"
var y = "2ews"
var z = ""

func BenchmarkConcat2(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = concat2(x, "abc")
	}
}

func BenchmarkConcat3(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = concat3(x, "abc", y)
	}
}

func BenchmarkConcat2Empty(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = concat2(x, "")
	}
}

func BenchmarkConcat3Empty(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = concat3("", x, z)
	}
}
```

I would like to know:
1. That this kind of optimization is welcome.
2. If it is desired, we need to choose which approach to take.

CC @martisch
Repository: pytorch
Issue: [feature request] Kumaraswamy distribution
Labels: module: distributions,feature,triaged

## Issue description

There is currently no `Kumaraswamy` distribution in `torch.distributions`.
It would be nice to have! It is already available in Tensorflow Probability.

I'm happy to contribute it.

cc @vincentqb @fritzo @neerajprad @alicanb @vishwakftw
Repository: TypeScript
Issue: Object spread drops index signature
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.0.1

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
spread index signature, spread indexer

**Code**

```ts
declare var v: Record<string, string>;

let v2 = {...v}; // works
let v3 = {a: '', ...v}; // index signature lost
let v4 = {...v, a: ''}; // same as above
let v5 = {a: 1, ...v}; // index signature lost, should be '{a: number, [x: string]: number | string}'
let v6 = {[Number()]: 1, ...v}; // empty object type ò,Ó, should be '{[x: string]: number | string}'
```

**Expected behavior:**
Index signature exists on all object types.

**Actual behavior:**
Index signature is lost if object literal contains another property assignment. I'm not entirely sure what the type of `v6` should be.

**Playground Link:** https://agentcooper.github.io/typescript-play/#code/CYUwxgNghgTiAEA3WSBc8BK4D2NgB4BnAFxgEsA7AcwBp4TzqA+AbgCg2IRikAmeALzwA3gDpxiAL4t4AelnwA7rgDWhTtyQBmQSKjoA5AbrjRUmfPiVQAD3pkqFKMQCuceBGwkNPRABZdMQk6fXgjaTkFQigAWwQoQngoACNsRBAfJABWQNCARhMJCMtrEDtCBydXd08SOkIAC2wXCGB4ZIQDYVCKFxiOmDoAbRt0BkoqAF10Xv6QGHgAH3pSCckDTMQANkChgDk+gYAKAEpp+AL4U3NI+BAYgAdiAE94bGSAK3AeF4eEACeaABl+pNFptDphYQjMarajnWYDJYrRhUdZAA

**Related Issues:**
#16694
#16373
Repository: go
Issue: proposal: spec:  reduce unspecified behaviors of expression evaluation orders in assignment statements
Labels: LanguageChange,Proposal,LanguageChangeReview

_(As [this proposal](https://github.com/golang/go/issues/27098) is rejected, I change it as a Go 2 proposal instead.)_

One feature of Go is multi-value assignments support. However, currently, the rules of the expression orders in one multi-value assignment are very not specified, which causes many ambiguities in practice. Please read [this](https://github.com/go101/go101/wiki/Some-evaluation-orders-in-multi-value-assignments-are-unspecified) ~~and [this](https://github.com/go101/go101/wiki/An-ambiguity-of-(or-dispute-on)-the-evaluation-order-of-LHS-(left-hand-side)-items-in-a-multi-value-assignment)~~ for details.

As a so called C+ language, one of the main goals of Go is to remove as many unspecified behaviors in C as possible, in particular for the unspecified behaviors which may be common encountered. So here I propose Go 2 should specify more on the expression orders in one multi-value assignment.

Currently, Go specification specifies:

> At package level, initialization dependencies determine the evaluation order of individual initialization expressions in variable declarations. Otherwise, when evaluating the operands of an expression, assignment, or return statement, all function calls, method calls, and communication operations are evaluated in lexical left-to-right order. 

By the rule, the following program must print `1` and `2` for `y` and `z`,
but the print result for `x` might be `0`, `1` or `2`. The standard Go compiler prints `x` as `2`,
which is counterintuitive for most programmers.

```golang
package main

func main() {
	a, b := 0, 0
	f := func() int {
		a++
		b++
		return b
	}
	
	x, y, z := a, f(), f()
	println(x, y, z)
}
```

If we (or the compiler) rewrite the last multi-value assignment in the above example as

```golang
	x, y, z := func() int{return a}(), f(), f()
```

Then the print result should be `0 1 2` for sure. In other words, there are not any technical obstacles to **evaluate expressions in a ~~multi-value~~ assignment by the from-left-to-right rule** . The reason of why Go specification doesn't adopt this more specified rule might be related to code optimization consideration.

The bold line is my proposal.

[edit: the following content is moved to a new issue: https://github.com/golang/go/issues/27821]
Repository: flutter
Issue: Option to mimic cmd+k event in IOS to open/hide virtual keyboard
Labels: a: text input,c: new feature,platform-ios,framework,engine,P2,team-ios,triaged-ios

Hello,

I have a physical keyboard attached to my ios device, by default the virtual keyboard is hidden. This can be brought back by pressing cmd+k keys in the physical keyboard. Is there a way to programmatically trigger this key events so that we can bring the virtual keyboard by pressing a RaisedButton widget?

thank you in advance.
Repository: bitcoin
Issue: Unbounded growth of scheduler queue
Labels: Brainstorming,Resource usage

In `validation.cpp`, both `ConnectTip` and `DisconnectTip` invoke a `GetMainSignals()...` callback, which schedules a future event though the CScheduler interface.

These functions are called in 3 places:
- `ActivateBestChainTipStep`
- `InvalidateBlock`
- `RewindBlockIndex`

The first of these 3 prevents the scheduler queue from growing unboundedly, by limiting the size to 10 in `ActivateBestChainTip`. The other two however do not, and @Sjors discovered that doing a giant `invalidateblock` RPC call will in fact blow up the node's memory usage (which turns out to be caused by the queue events holding all disconnected blocks in memory).

I believe there are several improvements necessary.

1. (short term symptom fix) If this issue also appears for `RewindBlockIndex`, we must fix it before 0.17, as this may prevent nodes from upgrading pre-0.13 code. I think this is easy, as this function is called prior to normal node operation, so it can easily be reworked to release `cs_main` intermittently and drain the queue.

2. (long term fix) The use of background queues is a means to increase parallellism, not a way to break lock dependencies (as @gmaxwell pointed out privately to me, whenever a background queue is used to break a dependency, attempts to limit its size can turn into a deadlock). One way I think is to have a debug mode where the background scheduler immediately runs all scheduled actions synchronously, forcing all add-to-queue calls to happen without locks held. Once everything works in such a mode, we can safely add actual queue size limits as opposed to ad-hoc checks to prevent the queue from growing too large.

3. (orthogonal memory usage reduction) It's unfortunate that our `DisconnectBlock` events hold a shared pointer to the block being disconnected. Ideally there is a shared layer that only keeps the last few blocks in memory, and releases and reloads them from disk when needed otherwise. This wouldn't fix the unbounded growth issue above, but it would reduce the impact. It's also independently useful to reduce the memory during very large reorgs (where we can't run callbacks until the entire thing completed).
Repository: pytorch
Issue: dtype mismatch error messages can be misleading
Labels: todo,module: error checking,module: molly-guard,triaged

Example:
```
In [2]: import torch
   ...: import torch.nn as nn
   ...:
   ...: mat1 = torch.randn(3, 3, dtype=torch.double)
   ...: mat2 = torch.randn(3, 3, dtype=torch.float)
   ...: torch.mm(mat1, mat2)
   ...:
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-2-3bb89e9eafdc> in <module>()
      4 mat1 = torch.randn(3, 3, dtype=torch.double)
      5 mat2 = torch.randn(3, 3, dtype=torch.float)
----> 6 torch.mm(mat1, mat2)

RuntimeError: Expected object of scalar type Double but got scalar type Float for argument #2 'mat2'
```

Consider the following:
- Let's say as a user I was given mat2 from a black box
- The user supplies mat1, and then gets this error message, which is misleading because what the user really needs to hear is that "mat1 is of scalar type Float but should be scalar type Double"

Maybe we should change the error message to say
"Scalar type mismatch: got scalar type Double for argument #1 mat1 and scalar type Float for argument #2 mat2"

What do we think?
Repository: rust
Issue: FFI mechanism to declare a symbol for an array
Labels: A-FFI,T-compiler,C-feature-request,A-array

If I have a C declaration

```c
char *symbol = "hello world";
```

I can declare that symbol in Rust as

```rust
extern "C" { pub static symbol: *c_char; }
```

But if I have a C declaration
```c
char symbol[] = "hello world";
```

I can't directly declare that in Rust in an immediately usable way. In this case, `symbol` refers *directly* to the array of characters; while in C it will "degrade" to a pointer if used in a context that expects a pointer, in Rust a declaration referring to `symbol` will refer to the characters directly. So, for instance, declaring it as a `*c_char` will result in a pointer whose numeric value contains the first `sizeof::<*c_char>()` bytes of `"hello world"`.

Declaring `symbol` as a `[c_char; 0]` and then obtaining and using its pointer seems wrong.

I can think of a few useful ways to do this, one more straightforward than the other.

One would be to have a means of defining in an `extern "C"` block something that gets the value of the *address* of the symbol, just as if in C I'd written `char *symbol_ptr = symbol;` and then referenced *that* from Rust. That seems easy enough to do, modulo bikeshedding over the syntax to do so.

Another would be to define `symbol` as a C array of unknown length. However, that seems unfortunate to deal with.

The most ideal approach I can think of would be to define `symbol` as a `[c_char; _]` (using the elided size syntax from https://github.com/rust-lang/rfcs/pull/2545), and then infer the size from the symbol size:

```
$ nm --print-size test.o 
0000000000000000 000000000000000c D symbol
```

I don't know how feasible that would be, but it'd be incredibly convenient.
Repository: rust
Issue: Expand macros inside inline asm clobbers.
Labels: A-inline-assembly,A-macros,T-compiler,C-bug,requires-nightly

https://play.rust-lang.org/?gist=a0de4df14ed21add77a2f74d5665a31c&version=nightly&mode=debug&edition=2015

It'd be nice if rust allowed expanding macros inside the inline asm input/output/clobbers.
Repository: kubernetes
Issue: Support Windows Certificate Store for kubectl client certs
Labels: kind/feature,sig/windows,lifecycle/frozen

**Is this a BUG REPORT or FEATURE REQUEST?**:
/kind feature

(I checked and don't think this support already exists, but perhaps I just missed it somewhere.)

**Anything else we need to know?**:
.kube/config has client-certificate-data and client-key-data on windows. Windows natively puts certificates in a certificate store and configures them via a reference to a certificate in a store, such as
```
Location: CurrentUser
Store: My
Subject: CN=CertName
```

For some examples, see:
* https://docs.microsoft.com/en-us/windows/desktop/WinHttp/winhttpcertcfg-exe--a-certificate-configuration-tool
* https://docs.microsoft.com/en-us/previous-versions/orphan-topics/ws.10/cc772898(v=ws.10)
> To view the certificate of the user that has the serial number 26e0aaaf000000000004 in the store named My, type:
> ```
> certutil -store -user My 26e0aaaf000000000004
> ```

Can .kube/config on Windows support an alternative to client-certificate-data and client-key-data that allows referencing a certificate installed in a Windows certificate store instead? This functionality would allow full integration with Windows key storage mechanisms, such as encrypted or hardware storage of private keys.

An example might be
```
user:
  client-certificate-store: "CurrentUser\My, CN=CertName"
```
Repository: TypeScript
Issue: findAllReferences broken when immediately looping over array literal of object literals
Labels: Bug

**TypeScript Version:**  3.1.0-dev.20180921

**Code**

```ts
for (const { a } of [{ a: 0 }, { a: 1 }]) {
    a;
}
```

**Expected behavior:**

All 4 `a` are references of each other.

**Actual behavior:**

The `a` in `{ a: 1 }` is not counted as a reference of the others.
Repository: pytorch
Issue: Jit cannot trace autograd for certain operator
Labels: oncall: jit

## Issue description

`torch.jit.trace` can not trace `torch.autograd.grad` for some cetrain operator(SliceBackward)

same issue which submit to discuss.pytorch.org: [https://discuss.pytorch.org/t/jit-cannot-trace-autograd-for-certain-operator](url)

## Code example

code:
```python
import torch

def test(fun):
    x = torch.ones([1, 4], requires_grad=True)
    y = fun(x)

    @torch.jit.trace(torch.zeros([1, 4]))
    def difference_forward(z):
        return torch.autograd.grad(y, x, grad_outputs=z, retain_graph=True)

    print(difference_forward(torch.ones([1, 4])))

if __name__ == '__main__':
    test(lambda x: x * x)
    test(lambda x: x[0:1])
```

output:
```bash
tensor([[2., 2., 2., 2.]])
Traceback (most recent call last):
  File "playground.py", line 16, in <module>
    test(lambda x: x[0:1])
  File "playground.py", line 7, in test
    @torch.jit.trace(torch.zeros([1, 4]))
  File "/home/ubuntu/anaconda3/lib/python3.6/site-packages/torch/jit/__init__.py", line 310, in wrapper
    module._create_method_from_trace('forward', func, args)
  File "playground.py", line 9, in difference_forward
    return torch.autograd.grad(y, x, grad_outputs=z, retain_graph=True)
  File "/home/ubuntu/anaconda3/lib/python3.6/site-packages/torch/autograd/__init__.py", line 145, in grad
    inputs, allow_unused)
RuntimeError: saved_variables() needed but not implemented in SliceBackward
```

## System Info
- PyTorch version: 0.5.0a0+4ad6e53
- Is debug build: No
- CUDA used to build PyTorch: 9.1.85

- OS: Ubuntu 16.04.5 LTS
- GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
- CMake version: version 3.5.1

- Python version: 3.6
- Is CUDA available: Yes
- CUDA runtime version: Could not collect
- GPU models and configuration: GPU 0: GeForce GTX 1080
- Nvidia driver version: 396.37
- cuDNN version: Probably one of the following:
- /usr/lib/x86_64-linux-gnu/libcudnn.so.7.0.5
- /usr/lib/x86_64-linux-gnu/libcudnn_static_v7.a

Versions of relevant libraries:
- [pip] Could not collect
- [conda] Could not collect
Repository: rust
Issue: Add `String::from_with_capacity(value, capacity)`
Labels: T-libs-api,C-feature-request,A-str

In some situations it would be useful to create a string from a &str with a bigger capacity if it is know that the string is extended later on.

````rust
fn main() {
    let mut s = String::from("Hello world");
    println!("len: {}, cap: {}", s.len(), s.capacity());
    s.push_str("add more characters");
    s.push_str("and more");
    s.push_str("and even more");
    println!("len: {}, cap: {}", s.len(), s.capacity());
}
````
````
len: 11, cap: 11
len: 51, cap: 60
````

To not have unused capacity, I wonder if we could have something like `String::from_with_capacity()`
````rust
fn main() {
    let mut s = String::from_with_capacity("Hello world", 51);
    println!("len: {}, cap: {}", s.len(), s.capacity());
    s.push_str("add more characters");
    s.push_str("and more");
    s.push_str("and even more");
    println!("len: {}, cap: {}", s.len(), s.capacity());
}
````
````
len: 11, cap: 51
len: 51, cap: 51
````

This would be a shorter way of writing
````rust
let mut s = String::with_capacity(51);
s.push_str("Hello world");
....
````
Repository: rust
Issue: Consider replacing RawVec<T> with Box<[MaybeUninit<T>]>.
Labels: A-collections,T-libs

After #53508 lands, we could look into this. It might provide a bit more type-safety, although it could be worse to not have the capacity as a separate field.

~~One thing to note is that setting the "length" component of a reference/pointer to `[MaybeUninit<T>]` is "less unsafe" than doing so for for `[T]`, but it's unclear to me whether having a `&[MaybeUninit<T>]` that's larger than the object it points to, is UB or not.~~ (*please ignore, I managed to confuse myself*)

cc @RalfJung @Gankro @rust-lang/libs
Repository: pytorch
Issue: Specify out= argument to convolution
Labels: module: convolution,triaged,enhancement

Hi,
i want to use the functions in torch._C._thcunn. Is there any docs for that?
what’s the meaning of the parameters?
i find the C code for CudaSpatialFullDilatedConvolution_updateGradInput
```
void THNN_(SpatialFullDilatedConvolution_updateOutput)(
           THCState *state,
           THCTensor *input,
           THCTensor *output,
           THCTensor *weight,
           THCTensor *bias,
           THCTensor *columns,
           THCTensor *ones,
           int kW, int kH,
           int dW, int dH,
           int padW, int padH,
           int dilationW, int dilationH,
           int adjW, int adjH)
```

but i don't know the meaning of the ```state```? How can i specify that variable in python?