sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: rustc accepts impls that has different type signatures from trait decls in lifetime parameters of the type
Labels: A-lifetimes,A-trait-system,T-compiler,C-bug,T-types

I thought this code was invalid because 1. it had a redundant lifetime parameter and 2. it had different types from the trait decl in the types of the argument and the return value.

```rust
trait Foo<T> {
    fn foo(&self, t: T) -> T;
}

impl<'a> Foo<Option<&'a str>> for () {
    fn foo<'b>(&self, t: Option<&'b str>) -> Option<&'b str> {
        t
    }
}
```

but the compiler (both stable (1.22.1) and nightly (9fe7aa353 2017-12-11)) accepts this code.
Is this indended or a bug?

FYI: it seems compiler treat the signature method `foo` as the one of `Foo` (or, perhaps unifying `'b` to `'a`?) so it doesn't cause unsafe states like dangling pointer.

```rust
fn main() {
    let s = "String".to_string();
    {
        let o = Some(s.as_ref());
        let _ = <() as Foo<Option<&'static str>>>::foo(&(), Some("static"));
        // error
        let _ = <() as Foo<Option<&'static str>>>::foo(&(), o);
        // error
        let _: Option<&'static str> = ().foo(o);
    }

}
```
Repository: rust
Issue: Better error reporting for Sync and type that impl !Sync
Labels: C-enhancement,A-diagnostics,A-trait-system,T-compiler

