sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Implement `propagate_panic` on `LockResult`
Labels: T-libs-api,C-feature-request

`LockResult<Guard>` is an alias of `Result<T, E>` used when locking a `Mutex<T>`, `RwLock<T>`, or other synchronization primitive. It exists to take into account the fact that a panicked thread may poison the lock, thereby corrupting the state of whatever is contained within the lock.

When developing in Rust, it is common to search a codebase for instances of `.unwrap()` to find places in which the code may panic. However, instances of `.unwrap()` are extremely common in multithreaded code where locks are frequently used.

Since calling `.unwrap()` upon a `LockResult<Guard>` **only** triggers a panic if a panic has already occurred in the thread holding the lock, it cannot be the 'original' source of a panic, and therefore is perfectly fine to call in a codebase in which no other instances of `.unwrap()` exist.

I suggest implementing a `.propagate_panic()` method on `LockResult<Guard>` that has identical functionality to `.unwrap()`, but prevents additional noise when searching a codebase for real sources of panics.
Repository: node
Issue: Creating a branch of the Docs using RunKit
Labels: doc,meta

As a part of the @nodejs/website-redesign work, we've gone through some work to analyze a way to improve some of the interactivity of the documentation on the website once we re-launch with the work the Website Redesign team is working on.

Early on, RunKit approached us with an interest to help improve the docs and make them more interactive while degrading gracefully.

My personal biggest concern was offline mode and not blocking the Docs for those who have JavaScript disabled – both of which are entirely addressed by the demos that the RunKit team has provided.

They've also been going to great lengths to ensure that some of the edge cases we have are addressed entirely within the platform.

@tolmasky from the RunKit team has requested that we begin to spin up an initial setup of RunKit enabled docs to help load-test the RunKit servers. This is purely to help see if they're going to need to set up a dedicated server for Node.js or if their existing infra will suffice.

I offered to be a bridge to Core to begin to help process this request – not sure what the barriers on the Docs side will be, but happy to help connect the dots and do what we need to to make this work 👍 

Also wanted to mention that the RunKit team has been incredibly willing to help out and bend over backward to enable the Website Redesign team to succeed in revamping the Node.js website and improving the UX for developers. Huge thank you to them for all the work they're doing 🙌
Repository: godot
Issue: Color transformation issue when rendering to viewports
Labels: bug,topic:rendering

Godot 3.0.2 + Windows 10

When rendering a solid color image to a viewport, the final image will produce a different color to the same image being rendered outside of the viewport.
<br>
Consider this node structure:
```
root
--imageA
--viewportTexture
--viewport
----imageB
```
`imageA` and `imageB` are solid color `#090800` quads, both rendered sampling the color from a texture in the shader, using the engine default `force_srgb` option code:
```
mix(pow((color + vec3(0.055)) * (1.0 / (1.0 + 0.055)),vec3(2.4)),color * (1.0 / 12.92),lessThan(color,vec3(0.04045)));
```
`imageA` renders to screen as the original `#090800`, whereas imageB renders as `#0d0d00`, making them slightly off, and thus non-indentical, even though they should be.
<br>
I guess this implies that the transformation code is not accurate and when applied twice (when rendering to viewport + rendering to screen) distorts the source color. This happens both with a custom shader and a default spatialMaterial with the force srgb setting.

If not fixes, quick hacks to fix this appreciated.
____________________________________
Edit: The issue appears to be reading the viewport texture color, which produces the incorrect value.
Edit2: Tried using the `keep_3d_linear` flag mentioned in #19375, available in the 3.1 nightlies, but the result remains unchanged, the read, and in turn rendered, color remains the wrong one.
Repository: go
Issue: os: Remove/RemoveAll should remove read-only folders on Windows
Labels: OS-Windows,NeedsInvestigation

### What version of Go are you using (`go version`)?
`go version go1.10.2 windows/amd64`
### Does this issue reproduce with the latest release?
Untested, but I don't see any changes that would have fixed it
### What operating system and processor architecture are you using (`go env`)?
`windows/amd64`
### What did you do?
```go
package main

import (
	"os"
)

func main() {
	err := os.RemoveAll("./folder_with_icon")
	if err != nil {
		panic(err)
	}
}
```
`folder_with_icon` is an empty folder that has had a custom icon added via Windows Explorer's interface (`Properties` => `Customize` => `Change Icon...`).
### What did you expect to see?
`folder_with_icon` should be deleted.
### What did you see instead?
```
panic: remove ./folder_with_icon: Access is denied.

goroutine 1 [running]:
main.main()
        C:/[path]/test.go:10 +0x6a
```
### Notes
This is similar to #9606.

