sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: Input element's value attribute is not set
Labels: feature,state: Needs Design,freq2: medium,area: forms,feature: under consideration

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ X ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
<!-- Describe how the issue manifests. -->
When initializing a FormControl with an initial value, the html input element's value attribute is not set.

## Expected behavior
<!-- Describe what the desired behavior would be. -->
The value attribute of an input element to be set like the specs describe:
[https://www.w3.org/TR/html5/forms.html#attr-input-value]

> The value content attribute gives the default value of the input element. When the value content attribute is added, set, or removed, if the control's dirty value flag is false, the user agent must set the value of the element to the value of the value content attribute, if there is one, or the empty string otherwise, and then run the current value sanitization algorithm, if one is defined.


## Minimal reproduction of the problem with instructions
create a new FormControl with an initial value:
`const control = new FormControl('initial value', [Validators.required]);`
Inspect the input element, and see that the input element does not have the value attribute:
`<input _ngcontent-c13="" formcontrolname="myProperty" type="number" ng-reflect-name="myProperty" class="ng-untouched ng-pristine">`

## What is the motivation / use case for changing the behavior?
Without the value attribute screenreaders cannot get the element's value.
It also makes automatic testing more difficult, since element properties are not accessible by css selectors or xpath. (We have to use a hack: [attr.value]="myForm.get('key').value)

## Environment
angular version: 4.3.4

Browser:
- [ X ] Chrome (desktop) version 60.0.3112.78
- [ X ] Firefox version 54.0
and probably the others as well.
Repository: TypeScript
Issue: Improve CSSStyleDeclaration typings
Labels: Suggestion,In Discussion,Domain: lib.d.ts

Not every string should be allowed in properties of the `CSSStyleDeclaration` interface, such as `display`, `overflow`, etc. The [TypeStyle](https://github.com/typestyle/typestyle/) project seems to have put quite some effort into this already, from which _inspiration_ could be taken.
Repository: axios
Issue: Requests fully buffered by default
Labels: state::triage

#### Summary

By default, when making a streaming request using Axios setting data to a stream, the request is fully buffered. E.g. if you use Axios to send a 10GB file over a network using a file stream, it will consume 10GB of RAM, minimum. This is due to the default behaviour of maxRedirects, which is to allow redirects, which means that the follow-redirects module buffers all data written in case there's a redirect.

I think a section in the docs on streams and buffering with a prominent warning in the docs for maxRedirects that setting it to any value other than 0 (or not setting it at all) will cause writes to be fully buffered would be valuable.

               axios({
                    url: "http://somewhere",
                    method: 'post',
                    responseType: 'json',
                    data: fs.createReadStream('huge10GBFile.txt'),
                    headers: {
                        'Content-Type': 'text/plain'
                    }
                });`

#### Context

- axios version: v0.16.2
- Environment: Mac OS X Sierra
Repository: go
Issue: proposal: permit iota, omission of init expressions in var declarations
Labels: LanguageChange,Proposal,LanguageChangeReview

This was discussed very early in the language design, at the same time when we also introduced iota for constant declarations: Permit iota and the omission of initialization expressions not only in constant but also variable declarations. For instance, this would permit code like:
```
var (
    mercury = NewPlanet(iota + 1)
    venus
    earth
    mars
    ...
)
```
If my memory serves me right, we didn't pursue it at the time because there was no compelling or urgent argument in favor of it.

Such a mechanism could simplify the construction of related named objects and open the door to "enum" values that are not restricted to constant values and their respective types.

As such it may be a more elementary building block towards more complex "enums" in Go (see also the discussion in #19814).

Implementation:
- Straight-forward changes would be required in the front-end of the compiler.

Language:
- This would be a fully backward-compatible language change.
- The change is fully orthogonal to existing features and would make variable and constant declarations more symmetric (and thus the language simpler).
- No new concepts are introduced as this is essentially syntactic sugar.
Repository: javascript
Issue: Please explain using inline styles comment about expensive stylesheets
Labels: question

The [css-in-javascript page](https://github.com/airbnb/javascript/tree/master/css-in-javascript) states

* Use inline styles for styles that have a high cardinality (e.g. uses the value of a prop) and not for styles that have a low cardinality.

> Why? Generating themed stylesheets can be expensive, so they are best for discrete sets of styles.

In the example, you have ` css(styles.periodic, { margin: spacing })`, but this still requires you to use the `withStyles` HOC, so aren't you generated a themed stylesheet regardless of the prop? What makes this less expensive?

For another example that I'm actually using and am wondering about, I have these various column classes, which I then spread into the styles returned by `withStyles`.

```js
const sizes = [10, 20, 30, 40, 50, 60, 70, 80, 90, 25, 75];
const sizeStyles = sizes.reduce((object, size) => ({
  ...object,
  [`columnOffset${size}`]: {marginLeft: `${size}%`},
  [`columnPercent${size}`]: {flex: `0 0 ${size}%`, maxWidth: `${size}%`},
}), {});

withStyles(() => ({
  // other styles above
  ...sizeStyles,
}))(Column);
```

And my `css` call is ``css(styles.column, styles[`columnPercent${size}`], styles[`columnOffset${offset}`])``.

But would it be somehow better to skip adding it to the returned styles and instead do ``css(styles.column, sizeStyles[`columnPercent${size}`], sizeStyles[`columnOffset${offset}`])``?
Repository: rust
Issue: "The following implementations were found" should also mention the trait bounds.
Labels: C-enhancement,A-diagnostics,T-compiler

Test case:

```rust
struct Index;
fn iterate(s: std::collections::HashSet<Index>) {
    for _ in s {}
}
```

This errors with:

```
error[E0277]: the trait bound `std::collections::HashSet<Index>: std::iter::IntoIterator` is not satisfied
 --> src/main.rs:3:5
  |
3 |     for _ in s {}
  |     ^^^^^^^^^^^^^ the trait `std::iter::IntoIterator` is not implemented for `std::collections::HashSet<Index>`
  |
  = help: the following implementations were found:
            <std::collections::HashSet<T, S> as std::iter::IntoIterator>
            <&'a std::collections::HashSet<T, S> as std::iter::IntoIterator>
  = note: required by `std::iter::IntoIterator::into_iter`
```

So, the error is `HashSet<Index>` does not implement `IntoIterator`, but the help also suggests that `HashSet<T, S>` does implement `IntoIterator`, so what is it??

The help should also mention the bounds `T: Eq + Hash`. Or even better, points out that this impl is not chosen because `Index` does not implement `Eq + Hash`.

(Original source code: https://stackoverflow.com/revisions/45717092/2. Tested on playground, `rustc 1.21.0-nightly (df511d554 2017-08-14) running on x86_64-unknown-linux-gnu`)
Repository: go
Issue: x/tools/cmd/goimports: support gofmt option to simplify code
Labels: Tools

```
go version go1.8.3 darwin/amd64
```

Using `goimports` as of https://github.com/golang/tools/commit/84a35ef54dff3c5596983e180ec10919fc432242

The `goimports` command handles import fixing and `gofmt` code formatting. It does not, however, implement the code simplification option `-s`.

This means that `goimports` cannot be used as a drop-in replacement to save-hooks that use `gofmt -s` (for example, when using `-s` as the `gofmt-args` value for the save-hook with `go-mode.el`).

```
package main

import "fmt"

type Thing struct {
	value int
}

func main() {
	things := []Thing{
		Thing{value: 42},
	}
	fmt.Printf("things: %+v\n", things)
}
```

There are no problems identified by `goimports`:
```
$ goimports -d complex.go
```

With `gofmt -s`, we get:
```
$ gofmt -s -d complex.go
diff complex.go gofmt/complex.go
--- /var/folders/ts/s940qvdj5vj1czr9qh07fvtw0000gn/T/gofmt822245016	2017-08-16 12:34:31.000000000 -0400
+++ /var/folders/ts/s940qvdj5vj1czr9qh07fvtw0000gn/T/gofmt235716375	2017-08-16 12:34:31.000000000 -0400
@@ -8,7 +8,7 @@

 func main() {
 	things := []Thing{
-		Thing{value: 42},
+		{value: 42},
 	}
 	fmt.Printf("things: %+v\n", things)
 }
```
Repository: rust
Issue: Precision for debug formatting works with empty tuple, but not other things (odd inconsistency)
Labels: T-libs-api,C-bug,A-fmt

It may be intentional that precision doesn't work with debug formatting (only with display), but this inconsistency is odd.

```rust
println!("{:?}", ()); // prints '()'
println!("{:.0?}", ()); // prints ''
println!("{:.1?}", ()); // prints '('

// In all of the below, the precision specifier has no effect at all;
// the full debug text is printed
println!("{:.0?}", 125);
println!("{:.1?}", 125);
println!("{:.0?}", (1, 2, 3));
println!("{:.1?}", (1, 2, 3));
println!("{:.0?}", ((), (), ()));
println!("{:.1?}", ((), (), ()));
println!("{:.0?}", "test");
println!("{:.1?}", "test");
```

I presume this is unintended (I can't imagine why it would be intentional)? Although any change may technically be breaking. Of course, if it is desired that precision doesn't work with debug, it doesn't really matter since there's no reason to use it.
Repository: puppeteer
Issue: Question: How do I get puppeteer to download a file?
Labels: feature,upstream,confirmed

Question: How do I get puppeteer to download a file or make additional http requests and save the response?
Repository: react
Issue: The fake event trick for rethrowing errors in DEV fires unexpected global error handlers and makes testing harder
Labels: Component: DOM,Type: Discussion

I'm trying to make use of componentDidCatch in the React 16 beta. I already had a global window error handler which was working fine, but it unexpectedly catches errors that I would expect componentDidCatch to have handled. That is, component-local errors are being treated as window-global errors in dev builds.

The problem seems to stem from `invokeGuardedCallbackDev` in `ReactErrorUtils.js`. I think that this entire `__DEV__` block of code is problematic. The stated rational is:

```
  // In DEV mode, we swap out invokeGuardedCallback for a special version
  // that plays more nicely with the browser's DevTools. The idea is to preserve
  // "Pause on exceptions" behavior. Because React wraps all user-provided
  // functions in invokeGuardedCallback, and the production version of
  // invokeGuardedCallback uses a try-catch, all user exceptions are treated
  // like caught exceptions, and the DevTools won't pause unless the developer
  // takes the extra step of enabling pause on caught exceptions. This is
  // untintuitive, though, because even though React has caught the error, from
  // the developer's perspective, the error is uncaught.
```

This is misguided because it's not about pausing on exceptions, it's about "pause on _uncaught_ exceptions." However, `componentDidCatch` makes exceptions _caught_!

Rather than switching on prod vs dev and using try/catch in prod and window's error handler in dev, React should always use try/catch, but rethrow if you reach the root without hitting a componentDidCatch handler. This would preserve the correct "pause on uncaught exceptions" behavior without messing with global error handlers.
Repository: kubernetes
Issue: Move selector immutability check to validation after v1beta1 retires
Labels: kind/bug,sig/apps,help wanted,lifecycle/frozen,good first issue

The check for selector immutability is located at `PrepareForUpdate` functions of `deploymentStrategy`, `rsStrategy` and `daemonSetStrategy`. We are not able to have the check at validation before _v1beta1_ API version retires due to breaking change to some tests (discussed in this closed [PR](https://github.com/kubernetes/kubernetes/pull/50348)). Once _v1beta1_ retires, we should move the check to validation.
Repository: neovim
Issue: Lua: vim.firstline, vim.lastline
Labels: compatibility,complexity:low,lua

Currently the only command actually supporting `[range]` is `luado`, but documentation (copied from Vim) states that `:lua` and `:luafile` also should, by storing the range in `vim.firstline` and `vim.lastline`. In the current state other commands ignore range completely.

Regarding the implementation I currently more like the idea of adding a metatable to `vim` “module” which will do the following two things:

1. Make `vim` module read-only.
2. Provide firstline and lastline.

This would protect vim module from accidental changes (and similar metatable is to be applied to `vim.types` and `vim.api`; “similar” = “read-only, but no `*line`”). It would still be not impossible to modify our tables, metatable can only protect from some accidental modifications.
Repository: go
Issue: debug/macho: add missing load commands
Labels: NeedsFix

There are nearly 50 load commands. Current code supports few of them.
Repository: vscode
Issue: Monolithic structure, multiple project settings
Labels: feature-request,config

I was wondering if it is possible for VSCode to pick up on multiple `.vscode/settings.json`

For instance if you are working in an monolithic environment with multiple smaller projects inside it, and each have their own `.vscode/settings.json`.
Can VSCode pickup on that, and apply the settings from the smaller projects `.vscode/settings.json` to their subtree and descendant files?

```
monolithic-project/
├── small-project1/
│   ├── .vsocde
│   │   └── settings.json
│   └── src/
│       └── index.ts
└── small-project2/
    ├── .vsocde
    │   └── settings.json
    └── src/
        └── index.ts              
```

**Wanted effect:**
`monolithic-project/small-project1/.vscode/settings.json` applies to `monolithic-project/small-project1` and all descendant files.
`monolithic-project/small-project2/.vscode/settings.json` applies to `monolithic-project/small-project2` and all descendant files.
Repository: opencv
Issue: Adjusting Viz camera parameters yields stuttering effect
Labels: bug,category: viz

##### System information (version)
- OpenCV => 3.3
- Operating System / Platform => Ubuntu 16.04 (x86-64)
- Compiler => g++ 5.4.0

##### Detailed description

Adjusting the intrinsic camera parameters of a `Viz3d` window yields a strange stuttering effect. For example, when adjusting the focal length, there is a slight up-and-down movement every second time. The movement is reproducible (albeit unwanted) and always between the same two (relative) positions. Consider the following minimum example:

##### Steps to reproduce

```
#include <iostream>
#include <opencv2/viz.hpp>

using namespace std;
using namespace cv;
using namespace cv::viz;

int main()
{
  Viz3d window("Test");
  window.showWidget("Test object", WCone(1, 0.5, 100));
  window.spinOnce(1, true); //(unrelated) If this is not called here, getCamera returns different values and setCamera below throws a stack underflow exception!?
  const auto camera = window.getCamera();
  const auto focal_length = camera.getFocalLength();
  const int fx = focal_length[0]; //Deliberate round to int
  const int fy = focal_length[1];
  const auto principal_point = camera.getPrincipalPoint();
  const int px = principal_point[0];
  const int py = principal_point[1];

  for (int i = 1; i <= 30; i++) 
  {
    cout << "Iteration " << i << endl;
    const auto old_camera = window.getCamera();
    Matx44d matrix;
    old_camera.computeProjectionMatrix(matrix);
    cout << "Old proj. matrix: " << matrix << endl;
    Camera new_camera(fx - 10 * i, fy, px, py, old_camera.getWindowSize());
    new_camera.computeProjectionMatrix(matrix);
    cout << "New proj. matrix: " << matrix << endl;
    window.setCamera(new_camera);
    window.spinOnce(500, true);
  }
  return 0;
}
```

I am aware that numerical inaccuracies could be to blame for this, but the effect is far to severe for it only being that. The effect becomes even stronger for larger deviations from the initial parameters and increases when I change multiple parameters at once (it remains to the same extent even when I change `10 * i` to `i` for very small animation steps.). It goes so far as to make the object disappear for relatively sane values of focal length and principal point after a few dozen changes to the parameters.

I also posted this [here](http://answers.opencv.org/question/171647/adjusting-viz-camera-parameters-yields-stuttering-effect/) and [here](https://stackoverflow.com/questions/45542117/adjusting-camera-parameters-yields-stuttering-effect), but did not get any replies. I assume that this is a bug.
Repository: angular
Issue: ExpressionChangedAfterItHasBeenCheckedError is thrown by ngModel.invalid above the ngModel control declaration
Labels: type: bug/fix,freq3: high,area: forms,hotlist: google,state: confirmed,forms: change detection,P3

## I'm submitting a...
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ X] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
When you use NgModel.invalid in an expression above the ngModel control in the dom an ExpressionChangedAfterItHasBeenCheckedError is thrown. when you put the same expression below the ngModel control there is no issue.


## Expected behavior
No errors to be thrown


## Minimal reproduction of the problem with instructions
see https://plnkr.co/edit/0BSoP7SskyE3tD6FzPRy for an example.

## What is the motivation / use case for changing the behavior?
I need to set a 'has-error' class on the parent DomElement when given ngModel control is in an invalid state which doesn't work now.

## Environment
<pre><code>
Angular version: 4.3.5
</code></pre>
Repository: angular
Issue: `*` token not working in AnimationBuilder
Labels: type: bug/fix,area: animations,freq2: medium,P3

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
I noticed that If I use the AnimationBuilder and have an animation that sets the height example 141px, and than after x amount of time another animation is triggered to remove this height by the "*" token, this has no effect at all, as the height still stays the same. 

For the time being I had to replace the "*" with 100%, however this comes with another problem that the animation effect is not working.

## Expected behavior
When the second animation is triggered the full element height is used and have a transition when going from 141px to the full heigh.

## Minimal reproduction
```ts
this.collapseAnimation = this.animationBuilder.build([
  animate("200ms ease-out", style({
    height: `141px`
  }))
]);

this.expandAnimation.create(this.content.nativeElement).play();

// run the below a couple of seconds after
this.expandAnimation = this.animationBuilder.build([
  animate("200ms ease-in", style({
    height: "*"
  }))
]);

this.collapseAnimation.create(this.content.nativeElement).play();
```

## Environment
```
Angular version: 4.3.5
```

https://stackblitz.com/edit/angular-animation-star-token
Repository: rust
Issue: Is automatic insertion of type inference placeholders possible?
Labels: T-lang,C-feature-request

Would it be possible to automatically insert `_` type inference placeholders where none (or not enough) type placeholders are provided, or does this conflict with any other tokens the parser has to deal with?

i.e. can `["foo", "bar"].iter().collect::Vec::()` be turned into `["foo", "bar"].iter().collect::Vec<_>::()` automatically?

and given a `Struct<X,Y>`, can `Struct<Foo>` automatically be understood as `Struct<Foo, _>`?

These would both simplify boilerplate considerably, and the latter could obviate the need to revisit old code when a type is expanded with an additional generic type parameter that can be inferred from its usage.
Repository: flutter
Issue: LocalHistoryEntry api docs are sparse
Labels: framework,d: api docs,f: routes,has reproducible steps,P2,found in release: 3.3,found in release: 3.5,team-framework,triaged-framework

It's just a one liner:
https://docs.flutter.io/flutter/widgets/LocalHistoryEntry-class.html

"An entry in the history of a LocalHistoryRoute."

Which links to a slightly larger description in LocalHistoryRoute.

Maybe this just needs to link to a navigation tutorial?  @alardizabal expressed some confusion attempting to use the API.
Repository: rust
Issue: Type mismatch with generic parameter returns less than helpful errors
Labels: A-type-system,C-enhancement,A-diagnostics,T-compiler,A-impl-trait,WG-diagnostics,A-suggestion-diagnostics,T-types

When a type does not match a generic parameter (I'm not sure if it's treated differently if it's because a generic constraint failed or because a previous usage dictated a particular variant of that generic), the resulting error message is not helpful because it seems to indicate that everything is OK.

As an example:

```rust
error[E0308]: mismatched types
  --> src/main.rs:80:23
   |
80 |             return Ok(response);
   |                       ^^^^^^^^ expected type parameter, found struct `std::io::Cursor`
   |
   = note: expected type `tiny_http::Response<R>`
              found type `tiny_http::Response<std::io::Cursor<std::vec::Vec<u8>>>`
   = help: here are some functions which might fulfill your needs:
           - .with_data(...)
           - .with_header(...)
           - .with_status_code(...)
```

the method in question was declared as

```rust
fn send_email<R>(req: &mut Request) -> Result<Response<R>, String>
    where R: std::io::Read
```

I believe the compiler message should at least indicate the constraints on `R`, because as it currently reads, `tiny_http::Response<std::io::Cursor<std::vec::Vec<u8>>>` _is_ a valid form of `tiny_http::Response<R>` for `R=std::io::Cursor<std::vec::Vec<u8>>`