sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: kubernetes
Issue: Add local PV e2e block test for GCE local SSD
Labels: sig/storage,kind/feature,lifecycle/frozen

<!-- This form is for bug reports and feature requests ONLY! 

If you're looking for help check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) and the [troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/).
-->

**Is this a BUG REPORT or FEATURE REQUEST?**:
/kind feature
/sig storage
/assign

**What happened**:
Once #60137 merges, add local SSD block as another type
Repository: rust
Issue: Misleading diagnostics for method call
Labels: C-enhancement,A-diagnostics,T-compiler

The following (reduced example) code leads to a misleading error message:

```rust
trait IsARectangle<T> {}

struct GeneralRectangle<T>
{
    x: T
}

impl<T> IsARectangle<T> for GeneralRectangle<T> {}

impl<U> GeneralRectangle<U> where U: std::ops::Add<Output = U>
{
    fn from<T, R>(_: &R) -> Result<GeneralRectangle<U>, ()>
    where
        R: IsARectangle<T>,
    {
        unimplemented!()
    }
}

fn box_to_pixel<T, S>( (_, _): (S, S)) -> Result<GeneralRectangle<T>, ()>
// if you enable the following line, it will work:
//where T: std::ops::Add<Output = T>
    {
        GeneralRectangle::<T>::from::<u32, GeneralRectangle<u32>>(&GeneralRectangle::<u32> {
            x: 0,
        })
    }


fn main() {
   box_to_pixel::<u32, u32>( (0, 0) );
}
```
The problem is that the `where`-clause for `box_to_pixel` is missing (it works if it is added), but the compiler instead reports:

```
error[E0087]: too many type parameters provided: expected at most 0 type parameters, found 2 type parameters
  --> src\main.rs:22:39
   |
22 |         GeneralRectangle::<T>::from::<u32, GeneralRectangle<u32>>(&GeneralRectangle::<u32> {
   |                                       ^^^ expected 0 type parameters

error[E0277]: the trait bound `std::result::Result<GeneralRectangle<T>, ()>: std::convert::From<&GeneralRectangle<u32>>` is not satisfied
  --> src\main.rs:22:9
   |
22 |         GeneralRectangle::<T>::from::<u32, GeneralRectangle<u32>>(&GeneralRectangle::<u32> {
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::convert::From<&GeneralRectangle<u32>>` is not implemented for `std::result::Result<GeneralRectangle<T>, ()>`
   |
   = note: required by `std::convert::From::from`
```

As a Rust beginner, who might have not yet heard about `std::convert::From::from`, I would now be really confused, because the `from` method exists (in my code!), and it does expect 2 type parameters, not 0.

The error message is better if the `where U: std::ops::Add<Output = U>` is moved from the `impl` block to the `fn from`, so I do understand what the compiler does here (it probably totally disregards the whole `impl` block because its `where` clause is not satisfied), but maybe the situation can be improved anyway?
Repository: opencv
Issue: fisheye::estimateNewCameraMatrixForUndistrortRectify computes unfeasible new cam matrix
Labels: category: calib3d



##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => :  3.4
- Operating System / Platform =>  Linux Mint 18.1
- Compiler => gcc 5.4

##### Detailed description
fisheye::estimateNewCameraMatrixForUndistortRectify() estimates a unfeasible new camera matrix.

newCamMat = 
 [16.56655127068949, 0, 804.0577455220744;
 0, 16.56435955242479, 795.9641361656702;
 0, 0, 1]

with old cameraMatrix K=
 [479.8212553715528, 0, 804.0575648361054;
 0, 479.757776075711, 795.958873881724;
 0, 0, 1]

##### Steps to reproduce
Calling fisheye::estimateNewCameraMatrixForUndistortRectify() with:  
Mat newCamMat, map1, map2;
K = 
 [479.8212553715528, 0, 804.0575648361054;
 0, 479.757776075711, 795.958873881724;
 0, 0, 1]
imageSize = (1668,1668)
distCoeffs =  [0.01280820642470711;
 0.002218423317829948;
 -0.002689326073929679;
 0.0002362784535736659]

such that the call is 
fisheye::estimateNewCameraMatrixForUndistrortRectify(K, distCoeffs, imageSize, Matx33d::eye(), newCamMat, 1.0)

<!-- 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: flutter
Issue: Support specifying transitions in Navigator.xNamed calls
Labels: c: new feature,framework,customer: mulligan (g3),f: routes,P2,team-framework,triaged-framework

Internal: b/292548374

Mulligan uses named routes for all navigation. The `Navigator.pushNamed` method does not support specifying a transition. Instead, it is my understanding that the transition must be declared when we construct the `MaterialPageRoute`. 

From my previous discussions with our UX designer, transitions to a given route could vary based on the user action that triggers the navigator push. For example, the transition to route C could be different coming from route A than from route B. This means that in order to support different transitions with the current design, we would have to pass metadata in the named route (e.g., via query parameters) in order to decide what transition to use when constructing the `MaterialPageRoute`.

While this is certainly possible, it seems cumbersome for what I believe would be a common use case.
Repository: TypeScript
Issue: Add support for an `@export` tag
Labels: Suggestion,In Discussion,Domain: JSDoc,Domain: JavaScript

```ts
/** 
 * @export
 * @typedef {{a: number}}  X 
*/

