sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Can’t declare lifetime for closure that returns a reference
Labels: A-closures,T-compiler,C-bug

When you declare closure argument types, there is no syntax to declare a lifetime parameter. And I guess lifetime elision does not apply to closures. Therefore, there seems to be no way to declare the type of a closure that returns a reference.

It compiles if you avoid declaring the type of the closure and depend on type inference. But then you would not be able to assign the closure to a local variable.

```
fn print_first(list: Vec<String>) {
    let x: &str = list
    .first()
    .map(|s: &String| -> &str &s[])  // ERROR 
    //.map(|s: &String| &s[]) // ERROR
    //.map(|s| -> &str &s[]) // ERROR
    //.map(|s| &s[])  // OK
    .unwrap_or("");
    println!("First element is {}", x);
}
```

It gives a compiler error and a suggestion that does not make sense.

```
    src/rusttest.rs:4:29: 4:32 error: cannot infer an appropriate lifetime for lifetime parameter 'a in function call due to conflicting requirements
    src/rusttest.rs:4   .map(|s: &String| -> &str &s[])
                                                   ^~~
    src/rusttest.rs:1:1: 10:2 help: consider using an explicit lifetime parameter as shown: fn print_first<'a>(list: Vec<String>)
    src/rusttest.rs:1 fn print_first(list: Vec<String>) {
    src/rusttest.rs:2   let x: &str = list
    src/rusttest.rs:3   .first()
    src/rusttest.rs:4   .map(|s: &String| -> &str &s[])  // ERROR
    src/rusttest.rs:5   //.map(|s: &String| &s[]) // ERROR
    src/rusttest.rs:6   //.map(|s| -> &str &s[]) // ERROR
```

