sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: unused_must_use lint after `write!` fails to note its origin
Labels: A-lints,T-compiler

Consider the following code ([play](https://play.rust-lang.org/?gist=411e153d8d1bc1a04a7538575aa02d31&version=nightly&mode=debug&edition=2015)):

```rust
// Uncomment the `cfg` to see expected output noting `#[warn(unused_must_use)]`
// #[cfg(without_write)]
pub fn encode_json<T: std::fmt::Display>(val: &T, wr: &mut Vec<u8>) {
    use std::io::Write;
    write!(wr, "{}", val);
}

pub fn after_write_macro() {
    Result::Ok::<_, ()>(());
}

fn main() {
}
```

It generates the following warning:

```
warning: unused `std::result::Result` which must be used
 --> src/main.rs:9:5
  |
9 |     Result::Ok::<_, ()>(());
  |     ^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this `Result` may be an `Err` variant, which should be handled
```

which is *almost*, but not quite, what I expect to see.

Namely, I expect to see this:

```
warning: unused `std::result::Result` which must be used
 --> src/main.rs:9:5
  |
9 |     Result::Ok::<_, ()>(());
  |     ^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(unused_must_use)] on by default
  = note: this `Result` may be an `Err` variant, which should be handled
```

which includes the useful `note: #[warn(unused_must_use)] on by default`

As far as I can tell, the choice whether or not to include that note is based on the presence/absence of the earlier `write!` invocation.

(Hypothesis: perhaps there is an occurrence of an unused must_use within that macros expansion that we are silencing, but even though it is silenced, it is erroneously counted in whatever mechanism we are using to avoid printing out multiple redundant instances of notes like `note: #[warn(unused_must_use)] on by default`?)
Repository: rust
Issue: Aarch64-Windows: Cannot build libcore with exception handling enabled
Labels: A-LLVM,T-compiler,O-windows-msvc,O-AArch64

Trying to cross-compile libcore for `aarch64-pc-windows-msvc` fails with (see also https://github.com/rust-lang/rust/issues/54190#issuecomment-421968456):

```
Building stage2 test artifacts (x86_64-pc-windows-msvc -> aarch64-pc-windows-msvc)
   Compiling term v0.0.0 (file:///C:/msys64/home/mw/2-rust/src/libterm)
   Compiling getopts v0.2.17
   Compiling test v0.0.0 (file:///C:/msys64/home/mw/2-rust/src/libtest)
error: cannot link together two panic runtimes: panic_abort and panic_unwind

error: aborting due to previous error

error: Could not compile `test`.
```

(Note, one has to use `link.exe` instead of LLD as the linker (see #54290) in order to get that far.)

The underlying problem is (probably) that `aarch64-pc-windows-msvc` defaults to `panic_abort`, while `libstd` is unconditionally compiled with `panic_unwind`. All other targets that hard-code `panic_abort` are probably `#[no_std]`?

Making `aarch64-pc-windows-msvc` use `panic_unwind` like the other non-embedded platforms leads to LLVM running into an error while trying to compile `libcore`:
```
   Compiling core v0.0.0 (file:///C:/msys64/home/mw/2-rust/src/libcore)
LLVM ERROR: Cannot select: t10: ch = cleanupret t9, libcore\str\mod.rs:3734 @[ libcore\str\mod.rs:3563 ]
In function: _ZN4core3str21_$LT$impl$u20$str$GT$4trim17hd88bcddf6e49abc8E
error: Could not compile `core`.
```
Repository: kubernetes
Issue: StatefulSet: support resize pvc storage in K8s v1.11
Labels: sig/storage,kind/feature

/kind feature


**What happened**:
With k8s v1.11 the [new feature "Resizing Persistent Volume"](https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/)   was prompted to beta. 

I tried to update the field "statefulset.spec.volumeClaimTemplates.spec.resources.requests.storage" by increasing the storage size from 3Gi to 4Gi, however received following error message.

"The StatefulSet "es-data" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden."


**What you expected to happen**:
The storage size defined in volumeClaimTemplates should be updated using the new feature in v 1.11. 

**How to reproduce it (as minimally and precisely as possible)**:
Try following yaml file. Note that you might need to change the "storageClassName" field according to your cluster setup.

Once the deployment finished, try to change the field "statefulset.spec.volumeClaimTemplates.spec.resources.requests.storage" to e.g. 4Gi.

then applying the same yaml file will result in above error.

```
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 2 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "default"
      resources:
        requests:
          storage: 3Gi
```

**Anything else we need to know?**:

**Environment**:
- Kubernetes version (use `kubectl version`):
lient Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-08T16:31:10Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.2", GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean", BuildDate:"2018-08-07T23:08:19Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

- Cloud provider or hardware configuration:
GCP

/sig storage
Repository: TypeScript
Issue: Index signature is assignable to weak type whose properties don't match the signature type
Labels: Bug

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

From https://stackoverflow.com/q/52368008 .  Based on https://github.com/Microsoft/TypeScript/pull/16047#issue-122101801, it appears that @sandersn may have thought about the rule, but it still makes no sense to me and no rationale is stated.

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  master (394ee31a56c40033f31a3a8461ec267463033194)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** weak type index signature 

**Code**
```ts
interface Foo {
    a?: string;
}
interface Bar {
    [n: string]: number;
}
declare let b: Bar;
// No error; expected "Type 'Bar' has no properties in common with type 'Foo'."
let a: Foo = b;
```

**Expected behavior:** Error: "Type 'Bar' has no properties in common with type 'Foo'."

**Actual behavior:** No error.

**Playground Link:** [link](https://www.typescriptlang.org/play/#src=interface%20Foo%20%7B%0D%0A%20%20%20%20a%3F%3A%20string%3B%0D%0A%7D%0D%0Ainterface%20Bar%20%7B%0D%0A%20%20%20%20%5Bn%3A%20string%5D%3A%20number%3B%0D%0A%7D%0D%0Adeclare%20let%20b%3A%20Bar%3B%0D%0A%2F%2F%20No%20error%3B%20expected%20%22Type%20'Bar'%20has%20no%20properties%20in%20common%20with%20type%20'Foo'.%22%0D%0Alet%20a%3A%20Foo%20%3D%20b%3B%0D%0A)

**Related Issues:** Possibly #9900
Repository: rust
Issue: Expose `proc_macro::__internal::in_sess` in some manner
Labels: A-macros,T-libs-api,C-feature-request,A-proc-macros

Currently to detect whether or not the native `proc_macro` APIs can be used, `proc_macro2` tries to parse, and catches a panic. This isn't the best way to handle it, and involves racy work such as replacing the panic hook to silence the panic logging within the compiler.

It'd be nice to expose the `in_sess` method somehow, perhaps as `proc_macro::within_proc_macro` (strawman) or similar.

https://github.com/rust-lang/rust/blob/b7c6e8f1805cd8a4b0a1c1f22f17a89e9e2cea23/src/libproc_macro/lib.rs#L1438-L1442

cc @dtolnay @alexcrichton
Repository: go
Issue: x/tools/godoc/vfs: path separator character(s) in FileSystem, Opener interfaces is not specified
Labels: Documentation,NeedsFix,Tools

### Problem

Documentation for [`net/http.FileSystem`](https://godoc.org/net/http#FileSystem) reads:

> A FileSystem implements access to a collection of named files. **The elements in a file path are separated by slash ('/', U+002F) characters, regardless of host operating system convention.**

However, the [`FileSystem`](https://godoc.org/golang.org/x/tools/godoc/vfs#FileSystem) interface in `golang.org/x/tools/godoc/vfs` does not clearly specify what the path separator character is expected or allowed to be:

> The FileSystem interface specifies the methods godoc is using to access the file system for which it serves documentation.

**Edit:** [`vfs.Opener`](https://godoc.org/golang.org/x/tools/godoc/vfs#Opener) interface is affected too:

> Opener is a minimal virtual filesystem that can only open regular files.

We need to document it so this is clear to the users and implementors of the interfaces.

### Proposed Resolution

Following logic, I expect that it has to be slash, regardless of host OS conventions, since it's meant to be a virtual filesystem that works across platform boundaries, just like `http.FileSystem`. (Of course, implementations may use non-slash separator paths to access underlying physical filesystems.)

Applying `NeedsDecision` label because I want someone else to confirm my reasoning that this is a documentation bug and that we must specify `/` as the only allowed path separator element. /cc @andybons @bradfitz
Repository: go
Issue: cmd/go: unclear how to cache transitive dependencies in a Docker image
Labels: NeedsInvestigation,modules

### What version of Go are you using (`go version`)?
> go version go1.11 linux/amd64


### Does this issue reproduce with the latest release?
> yes

### What did you do?

I'm attempting to populate a Docker cache layer with compiled dependencies based on the contents of `go.mod`. The general recommendation with Docker is to use `go mod download` however this only provides caching of sources.

`go build all` can be used to compile these sources but instead of relying on `go.mod` contents, it requires my application source to be present to determine which deps to build. This causes a cache invalidation on every code change and renders the step useless.

Here's a Dockerfile demonstrating my issue:

```Dockerfile
FROM golang:1.11-alpine
RUN apk add git

ENV CGO_ENABLED=0 GOOS=linux

WORKDIR /app

COPY go.mod go.sum ./

RUN go mod download

# this fails
RUN go build all
# => go: warning: "all" matched no packages

COPY . .

# this now works but isn't needed
RUN go build all

# compile app along with any unbuilt deps
RUN go build
```

From [package lists and patterns](https://golang.org/cmd/go/#hdr-Package_lists_and_patterns):
> When using modules, "all" expands to all packages in the main module and their dependencies, including dependencies needed by tests of any of those.

where [the main module](https://golang.org/cmd/go/#hdr-The_main_module_and_the_build_list) is defined by the contents of `go.mod` (if I'm understanding this correctly).

Since "the main module's go.mod file defines the precise set of packages available for use by the go command", I would expect `go build all` to rely on `go.mod` and build any packages listed within.

Other actions which support "all" have this issue but some have flags which resolve it (`go list -m all`).
Repository: TypeScript
Issue: Quick fix proposal: declare property for jsdoc types
Labels: Suggestion,In Discussion,Domain: Refactorings,Domain: JavaScript

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->
From https://github.com/Microsoft/vscode/issues/44824

## Search Terms

- quick fix / code action
- jsdoc / jsdocs

## Suggestion

Introduce a new refactoring that introduces a property into a jsdoc type. For example, for the js:

```js
//@ts-check

/**
 * @param {{ }} arg
 */
function doStuff(arg) {
    console.log(arg.noSuch);
}
```

A quick fix on `noSuch` would add this property to the type of `arg`:

```js
//@ts-check

/**
 * @param {{noSuch: object }} arg
 */
function doStuff(arg) {
    console.log(arg.noSuch);
}
```

A similar refactoring already exists for typescript:

```ts
interface IFoo {
    a: number
}

function doStuff(arg: IFoo) {
    console.log(arg.noSuch);
}
```

![screen shot 2018-09-17 at 3 43 00 pm](https://user-images.githubusercontent.com/12821956/45654415-622d6800-ba90-11e8-977b-ea2640fa2fbf.png)


## Use Cases

Improve experience using ts-check, especially if using complex types

## Other cases to consider


**typedef**

```ts
//@ts-check

/**
 * @typedef {{ a: number}} IFoo
 */

/**
 * 
 * @param {IFoo} arg 
 */
function doStuff(arg) {
    console.log(arg.noSuch);
}
```


**Augments**

```ts
/**
 * @augments {Component<{}>}
 */
class Binek extends Component {
	render() {
		console.log(this.props.noSuch)
	}
}
```
Repository: TypeScript
Issue: Spreading private property is wrong
Labels: Bug

**TypeScript Version:**  3.1.0-dev.20180914

**Code**

```ts
class C {
    constructor(readonly x: number, private readonly y: number) {}
}
const a = { ...(new C(0, 1)) };
const b = { x: "", y: "", ...a };
b.x.toUpperCase(); // Error (good)
b.y.toUpperCase(); // No error (bad)
```

**Expected behavior:**

Error at the spread since that accesses a private property.
At least there should be an error at `b.y` since that accesses the same private property, and is a `number` at runtime.

**Actual behavior:**

No error except at `b.x.toUpperCase()` which is correctly an error.
Repository: go
Issue: encoding/json: cannot call UnmarshalJSON on value receiver through interface
Labels: NeedsFix

[Noticed this inconsistency when poking around the code](https://play.golang.org/p/Yw_2jS_Kr6r):
```go
type CustomUnmarshaler struct{ p *bytes.Buffer }

func (cu CustomUnmarshaler) UnmarshalJSON(b []byte) error {
	cu.p.Write(b)
	return nil
}
func (cu CustomUnmarshaler) String() string {
	return fmt.Sprintf("custom %v", cu.p.String())
}

func main() {
	s := &struct {
		F1 CustomUnmarshaler
		F2 interface{}
		F3 interface{}
	}{
		CustomUnmarshaler{new(bytes.Buffer)},
		CustomUnmarshaler{new(bytes.Buffer)},
		&CustomUnmarshaler{new(bytes.Buffer)},
	}
	json.Unmarshal([]byte(`{"F1": "F1", "F2": "F2", "F3": "F3"}`), s)
	fmt.Println(s.F1)
	fmt.Println(s.F2)
	fmt.Println(s.F3)
}
```

This current prints:
```
custom "F1"
F2
custom "F3"
```

I expect it to print:
```
custom "F1"
custom "F2"
custom "F3"
```

In this case, `UnmarshalJSON` is a method on the value receiver. This is a rare situation for methods that mutate the receiver, but is valid. I expect the method to still be called. That is, the `json` package should not assume that the receiver must be a pointer.

This is a very obscure use-case and I personally don't have a horse in the game to address this.
Repository: pytorch
Issue: Mysterious error due to num_workers: 1
Labels: module: multiprocessing,triaged

While I have found the workaround for below, I thought to log this anyway so others can use some insights. In one of my projects I started getting this error randomly after I did bunch of refactoring:

```
Exception ignored in: <bound method StorageRef.__del__ of <torch.multiprocessing.reductions.StorageRef object at 0x00000258213645C0>>
Traceback (most recent call last):
  File "C:\Program Files\Anaconda3\lib\site-packages\torch\multiprocessing\reductions.py", line 26, in __del__
AttributeError: 'NoneType' object has no attribute 'Storage'
```

One of the things I'm doing in my code that is not usual is to train the model on CPU and test on GPU, so I basically do `model.to(...)` to move the model back and forth in each epoch for train and test. Apart from that this is just simple MNIST official CNN code in nutshell.

**Workaround Found**

I haven't yet figured out why exactly this is happening but it turns out that test DataLoader (which I want to use on GPU), had following parameters being passed:

`'num_workers': 1, 'pin_memory': True`

After I removed `'num_workers': 1`, the error disappeared.

**Repro Code**

I haven't done the minimal version of code that reproduces this error but you can get this code from [this repo and commit](https://github.com/sytelus/NNExp/tree/f5d8cdfcde39d867cc090546a94051426d96acd8). If you run [partial_data.py](https://github.com/sytelus/NNExp/blob/f5d8cdfcde39d867cc090546a94051426d96acd8/NNExp/pytorch/mnist/partial_data.py), you will see above error shown in the console.

**Other Info**
PyTorch version: 0.4.1
Is debug build: No
CUDA used to build PyTorch: 9.0

OS: Microsoft Windows 10 Enterprise
CMake version: version 3.10.2

Python version: 3.5
Is CUDA available: Yes
CUDA runtime version: 9.2.88
GPU models and configuration:
GPU 0: TITAN Xp
GPU 1: TITAN Xp

Nvidia driver version: 397.44
cuDNN version: 7.2

Versions of relevant libraries:
[pip] Could not collect
[conda] pytorch                   0.4.1           py35_cuda90_cudnn7he774522_1    pytorch
[conda] torch                     0.5.0a0+f45dfbc           <pip>
[conda] torchvision               0.2.1                     <pip>
Repository: TypeScript
Issue: NodeList is no more compatible with Array<Node>. Breaking change in 3.0 
Labels: Help Wanted,Docs

**TypeScript Version: Version 3.0.3**

**Code**

I didn't find any mentioning to this breaking change.

This code used to compile in 2.9.2:
```ts
/**
 * Array based implementation of NodeList
 */
class JSArrayNodeList extends Array<Node> implements NodeList {
	constructor(items?: Array<Node>) {
		if (items) {
			super(...items);
		} else {
			super();
		}
	}

	public item(index: number): Node {
		return this[index];
	}

	public copy(): JSArrayNodeList {
		return new JSArrayNodeList(this);
	}
}
```

In 3.0 forEach method of NodeList and Array<Node> became incompatible.
Due to this changeset: https://github.com/Microsoft/TypeScript/commit/7a7d04e126fb7c1c6074ef26657eddb0f32e4003

A solution was to add explicit forEach which delegates call to super:

```ts
/**
 * Array based implementation of NodeList
 */
class JSArrayNodeList extends Array<Node> implements NodeList {
	constructor(items?: Array<Node>) {
		if (items) {
			super(...items);
		} else {
			super();
		}
	}

	public forEach(
		callbackfn: ((value: Node, index: number, array: Node[]) => void) | ((value: Node, key: number, parent: NodeList) => void),
		thisArg?: any): void {

		// Just call Array.forEach
		Array.prototype.forEach.call(thisArg, this, callbackfn);
	}

	public item(index: number): Node {
		return this[index];
	}

	public copy(): JSArrayNodeList {
		return new JSArrayNodeList(this);
	}
}
```

**Expected behavior:**

Documentation in breaking change list.

**Actual behavior:**

No information about breaking change.
Repository: pytorch
Issue: set num_workers on the dataloader make the jupyter kernel crash at the almost end of the epoch 
Labels: module: dataloader,triaged

I had code that was running perfectly and I decided to update pytorch from 0.4.0 to 0.4.1

now the program crash close to the end to the first epoch if num_workers is set.

How to fix that?

cc @SsnL @VitalyFedyunin @ejguan
Repository: pytorch
Issue: [caffe2]Can i build caffe2 library only for cpu inference purpose and reduce the binary size?
Labels: caffe2

  I want to deploy caffe2 on mobile device(including Android & IOS), but i found that the binary size is **too large** for my app. I only use a little operators on my net(convolution and forward calculation), how can I build caffe2 just including the inference operators i wanted to **reduce the size of library**?
  It's an urgent task for me, if anyone can provide help, i will be appreciate.
Repository: flutter
Issue: Dependency Injection for Flutter
Labels: c: new feature,framework,would be a good package,c: proposal,P3,team-framework,triaged-framework

I would love to have something similar to Dagger for flutter. I notice https://github.com/google/inject.dart but apparently it will not get any real support/maintenance from the team even if it use internally at Google.

For me it worth putting this repo open source as there no equivalent currently (or not as powerful as this one ^^).
Repository: TypeScript
Issue: Compiler Errors TS1110 and TS2345 with integer type pattern
Labels: Suggestion,In Discussion,Domain: Literal Types

**TypeScript Version:**  3.0.3

Explicitly marked positive integers are not recognized in a type pattern: 

```ts
    foo(direction: -1 | 1 | -2 | +2) { }
```
![image](https://user-images.githubusercontent.com/5341447/45680156-7c238500-bb3a-11e8-8855-bd11f4b639b4.png)

Likewise, calling it using a perfectly legit integer fails with TS2345: 

![image](https://user-images.githubusercontent.com/5341447/45683511-34a1f680-bb44-11e8-9382-766a9d08dff1.png)


**Expected behavior:**

As everywhere else, the unary operator + should be allowed in a type pattern. 
This is not urgent, just for completeness.
Repository: flutter
Issue: I am not able to use onDestroy() lifecycle hook in my flutter application? Can you tell me what is the workaround to this?
Labels: c: new feature,framework,engine,P3,team-engine,triaged-engine
Repository: kubernetes
Issue: Forbidden error returned from dynamic client is not typed correctly
Labels: kind/bug,area/client-libraries,sig/api-machinery,help wanted,lifecycle/frozen

As a user who didn't have permission to watch a CRD in a namespace, I got the correct error from the server, but the dynamic client didn't correctly report the error.

```
I0918 13:51:19.668687   78071 request.go:897] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"prowjobs.prow.k8s.io is forbidden: User \"smarterclayton\" cannot watch prowjobs.prow.k8s.io in the namespace \"ci\": no RBAC policy matched","reason":"Forbidden","details":{"group":"prow.k8s.io","kind":"prowjobs"},"code":403}
E0918 13:51:19.668801   78071 reflector.go:322] github.com/openshift/release-controller/cmd/release-controller/main.go:149: Failed to watch *unstructured.Unstructured: unknown &errors.StatusError{ErrStatus:v1.Status{TypeMeta:v1.TypeMeta{Kind:"", APIVersion:""}, ListMeta:v1.ListMeta{SelfLink:"", ResourceVersion:"", Continue:""}, Status:"Failure", Message:"unknown", Reason:"Forbidden", Details:(*v1.StatusDetails)(0xc42070ea80), Code:403}}
```

I think this may be a bug with unstructured and the dynamic client / scheme not being able to extract the correct message.  

@deads2k 
@kubernetes/sig-api-machinery-bugs