export {};
```
Repository: go
Issue: spec: document special cases for floating-point maps
Labels: Documentation,NeedsFix

In https://github.com/golang/go/issues/20660#issuecomment-367781440, I noted that there are undocumented special cases in the handling of maps with floating-point keys.

Regardless of what happens with that proposal for Go 2, we should fix the Go 1 spec to properly document those cases.

----

In [Map types](https://golang.org/ref/spec#Map_types), add:

Elements may be added during execution using assignments and retrieved with index expressions **and range clauses**; they may be removed with the `delete` built-in function.

----

In [Index expressions](https://golang.org/ref/spec#Index_expressions), add:

For a of map type `M`:

* `x`'s type must be assignable to the key type of `M`
* if the map contains an entry with key **equal to** `x`, `a[x]` is the map element with key `x` and the type of `a[x]` is the element type of `M`
* if the map is `nil` or does not contain such an entry **and the index expression is not a left-hand side operand of an assignment**, `a[x]` is the zero value for the element type of `M`

----

In [Assignments](https://golang.org/ref/spec#Assignments), add:

The assignment proceeds in two phases. First, the operands of index expressions and pointer indirections (including implicit pointer indirections in selectors) on the left and the expressions on the right are all evaluated in the usual order. Second, the assignments are carried out in left-to-right order.

**If the left operand of an assignment is an index expression on a map that does not contain a key equal to the given key, the assignment creates a new entry in the map. If the map is `nil`, a run-time panic occurs.**

----

In [For statements with `range` clause](https://golang.org/ref/spec#For_range), add:
```
Range expression                          1st value          2nd value