This bug is filed after I asked this [question on stack overflow](http://stackoverflow.com/questions/28512314/how-do-i-get-lifetime-of-reference-to-owned-object-cannot-infer-an-appropriate). It may be related to [Region inference fails for closure parameter #17004](https://github.com/rust-lang/rust/issues/17004).
Repository: node
Issue: vm: references to context inside objects are not === the original context
Labels: vm

Failing test case:

``` js
var common = require('../common');
var assert = require('assert');
var vm = require('vm');

var sandbox = {};
sandbox.document = { defaultView: sandbox };

vm.createContext(sandbox);

vm.runInContext('var result = document.defaultView === this', sandbox);

assert.equal(sandbox.result, true);
```

Investigating this in my local build ... this is the only remaining test suite failure after switching jsdom to io.js vm.
Repository: go
Issue: cmd/go: build the cgo artifacts for each package in parallel
Labels: ToolSpeed

The lack of parallelization for compilations within a single package doesn't matter too much when building go files, but does affect cgo compilation. I have a package with about 32k lines of (generated) C++. Compiling it serially takes ~10.5s. A small hack to cmd/go/build.go to compile C/C++/Obj-C files in parallel brings this down to ~3.7s.

The patch I hacked together to parallelize cgo compilation work is ~50 lines of deltas and is mostly contained in `builder.cgo()`.

PS The compilation times above were measured using go 1.4.1 on Mac OS X, but this code hasn't changed at head and similar compilation times can be seen there.
Repository: rust
Issue: rustc need a way to generate versioned libraries
Labels: O-linux,P-low,T-compiler,T-dev-tools,C-feature-request

The traditionnal way for a package distribution system (think `dpkg` for Debian, or `ports` under OpenBSD) to copte with upgrade of shared libraries is to have libraries with versioned number like `libfoo.so.MAJOR.MINOR`.

The rational for OpenBSD could be found here: http://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs
It is designed for OpenBSD specifically, but it spots several issues and invalids solutions (like renaming the file after linking).

To resume the problem is (in the example of packaging `rustc` program):
- I want to package rustc under OpenBSD.
- rustc come with shared libs (`libstd-4e7c5e5c.so` for example).
- the library isn't versioned.
- so any futur upgrade of rustc package will break any compiled program that depends of `libstd-4e7c5e5c.so` (the file will change, some functions will changes, or be added or be removed).

Having versioned libraries permit the package distribution system to have, at the same time, multiple version of the same library (`libstd-4e7c5e5c.so.1.0` and `libstd-4e7c5e5c.so.3.1` for example), and having binaries that depend of differents versions.
Repository: rust
Issue: Could type inference insert coercions to accommodate box desugaring?
Labels: A-type-system,T-compiler,A-inference,C-feature-request,T-types

The problem here was previously documented as a drawback in https://github.com/rust-lang/rfcs/pull/809 (with similar details provided in Appendix B).

Demonstration code:

``` rust
#![feature(box_syntax)]

// NOTE: Scroll down to "START HERE"

fn main() { }

macro_rules! box_ {
    ($value:expr) => { {
        let mut place = ::BoxPlace::make();
        let raw_place = ::Place::pointer(&mut place);
        let value = $value;
        unsafe { ::std::ptr::write(raw_place, value); ::Boxed::fin(place) }
    } }
}

pub trait BoxPlace<Data> : Place<Data> { fn make() -> Self; }
pub trait Place<Data: ?Sized> { fn pointer(&mut self) -> *mut Data; }
pub trait Boxed<CoercedFrom> { type Place; fn fin(filled: Self::Place) -> Self; }

struct BP<T: ?Sized> { _fake_box: Option<Box<T>> }

impl<T> BoxPlace<T> for BP<T> {
    fn make() -> BP<T> { make_pl() }
}
impl<T: ?Sized> Place<T> for BP<T> {
    fn pointer(&mut self) -> *mut T { pointer(self) }
}
impl<T> Boxed<T> for Box<T> {
    type Place = BP<T>;
    fn fin(x: BP<T>) -> Self { finaliz(x) }
}

fn make_pl<T>() -> BP<T> { loop { } }
fn finaliz<T: ?Sized, CoercedFrom>(mut _filled: BP<CoercedFrom>) -> Box<T> { loop { } }
fn pointer<T: ?Sized>(_p: &mut BP<T>) -> *mut T { loop { } }

// START HERE

trait D1 { fn duh() -> Self; }
trait D2 { fn duh() -> Self; }
trait D3 { fn duh() -> Self; }
trait D4 { fn duh() -> Self; }
trait D5 { fn duh() -> Self; }
trait D6 { fn duh() -> Self; }
trait D7 { fn duh() -> Self; }

// THIS WORKS TODAY (pre box desugaring).
impl<T> D1 for Box<[T]> { fn duh() -> Box<[T]> { box [] } }

// D2/D3/D4/D5 WORK TOMORROW (they accommodate the box desugaring).
impl<T> D2 for Box<[T]> {
    fn duh() -> Box<[T]> { let b: Box<[_; 0]> =  box_!( [] ); b }
}
impl<T> D3 for Box<[T]> {
    fn duh() -> Box<[T]> { (|b| -> Box<[_; 0]> { b })(box_!( [] )) }
}
impl<T> D4 for Box<[T]> {
    fn duh() -> Box<[T]> { (|b: Box<[_; 0]>| { b })(box_!( [] )) }
}
fn the<X>(x:X) -> X { x }
impl<T> D5 for Box<[T]> {
    fn duh() -> Box<[T]> { the::<Box<[_; 0]>>(box_!( [] )) }
}

// BUT: D6 and D7 do not work.

impl<T> D6 for Box<[T]> { fn duh() -> Box<[T]> { box_!([]) } }

impl<T> D7 for Box<[T]> {
    // fn duh() -> Box<[T]> { box_!( [] ) }
    //
    // desugars to:
    fn duh() -> Box<[T]> {
        let mut place = ::BoxPlace::make();
        let raw_place = ::Place::pointer(&mut place);
        let value = [];
        unsafe { ::std::ptr::write(raw_place, value);
                 ::Boxed::fin(place) }
    }
}
```

The question posed by this issue is: Could we enhance the type inference and/or the design of this protocol so that, by tracking the sized-ness of the type unification variables, we could determine where coercions need to be inserted.
Repository: go
Issue: x/tools/cmd/oracle: Support recursive search of packages to include in scope
Labels: NeedsInvestigation

Oracle takes a list of arguments that [set the analysis scope](https://docs.google.com/document/d/1SLk36YRjjMgKqe490mSRzOPYEDe0Y_WQNRv-EiFYUyw/view#heading=h.nwso96pj07q8). If a given argument (e.g. `github.com/example/project`) does not have any immediate source files, it is excluded from the analysis. However, many projects have sub-packages that do have main or test files, and enumerating these manually to oracle is difficult to manage. The user should have some way of indicating to oracle that a given path should be treated recursively and searched for any sub-packages that may have main or test files. In other words, given `github.com/example/project` which only has two sub-projects `github.com/example/project/subproject-one` and `github.com/example/project/subproject-two` which have main and/or test files, both should be included in the analysis scope.

This could be indicated with a command-line parameter ("includes packages recursively in scope") or as part of the path itself (`github.com/example/project/...`).
Repository: go
Issue: runtime/race: eliminate dependency on libc
Labels: RaceDetector

Race runtime currently depends on libc:

with CGO_ENABLED=0:
runtime/race(.text): __libc_malloc: not defined
runtime/race(.text): getuid: not defined
runtime/race(.text): pthread_self: not defined
...

This has several negative effects:
- don't work with CGO_ENABLED=0
- there is circular dependency between runtime/race and cmd/cgo
- cross-compilation is close to impossible
- external linkage is required

If we eliminate all libc dependencies from race runtime, all these problems go away.
Repository: neovim
Issue: Folds in saved session with invalid ranges cause sourcing the session to fail.
Labels: bug-vim

For example, if you `mksession` then your session file has something like `99,500fold` in it, but you've made changes to the file that fold applies to elsewhere so your file now has less than 500 lines, then loading the session will fail. Ideal behavior would be that the fold is simply ignored.
Repository: go
Issue: x/build: coordinator shows trybot successful builds as still active
Labels: Builders

There's some bug with the interaction of trybots and them succeeding in the build coordinator.

Look at the screenshot: the builds are done, but they're in the "active" section.

![succeeded](https://cloud.githubusercontent.com/assets/2621/6258293/5a5a05f4-b77c-11e4-8e12-264dd2ab52fa.png)

Further, down the page it says:

```
*** trybot state
Change-ID: I5f58aa58e74bbe4ec91b2e9b8c81921338053b00 Commit: 160f5ff2a7fad1fafa6cd817d64ebf488bd2d1fd
   Remain: 0, fails: []
  linux-386: running=false
  linux-amd64: running=false
  linux-amd64-race: running=false
  freebsd-386-gce101: running=false
  freebsd-amd64-gce101: running=false
  windows-386-gce: running=false
  windows-amd64-gce: running=false
  openbsd-386-gce56: running=false
  openbsd-amd64-gce56: running=false
  plan9-386-gcepartial: running=false
```

/cc @adg
Repository: rust
Issue: Resolve shorthand projections (`T::A`-style associated type paths) based solely on type, instead of a Def
Labels: A-type-system,E-hard,C-enhancement,A-trait-system,A-associated-items,T-compiler,T-types

Right now [`astconv::associated_path_def_to_ty`](https://github.com/rust-lang/rust/blob/dfc5c0f1e8799f47f9033bdcc8a7cd8a217620a5/src/librustc_typeck/astconv.rs#L989-L993) takes a `def::TyParamProvenance` obtained from [either `def::DefTyParam` or `def::DefSelfTy`](https://github.com/rust-lang/rust/blob/dfc5c0f1e8799f47f9033bdcc8a7cd8a217620a5/src/librustc_resolve/lib.rs#L3926-L3937).

This information cannot be easily extracted from the type, and #22172 doesn't change that, which means `<T>::AssocTy` does not work at all (pretends to be ambiguous).

We should be able to make progress after #22172 and #22512 both land, and I believe @nikomatsakis has a solution in mind for dealing with at least _some_ cases.

After this is fixed, the `finish_resolving_def_to_ty` function introduced in #22172 can be split into `def_to_ty` and `resolve_extra_associated_types` and its callers would only need the latter for `<T>::A::B::C`, instead of providing a dummy `Def` to the entire thing.
Repository: go
Issue: cmd/compile: improve generated type equality code
Labels: compiler/runtime

geneq generates a series of if statements, each returning false if they fail. Creating instead a long conjunction would result in shorter, faster generated code.

It might also be worth reordering the tests to place all the ones involving a function call last.

It might also be worth trying to prevent some of the spurious checknils that are currently produced. In some cases know that we are dereferencing fields on a struct (not a pointer to a struct).

We also appear to be generating equality routines when we shouldn't be. The following strike me as possibly spurious:
- `TEXT type..eq.[0]text/tabwriter.cell(SB) text/tabwriter/tabwriter.go`. An array of length zero? Where does it come from? And the equality check should be trivial, not generated.
- `TEXT type..eq.[2]string(SB) golang.org/x/tools/cmd/godoc/blog.go`. I don't see anything resembling `[2]string` in `blog.go`.
- `TEXT type..eq.[1]interface {}(SB) golang.org/x/tools/cmd/godoc/blog.go`. I don't see where this came from in `blog.go`. And an equality check for an array of length 1 should just be a check of the underlying type.

Look into these.

Given all the above, it might be worth also taking a closer look at the generated hash routines as well.

I'll poke at these once the c2go conversion is complete.
Repository: You-Dont-Know-JS
Issue: "types & grammar": update ch3 to talk about ES6 change to native's prototypes
Labels: for second edition

This section https://github.com/getify/You-Dont-Know-JS/blob/master/types%20&%20grammar/ch3.md#prototypes-as-defaults and the one before it, should be updated with recent ES6 changes to the native prototypes. See: https://esdiscuss.org/topic/array-prototype-change-was-tostringtag-spoofing-for-null-and-undefined
Repository: rust
Issue: Error messages are odd for delegating traits
Labels: A-trait-system,P-medium,E-mentor,T-compiler,E-help-wanted,C-bug

This is a more general version of https://github.com/rust-lang/rust/issues/22478. (i.e. probably should be considered to supersede it)

``` rust
trait A {
    fn a(self);
}

trait B {
    fn b(self);
}

impl<T: B> A for T {
    fn a(self) {
        B::b(self)
    }
}

struct C;

fn main() {
    A::a(C);
}
```

Compiling this will result in 

```
t.rs:18:5: 18:9 error: the trait `B` is not implemented for the type `C` [E0277]
t.rs:18     A::a(C);
            ^~~~
error: aborting due to previous error
```

but `impl<T: B> A for T`, `T = C` and `C` does not implement `B` and therefore the impl in question should not even be taken into consideration, even if it is the only implementation of a trait.


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"PoignardAzur"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: nvm
Issue: Install node 32bits in Ubuntu 64bits
Labels: installing node,feature requests,pull request wanted

Is there a way to install an specific node arch (32|64) with nvm, in a 64 bits OS?
Repository: nvm
Issue: ls-remote output is deceiving when one of nodejs.org and iojs.org is not accessible
Labels: installing node,SSL issue,pull request wanted

I recently installed nvm on a new server that did not have the Thawte root certificate used by nodejs.org configured as a trusted root certificate in OpenSSL.  The AddTrust root certificate used by iojs.org was configured as a trusted root cert.  The result of this was that when I ran `nvm ls-remote` it only displayed iojs versions with no other output.  This was very confusing as there was no indication that the requests to nodejs.org were failing.
Repository: rust
Issue: Deref coercion from `String` to `&str` doesn't seem to always work
Labels: A-type-system,T-compiler,C-bug,T-types

This code compiles fine:

``` rust
fn main() {
  let x = "a".to_string();
  let y: String = ["b", &x[..], "c"].concat();
  println!("{}", y);
}
```

but this code doesn't

``` rust
fn main() {
  let x = "a".to_string();
  // Doesn't work
  let y: String = ["b", &x, "c"].concat();
  println!("{}", y);
}
```

error output:

```
<anon>:4:25: 4:27 error: mismatched types:
 expected `&str`,
    found `&collections::string::String`
(expected str,
    found struct `collections::string::String`) [E0308]
<anon>:4   let y: String = ["b", &x, "c"].concat();
                                 ^~
```

I'd expect to not have to sometimes write `&foo[..]` and sometimes `&foo` to get a `&str` out a `String`. The longer form is too verbose, and the inconsistency of having to sometimes use one over the other seems like a needless user mental model cost, especially because it's not obvious to me at all when I should use one form over the other.

rustc version: `rustc 1.0.0-nightly (522d09dfe 2015-02-19) (built 2015-02-21)`
Repository: react
Issue: Optimizing Compiler: Tagging ReactElements
Labels: Component: Optimizing Compiler,Resolution: Backlog,React Core Team

We can make more optimized reconciliation by tagging ReactElements with the "hidden class" of their props.

For example, this is guaranteed to always have three props: `className`, `width`, `children`.

``` javascript
<div className="foo" style={{ width: w, height: 100 }}>{c}</div>
```

If we could tag every element with these properties with a unique ID:

``` javascript
{ __t: 7, type: 'div', props: { className: 'foo', style: { width: w, height: 5 }, children: c } }
```

Then we could use the hidden class to generate an optimized diffing algorithm for these instead of iterating over the properties. Presumably, we would only need to do this for `type: <string>` since we only diff native components.

Bonus points if we can determine which properties are constant. Perhaps using a property descriptor object:

``` javascript
// Constant properties are annotated as 1, other properties are excluded and inferred by props.
var t = { className: 1, style: { height: 1 } };
{ __t: t, type: 'div', props: { className: 'foo', style: { width: w, height: 5 }, children: c } }
```

We would use a heuristic inside React to determine when to create an optimized differ. For example, after 10+ updates to the same component. Just like a JIT would do.

``` javascript
if (oldElement.__t === newElement.__t) {
  numberOfUpdates++;
} else {
  numberOfUpdates = 0;
}

if (numberOfUpdates === 10) {
  optimizedDiffer = generateOptimizedDiffer(newElement);
  optimizedDiffer(oldElement, newElement);
} else if (numberOfUpdates > 10) {
  optimizedDiffer(oldElement, newElement);
} else {
  manualDiffing(oldElement, newElement);
}
```
Repository: rust
Issue: Extend #[bench] with memory usage
Labels: T-libs-api,C-feature-accepted

It would be nice to be able to see memory usage (and memory leak) in `#[bench]` tests to detect regressions. I guess jemalloc can do that with something like `je_malloc_stats_print`.

cc #14119
cc #14875
cc #19776
Repository: neovim
Issue: :! (with no arguments) should pipe the buffer to &shell
Labels: enhancement,terminal

Most (all?) shells can [execute stdin](http://stackoverflow.com/a/9966150/152142). E.g.:

```
echo ls | bash
```

Yet in Vim, if I have a buffer with these contents:

```
ls
```

and then execute any of these:

```
:%!
:%w !
:%r !
```

nothing happens. The buffer contents should pipe to `&shell` if `:!` has no arguments.

Also, `:!` does not work with a new, unsaved buffer. It should.
Repository: youtube-dl
Issue: Custom filename transformations (was: Filename: I want to restrict characters, but permit spaces)
Labels: request

Right now, restricting filenames to reasonable characters also prevents spaces.

Yea, I know, most unix scripts/etc. can't handle spaces, but most modern GUI tools can.
Repository: youtube-dl
Issue: add support for 'app passwd'
Labels: request

my understanding is that 2-step authentication is not supported. but i couldn't find anything about app specific passwd here. this should work with netrc just like regular passwd but i doesn't.
Repository: go
Issue: x/mobile/cmd/gomobile: icon support in gomobile
Labels: mobile

There are some useful defaults we could have for app icons. Place an icon in <pkg>/assets/icon.png, and it gets used.

But it turns out there are many icons. Android has an arbitrary number of potential sizes, depending on the DPI of the screen. iOS has a series of fixed sizes. Both also have much larger store icons (1024x1024 and 512x512).

http://developer.android.com/design/style/iconography.html
https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/IconMatrix.html

Given the large number of android combinations, automatic scaling might make sense. However users may need the ability to provide multiple icons, as small images often require artistic adjustment to the number of pixels. One possibility is <pkg>/assets/iconUxV.png.
Repository: TypeScript
Issue: SourceFileObject.getNamedDeclarations is missing declarations before methods
Labels: Bug,Help Wanted,API

I'm doing a SourceFileObject.getNamedDeclarations on the following code snippet:

``` javascript
module Mankala {
  export class Rectangle {
    x: number;
    y: number;
    width: number;
    height: number;
    square() {
    }
  }
}
```

This returns an array that is missing the property 'height'.

The problem is in
SourceFileObject.prototype.getNamedDeclarations 

``` javascript
     case 125 /* Method */:
             var functionDeclaration = node;
             if (functionDeclaration.name && functionDeclaration.name.getFullWidth() > 0) {
             var lastDeclaration = namedDeclarations.length > 0 ? namedDeclarations[namedDeclarations.length - 1] : undefined;
                                if (lastDeclaration && functionDeclaration.symbol === lastDeclaration.symbol) {
                                    if (functionDeclaration.body && !lastDeclaration.body) {
                                        namedDeclarations[namedDeclarations.length - 1] = functionDeclaration;
                                    }
                                }
```

functionDeclaration.symbol === lastDeclaration.symbol  is true as both symbols are undefined.
The property 'height' is then replaced by method 'square'
Repository: You-Dont-Know-JS
Issue: "async & performance": Document unhandled rejection hooks
Labels: for second edition

In async & performance you mention promise rejections and debuggability with error handling. A patch has landed in io.js in 1.4 which is released tomorrow with native promises that lets you do something similar to your example:

Your example syntax:

```
var p = Promise.reject( "Oops" ).defer();
var p2 = Promise.reject( "Oops" ); // will be reported as an unhandled rejection to the console
```

Can now be coded with

```
var p = Promise.reject( "Oops" ).catch(function(){});
var p2 = Promise.reject( "Oops" ); // will be reported as an unhandled rejection to the console
```

When doing:

```
process.on("unhandledRejection", function(promise, reason) {
    console.log("Unhandled Error", reason);
});
```

This will achieve semantics very close to your `.defer` semantics using native ES6 promises in io.js, I think it's worth mentioning :) How do you feel about this?
Repository: kubernetes
Issue: Efficient lookup by label selection, reverse label selection, uid, and IP addresses
Labels: sig/scalability,area/api,area/usability,priority/awaiting-more-evidence,sig/api-machinery,kind/feature,lifecycle/frozen

In a discussion I had yesterday with @bgrant0607 and @lavalamp it came up the need of indexing labels and probably ip addresses. Reference: https://github.com/GoogleCloudPlatform/kubernetes/pull/4482

> We'll still want to do the label indexing, reverse label indexing, lookup by IP address, specification of query URLs in service and controller statuses, field selection for more efficient listing of just metadata, etc.

On top of that I would like also to expose the entity relationship somehow in the api (e.g. /api/v1beta3/relations/{services,replicationcontroller,...})
Repository: go
Issue: proposal: spec: reconsider rule disallowing div-0 by constants
Labels: LanguageChange,Proposal,LanguageChangeReview

http://play.golang.org/p/flvr-MFRgR

is a perfectly reasonable program that doesn't compile. Perhaps the spec rule (which admittedly, I advocated) was a mistake after all.

We could reconsider this since permitting it would be backward-compatible.

(See also #10004 for context.)