Setting a custom folder icon on Windows sets the `read-only` attribute on the folder and creates a `desktop.ini` file with the `system` attribute inside the folder. Despite being read-only, the folder can be deleted both through File Explorer and by `rd /s folder_with_icon` by its owner, even if the owner is not an administrator account. The above Go program will not delete the folder, even if it is run with administrator privileges.

`os.RemoveAll()` removes the `desktop.ini` but does not delete the folder.
Repository: pytorch
Issue: [gradcheck] warn about the case that mulitple inputs share storage
Labels: module: autograd,triaged

also re-enable the skipped einsum tests



cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved
Repository: TypeScript
Issue: --noImplicitThis error is inconsistent
Labels: Bug

**TypeScript Version:**  3.0.0-dev.20180707

**Code**

```ts
declare function f(a: any): void;
f(function() {
	this.m();
});

f({
	callback: function() {
		this.m();
	}
});
```

**Expected behavior:**

With `--noImplicitThis`, errors in both cases or neither case.

**Actual behavior:**

Only error in the first case.
Repository: go
Issue: cmd/go: list: incomplete error message "no Go files in"
Labels: NeedsFix,GoCommand

```
$ cat a.go
package p

import "missing"

$ command go version
go version devel +4da84adc0c Mon Jul 9 19:35:21 2018 +0000 linux/amd64
$ command go list -export -e  a.go
go build missing: no Go files in 
command-line-arguments
```


I expect the fix is something like this:

```
--- a/src/cmd/go/internal/load/pkg.go
+++ b/src/cmd/go/internal/load/pkg.go
@@ -185,6 +185,9 @@ func (e *NoGoError) Error() string {
                // to appear at the end of error message.
                return "no non-test Go files in " + e.Package.Dir
        }
+       if e.Package.Dir == "" {
+               return "no directory for package " + e.Package.ImportPath
+       }
        return "no Go files in " + e.Package.Dir
 }
```
Repository: kubernetes
Issue: NamespaceSpec and ObjectMeta both contain a "finalizers" field
Labels: kind/documentation,sig/api-machinery,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/).

If the matter is security related, please disclose it privately via https://kubernetes.io/security/.
-->

**Is this a BUG REPORT or FEATURE REQUEST?**:

> Uncomment only one, leave it on its own line:
>
/kind bug
> /kind feature


**What happened**:

