sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Need a way to compute height of a row of baseline-aligned RenderBoxes
Labels: c: new feature,framework,P3,team-framework,triaged-framework

This comes up when trying to implement `RenderBox.computeMinIntrinsicHeight()`, and `RenderBox.computeMaxIntrinsicHeight()` for a renderer that contains more than one baseline-aligned child.

I thought this would work (it should be consistent with https://github.com/flutter/flutter/issues/10014):
```dart
  double _lineHeight(double width, List<RenderBox> boxes) {
    double aboveBaseline = 0.0;
    double belowBaseline = 0.0;
    for (RenderBox box in boxes) {
      final double baseline = box.getDistanceToBaseline(TextBaseline.alphabetic);
      aboveBaseline = math.max(baseline, aboveBaseline);
      belowBaseline = math.max(box.getMinIntrinsicHeight(width) - baseline, belowBaseline);
    }
    return aboveBaseline + belowBaseline;
  }
```
If fails in a complex assertion due to the call to getDistanceToBaseline():
```
Only call this function after calling layout on this box. You are only allowed to call
this from the parent of this box during that parent's performLayout or paint functions.
...
```
@Hixie pointed out the difficulty here:

> The distance to the baseline depends on the dimensions of the box, which aren't known until the box has been laid out. (For example, what's the distance to the baseline of a Center widget?)

So perhaps `getDistanceToBaseline()` should be: `getDistanceToBaseline(baseline, { Size size })`
where size defaults to this.size so long as the existing assertion is true.  

@Hixie also pointed out (vis the size parameter):

> There's some caching logic going on that we'd have to tweak.
Repository: vscode
Issue: insertSnippet produces trailing spaces
Labels: feature-request,snippets

<!-- Do you have a question? Please ask it on http://stackoverflow.com/questions/tagged/vscode. -->

<!-- Use Help > Report Issues to prefill these. -->
- VSCode Version: Version 1.19.1 (1.19.1)
- OS Version: macOS 10.13.2

The `insertSnippet` function in the vscode api takes a snippet and inserts it at the given position with the indentation of the position prepended to each line. This is great, except that it also adds the indentation to any blank lines in the snippet causing unnecessary trailing spaces. The logic also doesn't respect carriage return special chars like `\r`. 

This problem has been touched upon before in this issue: https://github.com/Microsoft/vscode/issues/20112
Repository: go
Issue: net: document that Dial/Listen with "ip4:tcp" or "ip6:tcp" fails on Windows
Labels: Documentation,OS-Windows,NeedsFix

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?

go version go1.9.2 windows/amd64

### Does this issue reproduce with the latest release?

yes

### What operating system and processor architecture are you using (`go env`)?

```bash
$ go env
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\ilyaigpetrov\go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
```

Windwos 10

### What did you do?

