sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Better display representation for intersection types
Labels: Suggestion,Help Wanted,Effort: Difficult

<!--
Thank you for contributing to TypeScript! Please review this checklist
       before submitting your issue.
[ ] Many common issues and suggestions are addressed in the FAQ
     https://github.com/Microsoft/TypeScript/wiki/FAQ
[ ] Search for duplicates before logging new issues
    https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=is%3Aissue
[ ] Questions are best asked and answered at Stack Overflow
    http://stackoverflow.com/questions/tagged/typescript

For bug reports, please include the information below.
__________________________________________________________ -->

I'm not sure if this has been discussed before, but join types are mostly unreadable. I think the type should be prettified somehow before being displayed to the user.

**TypeScript Version:** 

1.8

**Code**

``` ts
type T1 = {};
type T2 = {test: number};
type J = T1 & T2;
```

**Expected behavior:**

``` ts
var x: J;
typeof x; // {test: number}
```

**Actual behavior:** 

``` ts
var x: J;
typeof x; // {} & {test: number}
```
Repository: godot
Issue: Godot doesn't support mesh collisions for RigidBody and VehicleBody
Labels: enhancement,topic:physics,topic:3d

**Operating system or device:**
Any

**Issue description** (what happened, and what was expected):
In Unity you can use any convex shape for RigidBody (one can be generated from mesh).
This feature is strangely unimplemented yet.

**Steps to reproduce:**
Well, just adding convex mesh collision to RigidBody and trying to collide should do.
Repository: go
Issue: x/mobile/exp/f32: Mat4.Rotate incorrectly rotates around axes with non-zero X values
Labels: mobile

I have put together the following example to demonstrate a problem with Rotate method on f32.Mat4. I attempt to rotate a ~~vector v~~ (edit: vector u) around the X axis. The resulting vector does not have the same length (in this extreme case the "rotation" has collapsed a unit vector to zero-length). 

http://play.golang.org/p/INyRQCldPm

When I actually use the resulting transformation in OpenGL what I have observed is that my models gets flattened onto a plane (presumably the Y-Z plane, perpendicular to the X axis, at X=0).

I believe the problem lies in how the first row of the rotation matrix is constructed.

https://github.com/golang/mobile/blob/467d8559f22b81884dfbc37d1cef95d0fab78049/exp/f32/mat4.go#L157-L160

I kind of suck at this stuff. But you can see the subsequent rows in the matrix have a pattern which is not observed in the first row. So I tried changing the first row of the rotation matrix to the following. 

```
    {
        c + d*a[0]*a[0],
        0 + d*a[0]*a[1] + s*a[2],
        0 + d*a[0]*a[2] - s*a[1],
        0,
    }
```

And that looks like it works.

The following demonstrates the altered Rotate function: http://play.golang.org/p/8ZrOpdv_AY

This second example confirms rotation of [1, 0, 0] around the X axis yields [1, 0, 0]. Obviously length was preserved.
Repository: neovim
Issue: libsixel support?
Labels: enhancement,ui,tui

https://github.com/saitoha/libsixel is supported by a growing number of applications. Would this be useful for neovim?
Repository: rust
Issue: unresolved symbol imports in -pie musl binaries
Labels: O-musl,C-bug

I've noticed that there are two unresolved symbols when a [PIE](https://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables) is requested via the linker flags with nightly rustc's new musl target, e.g.:

`rust/bin/rustc --target=x86_64-unknown-linux-musl -C link-args="-Wl,-pie" main.rs`

yields a binary with two unresolved imports:

```
ELF X86_64 DYN @ 0x4f71
Imports (2)
          26e3a0 __dso_handle (0) ~> Unknown
          26e3a8 __cxa_thread_atexit_impl (0) ~> Unresolved
```

which you can see with `objdump -R main`:

```
0000000000270fd0 R_X86_64_GLOB_DAT  __cxa_thread_atexit_impl
0000000000271008 R_X86_64_64       __dso_handle
```

