sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: request| feat(form): Ability to programmatically submit an AbstractControl, NgForm or a FormGroupDirective
Labels: feature,state: Needs Design,freq2: medium,area: forms,feature: under consideration

## I'm submitting a...
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[x] 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
In standard HTML/TypeScript, without angular, it's possible to get a HTMLFormElement and call either `.sumbit()` or `.reset()` on it to submit it programmatically. If we want to do this in an Angular2 Component, we will need to either:

- have a `@ViewChild('myForm') formElementRef`, casting the `formElementRef.nativeElement` to `HtmlFormElement` and then call `.submit()` on it
- have a hidden `input type="sumbit"` (or similar), again do a `@ViewChild` on it and trigger it programmatically.

Note that in the case of `.reset()` this is very well supported and documented.

## Expected behavior
To be able to trigger the `.submit()` operation directly from an `FormGroup`/`FormArray` or even an `NgForm` would be really helpful.
There are cases where, for practical UI/UX reasons the submit button cannot be in the `<form>` element itself. Although this is far from ideal, it's still something that can be and is done.

## Minimal reproduction of the problem with instructions
`<button #submit>Submit!<button>
<form [formGroup]="form" (submit)="submitted()">[...]</form>`

Then try to submit the form without using an `ElementRef` or a hidden submit inside the `<form>`.

## What is the motivation / use case for changing the behavior?
Some UIs will require us to have the submit element outside of the `<form>`, or to submit a form relying on different mechanism/conditions (e.g., time triggered for a game-like UI).


## Environment
<pre><code>
Angular version: 5.1.0-beta.1
</code></pre>
Repository: rust
Issue: We should lint when !-fallback results in questionable code
Labels: C-enhancement,A-lints,A-diagnostics,T-compiler,F-never_type

An example is the following code:

```rust
#![feature(never_type)]

use std::error::Error;

pub trait Deserialize: Sized {
  fn deserialize() -> Result<Self, Box<Error>>;
}

impl Deserialize for ! {
  fn deserialize() -> Result<!, Box<Error>> {
    Err("oh geez")?;
    panic!()
  }
}

fn foo() -> Result<usize, Box<Error>> {
  Deserialize::deserialize()?;
  Ok(22)
}
```

Here, the type of `Deserialize::deserialize()?` defaults to `!`, making the `Ok(22)` unreachable. It might be unclear to users why the `Ok(22)` is unreachable since the `!`-fallback happens implicitly, so it would be good to point at it with an auxiliary note on the warning. eg. something like `note: unconstrained type variable fell back to !`
Repository: angular
Issue: by default not send undefined params in url
Labels: feature,breaking changes,area: router,feature: under consideration

## I'm submitting a...
- [x] Feature request

## CURRENT
To be simple, I will take example for GET request. Here you have a simple method making http call with an optional parameter:
```
public getCity(cityId?: number){
  this.get('city', { params: {city: cityId}})
}
``` 

`cityId?` is optional, so you can call method like `this.getCity()`, if you do so angular will make request to this url : `http://localhost/city?city=undefined` 




## EXPECTED
I think avoid sending undefined params (not including them in HttpParams if they are undefined) should be most common use case because we can check this on backend. If params aren't present == undefined.


## MOTIVATION