`Namespace` has two finalizers fields: `Namespace.ObjectMeta.finalizers` and `Namespace.Spec.finalizers`. `NamespacedResourcesDeleter` uses `NamespaceSpec.finalizers` and `ObjectMeta.finalizers` appears to be unused/ineffective (please correct me if I'm wrong).

**What you expected to happen**:

`NamespacedResourcesDeleter` should use `ObjectMeta.finalizers`, or if there is a technical reason for not doing so, it should be documented how and why the fields are different. Also, if the `ObjectMeta.finalizers` field is completely unused for namespaces (can't quite tell if it is), maybe the API should fail namespace creation requests that set it.

TL;DR: I mistakenly put a finalizer in the namespace metadata, instead of the namespace spec. That should either be supported, obviously wrong via documentation/naming, or not be a valid request.
Repository: pytorch
Issue: Accumulate into accreal instead of real for CPU loss functions
Labels: module: nn,module: loss,triaged

All the loss fns except for MSELoss (that I am patching right now) accumulate into real instead of accreal on CPU

cc @albanD @mruberry @jbschlosser @ezyang @zou3519 @gqchen @pearu @nikitaved @soulitzer
Repository: go
Issue: cmd/compile: teach prove about more type conversion operations
Labels: Performance,NeedsInvestigation,compiler/runtime

#26292 is about teaching the prove pass that, if `x byte` is <N, `int(x)` is also <N. In particular, it helps when using byte variables as indices, since that seems to mean an implicit conversion to int. That was causing an unnecessary bounds check in an `encoding/json` hot path.

Here are some other cases which might be worthwhile to do. I don't know how useful they would be for software out there, like removing bounds checks in the standard library.

* If `x uint32` is `<10`, `uint(x) < 10` (and same for `int32/int`)
* If `x uint64` is `<10` and we're on 64-bit, `uint(x) < 10`
* If `x uint` is `<10`, `byte(x) < 10`
* If `x int` is non-negative and `<10`, `uint(x) < 10`

/cc @aclements @rasky
Repository: go
Issue: x/net/http2: verify that net/http.Server.SetKeepAlivesEnabled(false) shuts down HTTP/2 server
Labels: help wanted,NeedsFix

Per https://github.com/golang/go/issues/20239#issuecomment-402199944 and its immediate reply, it seems that https://go-review.googlesource.com/c/net/+/43230 might've broken `net/http.Server.SetKeepAlivesEnabled(false)` shutting down HTTP/2 server connections.

I guess there's no test for it.

/cc @tombergan @pam4
Repository: rust
Issue: Consider using pair mode to return scalar pair bools as i1
Labels: A-codegen,T-compiler,A-cranelift

Starting in #51583, we're representing scalar pair `bool`s as `i8` in LLVM aggregates to match their memory storage, whereas they are `i1` as immediate values.

When a pair is the argument to a function, we use `PassMode::Pair` and pass each part like independent immediate values.  We don't use that mode for return values though, so a paired `bool` will be extended to `i8` for return, then truncated back to `i1` when the caller unpacks it.

Quoting @eddyb in https://github.com/rust-lang/rust/pull/51583#discussion_r195895958:

> I wonder if they should be using the pair "passing mode" that arguments do, and create a LLVM aggregate type on the fly, using the immediate types for the pair components. That way we'd get `{i1, i1}` for returns, but everything else would see `{i8, i8}`.
> 
> Not sure it's worth the complexity though. When inlining, LLVM should collapse the zext followed by trunc, just like it gets rid of packing into a pair and unpacking it.
Repository: rust
Issue: `trivial_casts` warning misfires when casting from reference -> pointer -> void pointer
Labels: A-lints,C-bug

When casting from a reference to a pointer to a void pointer (necessary sometimes when doing C FFI), the `trivial_casts` warning fires, despite this being an necessary cast.

```rust
#![warn(trivial_casts)]

extern crate libc;

fn main() {
    let x : libc::c_int = 4;
    let y : *const libc::c_void = &x
        as *const libc::c_int
        as *const libc::c_void;
}
```

This produces the warning:

> ```
> warning: trivial cast: `&i32` as `*const i32`. Cast can be replaced by coercion, this might require type ascription or a temporary variable
> ```

You can work around this by using coercion to assign the intermediate type to a variable, but this shouldn't be necessary.
Repository: react-native
Issue: Image Orientation on Android
Labels: Platform: Android

## Environment
  React Native Environment Info:
    System:
      OS: macOS High Sierra 10.13.5
      CPU: x64 Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
      Memory: 23.63 MB / 16.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 10.6.0 - /usr/local/bin/node
      npm: 6.1.0 - /usr/local/bin/npm
    SDKs:
      iOS SDK:
        Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3
    IDEs:
      Android Studio: 2.3 AI-162.3871768
      Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.4.1 => 16.4.1
      react-native: 0.56.0 => 0.56.0
    npmGlobalPackages:
      react-native-cli: 2.0.1
      react-native-git-upgrade: 0.2.7

## Description
There is an issue with how images are being rotated, specifically portrait images on Android. Portrait images are somewhat ambiguously rotated when they render. I found similar issues in the past explaining this problem that were fixed, but I am still experiencing it in 0.56. 

The Exif "orientation" value is seemingly not always respected. In screenshot below, both of these photos have orientation of "6", which from my research means rotate 90 degrees. As you can see, only one of the two were rotated (both photos of the cup were taken vertically).

![41812015-344c35d4-76f1-11e8-9e84-5a29a74672b1](https://user-images.githubusercontent.com/10585687/42486892-a9da41ca-83d4-11e8-8bc1-3a9c0203e681.jpg)

This is another screenshot using the sample app linked below in the reproducible demo section. I took 6 photos vertically in a row, then displayed them from CameraRoll. The first one in the grid is not rotated correctly.

![42421293-807d1a04-82a9-11e8-890e-73c56aeca746](https://user-images.githubusercontent.com/10585687/42486926-e7dd2b7c-83d4-11e8-87f5-101f69891ab8.jpg)

## Reproducible Demo
I could not create a snack with the most recent version of react native (0.56) as it appears that CRNA still uses 0.55 by default. However, I have a repo setup for a simple app that displays a photo grid from CameraRoll. 

I have only been able to reproduce this issue on Samsung Galaxy S8 and Samsung Galaxy S8+.

To reproduce:

- Take a few vertical photos with a physical device
- clone https://github.com/phillmill/rn-android-image-orientation-test
- run npm install
- react-native run-android

## A workaround:

Currently my workaround is to pass a false argument to setAutoRotateEnabled() in ./ReactAndroid/src/main/java/com/facebook/react/views/image/ReactImageView.java and compile react native from source. From there, I then rotate the image manually by reading the Exif value & using transforms accordingly. There may be a better work around, and I'd love to hear one, but that's all I have for now!
Repository: opencv
Issue: Add 'ptrT' methods to 'cv::Mat_'
Labels: category: core,RFC

`cv::Mat_` already provides the means to get a row/element pointer via `uchar* ptr(...)` and `template<T> T* ptr(...)` methods which are inconvenient since the element type is known at compile time, and there's an `operator[]` monstrosity (in my opinion) which makes source code unintelligible and somewhat unreadable:
```
cv::Mat_<float> mat;
...
auto data1 = mat(42); // works the same for all mats (cv::Mat, cv::Matx, cv::Mat_)
auto data2 = mat[13]; // additional bracket operator confuses the API semantics 
```
I would propose adding a set of `_Tp* ptrT(...)` overloads with the same arguments as `template<T> T* ptr(...)`.
Repository: rust
Issue: 2018 path clarity: When path lookup fails because of shadowed crate, provide hint
Labels: C-enhancement,A-diagnostics,A-resolve,T-compiler,D-terse

In Rust 2018, the new path system allows a local name to shadow a crate name:

```rust
use std::num;
struct Newtype(num::BigInt); // ERROR
```

The error is because `num` refers to the local name of the `num` module imported on the first line, so `num::BigInt` fails to look inside the crate. This can be avoided by using `extern::num::BigInt`, which explicitly refers to the crate (note that @aturon proposed [here](https://internals.rust-lang.org/t/relative-paths-in-rust-2018) to make `::num::BigInt` be the disambiguation syntax; this doesn't affect the feature request).

The compiler provides no hint of this, however. It could, upon path failure, provide an information along the lines of "`num` refers to the name declared here; the `num` crate contains `BigInt`, use `extern::num::BigInt` to refer to it" (except written more clearly).

EDIT: The same could apply to any other case where shadowing hides a name that's used as a prefix in a path, but crates seem like the most important.
Repository: go
Issue: cmd/compile: internal prefix paths leaking into generated DWARF
Labels: NeedsFix,Debugging,compiler/runtime

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?

go version devel +c78b7693ab Tue Jul 10 05:08:40 2018 +0000 linux/amd64

however this same problem appears to be present in older released (1.10, 1.9 etc)

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

linux/amd64

### What did you do?

Within my GOPATH, I have a subdir "b.v1" containing b.go:

```
$ cat b.v1/b.go
package b

var q int

func Top(x int) int {
	q += 1
	if q != x {
		return 3
	}
	return 4
}

func OOO(y int) int {
	defer func() { q += Top(y) }()
	t := q
	q = y * y
	return t
}
```

then a main program that imports the package b:

```
package main

import (
	"fmt"

	b "b.v1"
)

var z int

func main() {
	z = b.OOO(z)
	if b.Top(1) != 2 {
		fmt.Printf("Beware the Jabberwock, my son!\n")
	}
}
```

When I compile this program and look at the generated DWARF, it appears that the package path for things in "b" have been mangled (for functions and variables -- compile unit still shows the correct path):

```
 <1><7324d>: Abbrev Number: 3 (DW_TAG_subprogram)
    <7324e>   DW_AT_name:         issue26237/b%2ev1.Top
    <73264>   DW_AT_inline:       1	(inlined)
    <73265>   DW_AT_external:     1
 <2><73266>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <73267>   DW_AT_name:         x
    <73269>   DW_AT_variable_parameter: 0
    <7326a>   DW_AT_type:         <0x128a>
 <2><7326e>: Abbrev Number: 0
...
 <1><14ec2>: Abbrev Number: 7 (DW_TAG_variable)
    <14ec3>   DW_AT_name:         issue26237/b%2ev1.q
    <14ed7>   DW_AT_location:     9 byte block: 3 80 8f 56 0 0 0 0 0 	(DW_OP_addr: 568f80)
    <14ee1>   DW_AT_type:         <0x128a>
    <14ee5>   DW_AT_external:     1
```

Note the "%2ev1".  It looks like this mangling is being done in PathToPrefix() in cmd/internal/objabi, no doubt to hide/mangle the "." within the name.

While it seems fine to do mangling within the compiler, it doesn't seem as though the mangling should be leaking into the generated DWARF -- names there should reflect the original package path. If I build this program and run GDB on it, I can't print out the value of the variable 'q' without knowing the special mangled name, which seems unfriendly.
 
### What did you expect to see?

(gdb) p b.v1.q
0
(gdb)

### What did you see instead?

(gdb) p 'b.v1.q'
No symbol "b.v1.q" in current context.
Repository: go
Issue: x/text/cmd/gotext: extract command crash if no messages
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
go1.9.2

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
windows/amd64

### What did you do?

Run `gotext extract` command on a project directory without any messages to extract and no `golang.org/x/text/message` import.


### What did you expect to see?

A blank or error response.


### What did you see instead?

A runtime error :

```
>gotext extract
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x866423]

goroutine 1 [running]:
golang.org/x/text/message/pipeline.(*extracter).seedEndpoints(0xc0421c6000)
        C:/GO-projects/src/golang.org/x/text/message/pipeline/extract.go:100 +0x63
golang.org/x/text/message/pipeline.Extract(0xc0420dc750, 0x1, 0x1, 0x0)
        C:/GO-projects/src/golang.org/x/text/message/pipeline/extract.go:45 +0x5c
main.runExtract(0xd6c4c0, 0xc0420dc750, 0xc042046390, 0x0, 0x0, 0x0, 0x0)
        C:/GO-projects/src/golang.org/x/text/cmd/gotext/extract.go:29 +0x63
main.main()
        C:/GO-projects/src/golang.org/x/text/cmd/gotext/main.go:150 +0x34e
```
Repository: rust
Issue: 2018 lint migrating to `use crate::...` doesn't consider mixed imports
Labels: A-lints,C-bug,A-suggestion-diagnostics,A-edition-2018

Originally reported as https://github.com/rust-lang-nursery/rustfix/issues/124

Text inlined below...

---

Given the code:

```toml
# Cargo.toml
[package]
name = "test-badfix"
version = "0.1.0"

[dependencies]
futures = "*"
```

```rust
// src/lib.rs
#![feature(rust_2018_preview)]

extern crate futures;

mod a;

pub struct Useful;
```

```rust
// src/a.rs
pub use {
    Useful,
    futures::Future,
};
```

A call to `cargo fix --prepare-for 2018` causes `a.rs` to be changed to:

```rust
pub use crate::{
    Useful,
    futures::Future,
};
```

Which doesn't really seem right, it seems

```rust
pub use {
    crate::Useful,
    futures::Future,
};
```
would be more correct.

Interestingly enough, the code generated by rustfix does compile...not sure if that's intended behavior, but is unrelated as the code

```rust
#![feature(rust_2018_preview)]

extern crate futures;

use crate::futures::Future;
``` 

compiles fine.
Repository: pytorch
Issue: /usr/bin/ld: cannot find -lpthreads
Labels: module: build,triaged,has workaround

On Debian Buster

    cmake .

leads to an error

```
Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /home/zfsdt/temp/pytorch/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_d9266/fast"
/usr/bin/make -f CMakeFiles/cmTC_d9266.dir/build.make CMakeFiles/cmTC_d9266.dir/build
make[1]: Entering directory '/home/zfsdt/temp/pytorch/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_d9266.dir/CheckFunctionExists.c.o
/usr/bin/cc   -DCHECK_FUNCTION_EXISTS=pthread_create -fPIE   -o CMakeFiles/cmTC_d9266.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.11/Modules/CheckFunctionExists.c
Linking C executable cmTC_d9266
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_d9266.dir/link.txt --verbose=1
/usr/bin/cc  -DCHECK_FUNCTION_EXISTS=pthread_create    CMakeFiles/cmTC_d9266.dir/CheckFunctionExists.c.o  -o cmTC_d9266 -lpthreads 
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_d9266.dir/build.make:86: recipe for target 'cmTC_d9266' failed
make[1]: *** [cmTC_d9266] Error 1
make[1]: Leaving directory '/home/zfsdt/temp/pytorch/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_d9266/fast' failed
make: *** [cmTC_d9266/fast] Error 2
```

For compilation with pthreads  -pthread should be used not -lpthreads
Repository: go
Issue: runtime: Caller returns wrong file and line if called in a deferred function during panic
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?
### Does this issue reproduce with the latest release?
Tested on b001ffb.

### What did you do?
https://play.golang.org/p/mqVHDikFu8D

### What did you expect to see?
```
    return: main.go:13
     panic: main.go:18
```

### What did you see instead?
```
    return: main.go:13
     panic: asm_amd64p32.s:459
```

This bug was found in the discussion of #26275.