[net: Dial/Listen with "ip4:tcp" or "ip6:tcp" fails on Windows](https://github.com/golang/go/issues/23193)  
I want this to be documented

### What did you expect to see?

On page https://golang.org/pkg/net/ in section [Bugs](https://golang.org/pkg/net/#pkg-note-BUG) I want to see that Dial/Listen with "ip4:tcp" or "ip6:tcp" fails on Windows

### What did you see instead?

This is not documented.
Repository: youtube-dl
Issue: Proxy parameter is not working correctly inside of openload.py (PhantomJS)
Labels: request,bug

## Please follow the guide below

- You will be asked some questions and requested to provide some information, please read them **carefully** and answer honestly
- Put an `x` into all the boxes [ ] relevant to your *issue* (like this: `[x]`)
- Use the *Preview* tab to see what your issue will actually look like

---

### Make sure you are using the *latest* version: run `youtube-dl --version` and ensure your version is *2017.12.14*. If it's not, read [this FAQ entry](https://github.com/rg3/youtube-dl/blob/master/README.md#how-do-i-update-youtube-dl) and update. Issues with outdated version will be rejected.
- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.12.14**

### Before submitting an *issue* make sure you have:
- [x] At least skimmed through the [README](https://github.com/rg3/youtube-dl/blob/master/README.md), **most notably** the [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones

### What is the purpose of your *issue*?
- [x] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [ ] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

---

Currently openload.py is using PhantomJS in order the obtain the final URL, but it is not passing correctly the parameter --proxy URL to PhantomJS. 
Output is: https://openload.co/stream/None?mime=true
In the Proxy Server I could see only one https call to openload servers, missing the rest of them which are being originated in openload.py lines 228-231: 

        p = subprocess.Popen([
            self.exe, '--ssl-protocol=any',
            self._TMP_FILES['script'].name
        ], stdout=subprocess.PIPE, stderr=subprocess.PIPE)

Here we can see that the only parameter used for PhantomJS is "--ssl-protocol=any".
I have tested it in the latest version (2017.12.14) and the issue is still there.
Repository: rust
Issue: two-phase-borrows need a specification
Labels: E-hard,C-enhancement,P-medium,T-lang,T-compiler,A-NLL,NLL-reference

Spawned off of https://github.com/rust-lang/rust/pull/46887#issuecomment-353156090: While our short term solution for two-phase borrow support (#46037) is to make it as conservative as we can (e.g. the still planned #46747), the reality is that its complex and needs a specification.

(It might even be worth the exercise of adding them to the https://github.com/nikomatsakis/borrowck model )
Repository: angular
Issue: property binding syntax: [label] instead of this [label]="label"
Labels: feature,area: core,core: binding & interpolation,feature: under consideration


## I'm submitting a...
<pre><code>
[ X] Feature request
</code></pre>

## Current behavior


```
@Component({
 template: ' <my-other [label]="label"></my-other>'
 //...
})
export class TestComponent {
   label = 'hello';
}
```


## Expected behavior
Having to only type this 

```
<my-other [label]></my-other>
```

Or even better with a self closing tag

```
<my-other [label] />
```

I assume this is not yet the case because angular wants to be close to custom elements spec. Nevertheless that'd be great.
Repository: TypeScript
Issue: Typescript can't infer types when using Proxy
Labels: Bug,Help Wanted,Domain: lib.d.ts

**Code**
```javascript
let obj = {
    prop1: function () { },
    prop2: 'hello',
}

let prox = new Proxy(obj, {
    get: function (target, name) {
        return 5;
    }
});

prox.prop1.
```
**Expected behavior:**
I would expect that when I type ```prox.prop1.```, I would get typescript suggestions for ```Number.prototype```, but instead, I get suggestions for ```Function.prototype```.  ```prox.prop1``` will (according to typescript) still be callable as a function, but in runtime, it will clearly be a number and will throw an exception.

Statically evaluate the proxy traps and determine the type of thing being returned to offer proper typescript intellisense.
Repository: rust
Issue: Cannot generate unit struct with a macros
Labels: C-enhancement,A-macros,T-lang

It doesn't seem possible to generate unit struct declaration from a macros in neither stable nor nightly version of Rust.

[A simplified playground sample](https://play.rust-lang.org/?gist=0dbd7527efdae183f8bfc3fadb28c2d7&version=stable):

```rust
macro_rules! def_struct {
  ($name:ident $($body:tt)*) => {
    pub struct $name $($body)*
  };
}

def_struct!(X {}); // compiles
def_struct!(Y); // doesn't

fn main() {}
```

When trying to expand the second macro call, Rust complains:

```rust
error: expected `where`, `{`, `(`, or `;` after struct name, found `<eof>`
 --> src/main.rs:3:16
  |
3 |     pub struct $name $($body)*
  |                ^^^^^
...
8 | def_struct!(Y); // doesn't
  | --------------- in this macro invocation
```

If I add a semicolon as it asks right after the struct definition, the unit macro call starts compiling fine:

```rust
macro_rules! def_struct {
  ($name:ident $($body:tt)*) => {
    pub struct $name $($body)*;
  };
}

def_struct!(Y); // compiles
def_struct!(X {}); // doesn't

fn main() {}
```

 but the other one fails instead:

```rust
error: macro expansion ignores token `;` and any following
 --> src/main.rs:3:31
  |
3 |     pub struct $name $($body)*;
  |                               ^
  |
note: caused by the macro expansion here; the usage of `def_struct!` is likely invalid in item context
 --> src/main.rs:8:1
  |
8 | def_struct!(X {}); // compiles
  | ^^^^^^^^^^^^^^^^^^
```

The two errors seem to contradict each other here. The only obvious workaround to make both cases work I could find is to split macro definition into two, one with semicolon and another without:

```rust
macro_rules! def_struct {
  ($name:ident) => {
    pub struct $name;
  };
  
  ($name:ident $body:tt) => {
    pub struct $name $body
  }
}

def_struct!(X {}); // compiles
def_struct!(Y); // compiles

fn main() {}
```

But this is not very clean and gets even harder in more complicated macros. Is there any reason for such behaviour or is it a bug and it would be possible to allow macro to generate unit structs that are not followed by a semicolon, just like any other?
Repository: TypeScript
Issue: Inference problem
Labels: Bug

I only wish I could better describe the problem.
I'm trying to properly declare the type for `all()`. Here's how it's used:

```
Promise.resolve('kromid')
  .then(all(identity, identity))
  .then(([a, b]) => a.splita);
```

Problem is that `a` and `b` are inferred as `any` instead of `string`, so TS doesn't fail with the expected:

> Property 'splita' does not exist on type 'string'. Did you mean 'split'?

Here's the implementation:

```
function all<T1, Param>(a1: Res<Param, T1>): (p: Param) => Promise<[T1]>;
function all<T1, T2, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>): (p: Param) => Promise<[T1, T2]>;
function all<T1, T2, T3, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>, a3: Res<Param, T3>): (p: Param) => Promise<[T1, T2, T3]>;
function all<T1, T2, T3, T4, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>, a3: Res<Param, T3>, a4: Res<Param, T4>): (p: Param) => Promise<[T1, T2, T3, T4]>;
function all<T1, T2, T3, T4, T5, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>, a3: Res<Param, T3>, a4: Res<Param, T4>, a5: Res<Param, T5>): (p: Param) => Promise<[T1, T2, T3, T4, T5]>;
function all<T1, T2, T3, T4, T5, T6, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>, a3: Res<Param, T3>, a4: Res<Param, T4>, a5: Res<Param, T5>, a6: Res<Param, T6>): (p: Param) => Promise<[T1, T2, T3, T4, T5, T6]>;
function all<T1, T2, T3, T4, T5, T6, T7, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>, a3: Res<Param, T3>, a4: Res<Param, T4>, a5: Res<Param, T5>, a6: Res<Param, T6>, a7: Res<Param, T7>): (p: Param) => Promise<[T1, T2, T3, T4, T5, T6, T7]>;
function all<T1, T2, T3, T4, T5, T6, T7, T8, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>, a3: Res<Param, T3>, a4: Res<Param, T4>, a5: Res<Param, T5>, a6: Res<Param, T6>, a7: Res<Param, T7>, a8: Res<Param, T8>): (p: Param) => Promise<[T1, T2, T3, T4, T5, T6, T7, T8]>;
function all<T1, T2, T3, T4, T5, T6, T7, T8, T9, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>, a3: Res<Param, T3>, a4: Res<Param, T4>, a5: Res<Param, T5>, a6: Res<Param, T6>, a7: Res<Param, T7>, a8: Res<Param, T8>, a9: Res<Param, T9>): (p: Param) => Promise<[T1, T2, T3, T4, T5, T6, T7, T8, T9]>;
function all<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, Param>(a1: Res<Param, T1>, a2: Res<Param, T2>, a3: Res<Param, T3>, a4: Res<Param, T4>, a5: Res<Param, T5>, a6: Res<Param, T6>, a7: Res<Param, T7>, a8: Res<Param, T8>, a9: Res<Param, T9>, a10: Res<Param, T10>): (p: Param) => Promise<[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10]>;
function all<Param>(...values: Res<Param, any>[]): (p: Param) => Promise<any[]>;
function all<Param>(...values: Res<Param, any>[]): (p: Param) => Promise<any[]> {
  return param => Promise.all(values.map(obj => obj.apply ? obj(param) : obj));
}
type Res<I, O> = ((i: I) => O | Promise<O>) | O | Promise<O>


function identity<T>(a: T): T {
  return a;
}
```

There already is an effort here: https://stackoverflow.com/q/47934804/592641. But doesn't cut it.
Repository: TypeScript
Issue: Unions without discriminant properties do not perform excess property checking
Labels: Suggestion,Needs Proposal

<!-- BUGS: Please use this template. -->
<!-- QUESTIONS: This is not a general support forum! Ask Qs at http://stackoverflow.com/questions/tagged/typescript -->
<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.7.0-dev.201xxxxx

**Code**

```ts
// An object to hold all the possible options
type AllOptions = {
    startDate: Date
    endDate: Date
    author: number
}

// Any combination of startDate, endDate can be used
type DateOptions =
    | Pick<AllOptions, 'startDate'>
    | Pick<AllOptions, 'endDate'>
    | Pick<AllOptions, 'startDate' | 'endDate'>

type AuthorOptions = Pick<AllOptions, 'author'>

type AllowedOptions = DateOptions | AuthorOptions

const options: AllowedOptions = {
    startDate: new Date(),
    author: 1
}

```

**Expected behavior:**

An error that `options` cannot be coerced into type `AllowedOptions` because `startDate` and `author` cannot appear in the same object.

**Actual behavior:**

It compiles fine.
Repository: opencv
Issue: test_java: org.opencv.test.calib3d sporadic failure
Labels: bug,test,category: calib3d,category: java bindings

[Linux32](http://pullrequest.opencv.org/buildbot/builders/master_noOCL-lin32/builds/237):
```
testSolvePnPListOfPoint3ListOfPointMatMatMatMat

Max difference between expected and actiual Mats is 0.008481956505988819, that bigger than 0.001 

junit.framework.AssertionFailedError: Max difference between expected and actiual Mats is 0.008481956505988819, that bigger than 0.0001
at org.opencv.test.OpenCVTestCase.compareMats(Unknown Source)
at org.opencv.test.OpenCVTestCase.assertMatEEqual(Unknown Source)
at org.opencv.test.calib3d.Calib3dTest.testSolvePnPListOfPoint3ListOfPointMatMatMatMat(Unknown Source)
at orgg.opencv.test.OpenCVTestCase.runTest(Unknown Source)
at org.opencv.test.OpenCVTestCase.runBare(Unknown Source)
```
Repository: rust
Issue: Enforce informal properties of traits such as `PartialEq`
Labels: A-lints,A-trait-system,T-lang,C-feature-request

The trait `PartialEq` represents a partial equivalence — that is, a relation that is symmetric and transitive. However, Rust doesn't currently enforce these properties in any way. This means we get issues like this:
```rust
struct A;
struct B;

impl PartialEq<B> for A {
    fn eq(&self, _other: &B) -> bool {
        true
    }
}

fn main() {
    let a = A {};
    let b = B {};
    a == b; // Works
    b == a; // Error (B does not implement PartialEq<A>)
}
```
This is confusing, but it's usually not so much of an issue in user code, because it's easy to flip the operands. However, when attempting to write generic functions over these traits, you run into problems (for example in https://github.com/rust-lang/rust/pull/46934).

At the very least there should be a lint warning/error for this. It'd be nice to have a generic solution for properties of traits, though that could come later. It'd be even nicer if the symmetric case for `PartialEq`, for instance, could be automatically implemented by Rust, though this could require quite a bit more machinery.
Repository: rust
Issue: test_mul_add failt in debug mode for arm-unknown-linux-gnueabi
Labels: O-Arm,T-libs-api,C-bug

This following test extract from libstd:

```rust
#[cfg(test)]
mod tests {
    macro_rules! assert_approx_eq {
        ($a:expr, $b:expr) => ({
            let (a, b) = (&$a, &$b);
            assert!((*a - *b).abs() < 1.0e-6,
                    "{} is not approximately equal to {}", *a, *b);
        })
    }

    #[test]
    fn f64_test_mul_add() {
        assert_approx_eq!((-12.3f64).mul_add(-4.5, -6.7), 48.65);
        assert_approx_eq!(0.0f64.mul_add(8.9, 1.2), 1.2);
    }

    #[test]
    fn f32_test_mul_add() {
        assert_approx_eq!((-12.3f32).mul_add(-4.5, -6.7), 48.65);
        assert_approx_eq!(0.0f32.mul_add(8.9, 1.2), 1.2);
    }
}
```

fails to run in raspbarry pi 3 and in qemu when compiled in debug mode for the target `arm-unknown-linux-gnueabi`. It works if compiled in release mode. `rustc 1.24.0-nightly (250b49205 2017-12-21)` was used.

To test using [cross](https://github.com/japaric/cross), create a project execute `cross test --target arm-unknown-linux-gnueabi`. cross execute the test using qemu-arm, but I think it is not a problem with qemu because the test also fails running in a raspbarry pi 3. Also the test works if compiled in release mode.

qemu error:

```
---- tests::f32_test_mul_add stdout ----
        thread 'tests::f32_test_mul_add' panicked at '38.4 is not approximately equal to 1.2', src/lib.rs:20:8

---- tests::f64_test_mul_add stdout ----
        thread 'tests::f64_test_mul_add' panicked at '38.4 is not approximately equal to 1.2', src/lib.rs:14:8
```

raspberry pi error:

```
---- tests::f32_test_mul_add stdout ----
        thread 'tests::f32_test_mul_add' panicked at '-12.3 is not approximately equal to 48.65', src/lib.rs:19:8

---- tests::f64_test_mul_add stdout ----
        thread 'tests::f64_test_mul_add' panicked at '0 is not approximately equal to 48.65', src/lib.rs:13:8
```
Repository: rust
Issue: Highlight when APIs panic in rustdoc
Labels: T-rustdoc,C-enhancement

When an API specifically has a "will panic on X condition" guarantee (e.g. indexing APIs, unwrap, expect, perhaps allocating APIs) it would be nice if the stdlib could highlight these the way we do `unsafe` methods.

https://twitter.com/0x424c41434b/status/944316751919140865


Worth prototyping this behind a feature flag for now, and then discussing whether we should be stabilizing it (or keeping it forever unstable for the stdlib).

cc @rust-lang/docs

(I'm mentoring 0x424c41434b on implementing this, even if we eventually decide not to do this)
Repository: vue-element-admin
Issue: Speaking English
Labels: in plan

Hi everyone,

I would like to say that if issues have English translation with their original (Chinese) descriptions it would be awesome. It has two sides, we (not Chinese speakers/readers) can understand the problem and read the solution, and also we may help to overcome the issue as well. So it could be a win-win situation for the individuals from other languages.

Also I am not a native English speaker too, but those kind of platforms requires us to speak (I am clearly not forcing anyone). The documentation is as important as the code itself. We all know Vue has its attraction also due to its clear documentation.

Thank you.

PS: I would like to thank @PanJiaChen and all other contributors of this awesome project.
Repository: go
Issue: net: document that DialIP can only be used with WriteMsgIP of Connection-less protocols
Labels: Documentation,NeedsInvestigation

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`

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?

```sh-session
go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ilyaigpetrov/go"
GORACE=""
GOROOT="/usr/lib/go-1.9"
GOTOOLDIR="/usr/lib/go-1.9/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build418566627=/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"
```

### What did you do?

`WriteMsgIP` can't be used after `DialIP` to TCP

```go
package main

import (
  "net"
  "fmt"
)

func main() {

  loIP := net.IPv4(127,0,0,1)

  // Accept TCP connections on localohst
  listener, err := net.ListenTCP("tcp", &net.TCPAddr{ IP: loIP , Port: 0})
  if err != nil {
    panic(err)
  }
  go func(){
    for {
      _, err := listener.Accept()
      if err != nil {
        fmt.Println(err)
      }
    }
  }()

  // Dial localhost
  ipconn, err := net.DialIP("ip:tcp", nil, &net.IPAddr{IP: loIP})
  if err != nil {
    panic(err)
  }
  _, _, err = ipconn.WriteMsgIP([]byte{11,22,33}, []byte{}, &net.IPAddr{ IP: loIP })
  if err != nil {
    panic(err)
  }
  fmt.Println("Heppy exit!")

}
```

### What did you expect to see?

It doesn't work. Error appears: `write ip 127.0.0.1->127.0.0.1: use of WriteTo with pre-connected connection`.  
It seems `DialIP` can't be used with `WriteMsgIP` and __I want this to be documented__.

### What did you see instead?

No documentation.