Advantages of this is : maybe URL have limits and sending essential/useful data we really need is important. I don't understand why send them by default if they are undefined. Something like [Include.NON_NULL](https://github.com/FasterXML/jackson-annotations/blob/master/src/main/java/com/fasterxml/jackson/annotation/JsonInclude.java#L107) in jackson. 
What you think about not send them by default ? or add option in [options{}](https://angular.io/api/common/http/HttpClient#get) object  just to avoid this big codes: 
```
let cleanedParams = new HttpParams();
req.params.keys().forEach(x => {
  if(req.params.get(x) != undefined)
    cleanedParams = cleanedParams.append(x, req.params.get(x));
})

const clonedRequest = req.clone({
  params:cleanedParams
});

return next.handle(clonedRequest)
```

Otherwise yes actually we can fortunately workaround by interceptor or with : 
```
public getCity(cityId?: number){
  let params = {};
  if(cityId)
    params.city=cityId;
  this.get('city', params)
}
```

But when you have 10/20 params or  500/1k http request you are happy if you avoid  this condition :-D


I didn't think about others backend  endpoint  so will think within my use case. Idea should only react with undefined params not with null params. For instance my endpoint in java if I expect to receive `@PathVariable Long cityId` I can receive null but not undefined.

## Environment
Angular 5.0.2

Browser tested:
- [x] Chrome console (version 21.11.2017)
Repository: rust
Issue: Rustdoc: replace Self with concrete types
Labels: T-rustdoc,C-feature-request

It's pretty common to write code like:

```rust
pub struct Foo {
    field: usize,
}

impl Foo {
    pub fn new() -> Self {
        Self { field: 0 }
    }
}

impl Default for Foo {
    fn default() -> Self {
        Self::new()
    }
}
```

Generated docs:

![](https://screenshots.firefoxusercontent.com/images/702054a3-6243-4055-87ef-28bf5bee98d8.png)

This is a simple example, but generally I find documentation much easier to browse when `Self` is replaced with concrete types (i.e. `Foo`). Because of that, I tend to write concrete types in public interfaces, but otherwise use `Self` everywhere else because it's so easy to type.

It'd be great if rustdoc could automatically replace all occurences of `Self` in the interface with concrete types.

cc @jeehoonkang
Repository: TypeScript
Issue: `+=` on `string | undefined` should narrow its operand to `string`
Labels: Bug

<!-- 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.6.1

**Code**

```ts
let a: string | undefined;
a = a + "a";
a; // string

let b: string | undefined;
b += "a";
b;  // should be string, but is still string | undefined
```

**Expected behavior:**
Both notations should be equivalend
Repository: pytorch
Issue: Memory leak when doing backward with grad as yourself
Labels: module: autograd,module: memory usage,triaged,quansight-nack

@zdevito  You said you wanted to make a python repro?

```
void backward(std::vector<Variable> outputs) {
   variable_list varlst;
   function_list funclst;
   for (auto v : outputs) {
     funclst.emplace_back(v.grad_fn(), v.output_nr());
     varlst.emplace_back(v);
   }
   detail::engine.execute(funclst, varlst, false);
}
```

This will leak a bunch of Tensors and in general be very sad for whatever Variables used.

cc @ezyang @gchanan @zou3519 @bdhirsh @heitorschueroff @albanD @gqchen @pearu @nikitaved
Repository: opencv
Issue: Absent documentation for sub-pixel coordinate system
Labels: category: imgproc,category: documentation,RFC

##### System information (version)
- OpenCV => all
- Operating System / Platform => all
- Compiler => all

##### Detailed description

There are a number of methods in OpenCV that accept or generate pixel coordinates as floating point numbers, `remap` is one of those methods I am using. I googled for a while trying to find out whether this method places centre of the top-left pixel at `0,0` or at `0.5,0.5`, some conflicting information came up:

http://answers.opencv.org/question/87923/sub-pixel-coordinate-origin/
http://answers.opencv.org/question/35111/origin-pixel-in-the-image-coordinate-system-in-opencv/

It seems that the correct answer is **`0,0` is the centre of the top left pixel**, judging by this commit:

https://github.com/opencv/opencv/commit/e646f9d2f1b276991a59edf01bc87dcdf28e2b8f

There should be a place somewhere in the documentation where the pixel coordinate system is properly defined, not just for the integer case. One paragraph stating what the coordinates of the centre and the four corners of the top left pixel are would suffice.
Repository: go
Issue: proposal: net/http: add Client.Put, Client.Patch
Labels: Proposal,Proposal-Hold

# PROPOSAL
I am proposing the addition of the following functions to the net/http package.

func Put()
func Patch()
func ()Put
func ()Patch

These functions would be similar to the Post functions that already exist.

## REASONS
 I believe all the reasons that the Post functions where added would also apply to these functions. Furthermore the fact the the Post functions already exist would make these functions a natural extension of an approach that has already been started but is currently incomplete.

## WORK TO BE DONE BY
sjtwiv
Repository: pytorch
Issue: Fuse bias to CuDNN convolution
Labels: triaged,enhancement

CuDNN provides a fused cudnnConvolutionBiasActivationForward, but we don't use it. We should.

NB: Please don't work on this until #3666 merges.
Repository: TypeScript
Issue: Possible to narrow type of object literal property with strictNullChecks?
Labels: Suggestion,Committed

**TypeScript Version:**  Current playground (2.6?)

**Code**

```ts
type Foo = {
  bar?: number[];
}

let f1: Foo = {};
f1.bar = [];
f1.bar.push(0);

let f2: Foo = { bar: [] };
f2.bar.push(0);
```

**Expected behavior:**

Both references to `.bar` compile successfully.

**Actual behavior:**

Second reference (`f2.bar.push(0)`) fails with "object is possibly undefined" -- the type of `f2.bar` is still treated as `number[] | undefined` even though it obviously can't be undefined.

----

This might not be an actual *bug* as such but whatever magic allows the compiler to narrow the type of `f1.bar` after assigning to it, should also be able to narrow the type when it was assigned in the literal.
Repository: TypeScript
Issue: Feature Request: add TypeChecker API to query if identifier is definitely assigned
Labels: Suggestion,In Discussion,API

Currently it's not possible to query CFA. I need to find out if an identifier is definitely assigned. This logic is part of `checkIdentifier` and is not accessible outside of that function.

My use case is the TSLint rule `no-unnecessary-type-assertion` where we need to identify false positives. The current implementation compares the type before and after the non-null-assertion. That doesn't work well for identifiers that are not definitely assigned, because the assertion suppresses TS2454 and can therefore not be removed.
Repository: electron
Issue: Can't set VisibleOnAllWorkspaces for window.open windows
Labels: enhancement :sparkles:,platform/macOS

Here is what I'm trying to achieve: 

```
var win = window.open(window.location.pathname + '#/my-subwindow', 'Lovely Title');
win.focus();

win.setVisibleOnAllWorkspaces(true);
```

But of course, the window that is returned from the window.open() is not a BrowserWindow but instead, it's a [BrowserWindowProxy](https://electronjs.org/docs/api/browser-window-proxy).

The documentation of [window.open](https://electronjs.org/docs/api/window-open#windowopenurl-framename-features) suggests that you can define features where: "each feature has to be a field of BrowserWindow's options." but `visibleOnAllWorkspaces` is not available as an option from what I understand from the documentation.

Even if I had a way to get a hold of the window *through* the BrowserWindowProxy and mess with it directly that would be great 😂
Repository: opencv
Issue: cv::cudacodec::createVideoReader segfault
Labels: feature,priority: low,category: gpu/cuda (contrib)

<!--
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 => Ubuntu 16.04
- Compiler => gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609

##### Detailed description

Description of this problem and it's solution could be found here: http://answers.opencv.org/question/178227/cvcudacodeccreatevideoreader-segfault

My opinion that one should include sources with symbols loading code into the OpenCV.
Also it will be great if OpenCV would disable linking libnvcuvid at compile time. As of now, it is hard to build OpenCV with CUDA stubs leaving LIBNVCUVID enabled(e.g. on systems without CUDA or in the Docker), because nvidia provides no stubs for libnvcuvid.
Repository: kubernetes
Issue: API validation code is hard to review
Labels: sig/api-machinery,kind/feature,lifecycle/frozen

I do a fair number of code reviews.  I try to pay attention to API validation.  It's gotten very hard to review.

* There are at least 2 util libraries, and the core API validation is effectively a 3rd.

* There are poor conventions across those libraries.

* Commonly used functions might be in any of the 3.

* They are all called "validation".

* Every API version has a "validation" pkg, too.

I'd like to chip away at this and establish better conventions, leading towards a more declarative validation process.  It's not urgent, but I need some code to work on :)

@kubernetes/sig-api-machinery-feature-requests
Repository: rust
Issue: ill-typed unused FFI declarations can cause UB
Labels: A-LLVM,A-codegen,A-FFI,P-medium,T-lang,T-compiler,I-unsound,C-bug

This compiles and prints "p is not null and 0x0":

```Rust
pub mod bad {
    #[allow(improper_ctypes)]
    extern {
        pub fn malloc(x: usize) -> &'static mut ();
    }
    
    #[no_mangle]
    pub fn bar() {
        let _m = malloc as unsafe extern "C" fn(usize) -> &'static mut ();
    }
}

pub mod good {
    extern {
        fn malloc(x: usize) -> *const u8;
    }
    
    pub fn foo() {
        unsafe {
            let p = malloc(0x13371337deadbeef); // your computer doesn't have enough memory
            if p.is_null() {
                panic!("p is null");
            } else {
                panic!("p is not null and {:?}", p);
            }
        }
    }
}

fn main() {
    bad::bar();
    good::foo();
}
```

The problem is that we have two declarations of the "malloc" symbol, but LLVM uses a global namespace for these. So during codegen, the 2nd declaration we generate overwrites the first. In this case, the "ill-typed" malloc declaration (`bad::malloc`) comes last, up putting a `nonnull` attribute on `malloc`, which causes `mod good` to be miscompiled.

Here's [another example](https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=ed2b1299a7d8dad50f7b4c911eefee44) that does not involve `malloc`. It does not get miscompiled currently, but it demonstrates the issue.

See [here](https://github.com/rust-lang/rust/issues/46188#issuecomment-2348194976) for a document that summarizes why this happens, and what our options are.
Repository: go
Issue: cmd/vet: know what builtin functions have no side effects
Labels: help wanted,NeedsFix,Analysis

Reminder issue to continue the work in https://go-review.googlesource.com/c/go/+/79536.

For example, `len` and `cap` never have any side effects, and it would be useful to know that `i == len(x) || i == len(x)` is a suspicious expression.

More broadly, this could be extended to automatically detect what functions are free of side effects. But this would require having access to the full source with full type information, and may be complex and costly, so I'm not entirely sure it's a right fit for vet.

A simpler version of the above would be to also add standard library functions, such as `strings.Contains` or `path.Join`. I don't know if it is OK for vet to treat standard library packages differently, though.
Repository: puppeteer
Issue: Properly handle target crashes
Labels: feature,chromium

Crashed targets should be handled gracefully:
1. All pending commands should be rejected. This includes protocol messages and watchdogs, such as NavigatorWatcher / WaitTask
2. All subsequent commands to the crashed target should reject right away

Neither (1) or (2) happen with Puppeteer v0.13.0.
Repository: godot
Issue: Double-clicking on a .gdns or .gdnlib opens the script editor
Labels: bug,topic:editor,confirmed,topic:gdextension

Godot 3.0 master 
Windows 10 64 bits

I noticed that double-clicking on .gdn or .gdnlib resources in the file browser is not only opening them in the inspector, but also opens an empty script editor and adds them to the open list as if they were scripts.
I guess this is not intented, as these don't contain source code.
Repository: bitcoin
Issue: Multiwallet rescan sequentially scans multiple wallets instead of in parallel
Labels: Wallet

If you start up with a collection of N out of sync wallets bitcoin will perform N interdependent rescans; this can be rather slow e.g. if they're all at height 200k.

This should be fixed, or we should offer suicide counseling at a minimum.
Repository: flutter
Issue: iOS mid-fling scroll simulation inaccurate
Labels: platform-ios,framework,a: fidelity,f: scrolling,f: cupertino,customer: crowd,has reproducible steps,P2,found in release: 3.6,team-ios,triaged-ios

The scroll motions during the ~50ms in the middle of a fast fling motion on iOS is not accurate. 

In the middle of the fling itself (and generally), the scrollable's position offset follows the finger exactly whereas on iOS, when the finger moves too fast, the scrollable has an inertia and follows the finger with a spring motion the entire time instead of just at the end when it goes ballistic. 

https://streamable.com/ki7an
Repository: opencv
Issue: Error in resize method when using nearest neighbour interpolation
Labels: category: imgproc,RFC

##### System information (version)
- OpenCV => master
- Operating System / Platform => all
- Compiler => all

##### Detailed description

When resizing image with nearest neighbour source image pixel coordinates are computed incorrectly. For example shrink a 5x5 image down to 1x1, you should get center pixel value in the result, instead top-left pixel value is present in the result.

Incorrect code is here:

https://github.com/opencv/opencv/blob/981009ac1f06106244ac52b16a20a4dc337ad816/modules/imgproc/src/resize.cpp#L235
Should be instead:
```.cpp
   int sx = cvFloor(x*ifx + (ifx-1)*0.5);
```
and here:

https://github.com/opencv/opencv/blob/981009ac1f06106244ac52b16a20a4dc337ad816/modules/imgproc/src/resize.cpp#L144
Should be instead:
```.cpp
   int sy = std::min(cvFloor(y*ify + (ify-1)*0.5), ssize.height-1);
```

There are probably more optimized versions (maybe AVX version) that are also using wrong math, I didn't look for them.

I have a more detailed explanation with equations in here:

https://gist.github.com/Kirill888/6b187e65f088971a48d078df72d27d32

I'm aware of this issue #9096, it's the same problem, but I thought I'll create new issue anyway to discuss the solution for it.
Repository: flutter
Issue: Text editing handles go over, not under, appbars
Labels: a: text input,framework,f: material design,a: fidelity,a: quality,has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-text-input,triaged-text-input

Cursor is not respecting the app z-index (it should be under the AppBar)

## Steps to Reproduce

As you can see in the image bellow, the cursor is not Hidden by the AppBar.

![z-index](https://user-images.githubusercontent.com/1667961/33181696-573f334c-d058-11e7-8195-6f9628c4706f.png)

## Flutter Doctor
```
[✓] Flutter (on Linux, locale pt_BR.UTF-8, channel master)
    • Flutter at /home/bispo/workspace/flutter
    • Framework revision 167382480a (7 horas atrás), 2017-11-23 10:24:16 +0100
    • Engine revision 93b2179597
    • Tools Dart version 1.25.0-dev.11.0

[✓] Android toolchain - develop for Android devices (Android SDK 26.0.3)
    • Android SDK at /home/bispo/Android/Sdk
    • Android NDK at /home/bispo/Android/Sdk/ndk-bundle
    • Compiler in Android NDK at /home/bispo/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
    • Platform android-26, build-tools 26.0.3
    • Java binary at: /usr/local/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_112-release-b06)

[✓] Android Studio (version 2.3)
    • Android Studio at /usr/local/android-studio
    • Java version OpenJDK Runtime Environment (build 1.8.0_112-release-b06)

[✓] IntelliJ IDEA Community Edition (version 2017.2)
    • Flutter plugin version 19.1
    • Dart plugin version 172.4343.25

[✓] Connected devices
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 7.1.1 (API 25) (emulator)
```
Repository: godot
Issue: The Remote Scene Tree causes jerky movement everytime it updates
Labels: enhancement,topic:editor,confirmed,performance

**Operating system or device, Godot version, GPU Model and driver (if graphics related):**
Godot 3.0 master https://github.com/godotengine/godot/commit/3a33725014169ce51d6ac581a4dce3b97a60da00

**Issue description:**
<!-- What happened, and what was expected. -->
In the example, Every time the Remote Scene Tree updates it causes some choppy movement. If I disable the auto switching to it under Editor settings / Debugger the issue disappear.

**Steps to reproduce:**
1. Open the example and make sure the remote scene tree is opened.

**Link to minimal example project:**
<!-- Optional but very welcome. You can drag and drop a zip archive to upload it. -->
[level_test.zip](https://github.com/godotengine/godot/files/1500106/level_test.zip)