sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/compile: provide a more explanatory error message on trying to take the address of an unaddressable value e.g. constants, integer and string literals
Labels: NeedsDecision

### What version of Go are you using (`go version`)?
go version go1.11.1 linux/amd64

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN="/home/24G/.bin"
GOCACHE="/home/24G/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/24G/go"
GOPROXY=""
GORACE=""
GOROOT="/snap/go/2890"
GOTMPDIR=""
GOTOOLDIR="/snap/go/2890/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build434234612=/tmp/go-build -gno-record-gcc-switches"
```

### What did you do?

https://play.golang.org/p/uU1XNXaFYG-

### What did you expect to see?

This isn't a bug report, that's exactly what I expected haha. But the purpose of this issue is to get a more helpful error message.

### What did you see instead?

`cannot take the address of 5`

This is quite repulsive toward beginners. People who encounter this error may not understand exactly how constant values work, and what the differences between constants and normal values (after all, they look a lot like variables). Pointers are extremely hard for beginners to deal with, and changing this error message will make the language a bit more approachable.

This is especially unintuitive because `&StructValue{...}` is okay, but `&5` is not.

I propose instead that the message is changed to `cannot take the address of the constant value <const>`. This should at least explain a reason _why_ the value is not addressable.

If there are cases where this is error message change would be unhelpful, that would be important to consider.
Repository: go
Issue: text/template: documentation for IsTrue disagrees with its implementation for struct types
Labels: Documentation,NeedsFix

As noted in #28391, the [documentation for `template.IsTrue`](https://tip.golang.org/pkg/text/template/#IsTrue) says:
> IsTrue reports whether the value is 'true', in the sense of not the zero of its type, and whether the value has a meaningful truth value.

The zero `time.Time` *is* the zero of its type, so according to the documentation it should be considered to be true, but the implementation clearly intends otherwise:
https://github.com/golang/go/blob/f6b554fec75ff1a36c6204755db8c1f638255b64/src/text/template/exec.go#L326-L327

Either the documentation should be clarified, or the behavior of `IsTrue` should be fixed to match what is documented. Probably the former.
Repository: TypeScript
Issue: Ignored check result of typeof a === typeof b
Labels: Suggestion,In Discussion

<!-- 🚨 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.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.0-dev.20181025

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
type argType = string | number | boolean;
function sort(a: argType, b: argType): number {
    if (typeof a !== typeof b) {
        return 0;
    }
   // typeof a should be number now
    if (typeof a !== 'number') {
        return 0;
    }
    // typeof b should be number now
    return a - b; // Here TS is not sure that b is number
}
```

**Expected behavior:**
We have already checked that `typeof a` is equal `typeof b`. So if typeof `a` is `number`, than and `b` is `number` too.

**Actual behavior:**
error: `The right-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.`

**Playground Link:** http://www.typescriptlang.org/play/#src=%0D%0Atype%20argType%20%3D%20string%20%7C%20number%20%7C%20boolean%3B%0D%0Afunction%20sort(a%3A%20argType%2C%20b%3A%20argType)%3A%20number%20%7B%0D%0A%20%20%20%20if%20(typeof%20a%20!%3D%3D%20typeof%20b)%20%7B%0D%0A%20%20%20%20%20%20%20%20return%200%3B%0D%0A%20%20%20%20%7D%0D%0A%0D%0A%20%20%20%20if%20(typeof%20a%20!%3D%3D%20'number')%20%7B%0D%0A%20%20%20%20%20%20%20%20return%200%3B%0D%0A%20%20%20%20%7D%0D%0A%0D%0A%20%20%20%20return%20a%20-%20b%3B%0D%0A%7D

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: pytorch
Issue: Tracing custom ops
Labels: oncall: jit

