sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: debug/dwarf: No method to lookup type by type signature
Labels: compiler/runtime

The dwarf package internally has support for finding type entries by type signature, but it does not expose this to users of the dwarf package. (*Data).Type takes an "info" offset of a type entry and understands internally how to follow AttrType fields within that type that reference other types by signature. But AttrType can also be used on program entities to reference the type of that entity (e.g., the type of a variable), and any occurrence of AttrType can be either an "info" offset, which can be resolved by the package user; or a type signature, which cannot currently be resolved by the package user.

In practice this often isn't an issue because compilers that emit type signatures typically do so for typedef'd types (since there's little value in doing this for a single instance type), so the AttrType of the program entity will be an "info" offset of the typedef and that, in turn, will reference the type signature. However, compilers are free to do what they want and may emit type signatures in program entities, making the current API fragile. There's also no way for a caller to do its own decoding of the type structure if it references types by signature.

Consider adding an API to fetch a type by its signature. This could be accomplished by simply exposing (_Data).sigToType, but this puts the burden of distinguishing "info" offests and type signatures on the user. We could instead add a variant of (_Data).Type that takes a Val (really an interface{}) and does the appropriate kind of lookup.

Orthogonally, this new method could return either a dwarf.Type or a dwarf.Entry. Returning dwarf.Type forces the user to accept the dwarf package's decoding of the type structure. On the other hand, a method to resolve a type offset or signature into an Entry and another method to decode an Entry into a Type would be more flexible and would expose the ability to read the types section without forcing the caller to use dwarf.Type.

See related discussion at https://go-review.googlesource.com/#/c/7280/
Repository: rust
Issue: Coherence error messages can be inscrutable
Labels: E-hard,A-diagnostics,P-medium,T-compiler,C-bug

In particular, when the overlap check fails, it doesn't give much clarity, particularly when the overlap is between impls in different crates. It should tell you:
1. Precisely what type overlaps
2. For each case of negative reasoning it was not able to make, why it was not able to make it.
#2 might be a bit tricky to do, not sure, but we can certainly improve on current state of affairs.
Repository: go
Issue: x/tools/cmd/eg: take better care with pointers, maintain addressability of expressions
Labels: NeedsInvestigation

Given this package:

``` go
package egbug

var Imap = map[*T]int{}

type T struct {
    I int
}

func main() {
    var t T
    p := &t.I
    _ = p
}
```

and this template:

``` go
package p

import "egbug"

func before(t *egbug.T) int { return t.I }
func after(t *egbug.T) int  { return egbug.Imap[t] }
```

applying eg generates uncompilable code:

``` go
package egbug

var Imap = map[*T]int{}

type T struct {
    I int
}

func main() {
    var t T
    p := &Imap[t]
    _ = p
}
```

``` bash
$ go build
# egbug
./x.go:11: cannot use t (type T) as type *T in map index
./x.go:11: cannot take the address of Imap[t]
```

There are two separate bugs here--T vs *T and breaking addressability.

This is a real life example, from attempting to use `eg` to instrument the gc compiler to find correlations in Node field usage.
Repository: go
Issue: x/mobile/app: detect device orientation
Labels: mobile

A function that returns the device's current orientation would be handy to switch between portrait- and landscape-optimized user interfaces.

``` go
const (
   OrientationLandscape = iota
   OrientationPortrait
   // ...
)

func Orientation() int
```

Thoughts? cc/ @crawshaw @hyangah
Repository: go
Issue: x/mobile/exp/audio: support audio streaming
Labels: mobile

Currently, the audio player has a naive OpenAL backend that buffers the entire source into the memory to prepare the media. We currently can only recommend the audio player to play small audio files such as sound effects.

In order to relax this restriction we should limit the generation of OpenAL buffers and reuse them as the source is done processing. The number of buffers to be generated are limited on some platforms, such as iOS, to certain number. The rate of processing, and the host device's resources are both critical in the determination of the number of active buffers.
Repository: TypeScript
Issue: Generic decorators - could they receive some default type arguments?
Labels: Suggestion,In Discussion,Domain: Decorators

A decorator can receive arguments, by being defined as a function that accepts parameters and then returns a normal decorator function:

```
function computed(evaluator: (obj: any) => any) {
    return (obj: any, key: string) => {
        Object.defineProperty(obj, key, { 
            get() { return evaluator(obj); }
        });
    };
}
```

I could use the above example like this:

```
class C {
    firstName = "Homer";
    lastName = "Simpson";

    @computed(c => c.firstName + " " + c.lastName) 
    fullName: string;
}
```

Not a realistic example in that it's just another way of defining a property getter, but it's enough to demonstrates the general problem: `c` is of type `any` so the access to `firstName` and `lastName` is not type-checked, and nor is the result of the expression.

We can attempt to address this manually, because decorators can be generic:

```
function computed<O, R>(evaluator: (obj: O) => R) {
    return (obj: O, key: string) => {
        Object.defineProperty(obj, key, { 
            get() { return evaluator(obj); }
        });
    };
}

class C {
    firstName = "Homer";
    lastName = "Simpson";

    @computed<C, string>(c => c.firstName + " " + c.lastName)
    fullName: string;
}
```

But this still doesn't close the loop. The compiler is happy with the following abuse, in which `c` is supposedly a `string` but is actually a `C`, and `fullName` is declared a `string` but will actually become a `number` (albeit `NaN` I guess):

```
@computed<string, number>(c => parseInt(c, 10))
fullName: string;
```

In summary: decorators are passed the values of the meta-information in standard parameters (`target`, `key`, `value`), but they are not passed the compile-time types of those values in a way that can be used to create fully type-safe decorators.

So it would be helpful if in decorator-defining functions with generic parameters, those parameters could somehow map automatically to the types of `target` and `value` (as given meaning in the `__decorate` helper).

For big yucks, a straw man in which the compiler recognises a couple of built-in decorators that can appear on the type parameters:

```
function computed<@decoratorTarget O, @decoratorValue R>(evaluator: (obj: O) => R) {
    ...
}
```

Being decorated in this way, it would not be possible to manually specify type arguments for those type parameters when using the decorator. They would effectively be invisible to the user. If the decorator has its own custom type parameters, they would appear from the outside to be the only parameters (and for clarity should be at the front of the list).
Repository: rust
Issue: Trait impls from where clauses (`ParamEnv`) take precedence over freestanding trait impls
Labels: A-trait-system,T-compiler,C-bug,T-types

I stumbled upon this trying to write a function that generically takes a range (or something else with which `str` can be indexed), and slices a str with that range. I got that to work, this bug comes into play when the str is produced by slicing another string with a `RangeFrom` or another concrete type (in the same function).

Here's a simpler (no lifetimes, no associated types) and self-contained example ([playpen](http://is.gd/f5auhw)):

``` rust
trait Frobnicate<I> {
    fn frob(&self, i: I) -> Self;
}

struct Thing;

struct IA;
struct IB;

impl Frobnicate<IA> for Thing {
    fn frob(&self, _i: IA) -> Thing { Thing }
}

impl Frobnicate<IB> for Thing {
    fn frob(&self, _i: IB) -> Thing { Thing }
}

fn delegate_frob<I>(t: Thing, i: I) -> Thing
        where Thing : Frobnicate<I> {
    let t2: Thing = t.frob(IA);
    t2.frob(i)
}

fn main() {}
```

This seems innocent enough. There's a `impl Frobnicate<IA> for Thing`, so the `.frob(IA)` call should work, and it's known to return `Thing` again, so via the `where` clause the `.frob(i)` call is good as well. However, I get this error message:

```
<anon>:20:28: 20:30 error: mismatched types:
 expected `I`,
    found `IA`
(expected type parameter,
    found struct `IA`) [E0308]
<anon>:20     let t2: Thing = t.frob(IA);
                                     ^~
```

It appears that the where clause makes the compiler forget that there are other impls.
Adding a `Thing : Frobnicate<IA>` bound only makes the compiler (rightly) complain that that's not a bound at all, since it doesn't involve any type parameters.
UFCS makes it compile, though:

``` rust
    let t2: Thing = <Thing as Frobnicate<IA>>::frob(&t, IA);
```

Edit: Besides playpen, I can also reproduce this locally:

```
rustc 1.0.0-beta (9854143cb 2015-04-02) (built 2015-04-02)
binary: rustc
commit-hash: 9854143cba679834bc4ef932858cd5303f015a0e
commit-date: 2015-04-02
build-date: 2015-04-02
host: x86_64-pc-windows-gnu
release: 1.0.0-beta
```

But I already noticed it a couple of weeks ago, so it can't be a recent regression.
Repository: go
Issue: net: File method of Conn on Windows
Labels: help wanted,OS-Windows

I am writing something that requires access to the file descriptor of a socket created by net.Dial (which returns a net.conn)  and then recast as net.TCPConn so that I can use net.TCPConn.File().Fd().

However, (as the error message says), "dup is not supported on windows". for my purposes, I don't "need" the dup() and would love to settle for just getting the raw file descriptor, but sadly the code within conn.File() appears as follows.

https://golang.org/src/net/net.go?s=5510:5555#L195

``` golang
func (c *conn) File() (f *os.File, err error) { return c.fd.dup() }
```

Is there any way I could ask for an "if windows then just return c.fd" option? Hopefully this request isn't a waste of time, I am far from an expert on go.
Repository: nvm
Issue: Write tests for bare `nvm run X`
Labels: testing,pull request wanted

In order to test this, I'd need to figure out some way to intercept the call to `nvm-exec`, or, to intercept its call to `exec`.

From #625.
Repository: rust
Issue: Numeric fallbacks don't work when inherent methods are involved
Labels: A-type-system,T-lang,T-compiler,A-inference,C-bug,T-types

I would expect `2.0.sqrt()` to return sqrt(2) as a f64. Instead,

```
<anon>:9:13: 9:19 error: type `_` does not implement any method in scope named `sqrt`
<anon>:9         2.0.sqrt()

<anon>:9:19: 9:19 help: methods from traits can only be called if the trait is in scope; the following traits are implemented but not in scope, perhaps add a `use` for one of them:
<anon>:9:19: 9:19 help: candidate #1: use `std::num::Float`
<anon>:9:19: 9:19 help: candidate #2: use `core::num::Float`
```

... and the Float trait is deprecated!

This also occurs with integer literals.

I ran into this in the wild while doing an exponential decay: 

``` rust
let k = c * 2.0.powf(-1.0 * scale * dt);
```

A workaround is to annotate the literal's type explicitly.
Repository: neovim
Issue: Terminal buffers don't respect `bufhidden` when not `hide` or `delete`
Labels: terminal

With a master build from a few days ago, terminal buffers seem to be deleted when the windows showing them is closed. This seems to contradict the usual usage patterns where buffers live until they are explicitly deleted by the user. Moreover, I'd like to be able to use a terminal session for some time, put it into the background, an reload it into a split once I need it back.
Repository: go
Issue: cmd/compile: assigning large values does not use memmove
Labels: compiler/runtime

Consider this piece of code

```
package main

import "fmt"

func main() {
        f()
}

func f() {
        var a [200]int
        var b [200]int

        a = b
        b = a

        fmt.Println(&a, &b)
}
```

The assignments of `a = b` or `b = a` where the size of `a` or `b` is above the DUFFCOPY limit of 128 words produces some very simplistic code

```
        a = b
   10c60:       e1a01004        mov     r1, r4
   10c64:       e1a00005        mov     r0, r5
   10c68:       e2843e32        add     r3, r4, #800    ; 0x320
   10c6c:       e4912004        ldr     r2, [r1], #4
   10c70:       e4802004        str     r2, [r0], #4
   10c74:       e1530001        cmp     r3, r1
   10c78:       1afffffb        bne     10c6c <main.f+0x4c>
        b = a
   10c7c:       e1a01005        mov     r1, r5
   10c80:       e1a00004        mov     r0, r4
   10c84:       e2853e32        add     r3, r5, #800    ; 0x320
   10c88:       e4912004        ldr     r2, [r1], #4
   10c8c:       e4802004        str     r2, [r0], #4
   10c90:       e1530001        cmp     r3, r1
   10c94:       1afffffb        bne     10c88 <main.f+0x68>
```

Should `sgen/stackcopy` take the opportunity to setup a call to `runtime.memmove` for values larger than 128 words ?
Repository: rust
Issue: regression: dead heap allocations aren't optimized out anymore
Labels: A-LLVM,I-slow,C-enhancement,A-codegen,P-medium,T-compiler,C-optimization

#22159 was closed after a llvm update (#22526). It used to work (I remember I tried it out). Now it doesn't work anymore.

``` rust
fn main() {
    let _ = Box::new(42);
}
```

http://is.gd/Wekr7w

LLVM-IR:

``` llvm
; ModuleID = 'rust_out.0.rs'
target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: uwtable
define internal void @_ZN4main20h657e6a8d1dc11120eaaE() unnamed_addr #0 {
entry-block:
  %0 = tail call i8* @je_mallocx(i64 4, i32 0)
  %1 = icmp eq i8* %0, null
  br i1 %1, label %then-block-57-.i.i, label %"_ZN5boxed12Box$LT$T$GT$3new19h823444268625886800E.exit"

then-block-57-.i.i:                               ; preds = %entry-block
  tail call void @_ZN3oom20he7076b57c17ed7c6HYaE()
  unreachable

"_ZN5boxed12Box$LT$T$GT$3new19h823444268625886800E.exit": ; preds = %entry-block
  %2 = bitcast i8* %0 to i32*
  store i32 42, i32* %2, align 4
  %3 = icmp eq i8* %0, inttoptr (i64 2097865012304223517 to i8*)
  br i1 %3, label %"_ZN14Box$LT$i32$GT$8drop.86517h1e7c6ecb62969b35E.exit", label %cond.i

cond.i:                                           ; preds = %"_ZN5boxed12Box$LT$T$GT$3new19h823444268625886800E.exit"
  tail call void @je_sdallocx(i8* %0, i64 4, i32 0)
  br label %"_ZN14Box$LT$i32$GT$8drop.86517h1e7c6ecb62969b35E.exit"

"_ZN14Box$LT$i32$GT$8drop.86517h1e7c6ecb62969b35E.exit": ; preds = %"_ZN5boxed12Box$LT$T$GT$3new19h823444268625886800E.exit", %cond.i
  ret void
}

define i64 @main(i64, i8**) unnamed_addr #1 {
top:
  %2 = tail call i64 @_ZN2rt10lang_start20he050f8de3bcc02b7VRIE(i8* bitcast (void ()* @_ZN4main20h657e6a8d1dc11120eaaE to i8*), i64 %0, i8** %1)
  ret i64 %2
}

declare i64 @_ZN2rt10lang_start20he050f8de3bcc02b7VRIE(i8*, i64, i8**) unnamed_addr #1

declare noalias i8* @je_mallocx(i64, i32) unnamed_addr #1

; Function Attrs: cold noinline noreturn
declare void @_ZN3oom20he7076b57c17ed7c6HYaE() unnamed_addr #2

declare void @je_sdallocx(i8*, i64, i32) unnamed_addr #1

attributes #0 = { uwtable "split-stack" }
attributes #1 = { "split-stack" }
attributes #2 = { cold noinline noreturn "split-stack" }
```
Repository: go
Issue: cmd/compile: use conditional execution in place of branches for small blocks on arm
Labels: NeedsInvestigation

For example, consider max:

``` go
func max(a, b int) int {
    if a > b {
        return a
    }
    return b
}
```

This compiles roughly to:

```
MOVW    "".a(FP), R3
MOVW    "".b+4(FP), R2
CMP R2, R3
BLE a
MOVW    R3, "".~r2+8(FP)
RET
a:
MOVW    R2, "".~r2+8(FP)
RET
```

But it could be:

```
MOVW    "".a(FP), R3
MOVW    "".b+4(FP), R2
CMP R2, R3
MOVW.LE R2, "".~r2+8(FP)
RET.LE
MOVW    R3, "".~r2+8(FP)
RET
```

The general guidance from ARM is that it is worth branching instead of using conditional instructions when you reach 4-6 conditional instructions.

It's unclear to me when this should be done:
- during codegen (would require significant state to be passed around)
- as a peephole optimization
- at instruction selection time (since it already moves branch sequences around)
- as part of the 1.6 SSA effort (probably the best option)

Not urgent.

/cc @davecheney @4ad @minux
Repository: go
Issue: x/review/git-codereview: give an error if the Change-Id: line is deleted
Labels: NeedsInvestigation

I think this is the reason why some CLs have more than one Gerrit
CL.

Given that using the same change to open a fresh new gerrit CL is
rarely needed, I think git-codereview should error out if the user
deletes the Change-Id: line (with git change).

And we can add a -f option to override the error (I'm also fine with
let the user `git commit --amend` to manually remove the Change-Id.)

Of course, git-codereview probably can't detect the case where
the user has used `git commit --amend` to remove the Change-Id,
but our contribution guideline uses git change, so the proposed
check should catch most problems.
Repository: youtube-dl
Issue: add bbc archive
Labels: site-support-request

hi,

could you add support for bbc archive? thanks

example page: http://www.bbc.co.uk/archive/whatwewore/5607.shtml

```
$ youtube-dl http://www.bbc.co.uk/archive/whatwewore/5607.shtml
[generic] 5607: Requesting header
WARNING: Falling back on generic information extractor.
[generic] 5607: Downloading webpage
[generic] 5607: Extracting information
ERROR: Unsupported URL: http://www.bbc.co.uk/archive/whatwewore/5607.shtml
$ 
```
Repository: youtube-dl
Issue: Display speed and percentage when updating
Labels: request,build/update
Repository: TypeScript
Issue: Define assignability relation for primitive-constrained type parameters
Labels: Suggestion,Help Wanted

The spec does not define any case in Assignment Compatibility where `S` is a type parameter constrained to a primitive type and `T` is that same primitive type.

This leads to some weird errors, e.g. `T` is not assignable to `number` even though `T extends number`:

``` ts
enum E { A, B, C }
enum F { X, Y, Z }

function f<T extends number>(x: T[]): T {
    var y: number = x[0]; // Error, T is not assignable to number...??
} 

// f<T extends number> is useful:
var x = f([E.A, E.B]); // ok, x: E
var y = f([F.X, F.Y]); // ok, y: F
var z = f(['foo', 'bar']); // Error
```

See also http://stackoverflow.com/questions/29545216/inconsistent-behavior-of-enum-as-constrained-parameter-in-generic
Repository: go
Issue: gccgo: "incompatible type in initialization" is too vague
Labels: NeedsInvestigation

The error "incompatible type in initialization"  is not very informative, here is a simple patch that of course could be better but shows the error.

https://github.com/h4ck3rm1k3/gcc-1/commit/ba7845236966facf2a3a20e6a2c1817b59b9a913
Repository: javascript
Issue: Suggestion to set up Github Page
Labels: enhancement,question

Maybe you want to set up a [GitHub Page](https://pages.github.com/) and get the custom domain [styleguide.js.org](http://dns.js.org) for free.
(renaming the repo to `styleguide` would be required)
Repository: TypeScript
Issue: Flow type helpers
Labels: Suggestion,Needs Proposal

Flow offer some nice type helpers in his recent versions, while some of them are already addressed by typescript, some could perhaps be helpful.
Here are extracted comments from flow source just for inspiration.
- $Either<...T> is the union of types ...T 
- $All<...T> is the intersection of types ...T 
- $Supertype<T> acts as any over supertypes of T 
- $Subtype<T> acts as any over subtypes of T 
- $Shape<T> matches the shape of T 
- $Diff<T,S> 
- $Enum<T> is the set of keys of T 
- $Record<T> is the type of objects whose keys are those of T
Repository: neovim
Issue: Dynamically change `undofile()` / multiple undo trees per file
Labels: enhancement

I often see that undofiles are not being taken into account anymore, which is likely to be caused by changing branches in Git etc, where the file contents then does not match anymore the expected contents - which then causes the undo information to be discarded.

A good workaround for this might be to use additional information in the undo filename, like the current Git branch.  This could be done by allowing to override the `undofile()` function used by Vim.

A better fix might be if Neovim could store multiple branches of the file in the default undo file by itself.  I.e., if there is no entry for the current file's hash, it would create a new entry / root in the undo file.
When you then change back to another branch, the previous undo file entry would be used again.
Repository: rust
Issue: name-based comparison in new label-shadowing check has likely hygiene issues.
Labels: P-low,A-macros,T-compiler,C-bug,A-hygiene

Spawned off of #24162.  Our lifetimes only carry a `Name`, not an `Ident`, which means the comparisons for shadowing are only doing name based comparisons.

But macros should be free to introduce labels, and have them be treated as independent due to hygiene.

This bug is believed to only introduce issues where code will cause a warning to be emitted by the new shadowing check when it should be accepted; i.e. there are not any known soundness issues associated with this problem.

(Note: While loop labels themselves are `Ident`s, much of the syntax system does not treat them the same way it treats "normal" variables with respect to e.g. hygiene.  For example the `syntax::visit` system does not invoke `visit_ident` on loop labels.)
Repository: youtube-dl
Issue: add support for spoilertv.com
Labels: site-support-request

URL: http://www.spoilertv.com/2015/04/mr-robot-first-look-full-promo.html
Repository: neovim
Issue: perf: in_id_list()
Labels: performance,bug-vim,syntax

When setting `cursorline` or `relativenumber` and opening a LaTeX file, the UI become sluggish and slow. This is a known problem in vim as well but I figured out maybe the UI refactoring that is going on makes it a good time to check it out. If it's not in its place, please let me know and I'll close.
Repository: rust
Issue: rustdoc: Pain points of reexports
Labels: T-rustdoc,metabug,C-tracking-issue,A-cross-crate-reexports

There's a lot of pain points that come up over time about rustdoc and reexports, and there's a lot of open issues as well, so this is going to serve as a metabug connecting all of them:
- [x] When a name is reexported across crates, the source crate does not show where it was reexported as (often the more canonical location). #13414
- [x] Lifetime parameters on functions can be lost. #14462
- [x] Private implementors are showing up. #14586
- [ ] Search results return more than one instance. #15723
- [ ] Information about type aliases is lost across crates. #15823
- [x] Methods can be missing from the search index. #20246
- [x] Macro source looks... interesting. #21311
- [ ] Incoming hyperlinks go to the source crate, not the "canonical location". #22083
- [x] Some `Self: Sized` bounds are lost. #24183
- [x] Sometimes reexports just don't show at all #24296
- [ ] Inclusion changes order of impl blocks #32290 
- [x] Only type namespace shows up when processing re-export of private module #34843
- [x] Re-exported enum variants don't show up in documentation #35488
- [x] Many times re-exported type shows wrong documentation page #37608

This is just a list of the _current set_ of bugs, there have been countless others that have been fixed over time. Some of these are fundamental limitations, some of these are just bug fixes. I think that a huge part of "truly fixing this" will be tracking where the "canonical location" for a type is. For example rustdoc should understand that `Vec` traditionally comes from the standard library, not `libcollections`, and all incoming links, references, etc, should go there.

I'll try to keep this updated over time!