[…]
map             m  map[K]V                key      k  K      see below  V
[…]
```

[…]

3. **For a map value, the "range" clause iterates over successive entries of the map.
   On successive iterations, the index value will be the key, and the second value will be the element associated with that key. If the key is or contains a NaN value, it may be associated with multiple entries; the elements of those entries can only be retrieved using "range" clauses (not index expressions).**
  
   The iteration order over maps is not specified and is not guaranteed to be the same from one iteration to the next. If a map entry that has not yet been reached is removed during iteration, the corresponding iteration value will not be produced. If a map entry is created during iteration, that entry may be produced during the iteration or may be skipped. The choice may vary for each entry created and from one iteration to the next. If the map is nil, the number of iterations is 0.

----

In [Deletion of map elements](https://golang.org/ref/spec#Deletion_of_map_elements), add:

The built-in function delete removes the element with key **equal to** `k` from a map `m`.
Repository: neovim
Issue: rpcnotify: no Vim error with "no notification handler registered for"
Labels: documentation,provider,channels-rpc,remote-plugin

When using deoplete and using `:call rpcnotify(g:deoplete#_channel_id, 'foo')` you will get an error displayed ("no notification handler registered for "foo""), which is not a real Neovim error: it cannot be caught using `:try` and has no error number etc.

I could not find the source for it in Neovim's sources, so it might come from some library being used for this.

It would also be nice to get the list of registered handlers, and a list of current channels, so that you could better inspect them and e.g. check if a particular one is (still) valid.
Repository: rust
Issue: 🛠️ specialization permits empty impls when parent has no default items
Labels: C-enhancement,A-trait-system,T-compiler,A-specialization,requires-nightly,F-specialization,T-types,S-types-deferred

It is potentially somewhat surprising that [the following impls are accepted](https://play.rust-lang.org/?gist=a99b1b66262b0f2a529473617a3e5062&version=nightly):

```rust
#![feature(specialization)]

trait Foo {
    fn bar();
}

impl<T> Foo for T {
    fn bar() { } // no default
}

impl Foo for i32 {
    // OK so long as we define no items:
    // fn bar() { }
}


fn main() {}
```

The [original example](https://play.rust-lang.org/?gist=74df7c5648b164ce857b8db20fe49ed3&version=nightly) was unearthed by @eddyb and @varkor as part of a PR.

To be clear, I don't see this as a *soundness* problem per se. Just a question of what we think it *ought* to do.

cc @aturon
Repository: angular
Issue: Same route with animation and param
Labels: type: bug/fix,area: animations,freq2: medium,P4

Hello,

I used this child routing system with a transition animation. The problem is that if I want to go from one stage to another I do not have the animation.

<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
When I call the index/state route the animation goes well the first time but not the next.

## Expected behavior
The animation is restarted (enter & leave) and the data are updated on the template
Here is the example of the problem in plunker:

https://plnkr.co/edit/hCc1l3AOYecIWk8Vg63n

I thought about this technique except that when we come back we hit a 404, I guess there is better to go back to the old state :

    this.router.navigate(['index']);
    setTimeout(() => {
       this.router.navigate(['index/state/', id]);
    }, 1);

How to force the animation to leave and restart the opening of the component?

Thank you

## Environment

<pre><code>
Angular version: 5.1
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- [x] Chrome (desktop) version 64.0.3282.167
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: 8.9.4
- Platform:  Mac

</code></pre>
Repository: go
Issue: cmd/go: give a better error message when building Go package with CGO_ENABLED=0
Labels: NeedsFix

When trying to cross compile the go compiler silently ignores any files that use `import "C"` statement.
In this example I've tried to compile for windows on a linux host machine, but this issue seems to be present on other host platforms as well.
It seems to do this because it disables `CGO_ENABLED` being disabled by default when the host and target platform mismatch despite the required toolchains being present (mingw-w64 in my case).

I managed to resolve this issue by enabling `CGO_ENABLED` and setting `CC` and `CXX`, but this issue is more about the unclear error message.

### What version of Go are you using (`go version`)?
`go version go1.10 linux/amd64`

### Does this issue reproduce with the latest release?
Yes.

### What operating system and processor architecture are you using (`go env`)?
Without GOOS:
```
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ikkerens/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/usr/lib/go:/var/git/Go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
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"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build897508503=/tmp/go-build -gno-record-gcc-switches"
```
With GOOS=windows
```
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ikkerens/.cache/go-build"
GOEXE=".exe"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="windows"
GOPATH="/usr/lib/go:/var/git/Go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="0"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build822882573=/tmp/go-build -gno-record-gcc-switches"
```

### What did you do?
2 Go files:
```go
// cgo.go
package main

import "C"

func test() {
}
```
```go
// main.go
package main

func main() {
        test()
}
```

### What did you expect to see?
Some kind of warning that cgo.go is being skipped in compilation due to `CGO_ENABLED` being `0`.

### What did you see instead?
```
# test
./main.go:4:2: undefined: test
```
Repository: godot
Issue: Circular script preloading causes leak without warning (both with preload or named classes)
Labels: bug,discussion,topic:gdscript,confirmed

Godot 2.1.5 beta, Godot 2.1.4, Windows 10 64 bits

I found out my project had a circular dependency between two scripts which were preloading each other into a `const` (though the game has worked perfectly fine so far, it's been a year).
The use case was only to use `extends` on it. Workaround is to use `load`...

The result of this is a *random* memory leak (which doesn't always happen) and two cryptic errors:
```
ERROR: SelfList<class GDFunction>::List::~List: Condition ' _first != 0 ' is true.
   At: core\self_list.h:80
ERROR: SelfList<class GDScript>::List::~List: Condition ' _first != 0 ' is true.
   At: core\self_list.h:80
WARNING: ObjectDB::cleanup: ObjectDB Instances still exist!
     At: core\object.cpp:1845
ERROR: ResourceCache::clear: Resources Still in use at Exit!
   At: core\resource.cpp:378
```

Reproduction project;
[CircularScriptPreload.zip](https://github.com/godotengine/godot/files/1753083/CircularScriptPreload.zip)
Repository: go
Issue: archive/zip: FileInfoHeader does not handle directories
Labels: NeedsInvestigation,early-in-cycle

Consider the following:
```go
fi, _ := os.Stat("/home/")
h, _ := zip.FileInfoHeader(fi)
fmt.Println(h.Name)
```

This currently prints:
```
home
```

However, ZIP treats directories as files with a trailing "/" in the name, which `FileInfoHeader` should automatically append if `os.FileInfo.IsDir` reports true.

This difference is minor since users are usually expected to replace the `FileHeader.Name` shortly afterwards anyways.
Repository: pytorch
Issue: Handle python_arg_parser dtype constants better
Labels: todo,feature,triaged

The default is a dtype name, but we find the default via the Type; we should use dtypes because this won't work if the Types aren't compiled.
Repository: pytorch
Issue: Perf regression: indexing 1-d tensor
Labels: module: performance,in progress,triaged

After the Tensor/Variable merge we have a perf regression with indexing a 1-d tensor:

As of 6a2afe3

```python
>>> import torch
>>> x = torch.randn(1000)
>>> %timeit x[0]
435 ns ± 3.34 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
>>> %timeit x[0] = 1
449 ns ± 1.41 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)
```

As of Tensor/Variable merge:

```python
>>> import torch
>>> x = torch.randn(1000)
>>> %timeit x[0]
1000000 loops, best of 3: 1.05 µs per loop
>>> %timeit x[0] = 1
100000 loops, best of 3: 4.02 µs per loop
```

Note that indexing a Python list is even faster:

```python
>>> x = [0] * 1000
>>> %timeit x[0]
10000000 loops, best of 3: 36.3 ns per loop
>>> %timeit x[0] = 1
10000000 loops, best of 3: 37.7 ns per loop
```

This affects things like:
https://github.com/pytorch/examples/blob/4ef2d4d0c8524372d0047e050065edcac665ce1a/word_language_model/data.py#L39-L46
Repository: rust
Issue: #[must_use] on associated function definition when trait declaration does not have it should still trigger warning when calling function concretely
Labels: C-enhancement,A-diagnostics,T-compiler

I expect the following code ([Playpen](https://play.rust-lang.org/?gist=4212fdd85fabb3b79d20186f0a7f0acb&version=nightly)) to emit a warning on the last line of `main` that the result of `s.the_must_use_fn()` must be used.

```rust
fn main () {
    let s = Struct;
    s.the_must_use_fn();
}

trait Trait {
    fn the_must_use_fn(&self) -> String;
}

struct Struct;

impl Trait for Struct {
    #[must_use]
    fn the_must_use_fn(&self) -> String { "".to_string() }
}
```

Ref #43302 as the tracking issue for this feature.
Repository: kubernetes
Issue: Figure out a way to manage the discrepancy on windows nodes from the linux node
Labels: kind/cleanup,sig/node,sig/windows,help wanted,lifecycle/frozen,good first issue,needs-triage

https://github.com/kubernetes/kubernetes/pull/60275/files/2d942dab68b64e684dd2b75232cf9daabc6e0a95#diff-10055ae93a8699af13ceba0482fc43c3

I am expecting we have more windows specific config like code coming to Kubelet and other node components. We should figure out a way to handle this, so that the code can be easily managed? Instead of letting windows-special handling code like this scattered everywhere in our codebase. 

cc/ @feiskyer @michmike  @kubernetes/sig-windows-bugs
Repository: rust
Issue: Operators in patterns have incorrect priorities
Labels: C-enhancement,A-grammar,A-parser,T-lang,T-compiler,F-half_open_range_patterns,F-exclusive_range_pattern,A-patterns

(Or at least unnatural priorities.)

Binary range operators have higher priority than unary operators like `&` or `box`.

```rust
#![feature(exclusive_range_pattern)]

fn main() {
    // Interpreted as (&0) .. (10), ERROR mismatched types
    let x = &0 .. 10;

    match &0 {
        &0 .. 10 => {} // OK?!
        _ => {}
    }
}
```

We can change the priorities for all the unstable kinds of ranges and come up with some deprecation story for stable `BEGIN ... END`.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: vscode
Issue: Licensing for packaging
Labels: linux,under-discussion,license

Sorry if this is the wrong place, StackOverflow would tag this as irrelevant if I posted there.

I'm currently building a package template for Void Linux for VSCode, and I'm wondering what licensing concerns I should consider. I plan on using the prebuilt VSCode binaries available in tarballs from Microsoft.

Thanks
Repository: opencv
Issue: Expose Domain_Filter functionality
Labels: feature,category: photo

`photo` module has a `Domain Transform` filter implementation that can not be accessed from outside. It implemented in `npr.hpp` and it is only used by several exposed functions. It can be very useful by direct access/customization from the OpenCV user.
Repository: rust
Issue: Evaluation overflow with specialization feature
Labels: C-enhancement,A-diagnostics,T-compiler,A-specialization,F-specialization

The current nightly compiler gives the error "overflow evaluating requirement" when a type is used as a trait with a default impl. For example:

```rust
#![feature(specialization)]

fn main() {
    println!("{}", <(usize) as TypeString>::type_string());
}

trait TypeString {
    fn type_string() -> &'static str;
}

default impl<T> TypeString for T {
    fn type_string() -> &'static str {
        "unknown type"
    }
}

impl TypeString for () {
    fn type_string() -> &'static str {
        "()"
    }
}
```
([playground link](https://play.rust-lang.org/?gist=1c378d92ac201f1ed0051b3a27cb4b94&version=nightly))

...gives the following error:

```text
error[E0275]: overflow evaluating the requirement `usize: TypeString`
 --> src/main.rs:4:20
  |
4 |     println!("{}", <(usize) as TypeString>::type_string());
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: required by `TypeString::type_string`
 --> src/main.rs:8:5
  |
8 |     fn type_string() -> &'static str;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

Note that if we change `<(usize) as TypeString>::type_string()` to `<() as TypeString>::type_string()` - `()` has a specialized impl - it compiles and runs correctly.
Repository: angular
Issue: Support custom TypeScript transformers
Labels: feature,area: compiler,feature: under consideration

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION.
-->

## 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)
[ ] 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. -->
Now angular-cli does not support custom TypeScript transformers.

## Expected behavior
<!-- Describe what the desired behavior would be. -->
Provide custom transformers as it does Webpack [ts-loader](https://github.com/TypeStrong/ts-loader#getcustomtransformers-----before-transformerfactory-after-transformerfactory---) and [awesome-typescript-loader](https://github.com/s-panferov/awesome-typescript-loader/blob/master/src/checker/runtime.ts#L324).
Repository: rust
Issue: clarify effects of lto, thinlto and codegen-units
Labels: E-hard,C-enhancement,P-medium,T-compiler,A-docs

There seems to be a lot of confusion about performance implications of lto, thinlto, codegen-units and default optimizations of build targets, maybe we can clarify this somehow.

Where would be the best place for this?