It would make a lot more sense if when a type `impl !Sync` the compiler could report an other error than the error that comes from [this impl block](https://doc.rust-lang.org/beta/src/core/marker.rs.html#557).

For example, take a look at this code :

```rust
use std::sync::mpsc::channel;
use std::thread;

struct Foo {}

impl Foo {
    fn do_something(&self) {
        println!("hello");
    }
}

fn main() {
    let (tx, rx) = channel::<Foo>();
    thread::spawn(move || rx.iter().map(|f| f.do_something()));
}
```

Which outputs : 
```
17 |     thread::spawn(move || rx.iter().map(|f| f.do_something()));
   |     ^^^^^^^^^^^^^ `std::sync::mpsc::Receiver<Foo>` cannot be shared between threads safely
   |
   = help: the trait `std::marker::Sync` is not implemented for `std::sync::mpsc::Receiver<Foo>`
   = note: required because of the requirements on the impl of `std::marker::Send` for `&std::sync::mpsc::Receiver<Foo>`
   = note: required because it appears within the type `std::sync::mpsc::Iter<'_, Foo>`
   = note: required because it appears within the type `std::iter::Map<std::sync::mpsc::Iter<'_, Foo>, [closure@src/main.rs:17:41: 17:61]>`
   = note: required by `std::thread::spawn`
```

It would be way better if it could just say that `Receiver` is [explicitly](https://doc.rust-lang.org/src/std/sync/mpsc/mod.rs.html#339) not `Sync`.

I know that this a bad example because the error is actually due to the fact that the compiler does not move `rx` because we are returning a value from the call to `map()`, but it was the only one that I had...
Repository: go
Issue: runtime: delineate multiple panics by adding newlines between them
Labels: help wanted,NeedsFix

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

go version go1.9.2 linux/amd64

### What did you do?

```
// a.go
package main

func main() {
	var s []int
	var is interface{} = s
	go func() {
		_ = s == nil
	}()
	go func() {
		_ = is == is
	}()
	
	var m map[string]bool = nil
	_ = m["Go"]
	_, _ = m["Go"]
	m, _ = is.(map[string]bool)
	m = is.(map[string]bool)
}
```

### What did you expect to see?

```
$ go run a.go
panic: interface conversion: interface {} is []int, not map[string]bool

goroutine 1 [running]:
main.main()
	/tmp/a.go:17 +0x15a
panic: runtime error: comparing uncomparable type []int

goroutine 19 [running]:
main.main.func2(0x45b480, 0x4cc2c0)
	/tmp/a.go:10 +0x3a
created by main.main
	/tmp/a.go:9 +0xc9
exit status 2
```

### What did you see instead?

```
$ go run a.go

panic: interface conversion: interface {} is []int, not map[string]bool
goroutine 1 [running]:
main.main()
	/tmp/a.go:17 +0x15a

panic: runtime error: comparing uncomparable type []int
goroutine 19 [running]:
main.main.func2(0x45b480, 0x4cc2c0)
	/tmp/a.go:10 +0x3a
created by main.main
	/tmp/a.go:9 +0xc9
exit status 2
```
Repository: ant-design
Issue: will the Tabs can be triggered by using hover?
Labels: 💡 Feature Request,Inactive,IssueHuntFest

### What problem does this feature solve?
if Tabs can only be changed by click, it's not cooool

### What does the proposed API look like?
onMouseEnter
onMouseLeave

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: [E0277] Add Note when trait is not satisfied because of missing reference in where
Labels: C-enhancement,A-diagnostics,T-compiler

When "where T: TraitX" is missing an "&" the error message E0277 could be improved with a note.

I'm also not sure why the same looking code (`fn a<B>(b: &B) where B: TraitB;`) inside a trait compiles just fine, maybe there is more to it.

I tried this code:
```rust
trait TraitA { fn a<B>(b: &B) where B: TraitB; }
struct StructA { }
impl TraitA for StructA { fn a<B>(b: &B) where B: TraitB { } }

trait TraitB { fn b(); }
struct StructB { }
impl TraitB for StructB { fn b() { } }

// (should be:) fn c<'a, B: 'a>(b: &'a B) where &'a B: TraitB
fn c<B>(b: &B) where B: TraitB {
        StructA::a(&b);
}
```

I expected to see this happen (or similar):
```text
[...]
   = note: Try "where &'a B: TraitB" instead of "where B: TraitB"
```

Instead, this happened:
```text
error[E0277]: the trait bound `&B: TraitB` is not satisfied
  --> src/lib.rs:20:9
   |
20 |         StructA::a(&b);
   |         ^^^^^^^^^^ the trait `TraitB` is not implemented for `&B`
   |
   = note: required by `TraitA::a`
```

## Meta

`rustc --version --verbose`:
```
rustc 1.24.0-nightly (9fe7aa353 2017-12-11)
binary: rustc
commit-hash: 9fe7aa353fac5084d0a44d6a15970310e9be67f4
commit-date: 2017-12-11
host: x86_64-unknown-linux-gnu
release: 1.24.0-nightly
LLVM version: 4.0
```
Repository: svelte
Issue: Document the architecture behind Svelte
Labels: meta,documentation

Hi,
I'm really interested in how svelte internally works and which problems and challenges you had faced. I could read the whole source code but the author can provide a much better picture. Svelte is able to compile itself away this is amazing because when the API is settled you can share performant, runtime-independent web components.

 Interesting points
- Code generation
- Compile-time static analysis
- Role of Typescript
- Your motivation
- Roadmap
- .....
Repository: vscode
Issue: Wrap with abbreviation history
Labels: help wanted,feature-request,emmet

Coming from atom this is a feature that i miss. 

When wrapping with abbreviation you could use the up and down arrows to go through previously used abbreviations.

So if you had created a long abbreviation and it was slightly wrong or you wanted to reuse you wouldn't have to type it out all over again.
Repository: TypeScript
Issue: TypeScript VS: Doesn't re-transpile file when source-control revert-changes
Labels: Visual Studio,Needs Investigation

TypeScript integration in Visual Studio 2017:

When I change a typescript-file in a visual studio project ( that is in TFS source control )
then I decide to abandon the change (revert changes from right-click context menu)
then Visual Studio correctly replaces the local typescript-file with the server version. 
But it doesn't re-transpile the changed file.

`"compileOnSave": true,`

also, the option should then be called/added "compileOnChange", not compileOnSave...
Because apparently, these two things are not the same, which i find somewhat surprising... 
although ...

Consequence is, the JavaScript file doesn't run as it should when debugging.
Repository: vscode
Issue: indent back to line start after enter newline and press up
Labels: editor-autoindent,under-discussion

- VSCode Version: Code 1.18.1 (929bacba01ef658b873545e26034d1a8067445e9, 2017-11-16T18:32:36.026Z)
- OS Version: Windows_NT ia32 10.0.16299

Hi, I have a feature request related to intent,

I think Notepad++ and Visual Studio's indent `after enter newline and press up` works better and more intuitive, it'll remain the indent position, as in the gif:
![vsindent gif](https://user-images.githubusercontent.com/23180780/33894214-5eef9326-df98-11e7-99dc-f97621889720.gif)

But VSCode's indent `after enter newline and press up` go back to line start, which I think is not so reasonable:
![vscodeindent gif](https://user-images.githubusercontent.com/23180780/33894344-b4b70582-df98-11e7-9032-bc7c98a415b6.gif)

Hope vscode can remain the indent position `after enter newline and press up`, thank you.

.

<!-- Launch with `code --disable-extensions` to check. -->
Reproduces without extensions: Yes
Repository: ant-design
Issue: Upload component - enable sending multiple files in one XHR request
Labels: help wanted,💡 Feature Request,Inactive,IssueHuntFest

### What problem does this feature solve?
Simplifies back-end implementation when in need to process multiple files at the same time; and when files need to be processed in one transaction without the need for the front-end to have the link to the uploaded files.  

### What does the proposed API look like?
It can be similar or the same as jQuery-File-Upload *[singleFileUploads](https://github.com/blueimp/jQuery-File-Upload/wiki/Options#singlefileuploads)* option when the multiple option is enabled on the Upload component.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: x.grad should be 0 but get NaN after x/0
Labels: module: docs,module: autograd,triaged,module: NaNs and Infs,has workaround,needs design

# x.grad should be 0 but get NaN after x/0


### Reproduction BUG code
```python
import torch
from torch.autograd import Variable

x = Variable(torch.FloatTensor([1.,1]), requires_grad=True)
div = Variable(torch.FloatTensor([0.,1]))

y = x/div # => y is [inf, 1]

zero_mask = (div==0) # => zero_mask is [1, 0]
y[zero_mask] = 0  # => y is [0, 1]

loss = y.sum()
loss.backward()
print(x.grad) # grad is [nan, 1], but expected [0, 1]
```

Computational graph of loss not include `x[0]`
So, gradient of `x[0]` should be 0, but get `NaN` 

### more simple reproduction
```python
x = Variable(torch.FloatTensor([1.,1]), requires_grad=True)
div = Variable(torch.FloatTensor([0.,1]))

y = x/div # => y is [inf, 1]

mask = (div!=0) # => mask is [0, 1]
loss = y[mask]

loss.backward()
print(x.grad) # grad is [nan, 1], but expected [0, 1]
```

### Versions:
 * Python: 2.7
 * pyTorch: 0.3.0.post4

cc @svekars @holly1238 @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @brianjo @mruberry @gchanan @bdhirsh @jbschlosser @anjali411 @jlin27
Repository: flutter
Issue: libtxt: TextPainter.minIntrinsicWidth doesn't take into account ellipsis or maxLines
Labels: engine,a: typography,P2,c: tech-debt,team: skip-test,team-engine,triaged-engine

I've only tested this with the Blink text rendering.
Repository: TypeScript
Issue: Quick fix to install regular .js npm packages
Labels: Suggestion,In Discussion,Domain: Quick Fixes

Let's say I start a new project. I start writing out an import for, say, `express` because I'm certain I'll be using that, but I haven't bothered to install it yet.

```ts
import express from "express";
```

Immediately, I might get an error like `Cannot find module 'express'.` because I didn't install the package before using it. This happens regardless of if I have `noImplicitAny` on. But this means I have to switch to a terminal and do an npm install.

We already give a quick fix to install missing `@types` packages, we should have a fix that

1. Gives the option of installing a missing package as a dependency or a dev dependency.
2. Also installs the types for that package if necessary in the same fashion.
Repository: rust
Issue: Lints sometimes don't trigger, with no discernable pattern
Labels: C-enhancement,A-lints,T-compiler,E-needs-mcve

This has cropped up in Diesel for a long time, either manifesting as having to change some unrelated code because a lint started triggering that wasn't before, or occasionally noticing "oh hey you need to implement `Copy` on this type, why didn't the lint trigger?"

I finally have a case that I can report though, which I noticed before it started failing, and very clearly should be triggering. https://github.com/diesel-rs/diesel/pull/1375 adds `#[deny(missing_docs)]` to the `query_dsl` module. However, `query_dsl::boxed_dsl::BoxedDsl` is a public item which has no documentation on it, and should be triggering the lint. I can even go in and add `#[deny(missing_docs)]` to that trait directly, and the lint still doesn't fire.

I'm not sure what other information I can add -- This is not specific to this one lint in this one case, we've had tons of cases of lints which should have always been failing randomly starting to fail due to changes in completely unrelated code.
Repository: rust
Issue: arguments `<optimized out>` when optimizations remove unused data fields
Labels: A-debuginfo,T-compiler,C-bug

This program:

```rust
use std::env;

#[inline(never)]
fn foo(x: &str, y: &str) -> usize {
    x.len() + y.len()
}

fn main() {
    let mut args = env::args();

    let x = args.next().unwrap();
    let y = args.next().unwrap();
    let z = foo(&x, &y);
    println!("z={:?}", z);
}
```

when compiled with optimizations enabled, seems to strip out all of the local variable information:

```
lunch-box. rustc +nightly -O -g ~/tmp/foo.rs
lunch-box. gdb foo
Error in sitecustomize; set PYTHONVERBOSE for traceback:
AttributeError: module 'sys' has no attribute 'setdefaultencoding'
GNU gdb (Ubuntu 7.12.50.20170314-0ubuntu1.1) 7.12.50.20170314-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from foo...done.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/nmatsakis/tmp/foo.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) break 3
Breakpoint 1 at 0x7264: file /home/nmatsakis/tmp/foo.rs, line 3.
(gdb) r a b
Starting program: /home/nmatsakis/tmp/foo a b
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, foo::foo (x=..., y=...) at /home/nmatsakis/tmp/foo.rs:5
5       x.len() + y.len()
(gdb) p x
$1 = <optimized out>
```

cc @tromey
Repository: rust
Issue: item paths use the name of the item, which might differ from the name of the import
Labels: C-enhancement,A-diagnostics,T-compiler

## STR

Crate foo:
```Rust
mod internal {
    pub struct S;
}

pub use internal::S as T;
```

Crate main:
```Rust
extern crate foo;

fn main() {
    foo::T
}
```

## Results

```
error[E0308]: mismatched types
 --> x.rs:4:5
  |
3 | fn main() {
  |           - expected `()` because of default return type
4 |     foo::T
  |     ^^^^^^ expected (), found struct `foo::S`
  |
  = note: expected type `()`
             found type `foo::S`

error: aborting due to previous error
```

The error message refers to `foo::S`, which does not exist (only `foo::T` does)
Repository: rust
Issue: Use SIMD to accelerate UTF-8 encoding and decoding
Labels: C-enhancement,T-libs,A-str

This is a feature request: use SIMD instructions to accelerate UTF-8 encoding and decoding operations.
Repository: go
Issue: proposal: add golang.org/x/text/diff package
Labels: Proposal,Proposal-Hold

Many test code are something like:
```
func TestAAA(t *testing.T) {
  if got != want {
    t.Errorf("got %v, want %v")
  }
}
```
However, these kind of code are pretty useless when we expected multi-line values.
For example,
```
--- FAIL: TestExamples (0.00s)
	example_test.go:186: Import: got Play == "package main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\t\"os/exec\"\n)\n\nfunc main() {\n\tout, err := exec.Command(\"date\").Output()\n\tif err != nil {\n\t\tlog.Fatal(err)\n\t}\n\tfmt.Printf(\"The date is %s\\n\", out)\n}\n", want "package main\n\nimport (\n\t\"fmt\"\n\t\"log\"\n\t\"os/exec\"\n)\n\n// aaa\n\nfunc main() {\n    out, err := exec.Command(\"date\").Output()\n\tif err != nil {\n\t\tlog.Fatal(err)\n\t}\n\tfmt.Printf(\"The date is %s\\n\", out)\n}\n"
FAIL
```
So, I propose to support diff algorithm for making error messages human-readable.

The simplest implementation is executing the `diff` command. It doesn't work on windows.
But we can use fallback, so it can be a good starting point.

I'm not sure that supporting the "diff" package officially is worth doing.
But "internal" packages seem harmless.
Repository: go
Issue: x/image/tiff: no support for cJPEG or cJPEGOld
Labels: NeedsInvestigation

#### What did you do?
tried to decode a jpeg compressed tiff or a canon raw (weird tiff with jpeg data)

#### What did you expect to see?
the image to be decoded correctly without errors.

#### What did you see instead?
with a cr2:
`tiff: unsupported feature: compression value 6`
with a tiff with proper jpeg compressed image data:
`tiff: unsupported feature: compression value 7`

#### System details

```
go version go1.9.2 linux/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/gareth/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build053335415=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version go1.9.2 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.9.2
uname -sr: Linux 4.14.4-1-ARCH
LSB Version:	1.4
Distributor ID:	Arch
Description:	Arch Linux
Release:	rolling
Codename:	n/a
/usr/lib/libc.so.6: GNU C Library (GNU libc) stable release version 2.26, by Roland McGrath et al.
gdb --version: GNU gdb (GDB) 8.0.1
```
Repository: pytorch
Issue: [Proposal] Consistent `batch_first` effect for RNN modules
Labels: module: docs,module: nn,module: rnn,triaged

In current RNN (including `nn.RNN`, `nn.GRU`, `nn.LSTM`) implementation, the `batch_first` will only affect the dimension order of **input** and **output** variables. But there are also **hidden states** returned from RNN, and the *batch* dimension is always placed in the 2nd dimension regardless of the `batch_first` argument.
Could someone tell me the advantages of such odd behaviour? Or I can help to patch this.

cc @ezyang @gchanan @zou3519 @bdhirsh @jlin27 @mruberry @albanD
Repository: pytorch
Issue: ATen explicitly differentiated native function resolution hazard (call is ambiguous)
Labels: module: internals,triaged

Functions in ATen either can have derivatives defined for them, or they can defer to the implementations of derivatives of the methods they invoke.

Suppose you write this (assume f and g are functions):

```
#include <ATen/ATen.h>

namespace at { namespace native {

Tensor f(at::Tensor x) {
  // some primitive implementation (f will need an explicit derivative)
}

Tensor g(at::Tensor x) {
  return f(x);
}

}}
```

If you have ever written this, you may notice that compilation fails, with the compiler complaining that 'f is ambiguous'. Puzzled, you might slap on the prefix `at::native::` to shut up the compiler. At time of writing, I see `narrow` dispatches to `at::native::slice`.

The hazard is this: *if* g was intended to be a non-primitive function whose derivative was to be deferred to f's derivative implementation, resolving the ambiguity to `at::native::` will simply not work, because you will fail to actually go through the variable unpacking/wrapping code that is done by the `at::` version of the function. (In the particular case of `narrow`, `slice` happens to be a non-primitive native function, solving the problem.)

This issue will become more pressing as we add more "primitive" native functions to ATen, e.g., functions which must have their derivatives expressed directly.

EDIT: there is also a case where this hazard will silently introduce a performance problem to your code:

1. You use `at::native` to call a non-primitive ATen native function, BUT
2. The non-primitive ATen function has a more efficient derivative defined for it.

If you call the `at::native` version, you will fall back to the less efficient derivative.

cc @ezyang @bhosmer @smessmer @ljk53
Repository: rust
Issue: Unsatisfied trait bound for inner type in result leads to imprecise error message
Labels: C-enhancement,A-diagnostics,T-compiler

Given a function that returns an instance of a generic expecting an inner type to implement a trait but that bound is not satisfied, the compiler unhelpfully points to the entire function and does not specify which inner type is the root of the problem.

Sample code ([full error case on git](https://git.neosmart.net/mqudsi/futuretest/src/branch/rust-46711)):

```rust
fn test() -> MapErr<(), ()> {
    future::ok(())
        .map_err(|String| ())
}
```

`MapErr` is a type that expects its first type parameter to implement the `Future` trait, `()` does not do so. 

The compiler generates the following:

```rust
   Compiling futuretest v0.1.0 (file:///mnt/c/Users/Mahmoud/git/futuretest)
error[E0277]: the trait bound `(): futures::Future` is not satisfied
  --> src/main.rs:17:1
   |
17 | / fn test() -> MapErr<(), ()> {
18 | |     future::ok(())
19 | |         .map_err(|String| ())
20 | | }
   | |_^ the trait `futures::Future` is not implemented for `()`
   |
   = note: required by `futures::MapErr`

error: aborting due to previous error

error: Could not compile `futuretest`.

To learn more, run the command again with --verbose.
```

It is extremely unclear from the resulting error message what the problem is. The text specifies that `MapErr` requires `()` to implement `futures::Future`, but highlights the entire function instead of (ideally) just the first type parameter in the function return type.

In this specifically chosen case, the error complains about `()` and `MapErr` - but trickily, `()` is just fine for the second type parameter to `MapErr<(), ()>`, it's the first `()` that needs to implement `futures::Future`.

So to recap:

* Error should point to the return type declaration instead of the entire function
* Error needs to clarify which inner type must satisfy the trait in question