sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: youtube-dl
Issue: Feature Request: Alternate thumbnail embedder - tageditor
Labels: request,postprocessors

- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.03.15**

### 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
- [ ] [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*?
- [x] Feature request (request for a new functionality)
---


### Description of your *issue*, suggested solution and other information

I'd like to propose an alternative to `atomicparsley` for thumbnail embedding: `tageditor` (https://github.com/Martchus/tageditor). It's supports mp4 *and* mkv embedding of cover images (among quite a lot of other things).

Example command line:
```
tageditor -set cover="foo.png" -f "foo.mp4"  [--max-padding nnnn]
```
Might be able to resolve #10359.

If using an alternate external application for thumbnail embedding is already supported, at least `--help` doesn't mention it.
Repository: neovim
Issue: :nineties mode: disable various settings for slow terminals
Labels: enhancement,performance,tui

On slow connections, 'showcmd', 'ruler', etc. can cause bad performance. We can serve that use-case by providing a single built-in mapping (`{count}CTRL-L` ?) or command (`:ni[neties]`) that disables various settings known to cause extra redraws. 

    :ni[neties]      Party like it's the 90s. Disable various features, 
                     for slow environments. Ni!

So then we can have defaults that serve most users, but when using nvim on a slow connection, one can just hit a single mapping to make it faster.

List of effects:

```
set mouse=
set noshowcmd
set noruler
set nosmoothscroll
```
Repository: go
Issue: plugin: requires CGO_ENABLED=1
Labels: compiler/runtime

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
`go version go1.8 linux/amd64`

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN="/home/johan/gows/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/johan/gows"
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-build464530147=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
```

### What did you do?
I tried to build a simple plugin with `CGO_ENABLED=0`. It builds fine, and at plugin load time you get an error `plugin: not implemented`. This is an intentional limitation at the moment, but I think it moves backwards in the general trend of the language development, which has been moving away from C dependencies. This should hopefully be a discussion around supporting plugins without the need for CGO.

### What did you expect to see?
I expected to be able to build and load plugins without CGO.

### What did you see instead?
I got an error saying `plugin: not implemented`.
Repository: rust
Issue: Rust allows function argument names to shadow unit structs imported in function body
Labels: A-resolve,T-lang,T-compiler,C-bug

Assume that `foo::bar` is a unit struct in all these examples. This fails to compile:

```rust
use foo::bar;

fn foo(bar: i32) {}
```

As does this:

```rust
fn foo() {
    use foo::bar;
    let bar = 1;
}
```

However, this compiles successfully:

```rust
fn foo(bar: i32) {
    use foo::bar;
}
```

It probably shouldn't. The local variable `bar` can never be accessed for the same reason as the first two. This has led to some confusion by users of Diesel, when they tried to write code like the following:

```rust
fn find_by_email(conn: &PgConnection, email: &str) -> QueryResult<User> {
    use schema::users::dsl::*;
    use schema::users;

    users.filter(users::email.eq(email)).first(conn)
```

However, `users::email` and `email` are both that unit struct, so this code would return the first user in the database not the user with the given email as you'd expect. It does at least complain about the unused argument, but this should be a hard error.
Repository: go
Issue: x/build/cmd/gopherbot: ping a CL when it has +2 but OP can't submit
Labels: Builders,FeatureRequest

Have gopherbot ping a CL when it has +2 but OP can't submit.
Repository: go
Issue: test: errorcheck support for intraline errors
Labels: help wanted,NeedsFix,FeatureRequest

Now that the compiler supports reporting column position for errors, we need a mechanism in test/run.go for testing this.

I propose we use `/* ERROR "foo" */` placed just before where we expect the error to be emitted, except to allow for white space in between.

E.g., for #19576, the test would be

    package p

    func f() int { /* ERROR "missing return" */ }

Rationale:

- run.go currently only looks for `// ERROR` annotations, which can only occur at the end of the line, so there's no risk of collision using `/* ERROR */` for column-precise error matching.

- Not explicitly having to write column numbers into the errors makes them easier to maintain, just like how we don't currently have to worry about line numbers.

- We emit errors at the start of tokens, so putting the error expectation before that lets us unambiguously match it to an expected column. Putting afterwards would require more complex logic for figuring out how many characters to rewind past.

- Allowing whitespace after the error comment allows the code to be gofmt'd.

/cc @griesemer @ianlancetaylor @bradfitz
Repository: rust
Issue: Specialization and lifetime dispatch
Labels: P-medium,T-compiler,B-unstable,I-unsound,A-specialization,C-bug,requires-nightly,F-specialization,S-bug-has-test,T-types

I see this briefly mentioned in #31844 but no existing issue tracking the incorrect behavior.

Something in the following code is unsound. It should not be possible to implement `make_static`.

```rust
#![feature(specialization)]

trait FromRef<'a, T: ?Sized> {
    fn from_ref(r: &'a T) -> Self;
}

impl<'a, T: ?Sized> FromRef<'a, T> for &'a T {
    fn from_ref(r: &'a T) -> Self {
        r
    }
}

impl<'a, T: ?Sized, R> FromRef<'a, T> for R {
    default fn from_ref(_: &'a T) -> Self {
        unimplemented!()
    }
}

fn main() {
    let s = "specialization".to_owned();
    println!("{:?}", make_static(s.as_str()));
}

fn make_static<T: ?Sized>(data: &T) -> &'static T {
    fn helper<T: ?Sized, R>(data: &T) -> R {
        R::from_ref(data)
    }
    helper(data)
}
```
Repository: rust
Issue: Overflow on requirement evaluation with associated types
Labels: A-type-system,T-compiler,C-bug,T-types

```rust
trait Foo { }

trait Bar<P> {
    type X;
}

impl<T, U> Foo for (T, U)
    where T: Bar<(T, U), X=U>
{ }

impl<T, P: Foo> Bar<P> for T {
    type X = u32;
}

fn main() { }
```

produces on stable and nightly:

```
error[E0275]: overflow evaluating the requirement `<T as Bar<(T, U)>>::X`
 --> src/lol.rs:7:1
  |
7 |   impl<T, U> Foo for (T, U)
  |  _^ starting here...
8 | |     where T: Bar<(T, U), X=U>
9 | | { }
  | |___^ ...ending here
  |
  = note: required because of the requirements on the impl of `Foo` for `(T, U)`
  = note: required because of the requirements on the impl of `Bar<(T, U)>` for `T`

error: aborting due to previous error

```

The impl's compile individually but not together. I expect it to be able to compile.
Repository: flutter
Issue: Color-code stack traces to ease interpretation of crash reports
Labels: c: new feature,c: crash,framework,a: quality,P3,team-framework,triaged-framework

There's been some discussion in `gitter` about how to pick out app-code/user-code from the super-long stack.

Simply put some symbols around the line numbers would've just done the job, say `# 52` for framework code and `#* 53` for user code.

Colored stacks may also be a good idea, though it involves much more work.
Repository: node
Issue: Node.js' internal scripts should be hidden in the inspector.
Labels: module,feature request,inspector

Node.js' internal scripts are not distinguished from user scripts. So when debugging a user script, the inspector is polluted with these internal scripts.

This could be solved either by blackboxing internal scripts by default, or setting a different script kind in V8 internally for these scripts. The latter probably requires an API change in V8.

@ak239 @ofrobots 

![screenshot from 2017-03-17 09 02 09](https://cloud.githubusercontent.com/assets/2291463/24034164/850a86ba-0af0-11e7-94f8-1d770135541b.png)
Repository: opencv
Issue: OpenCL Kernel only takes up to 16 arguments
Labels: feature,category: ocl,category: t-api


##### System information (version)
- OpenCV => 3.2
- Operating System / Platform => Ubuntu 16.04
- Compiler => g++

##### Detailed description

cv::ocl::Kernel::args() only takes up to 16 arguments. This is hard-coded in the source (ocl.hpp). Presumably, the developer did not expect users to need more than that, but for my purposes, I need the option for more.
I would suggest either adding more overloads with more arguments (maybe a bit unflexible solution) or adding the option to add more arguments by calling the function again with some flag. The second option would require the index of the last added argument (i in the source) to be available from outside, so that the next call would be able to continue from that index, instead of overwriting previous arguments.
Repository: opencv
Issue: OpenCL kernel does not support user defined callback function
Labels: feature,category: ocl

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015

##### Detailed description
While the kernel is invoked to run asynchronously, it does not support user defined callback function,
instead it installs a fixed callback function `oclCleanupCallback`.

<!-- your description -->


<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: create-react-app
Issue: Warn about duplicate dependencies
Labels: issue: proposal

I haven’t tried this plugin, but it looks cool: https://github.com/darrenscerri/duplicate-package-checker-webpack-plugin.

Maybe we should do it?
Repository: rust
Issue: `UnwindSafe` is unergonomic
Labels: C-enhancement,T-lang

As I expressed on IRC, I feel like, unless quickly taken care of, `UnwindSafe` is going to be a "failed feature". I've seen now quite a bit of people that told me that "they just wrap everything in `AssertUnwindSafe`" defeating the whole purpose of it. I've also seen comments that `UnwindSafe` is a PITA - sentiment that I'm beginning to share. I am tempted to ignore `UnwindSafe` completely as well, even though I'd like to do stuff properly. Please hear me out.

`UnwindSafe` and `RefUnwindSafe` are not too complicated, but they force people into writing a lot of boilerplate, and the worst part once used ... force that boilerplate on all other users, that might not even know what is it all about.

Static dispatch works OK, since similarly to `Send` and `Sync` any `struct` will get `UnwindSafe` and `RefUnwindSafe` if all fields of it satisfy it.

The problem is dynamic dispatch, trait object and trait bounds. Any time someone has to use eg. `Box<TraitObject>`, even if it's only due to lack of `impl Trait` on stable, that person most probably should have done `Box<Trait + RefUnwindSafe>`. Otherwise that `Box<Trait>` does not satisfy `SafeUnwind`, even though most probably that would be the intention. After all ["This trait is namely not implemented by UnsafeCell, the root of all interior mutability"](https://doc.rust-lang.org/std/panic/trait.RefUnwindSafe.html).

And even if that person is aware of "unwind safety", after putting `+RefUnwindSafe` it won't work because:
 
    only Send/Sync traits can be used as additional traits in a trait object 

To get this working a lot of boilerplate needs to be added. [Example in my code](https://github.com/slog-rs/slog/blob/0b4c3f2923c2f35f643f212d0dd8562af8dfd954/src/lib.rs#L1112) which is just a PITA. And the worst part: after putting `UnwindSafe` bound in types used in open-traits (to be implemented by users of a library), now all users have to satisfy that bound. They will have to remember about it, add blanket implementations adding `UnwindSafe` for every type used as trait object, and get libraries they might want to use it, to do the same...

I don't know. Maybe I'm missing something here, but I feel like at least `+UnwindSafe` should work just like `+Send` and `+Sync`.

Also, I think if the default would be different, there would be almost no problem. `Box<Trait>` should mean `Box<Trait + RefUnwindSafe>`, and users should be able to opt-out of it with `Box<Trait + !RefUnwindSafe>`. This way, unaware uses would get their types `UnwindSafe` without knowing it.
Repository: go
Issue: x/net/idna: support label separators other than ASCII dot
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
```
go version go1.8 linux/amd64
```

### What operating system and processor architecture are you using (`go env`)?

```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/admin/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build229576781=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
```

### What did you do?

Passed a string `"example\u3002jp"` to `ToASCII()`.

### What did you expect to see?

The return value is `"example.jp"`

### What did you see instead?

The return value was `"xn--examplejp-ck3h"`

https://tools.ietf.org/html/rfc3490#section-3.1

```
3.1 Requirements

  IDNA conformance means adherence to the following four requirements:

  1) Whenever dots are used as label separators, the following
     characters MUST be recognized as dots: U+002E (full stop), U+3002
     (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
     (halfwidth ideographic full stop).
```

I created a fix and add test cases at https://github.com/hnakamur/net/commit/bd2fe133f3df97090c43d065b739774b900f67c9
I also followed the steps at [Contribution Guide - The Go Programming Language](https://golang.org/doc/contribute.html) and am ready to run `git mail` if this fix looks good to reviewers.

Thanks!
Repository: rust
Issue: E0122 says bounds aren't enforced, but they actually are?
Labels: T-compiler,C-feature-request

For [multistr](https://docs.rs/multistr) I've included trait bounds in type aliases so that it's clear in the documentation what should be passed to the generics for these aliases, e.g. [SliceArray5](https://docs.rs/multistr/latest/multistr/type.SliceArray5.html).

But because I've generated several of these aliases E0122 floods my error output and I don't see any way of turning it off:

```
warning[E0122]: trait bounds are not (yet) enforced in type definitions
   --> src/array.rs:166:13
    |
166 |             pub type $slice_name<T: 'static + Copy> = $name<[T]>;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
```

(× 17)

It'd be really nice if I could silence this error somehow, because while it's good to have the error by default, it's making debugging my code very hard when I have to scroll past a wall of these errors.
Repository: TypeScript
Issue: Type JSX elements based on createElement function
Labels: Suggestion,In Discussion,Fix Available

TypeScript currently uses a JSX namespace to type the props of JSX elements. This is customisable by modifying `JSX.IntrinsicElements`, `JSX.ElementClass`. However, the type of an element is always `JSX.Element`.

Of course more interfaces could be added to the `JSX` namespace. However, I think that with less effort, the compiler could be made more flexible. I'd propose to check JSX elements based on a (virtual) call to `JSX.createElement`. For instance, the current behaviour can approximately be written like this:

```typescript
namespace JSX {
  // intrinsic elements
  function createElement<K extends keyof JSX.IntrinsicElements>(tag: K, props: JSX.IntrinsicElements[K], children: JSX.Element[]): JSX.Element;
  // class and functional components
  function createElement<P>(component: (JSX.ElementClass & { new(): { props: P } }) | ((props: P) => JSX.Element), props: P, children: JSX.Element[]): JSX.Element;
}
```

Given that function signatures are well customisable with the use of generics for instance, most requests can be implemented this way. For instance, #13890 and #13618 would benefit from this change. Libraries that use JSX, but not on the React-way, will benefit from this too.

## Proposed semantics
For a JSX element, a virtual call to `JSX.createElement` is constructed. It is passed three arguments:

1. Tag name (string) in case of an intrinsic argument (`<div />`). Otherwise, the identifier is passed (`Foo` for `<Foo />`).
2. An object containing the props.
3. An array containing the children.

This should be roughly the same as the JSX transform used in the emitter phase. One notable difference is the following: in case of no properties or no children, an empty object or an empty array should be passed, instead ignoring the argument. This makes it easier to write `JSX.createElement` for library authors.

## Backwards compatibility
For backwards compatibility, one of the following approaches could be taken:

- Use old logic if `JSX.createElement` does not exist.
- If `JSX.createElement` does not exist, default it to (roughly) the definition above.

## Error reporting
When type checking the generated function call, the checker can give error messages like "Argument of type .. " or "Supplied parameters do not match any signature of call target". These messages should be replaced when checking JSX elements.
Repository: go
Issue: mime: BEncoding and QEncoding don't respect the 76 character line limit in RFC2047
Labels: help wanted,NeedsFix

As a continuation of Issue #12300, mime: BEncoding and QEncoding don't respect the 76 character line limit in RFC2047.

Here is the relevant part from Section 2 of RFC2047. (emphasis mine)

> An 'encoded-word' may not be more than 75 characters long, including
> 'charset', 'encoding', 'encoded-text', and delimiters.  If it is
> desirable to encode more text than will fit in an 'encoded-word' of
> 75 characters, multiple 'encoded-word's (**separated by CRLF SPACE**) may
> be used.
> 
> While there is no limit to the length of a multiple-line header
> field, **each line of a header field that contains one or more
> 'encoded-word's is limited to 76 characters**.


### What version of Go are you using (`go version`)?
1.8

### What operating system and processor architecture are you using (`go env`)?
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=E:\gowork\
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\graj04\AppData\Local\Temp\go-build930053034=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1

### What did you do?
https://play.golang.org/p/vO6pcZgesh


### What did you expect to see?
```
=?utf-8?q?=C2=A1Hola,_se=C3=B1or_this_is_to_see_what_happens_if_the_test_?= 
 =?utf-8?q?is_really_long._ltkhetslk_lskthe_lt_slkth_sekltse_ltksht_lskejt?= 
 =?utf-8?q?_lsht_lsht_lht_lht_lsht_lhtlshtlsetlksje_tlsejt_lksetlkse_tlkse?= 
 =?utf-8?q?_tlkst_lkstlkst_lskht_lstlsht_lshtlshtlshtslhtlshtlstle_tlse_tl?= 
 =?utf-8?q?se_tlkse_tlkse_tlse_tlst_lsetlstlset_setsle_tlset_lst_lset_lskt?= 
 =?utf-8?q?_alkthalkht_alkth_aeklth_aeslth_aeslth_eajraoiflanvwoalnwoaiehf?= 
 =?utf-8?q?_awesi_leahr_aflhf_awelh_aweh_awelh_wahwe_!?=
```

### What did you see instead?
```
=?utf-8?q?=C2=A1Hola,_se=C3=B1or_this_is_to_see_what_happens_if_the_test_?= =?utf-8?q?is_really_long._ltkhetslk_lskthe_lt_slkth_sekltse_ltksht_lskejt?= =?utf-8?q?_lsht_lsht_lht_lht_lsht_lhtlshtlsetlksje_tlsejt_lksetlkse_tlkse?= =?utf-8?q?_tlkst_lkstlkst_lskht_lstlsht_lshtlshtlshtslhtlshtlstle_tlse_tl?= =?utf-8?q?se_tlkse_tlkse_tlse_tlst_lsetlstlset_setsle_tlset_lst_lset_lskt?= =?utf-8?q?_alkthalkht_alkth_aeklth_aeslth_aeslth_eajraoiflanvwoalnwoaiehf?= =?utf-8?q?_awesi_leahr_aflhf_awelh_aweh_awelh_wahwe_!?=
```
Repository: react
Issue: Compiler Optimization Umbrella
Labels: Type: Umbrella,React Core Team

Spinoff from https://github.com/reactjs/react-future/issues/50

I wanted to create an umbrella task for when we start working on compiler level optimizations. We've had [a tag](https://github.com/facebook/react/issues?q=is%3Aopen+is%3Aissue+label%3A%22Component%3A+Optimizing+Compiler%22) open for a while but these are fairly primitive optimizations. We want to be able to go further.

I don't think we'll start this project immediately but soon after the Fiber stuff is in place.

__Compiler Infra__

- [ ] Base-line cross-module full JavaScript AOT compiler.
- [ ] Compiler infra structure that fits well into existing tooling at FB, Webpack, Rollup based ecosysem etc. Support parallelism and incremental builds.
- [ ] Solve things like what the npm ecosystem should do. Compile before publishing or after? Probably after.

__Optimizations__

- [ ] Enable multiple levels of host instances / DOM elements to be managed by a single Fiber. I think this is probably a key requirement for many optimizations. I'm not sure if that Fiber's children will have a single placement point (the parent that they get inserted into) or if it could have multiple insertion points. If it manually does the insertion of its children, then the later would work.
- [ ] Optimizing pure host/DOM elements ("string" components). Can be reasoned about at the core compiler level.
- [ ] Inlining pure functional components so that now the result can be reasoned about as a flat component.
- [ ] Basic constant folding for static configuration.
- [ ] Optimizing across component boundaries without inlining.
- [ ] Optimizing stateful functional components.

__Runtime Optimizations__

- [ ] Dead-code elimination of library code that isn't needed by a particular application. Such as certain events, controlled components or complex attributes.

__Stretch Goals__

- [ ] Computing delta updates after code changes and lets Service Workers update based on that.

More to come...