but 0 libraries (i.e., `DT_NEEDED`), so having unresolved imports without dynamic library dependencies is essentially an incoherent binary semantics.  (Not having libraries is fine, in fact that's the point of the musl target, and the `-pie` flag should just make it able to be loaded anywhere in memory, but having unresolved imports without dependencies is where it becomes problematic)

Similarly, grepping through the assembly, it looks like `__cxa_thread_atexit_impl` isn't called by anyone, but `__dso_handle` does show up in an external rust linkage symbol (I have no idea what the function of the `__rust_extern_with_linkage____X` is):

```
015:    48 8d 15 ec 7f 26 00    lea    0x267fec(%rip),%rdx        # 271008 <_rust_extern_with_linkage___dso_handle>
```

As such, doesn't seem like it's a major problem, but it is very unusual, and again, the lack of dynamic library dependencies + unresolved symbol imports is a red flag, and should probably be investigated.  My guess is that there is some weird interaction with the `link-args` flag and the generated link commands somehow.
Repository: angular
Issue: Inconsistant projection behavior
Labels: type: bug/fix,freq2: medium,area: core,state: confirmed,core: content projection,design complexity: major,P3

version: `ng2-beta12`
For some reason the order in which templates are defined is causing issues with transclusion.

[Doesn't Work for buttons but works for link](http://plnkr.co/edit/OmMGa65bNfrrQn0i5Wwm?p=preview)

```
<template [ngIf]="href ===''">
    <button [ngClass]="cssClassList">
        <ng-content></ng-content>
    </button>
</template>
<template [ngIf]="href !==''">
    <a [ngClass]="cssClassList" href="href">
        <ng-content></ng-content>
    </a>
</template>
```

![screen shot 2016-03-28 at 10 59 34 am](https://cloud.githubusercontent.com/assets/2133184/14080610/46e6e0a0-f4d4-11e5-9317-4acd79f61101.png)

[Works for buttons but not for links](http://plnkr.co/edit/ccpnmdnU53B5JqZMBnxP?p=preview)

```
<template [ngIf]="href !==''">
    <a [ngClass]="cssClassList" href="href">
        <ng-content></ng-content>
    </a>
</template>
<template [ngIf]="href ===''">
    <button [ngClass]="cssClassList">
        <ng-content></ng-content>
    </button>
</template>
```

![screen shot 2016-03-28 at 10 59 46 am](https://cloud.githubusercontent.com/assets/2133184/14080621/57ccd636-f4d4-11e5-8f57-e5c8fbb856ee.png)
Repository: go
Issue: cmd/compile: BLAS Idamax regression
Labels: Performance,NeedsFix,early-in-cycle

The blas routine Idamax is seeing a regression between 1.6 and tip (go version go version devel +7e88826 Mon Mar 28 14:10:21 2016 +0000 darwin/amd64).

Idamax finds the index with maximum absolute value. 

```
go get -u -t github.com/gonum/blas/native
cd $GOPATH/src/github.com/gonum/blas/native
go test -bench=Ida -tags=noasm -count=5
```

```
IdamaxSmallUnitaryInc-8   32.4ns ± 7%  39.1ns ± 6%  +20.80%  (p=0.008 n=5+5)
IdamaxSmallPosInc-8       28.7ns ±11%  41.1ns ±11%  +43.24%  (p=0.008 n=5+5)
IdamaxMediumUnitaryInc-8  1.58µs ± 2%  2.03µs ± 2%  +27.83%  (p=0.008 n=5+5)
IdamaxMediumPosInc-8      1.86µs ± 2%  2.38µs ±11%  +27.93%  (p=0.008 n=5+5)
IdamaxLargeUnitaryInc-8    150µs ± 2%   195µs ± 1%  +30.23%  (p=0.008 n=5+5)
IdamaxLargePosInc-8        202µs ± 1%   241µs ± 2%  +19.10%  (p=0.008 n=5+5)
IdamaxHugeUnitaryInc-8    15.1ms ± 1%  21.0ms ± 2%  +39.67%  (p=0.008 n=5+5)
IdamaxHugePosInc-8        27.9ms ± 3%  30.0ms ± 2%   +7.38%  (p=0.008 n=5+5)
```

@randall77 @josharian
Repository: go
Issue: doc: add wiki page on using text/template and html/template
Labels: Documentation,help wanted,NeedsInvestigation

I encountered [this comment](https://news.ycombinator.com/item?id=11374024) and its reply on HN. People feel that Go's template support is lacking; I had the same experience but only for lack of better reference documentation and examples. I would like a page added for Go's template support and listed under "Additional Go Programming Wikis".
Repository: go
Issue: x/pkgsite: verbosity dial
Labels: NeedsDecision,Tools,pkgsite

I was joking to David that we should have a slider knob on godoc to choose how much crap in a package we show.

Imagine if a user loaded the net package and they only saw `Dial` and `Listen` and `Conn` by default, but then had to do something to show all the noise.

I'm kinda joking, but kinda not. Maybe there's something to do here.

We've tried to address this in the past with package docs and examples, which helps, but also just adds to the overall noise.

Low priority.

/cc @adg
Repository: go
Issue: text/template: consider broadening the set of built-in template funcs
Labels: NeedsInvestigation

Some programs expect their users to write templates. One of these programs is [`docker-gen`](https://github.com/jwilder/docker-gen), and one of its users filed issue #14992 as they found the template language too restrictive for what they were trying to do.

As it happened, `docker-gen` provided the a template function to let the user do what they wanted (filter a set of structs based on the value of a field, and print something different if no structs with that field set to that specific value are found). That function is documented by the `docker-gen` README:

> `where $items $fieldPath $value`: Filters an array or slice based on the values of a field path expression `$fieldPath`. A field path expression is a dot-delimited list of map keys or struct member names specifying the path from container to a nested value. Returns an array of items having that value.

The `docker-gen` program provides many such functions (see the [README](https://github.com/jwilder/docker-gen/blob/master/README.md) for the full list). Some of them are specific to `docker-gen`'s purpose, but many of them are general purpose (such as `where` above).

Should we add some of these functions (or functions with similar behavior) to the built in set of template functions?

cc @robpike @bradfitz @JonasT
Repository: opencv
Issue: Support custom options in AVCodecContext (av_dict_set) in FFMPEG backend
Labels: feature,category: videoio

I'm looking for guidance in regards to submitting a PR that will allow you to specify raw options (i.e preset) using av_dict_set. This applies to `VideoCapture` and `VideoWriter` The use case here being that you could support encoding videos targeting a specific device (i.e Apple iPad). Or tune encoding performance for a given codec i.e. [VP9](http://www.ffmpeg.org/doxygen/3.0/libvpxenc_8c_source.html#1061)

**Specify backend options by instantiating a new VideoWriter (!?)**

``` cpp
VideoWriter::VideoWriter(const String& filename, int fourcc, double fps, Size frameSize, bool isColor=true, std::map<std::string, std::string> backendOptions)
```
Repository: rust
Issue: incorrect DW_AT_location for static
Labels: A-debuginfo,P-low,T-compiler,C-bug

I'm using rust from the Fedora COPR:

```
bapiya. rustc --version
rustc 1.7.0 (a5d1e7a59 2016-02-29)
```

Consider this program:

```
pub static AA: i32 = 5;

fn main() {
}
```

I compile with `-g` and then examine the DWARF using `readelf`.  I see:

```
 <2><2f>: Abbrev Number: 3 (DW_TAG_variable)
    <30>   DW_AT_name        : (indirect string, offset: 0x48): AA
    <34>   DW_AT_type        : <0x62>
    <38>   DW_AT_decl_file   : 1
    <39>   DW_AT_decl_line   : 1
    <3a>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
    <44>   DW_AT_linkage_name: (indirect string, offset: 0x4f): _ZN2b12AAE
```

Now, this variable is not actually emitted.  There's no ELF symbol for it.  Given this, it seems strange to emit `DW_AT_linkage_name` and `DW_AT_location`, especially considering that the latter is incorrect.
Repository: rust
Issue: DWARF omits typedef
Labels: A-debuginfo,P-low,T-compiler,C-bug

I'm using rustc from the Fedora COPR:

```
bapiya. rustc --version
rustc 1.7.0 (a5d1e7a59 2016-02-29)
```

Consider this program:

```
pub type Xty = fn() -> u32;

fn x() -> u32 {
    return 57u32;
}

pub static AA: Xty = x;

fn main() {
    println!("{}", AA());
}
```

I compile this with `-g` and then look for the type `Xty` in the DWARF using readelf.  It isn't there:

```
bapiya. readelf -wi B1 | grep Xty
bapiya. 
```

If I examine the type of `AA`, it ends up here:

```
 <1><14b>: Abbrev Number: 11 (DW_TAG_pointer_type)
    <14c>   DW_AT_type        : <0x154>
    <150>   DW_AT_name        : (indirect string, offset: 0x4b): fn() -> u32
 <1><154>: Abbrev Number: 12 (DW_TAG_subroutine_type)
    <155>   DW_AT_type        : <0x159>
[...]
```

That is, the typedef has been dropped.
Repository: youtube-dl
Issue: support for joj.sk site
Labels: site-support-request

- [x] I've **verified** and **I assure** that I'm running youtube-dl **2016.03.27**
### Before submitting an _issue_ make sure you have:
- [X] At least skimmed through [README](https://github.com/rg3/youtube-dl/blob/master/README.md) and **most notably** [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [X] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
### What is the purpose of your _issue_?
- [ ] Bug report (encountered problems with youtube-dl)
- [X] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other
### Example URLs
- Single video: http://dizajn.joj.sk/nove-byvanie-dizajn-archiv/2016-03-06-nove-byvanie-dizajn-premiera.html
- Single video: http://zoo.joj.sk/zoo-epizody/2016-03-23-zoo.html
Repository: TypeScript
Issue: Suggestion: execute property initializer expressions at the expected time
Labels: Suggestion,Committed

Currently, TS moves property initializers in a way that can be suprising and lead to subtle problems.  Eg, Issue #7644, but I've seen it in other places.  Another example which I ran into in a PL class (while trying to demonstrate something else...):

```
let y = 1;
class Foo {
    private x = y;
    constructor(y) {
    }
}
```

The error message for this is confusing, but IMO it is expected since it's the _behavior_ of these things that is confusing.  That's a result of moving the expressions into a different scope than the original source and also a different time (in the constructor call instead of when the class is generated).

So I think that it would be much better (and solve a bunch of issues around this area) if the emitted code would evaluate the initializer expressions at a proper time, for example, producing this code for the above:

```
var y = 1;
var Foo = (function () {
    var _y_init = y;
    function Foo(y) {
        this.x = _y_init;
    }
    return Foo;
}());
```

I'm gussing that (some of) the reasons to not do that are being able to refer to `this` in these expressions, and the fact that you get values that are shared for all instances (eg, with a `private x = {}` initializer).  Personally, I'd argue that neither of these is worth keeping: before I dug into this I _assumed_ that a `{}` value would be shared, and I never considered using `this.` on the RHS, since I automatically didn't assume that there exists one that can be used.

But assuming that it's hopeless to fix this completely (since it'd break code in subtle and potentially disastrous ways), so the unexpected (for me) execution order must stick.  But the scope breakage is more subtle and more important, so how about fixing just _that_ with something like:

```
var y = 1;
var Foo = (function () {
    function _init(_this) {
        _this.x = y;
    }
    function Foo(y) {
        _init(this);
    }
    return Foo;
}());
```

And it would be nice if such an `_init` thing is _consistently_ done after a `super()` when there is one, since the time when these expressions are evaluated is changed anyway, there's no reason for people to expect them to happen before a `super` (and such an expectation now is unreliable since the initialization happens, AFAICT, either before or after a `super`).
Repository: go
Issue: cmd/compile: unnecessary branching
Labels: Performance,compiler/runtime

```
type T struct {
    x, y, z int
}
func f(x interface{}) int {
    t, ok := x.(*T)
    if ok && t != nil {
        return 7
    }
    return 3
}
```

The SSA compiler for this function generates some extra branching logic that seems unnecessary.

```
    0x0000 00000 (bin.go:12)    LEAQ    type.*"".T(SB), AX
    0x0007 00007 (bin.go:8) MOVQ    "".x+8(FP), CX
    0x000c 00012 (bin.go:8) CMPQ    AX, CX
    0x000f 00015 (bin.go:8) JNE $0, 49
    0x0011 00017 (bin.go:7) MOVQ    "".x+16(FP), AX
    0x0016 00022 (bin.go:9) JNE 29
    0x0018 00024 (bin.go:9) TESTQ   AX, AX
    0x001b 00027 (bin.go:9) JNE $0, 39
    0x001d 00029 (bin.go:12)    MOVQ    $3, "".~r1+24(FP)
    0x0026 00038 (bin.go:12)    RET
    0x0027 00039 (bin.go:10)    MOVQ    $7, "".~r1+24(FP)
    0x0030 00048 (bin.go:10)    RET
    0x0031 00049 (bin.go:8) MOVQ    $0, AX
    0x0038 00056 (bin.go:9) JMP 22
```

The 4th line there could be JNE directly to line 29.  Instead it goes to 49/56, rejoins the main flow at 22, and then goes to 29.
Something wrong with the shortcircuit pass, maybe?
Repository: You-Dont-Know-JS
Issue: `.constructor` not restored in Chapter 5 : "(Prototypal) Inheritance"
Labels: for second edition

I generally agree with `.constructor` being unreliable and understand the explanations give in this chapter. I do worry about one detail toward the end of the "(Prototypal) Inheritance" section. 

When using either `new Foo()` or `Object.create(Foo.prototype)`, you replace the default `Bar.prototype` object with the newly created one in both cases. This also removes the default `.constructor` as you mention in the section above "(Prototypal) Inheritance". I think it would be valuable to re-iterate what happens to `Bar.prototype.constructor` here as well. 

Perhaps something along the lines (to match tone?), "Once you've created this new object, you can see that it's `.constructor` property returns Foo {}, which is wrong. All the more reason to avoid relying on `.constructor`!" and some reference to the section explaining why again?
Repository: go
Issue: cmd/cgo: unexpected allocations when passing void pointers
Labels: compiler/runtime

1. What version of Go are you using (`go version`)? **go1.6**
2. What operating system and processor architecture are you using (`go env`)? **linux/amd64**
3. What did you do?

I was helping to debug several unaccounted for allocations and we came across what we thought was very peculiar behavior. Consider the following two implementations of the same package

http://play.golang.org/p/hC-b5VSG58
http://play.golang.org/p/soCMGF1WjG

And the following benchmark

http://play.golang.org/p/e37ObBxwJP
1. What did you expect to see?

Neither implementation appears to allocate anything in the Foo function. So I expect `go test -bench` to report zero allocations for both implementations of the package.
1. What did you see instead?

For the first example (hC-b5VSG58) the command `go test -bench=. -benchmem` reports two allocations (48 bytes total) when the C function is passed a non-nil argument.

```
$ go test -bench=. -benchmem
testing: warning: no tests to run
PASS
BenchmarkFoo-4           5000000               317 ns/op              48 B/op          2 allocs/op
BenchmarkFoo_nil-4      10000000               164 ns/op               0 B/op          0 allocs/op
ok      github.com/bmatsuo/lmdb-go/tmp/cgo-allocs       3.718s
```

The second example avoids any allocation.

```
$ go test -bench=. -benchmem
testing: warning: no tests to run
PASS
BenchmarkFoo-4          10000000               151 ns/op               0 B/op          0 allocs/op
BenchmarkFoo_nil-4      10000000               151 ns/op               0 B/op          0 allocs/op
ok      github.com/bmatsuo/lmdb-go/tmp/cgo-allocs       3.345s
```

The first example does see a performance impact, I assume because of the allocations.
Repository: thefuck
Issue: white-space safe 'thefuck' with the history line passed as a single arg?
Labels: help wanted

In some shells' thefuck alias, e.g. for bash, the core part falls to:

``` bash
# https://github.com/nvbn/thefuck/blob/master/thefuck/shells/bash.py#L13
eval $(BUNCH_OF_VARIABLES=something thefuck $(fc -ln -1)))
```

But `$(fc -ln -1)` is not a safe thing to try. In python terminology, `$(fc -ln -1)` is something like:

``` Python
reduce(op.add, (glob.glob(i) or [i] for i in shell_stdout(['fc', '-ln', '-1']).split()))
```

which is almost certainly not the thing you are looking for. Similarly, `$TF_CMD` gets split and globbed and list-joined (and `' '.join()`'ed by `eval`) in `eval $TF_CMD`.

For POSIX shells like bash and zsh (well, POSIX-ish) this can be solved by passing in the whole history string and actually interpreting the results of `shlex.split(thestring)` (which seems to be done already somewhere in the source). For other shells.. perhaps a custom lexer?

tcsh seems to suffer from the same problem, but I am not a tcsh expert so I may be wrong:

``` csh
A2:~# sh -xvc ': "$@"' -- `echo 'foo bar /*'`
: "$@"
+ : foo bar /bin /boot /dev /etc /home /initrd.img /initrd.img.old /lib /lib32 /lib64 /libx32 /lost+found /media /mnt /opt /proc /pub /root /run /sbin /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old
```

(using sh for some arg dump that makes sense)
Repository: rust
Issue: Better diagnostics for error: can't find crate for `...` [E0463]
Labels: C-enhancement,A-diagnostics,T-compiler

It would be nice if rustc would print the search directory for a crate and rejected crates (with matching names) in those directories when it cannot find the crate.
Repository: TypeScript
Issue: add a modifier for pure functions
Labels: Suggestion,Needs Proposal

This is what pure means:
1. no destructive operations on parameters
2. all parameters must be guaranteed from being changed from the outside (immutable?)
2. no calls to any other callback/function/method/constructor that doesn't have the pure modifier
3. no reads from mutable values from a scope the pure function is closed over
4. no writes to values in the closed scope
Repository: TypeScript
Issue: Suggestion: use receiver's declared type arguments as defaults to its class constructor
Labels: Suggestion,Help Wanted,Effort: Difficult

I run into this relatively simple pattern a lot:

``` ts
class GenericClass<T, U, V> {
    a: T;
    b: U;
    c: V;
}

let x: GenericClass<number, string, boolean>;

x = new GenericClass();
// Which produces the error:
// Error: GenericClass<{}, {}, {}> is not assignable to GenericClass<number, string, boolean>
```

Since `x` has already been defined with a particular set of type arguments, these arguments could be implicitly assumed as defaults to its type's constructor when invoked with it being the receiver (for simplicity I'm assuming here it is the exact constructor as declared e.g. not a derived class).

I understand there will be cases where that would be very difficult or even impossible to achieve:

``` ts
let createInstance = () => new GenericClass()
x = createInstance();
```

but these are relatively rare. Most of the time it's just:

``` ts
class Example {
    myMap: Map<string, Array<{n: number}>>;

    constructor() {
        this.myMap = new Map<string, Array<{n: number}>>(); // <-- Why repeat?
    }
}
```

Which instead could have been:

``` ts
class Example {
    myMap: Map<string, Array<{n: number}>>;

    constructor() {
        this.myMap = new Map(); // <-- Better.. :)
    }
}
```
- Any possible issues with this? perhaps ones that I'm not aware of or haven't thought of?
- Potential name collisions? (though I'm not aware of any?)
- Maybe just a bit too difficult to implement? perhaps revisit later? (though #5256 appears more difficult than this and seems to be in consideration?)
- Or maybe this 'bends' the semantics of the constructor expression (`new Class<T>()`), or at least its default type arguments, in a way that's slightly unappealing from a "purist" point of view"? (though this doesn't seem like a "purist" language?). Perhaps some concept of "contextual baseline default type arguments" can be included as an integral part of the future proposal for [default type arguments](https://github.com/Microsoft/TypeScript/issues/2175)?