I wrote a custom op using the process described [here](https://pytorch.org/tutorials/advanced/cpp_extension.html), giving me a `torch.autograd.Function` called `MyOp`.

But when I run `torch.jit.trace()` on a module using it, and try to save the result, I get an error `RuntimeError: Couldn't export Python operator <MyOp>`. 

Is there a way to do this? I noticed [this](https://github.com/pytorch/pytorch/blob/master/torch/_ops.py) but I couldn't figure out how to get it to work.

Thanks!
Repository: TypeScript
Issue: In dom.d.ts, caretPositionFromPoint and caretRangeFromPoint should go on DocumentOrShadowRoot, not Document
Labels: Bug,Help Wanted,Domain: lib.d.ts


**TypeScript Version:**  3.1.3 (issue still present on github)

**Code**

```ts
let root: DocumentOrShadowRoot = document // Typechecks if declared as type Document
root.caretPositionFromPoint(1, 1)
```

**Expected behavior:**

The code typechecks

**Actual behavior:**

TypeScript complains that `caretPositionFromPoint` doesn't exist on `DocumentOrShadowRoot`.

**Playground Link:** https://www.typescriptlang.org/play/#src=let%20root%3A%20DocumentOrShadowRoot%20%3D%20document%0D%0Aroot.caretPositionFromPoint(1%2C%201)
Repository: rust
Issue: calling FnMut closure in an immutable value does not say why closure is FnMut
Labels: C-enhancement,A-diagnostics,T-compiler

The following error should at least mention `something` being the reason for the `mut` requirement on the closure.

```rust
fn main() {
    let mut something = 42;
    let dummy = || {
        something = 44;
    };
    dummy();
}
```

([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=7a3c32138c59a6d86d0c8b7639ea50dc))

Errors:

```
   Compiling playground v0.0.1 (/playground)
error[E0596]: cannot borrow `dummy` as mutable, as it is not declared as mutable
 --> src/main.rs:6:5
  |
3 |     let dummy = || {
  |         ----- help: consider changing this to be mutable: `mut dummy`
...
6 |     dummy();
  |     ^^^^^ cannot borrow as mutable

error: aborting due to previous error

For more information about this error, try `rustc --explain E0596`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.

```
Repository: opencv
Issue: IPP: cv::ipp::getIppTopFeatures() return value on 32-bit configurations
Labels: bug,optimization,category: core

Windows 32-bit:

```
Intel(R) IPP version: ippIP SSE4.2 (p8) 2019.0.0 Gold (-) Jul 26 2018
```

`cv::ipp::getIppTopFeatures()` returns `0x8000` (`ippCPUID_AVX2`).
It should be `0x80` (`ippCPUID_SSE42`) because SSE4.2 backend is used.

relates #12877
Repository: kubernetes
Issue: AvailableConditionController doesn't implement proper backoff/retry strategy
Labels: kind/bug,priority/backlog,sig/api-machinery,lifecycle/frozen,triage/not-reproducible

**What happened**:
When AvailableConditionController is unable to contact a api service it keeps retrying with high number of attempts per seconds (like 80 attempts per seconds) creating significant cpu usage. 
https://gist.github.com/mborsz/c6094ae23f84db10593f1e0a0fd5d38d contains kube-apiserver's logs from one of the attempts.

**What you expected to happen**:
AvailableConditionController should implement a proper backoff/retry strategy in that case.

**How to reproduce it (as minimally and precisely as possible)**:
1. Create a cluster
2. Block ssh tunnel access to the nodes with service running
3. Restart kube-apiserver
4. Watch logs and cpu usage of kube-apiserver

**Anything else we need to know?**:

AvailableConditionController seems to be trying to implement some backoff logic, but it either doesn't work or still generates too big load.

**Environment**:
- Kubernetes version (use `kubectl version`): 1.9.7
- Cloud provider or hardware configuration: gke
- OS (e.g. from /etc/os-release):  cos
- Kernel (e.g. `uname -a`): 4.4.111+
- Install tools:
- Others:

<!-- DO NOT EDIT BELOW THIS LINE -->
/kind bug
Repository: vscode
Issue: Git - VS Code no longer supports 'edit' in 'git rebase' flow
Labels: bug,git

As of a latest update, VS Code now does the wrong thing when using the Source Control pane during a `git rebase` command. `git rebase -i` allows the rebase to be stopped in in order to `edit` commits. This includes undoing them, changing the commit message, or adding more commits. Now, instead of just allowing commits as usual, VS Code attempts to use `git rebase --continue` after altering a commit, which fails because there is still a commit pending that is not the original.

- VSCode Version: 1.28.2 (system setup)
- OS Version: Windows 10 Enterprise 1809 17763.55

Steps to Reproduce:

1. Create a new branch, and add at least one commit to the branch.
2. In the terminal, do `git rebase -i master`
3. In the editor for the interactive rebase, change a commit from `pick` to `edit`
4. Close the editor.
5. Git will start the rebase, and stop on the commit. It will prompt to amend the commit or add more.
6. In the Source Control pane, use 'Undo last commit'
7. Once the commit is soft reset, attempt to edit the commit. Rename the commit description or make more local changes.
8. Note that VS Code shows a warning that editing the commit is not allowed, even though Git specifically allows it here.
9. Attempt to commit anyway through the Source Control pane.
10. VS Code pops a dialog from Git, saying that the operation is not allowed.
11. In the Git log, observe that the commit action actually sent `git rebase --continue`, which is not correct. It should have just done a usual `git commit`

One can work around the issue by completing the commit in the terminal window, but using VS Code normally handles the work of auto-staging files and deletions, making it a lot more useful.

![10 26 vs code git rebase edit blocked](https://user-images.githubusercontent.com/6828233/47572497-f5f41e80-d8ef-11e8-9200-8129e130bc2f.gif)

This used to work! If you want to be more helpful during rebases, I suggest adding a dedicated 'continue' button instead of altering the behavior of the commit button.

Does this issue occur when all extensions are disabled?: Yes
Repository: godot
Issue: Dynamic font sizes changed in script propagate to other nodes
Labels: topic:core,documentation

I have been looking online to see if there is a workaround to this, with no success. This is either a bug, or something that needs a fix. As I explained earlier, whenever I change a font size in script, it propagates to other nodes instances, some don't even share the same dynamic font.

**Godot version:**
3.0.6

**OS/device including version:**
All

**Issue description:**
Dynamic font sizes changed in script propagate to other nodes, sometimes not even sharing the same dynamic font file.

**Steps to reproduce:**
- Assign a dynamic font to a label node.
- Place various instances of node on scene.
- Make the dynamic font size be able to change in script. Per example,
```gdscript
extends Label

export(int) var font_size = 16

func _ready():
    self.get_font('font').size = font_size
```
- Assign different font sizes to each node.
- Run scene and watch as all nodes get the same font size of the last label rendered.
Repository: flutter
Issue: Tool doesn't support a project as both an app and module at the same time (both android and .android directories)
Labels: tool,a: existing-apps,P2,team-tool,triaged-tool

I have a Flutter project that is also a **module** project. That means:

 - I have a "android" folder.
 - I also have a ".android" (auto-generated) folder.

This causes some issues when I try to build or run the project:

 - When I run it, the flutter framework install the ".android" (generated) app into the phone.
 - When I build (release) it generates an apk based on the "android" folder.

How do I specify which folder I want the flutter's to work with? I believe this is not possible right now so, it should be considered for future implementations.

Ps.: I used Android as a example but also happens for iOS

----------------------------------------------------
To exemplify a problem that happend:

I added `shared_preferences `to my `pubspec.yaml`. Running the app by intellij was working fine and nothing wrong was happening, but when I run a `flutter build apk` and then a `flutter install`, the app in the Android device was throwing a "**MissingPluginException**".

Then I checked the GeneratedPluginRegistrant file from the "**android**" folder and it was completely out of date.

To fix it I had to comment the `pubscpec.yaml's` entire "module" property (with its **androidPackage** and **iosBundleIdentifier** sub-properties). By doing this, Flutter started to generate properly all the files for the "**android**" folder.



**(My flutter doctor is all fine)**
Repository: TypeScript
Issue: Bug: Chained this-intersecting methods don't work from within class
Labels: Bug,Domain: This-Typing

<!-- 🚨 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.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.1.1-insiders.20180926

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** this chain

**Code**

```ts
class Builder {
    private _class: undefined;
    withFoo<T>() {
        return this as this & { foo: T }
    }
    withBar<T>() {
        return this as this & { bar: T }
    }
    withFooBar<T>() {
        return this.withFoo<T>().withBar<T>();
    }
}

let good = new Builder().withFoo<number>().withBar<number>();
let bad = new Builder().withFooBar<number>();
good = bad;
```

**Expected behavior:**

`good` & `bad` should be identical

**Actual behavior:**

`bad` is missing `foo`

**Playground Link:** http://www.typescriptlang.org/play/#src=class%20Builder%20%7B%0D%0A%20%20%20%20private%20_class%3A%20undefined%3B%0D%0A%20%20%20%20withFoo%3CT%3E()%20%7B%0D%0A%20%20%20%20%20%20%20%20return%20this%20as%20this%20%26%20%7B%20foo%3A%20T%20%7D%0D%0A%20%20%20%20%7D%0D%0A%20%20%20%20withBar%3CT%3E()%20%7B%0D%0A%20%20%20%20%20%20%20%20return%20this%20as%20this%20%26%20%7B%20bar%3A%20T%20%7D%0D%0A%20%20%20%20%7D%0D%0A%20%20%20%20withFooBar%3CT%3E()%20%7B%0D%0A%20%20%20%20%20%20%20%20return%20this.withFoo%3CT%3E().withBar%3CT%3E()%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A%0D%0Alet%20good%20%3D%20new%20Builder().withFoo%3Cnumber%3E().withBar%3Cnumber%3E()%3B%0D%0Alet%20bad%20%3D%20new%20Builder().withFooBar%3Cnumber%3E()%3B%0D%0Agood%20%3D%20bad%3B
Repository: react
Issue: nextContext arg in shouldComponentUpdate() method
Labels: Type: Needs Investigation,Component: Reconciler

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**
I think it is feature, but could be a bug also

**What is the current behavior?**
When I subscribe to context using React16.6.0 contextType API, component rerenders even when unused context properties was changed. So, I want to use shouldComponentUpdate(), but that method don't have nextContext argument.

Is there any other way to solve this problem?

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

**What is the expected behavior?**

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**
Repository: vue
Issue: Allow <noscript> in Vue templates for SSR usage
Labels: discussion,improvement

### Version
2.5.17

### Reproduction link
[https://codepen.io/brophdawg11/pen/OBdZyX](https://codepen.io/brophdawg11/pen/OBdZyX)


### Steps to reproduce
I'm opening this issue as a follow up to https://github.com/vuejs/vue/issues/8247, as I don't think the solution provided there is suitable for all use-cases.  In a fairly simple UI, where everything is relatively positioned and flows downward, it would likely be fine to include `<noscript>` outside the context of the Vue application, and it would render correctly above the entire app.

However, there are plenty of other UI's that it may not be desirable or feasible to include `<noscript>` _outside_ of the Vue application context and display it properly.  The linked codepen shows a simple fixed-header layout, where including the `<noscript>` tag outside the Vue application context results in the `<noscript>` tag being hidden _behind_ the fixed header, where in reality it is intended to be rendered inside the main body content, and thus below the fixed header.  

The `<noscript>` outside the Vue context also has the unintended effect of pushing down the main content, which has a proper margin-top to account for the static-height fixed header.

Per MDN, `<noscript>` is Flow Content (https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories#Flow_content), it is perfectly viable to exist outside the `<head>` (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/noscript), and is perfectly valid to nest inside the DOM in a `<div>`, as div's allow Flow Content as their children (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/div).

Please reconsider the decision to not permit `noscript` tags in Vue templates.

### What is expected?
`<noscript>` elements should render properly in Vue templates

### What is actually happening?
`<noscript>` elements do not render properly in Vue templates and cause hydration issues when in SSR

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: flutter
Issue: Would like an analytics event every time a user hits "please file this" errors in Framework
Labels: c: new feature,team,tool,framework,P2,team-framework,triaged-framework

Ideally we'd also report the (anonymized) crash traces, but if that's not easy to do, at least we can report an analytics event so we know the frequency.

This came up in discussing with @timsneath, noting that he often sees these "something went wrong deep in the framework, please file a bug" messages.

Thoughts @gspencergoog @Hixie?
Repository: pytorch
Issue: Allow traced modules to return dictionaries
Labels: oncall: jit

For modules traced by `torch.jit.trace()`, allow dictionaries to be returned (ideally nested dictionaries as well) in addition to Tensors/tuples.
Repository: rust
Issue: Trivial proc macro crate can't be found for doc tests
Labels: T-rustdoc,A-macros,A-doctests

I tried making a trivial proc macro crate to try out the newly stabilized things in 1.30 and ran into a problem when running the tests from a crate that imports it.

The normal compilation/tests run perfectly fine, but then it tries to run doc tests, even though I have no doc comments or any other comments for that matter. When running these nonexistant doc tests, it fails to locate my proc macro crate, even though it was definitely there and working correctly for the normal tests.

Full error:
```
$ cargo +stable test
   Compiling foo v0.1.0 (/tmp/new_rust_testing/foo)                                                                                                                                            
   Compiling baz v0.1.0 (/tmp/new_rust_testing/baz)                                                                                                                                            
    Finished dev [unoptimized + debuginfo] target(s) in 0.87s                                                                                                                                  
     Running target/debug/deps/baz-a6614c8413dbf748

running 1 test
test tests::it_works ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

   Doc-tests baz
error[E0463]: can't find crate for `foo`
 --> /tmp/new_rust_testing/baz/src/lib.rs:1:1
  |
1 | extern crate foo;
  | ^^^^^^^^^^^^^^^^^ can't find crate

error: test failed, to rerun pass '--doc'
```

Full code can be found at https://github.com/jrobsonchase/proc_macro_problem

My current rustc version:
```
$ rustup run stable rustc --version
rustc 1.30.0 (da5f414c2 2018-10-24)
```
Repository: flutter
Issue: Ability to recess widgets (i.e. to negative on the z axis)
Labels: c: new feature,framework,f: material design,P3,team-design,triaged-design

It is currently possible to give Material widgets an elevation and have them hover over other widgets. It'd be great to go the other direction an provide give an 'embedded' look, in that one widget looks recessed inside another widget. Kind of like a negative elevation.
Repository: godot
Issue: Inherited export variables from a registered class don't show up in node inspector
Labels: bug,topic:gdscript,confirmed

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

**Godot version:**
Godot 3.1 Alpha


**OS/device including version:**
Mac OSX Sierra 10.12.6


**Issue description:**
Suppose you have a base class in GDScript.

```
# res://base.gd
extends Node2D

class_name Base

export(int) var number : int
```

(1) You can extend by using the path to the .gd script:
```
# res://inherited.gd
extends "res://base.gd"

```

(2) You can extend by using the registered class name:
```
# res://inherited.gd
extends Base
```

in case two the export variable `number` from `Base` does not appear in the inspector.

**Steps to reproduce:**

1.  Create a new Godot project with an empty scene.
2. Add a Node of any kind and give it a script, say "res://base.gd"
3. Give "res://base.gd" an export variable and register its class name
4. Create a new Node that extends from "res://base.gd" but uses the class name instead of the gdscript path
5. The export variable inside "res://base.gd" does not show up in the inherited node inspector


**Minimal reproduction project:**
[class_name_export_bug.zip](https://github.com/godotengine/godot/files/2520965/class_name_export_bug.zip)