sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Inconsistent behaviour of setup methods between GDScript and GDNative (C++) - values and default values of properties
Labels: documentation,topic:gdextension

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** v3.1.beta6.official 64b
<!-- Specify commit hash if non-official. -->

**OS/device including version:** Linux 64b
<!-- Specify GPU model and drivers if graphics-related. -->

---

**Issue description:**
<!-- What happened, and what was expected. -->
By *changed value* and *default value* I mean values in text fields in *Script Variables* in the editor.

GDNative: In `_init` property values are not initialized at all. In `_ready` properties which should have default values are not initialized to default values, properties with changed values are properly handled.

GDScript: In `_init` property values are initialized (to default values). In `_ready` changed properties are initialized to their current (changed) values.

I hit this issue many times even in a trivial benchmark project and was for some time really confused, why setting properties in the editor works only in some cases.

In my opinion both of these should behave exactly same. I am guessing the GDScript implementation is the desired one, since it makes more sense.

---

**Steps to reproduce:**
```cpp
...
  register_property<GDExample, float>("defaultValue", &GDExample::defaultValue, 5);
  register_property<GDExample, float>("changedValue", &GDExample::changedValue, 10);
...
void GDExample::_init() {
  Godot::print("[C++] init, defaultValue = {0}", defaultValue);
  Godot::print("[C++] init, changedValue = {0}", changedValue);
}
...
void GDExample::_ready() {
  Godot::print("[C++] ready, defaultValue = {0}", defaultValue);
  Godot::print("[C++] ready, changedValue = {0}", changedValue);
}
```

```python
extends Node

export var defaultValue = 5;
export var changedValue = 10;

func _init():
  print("[GDScript] init, defaultValue = ", defaultValue)
  print("[GDScript] init, changedValue = ", changedValue)

func _ready():
  print("[GDScript] ready, defaultValue = ", defaultValue)
  print("[GDScript] ready, changedValue = ", changedValue)
```

Output:
```
[C++] init, defaultValue = 0
[C++] init, changedValue = 0
[GDScript] init, defaultValue = 5
[GDScript] init, changedValue = 10
[C++] ready, defaultValue = 0
[C++] ready, changedValue = 11
[GDScript] ready, defaultValue = 5
[GDScript] ready, changedValue = 11
```
Repository: rust
Issue: libcore can use unstable library features without a feature flag
Labels: A-stability,T-compiler,C-bug

I've been assuming that feature flags can also be used "within" the standard library to control which features are already being used. That is helpful when stabilizing a part of the API, to test if that API is viable enough for whatveer the standard library does with it.

But it turns out that, e.g., [`core::fmt::float` can call `MaybeUninit::get_mut`](https://github.com/rust-lang/rust/blob/e17c48e2f21eefd59748e364234efc7037a3ec96/src/libcore/fmt/float.rs#L20) without enabling the relevant feature flag. That seems like a bug to me.
Repository: godot
Issue: Gdscript -> Assign a boolean value to a typed float produces no error.
Labels: enhancement,discussion,topic:gdscript,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if non-official. -->
5e837b3f13ab1e3b31bb8d705e87820fa4eff21e


**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
win 7

**Issue description:**
<!-- What happened, and what was expected. -->

This expresion:

`export (bool) var UseAceleration : float = false`

Produces no error: no error in the declaration nor in the logic... godot ignores the value entered in inspector and cast false to 0.

The expected result is godot advice to you that entered value doesn´t match the type.
Repository: godot
Issue: Add godot version # to windows firewall entries
Labels: enhancement,platform:windows,topic:editor,topic:network

**Godot version:**
Every version that exists lol


**OS/device including version:**
Windows 10 64bit


**Issue description:**
Basically anytime you run godot for the first time it'll ask you if you want to add it to the firewall for permissions (most likely for networking stuff?)

You can see a video here of all the entries I have with the same name https://streamable.com/1qk26

Would be cool if it added the version to the entry so it's easier to clean up later.
Repository: go
Issue: x/tools/go/packages: preserve information about original errors
Labels: NeedsInvestigation,Tools

I was looking at migrating a tool off of the golang.org/x/tools/go/loader package, as it is seemingly deprecated for use with Go modules, switching it onto https://godoc.org/golang.org/x/tools/go/packages. I ran into a disparity between the two packages in the type of errors that are available to the user after loading in the packages of interest.

A [`loader.PackageInfo`](https://godoc.org/golang.org/x/tools/go/loader#PackageInfo) provides a struct field `Errors []error`, which allows one to do type introspection on the actual error returned from within the loading process.

In contrast, the [`packages.Package`](https://godoc.org/golang.org/x/tools/go/packages#Package) has an `Errors []Error` struct field, where all the errors from the underlying loading process have been one-way transformed into a new struct that loses information, or at least makes it harder to get at. That conversion process happens here: https://github.com/golang/tools/blob/83362c3779f5f48611068d488a03ea7bbaddc81e/go/packages/packages.go#L613-L660

The specific use case I have is to introspect certain types of [`types.Error`](https://golang.org/pkg/go/types/#Error) values so that the tool can then go and attempt to fix those errors in an automated fashion. Since the `types.Error` gets stringified, that information is no longer readily available.

### Proposal

My proposal is to augment the `packages.Error` type to include an `Err error` field that a user of the package can introspect further if desired.

```go
// An Error describes a problem with a package's metadata, syntax, or types.
type Error struct {
	Pos  string // "file:line:col" or "file:line" or "" or "-"
	Msg  string
	Kind ErrorKind
    Err error
}
```

### Alternative workarounds

One can write parsing logic for the current `Error.Pos` field based on what is currently done in the source code, but this seems unnecessary given that the underlying information was already present in a more structured form.
Repository: rust
Issue: Tracking issue for RFC 2627: #[link(kind="raw-dylib")]
Labels: A-linkage,O-windows,B-RFC-approved,T-lang,C-tracking-issue,F-raw_dylib,S-tracking-impl-incomplete

This is the tracking issue for [RFC 2627](https://github.com/rust-lang/rfcs/pull/2627), `#[link(kind="raw-dylib")]`.

**Note:** `raw-dylib` and `link_ordinal` are now stabilized in 1.65 on Windows for x86_64, aarch64, and thumbv7a (not 32-bit x86) via #99916.

Opens:

- [x] Implementation for Windows (top priority) (msvc: #84171) (gnu: #90782)
  - [x] Emitting idata sections
  - [x] New `link_ordinal` attribute (#89025)
  - [x] Testing in winapi/windows-rs with nightly Rust before stabilization (https://github.com/microsoft/windows-rs/pull/977 and https://github.com/microsoft/windows-samples-rs/pull/18)
  - [x] Supporting all calling conventions
    - [x]  cdecl
    - [x] stdcall
    - [x] fastcall
    - [x] vectorcall
- [ ] Tests, including all the corner cases mentioned in the reference-level explanation
- [x] Documentation (https://github.com/rust-lang/rust/pull/87315)
- [ ] Implementation for Linux
- [ ] Implementation for macOS
- [ ] Implementation for other platforms
- [ ] Implementation of a pure Rust target for Windows (no libc, no msvc, no mingw). This may require another RFC

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"dpaoliello"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: pytorch
Issue: Overflow in fbgemm
Labels: caffe2

Hi,
recently I started to learn fbgemm. I notice both the fbgemm test case and here fully_connected_dnnlowp_op_test, fully_connected_dnnlowp_acc16_op_test  have some functions to avoid overflow.

I understand because of the AVX vpmaddubsw instruction, the result of a int8 value times a unsigned int8 value can be saturated. I am not familiar with caffe, so my question is how is the overflow/saturation is handled in the real situation? Are there any particular methods used in the training process so that no overflow happens in the inference or the overflow has little influence on the result precision?

Am I missing something?

Thanks in advance
Repository: TypeScript
Issue: Incorrect docs: type compatibility for functions with overloads
Labels: Docs

<!-- 🚨 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. -->

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** functions with overloads, type compatibility

In the [docs](https://www.typescriptlang.org/docs/handbook/type-compatibility.html), it says: "When a function has overloads, each overload in the source type must be matched by a compatible signature on the target type." But it should be "When a function has overloads, each overload in the ~~source type~~ **target type** must be matched by a compatible signature on the ~~target type~~ **source type**."

**Code**
The actual behaviour is right: 
```ts
type t1 = {
    (foo: string): string
    (foo: number): number
}

type t2 = {
    (foo: string): string
}

declare let v1: t1;
declare let v2: t2;
v2 = v1 // OK
v1 = v2 // Error
```
The type on the right side of `=` is considered "the source type".
Repository: vscode
Issue: Investigation: do not restart Extension host when first folder changes
Labels: workbench-multiroot,under-discussion,api-proposal

Today we restart the extension host whenever the first folder changes because `workspace.rootPath` is always set to that first folder and it never used to change after the extension host started once.

If we would not restart the extension host anymore an extension:
* could use `workspace.rootPath` as before, it would still point to the first folder always (which can be `undefined` if the workspace contains no folders)
* could subscribe to the `onDidChangeWorkspaceFolders` event to get notified about updates
* would see the value of `workspace.rootPath` changing during runtime whenever the first folder changes

//cc @sandy081 @jrieken
Repository: flutter
Issue: StatefulBuilder should either protect against !mounted or offer a way to do so
Labels: c: new feature,framework,c: proposal,P2,team-framework,triaged-framework
Repository: vue
Issue: transition before-leave js-hook does not manipulate the DOM which will be transitioned
Labels: has workaround

### Version
2.6.7

### Reproduction link
[https://jsfiddle.net/8zcdpkv0/](https://jsfiddle.net/8zcdpkv0/)







### Steps to reproduce
Please see jsfiddle.

Any changes in the `before-leave` hook won't affect the DOM which is transitioned.

My actual problem is that I try to transition an element which has `aria-live="polite"` or `rule="alert"`, which will be read out by a screenreader.
Apparently the change of classes from the transition are noticed by the screenreader and the message will be read out again.
I tried to fix this for accessibility purposes with the `before-leave` hook, but that doesn't seem to work correctly.



### What is expected?
It would either be great if the transitioned DOM will remove all attributes which will cause the screenreader to read it out again, or to allow the javascript hook `"before-leave"` to actually change the DOM **before** the transition happens.

### What is actually happening?
The old DOM will be transitioned (and the screenreader will read the content again).

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: The never type can be named despite its feature gate
Labels: A-stability,T-compiler,C-bug

Reported by @xfix in https://github.com/rust-lang/rust/issues/33417#issuecomment-467053097.

```rust
trait MyTrait {
    type Output;
}

impl<T> MyTrait for fn() -> T {
    type Output = T;
}

type Void = <fn() -> ! as MyTrait>::Output;

fn main() {
    let _a: Void;
}
```

The never type is unstable (https://github.com/rust-lang/rust/issues/35121) but the code above (which doesn’t use any feature gate) compiles in Rust 1.12.0 (which I think is the first with https://github.com/rust-lang/rust/pull/35162), 1.32.0, and 1.34.0-nightly (aadbc459b 2019-02-23). In 1.11.0, it errors with:

```rust
error: the trait bound `fn() -> !: MyTrait` is not satisfied [--explain E0277]
  --> a.rs:12:13
   |>
12 |>     let _a: Void;
   |>             ^^^^
help: the following implementations were found:
help:   <fn() -> T as MyTrait>

error: aborting due to previous error
```
Repository: go
Issue: testing: loses log messages made in a goroutine after test has completed
Labels: NeedsFix

The testing package silently drops `t.Log` messages that are made by a goroutine after the test has completed.  For example, the following test passes and logs nothing.

This should be fixed by extending the code added in 1.12 that panics if a goroutine logs after a test has completed to not silently discard the log message.  The silent discarding is occurring in the current code because every test runs in a parent context, and the output accumulated by the parent context is discarded.

```Go
package main

import (
	"testing"
	"time"
)

func TestLateLog(t *testing.T) {
	c := make(chan bool)
	go func() {
		<-c
		time.Sleep(time.Millisecond)
		t.Log("log after test")
	}()
	close(c)
}
```
Repository: rust
Issue: Panic in proc_macro::TokenStream::from_str
Labels: A-macros,T-compiler,A-proc-macros

[TokenStream::from_str](https://doc.rust-lang.org/proc_macro/struct.TokenStream.html#impl-FromStr) is supposed to return `Result<proc_macro::TokenStream, proc_macro::LexError>`. Currently it appears to print errors to stderr and then panic, rather than returning errors.

#### Cargo.toml

```toml
[package]
name = "repro"
version = "0.0.0"
edition = "2018"

[lib]
proc-macro = true
```

#### src/lib.rs

```rust
extern crate proc_macro;

use proc_macro::TokenStream;
use std::str::FromStr;

#[proc_macro_derive(ParseTokenStream)]
pub fn derive(_input: TokenStream) -> TokenStream {
    let _ = TokenStream::from_str("\\s");
    TokenStream::new()
}
```

#### src/main.rs

```rust
#[derive(repro::ParseTokenStream)]
struct S;

fn main() {}
```

Output of `cargo check`:

```console
$ cargo check

error: unknown start of token: \
 --> src/main.rs:1:10
  |
1 | #[derive(repro::ParseTokenStream)]
  |          ^^^^^^^^^^^^^^^^^^^^^^^

error: proc-macro derive panicked
 --> src/main.rs:1:10
  |
1 | #[derive(repro::ParseTokenStream)]
  |          ^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors
```

Mentioning @eddyb, @petrochenkov, @alexcrichton.
Mentioning @canndrew who reported this in https://github.com/alexcrichton/proc-macro2/issues/168.
Repository: TypeScript
Issue: tsc gets confused after assigning to module.exports - Property 'filename' does not exist on type
Labels: Needs Investigation

<!-- 🚨 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.4.0-dev.20190223

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
module.filename
require.main === module
**Code**

```js
// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.
module.exports = function(){ 
  return module.filename;
} 
```

**Expected behavior:**
Should not emit any error
**Actual behavior:**
```
D:\test>node_modules\.bin\tsc -v
Version 3.4.0-dev.20190223

D:\test>node_modules\.bin\tsc
test.js:2:17 - error TS2339: Property 'filename' does not exist on type '{ "D:/test/test": () => any; }'.

2   return module.filename;
                  ~~~~~~~~


Found 1 error.
```
**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
tsconfig.json: 
```json
{
  "compilerOptions": {
    "noEmit": true,
    "checkJs": true,
    "allowJs": true,
    "resolveJsonModule": true, 
    "module": "commonjs",
    "lib": ["es2018"],
    "target": "es2018",
    "baseUrl": ".",
    "paths": {
      "@/*": [
        "../*"
      ],
      "#/*": [
        "./*"
      ]
    },
    "types": [
      "node"
    ],
  },
  "exclude": [
    "node_modules",
    "public"
  ]
}
```

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33357
Repository: create-react-app
Issue: Add eslint rule: import/no-self-import
Labels: issue: proposal

Hello and thank you for this great tool.

Today I had a problem after a file rename and I should admit a bad copy paste, I ended up with a file importing itself. It made my browser crashes without any logs and I lost about 10 minutes to find the reason. When I found it, I was surprised to not see any warnings from my IDE or eslint. 

So I was wondering if we can add by default the import/no-self-import rule ?

It could help others or myself in the future and there is no breaking change has it impossible to run the app without respecting it.

I could made a PR but it's one line PR and I think it will be easier to do it by yourself if you agreed.

Thank you !
Repository: angular
Issue: docs request: writing e2e tests and debugging
Labels: area: testing,effort3: weeks,P4,docsarea: testing,doc-topic: reference,area: docs

<!--🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅

Oh hi there! 😄

To expedite issue processing please search open and closed issues before submitting a new one.
Existing issues often contain information about workarounds, resolution, or progress updates.

🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅🔅-->

# 📚 Docs or angular.io bug report

### Description

The docs currently have a fantastic testing section and is a key resource when directing other staff on how to write unit tests for Angular, however for writing e2e tests there is no documentation. In addition, how to debug e2e tests is not mentioned anywhere.

The cli ng e2e docs mention --elementExplorer, however this does not work in node 8+, so how do we do this?

Clear documentation outlining the process of e2e tests would be appreciated, given that angular supports this and has a cli command for it. As an end user, I don't know how to use this.

Going a step further, looking at the protractor website: https://www.protractortest.org it seems heavily focused on AngularJS, but does mention Angular. If this is the resource that we are meant to use, at the minimum the Angular docs should link to this, but it would be better if this was a first class citizen of the Angular docs that was specific to Angular to avoid confusion.

## 🔬 Minimal Reproduction

### What's the affected URL?**
<!-- ✍️edit:--> https://angular.io/cli/e2e

### Expected vs Actual Behavior**
<!-- If applicable please describe the difference between the expected and actual behavior after following the repro steps. -->
<!-- ✍️edit:-->
*Expected*
I'm expecting to find docs on how to write e2e tests and how I can debug my e2e tests.

*Actual*
Using the search terms 'protractor', 'e2e', 'end to end' do not provide any useful information on how to do this.
Repository: kubernetes
Issue: kubectl port-forward broken pipe
Labels: kind/bug,sig/api-machinery,help wanted,sig/cli,triage/unresolved

**What happened**:

We have a pod running in our k8s cluster that I connect to via `kubectl port-forward`. I am able to connect to this pod (using the following command) but then start getting broken pipe error messages after maintaining a connection for what is typically 30-60s. 

`kubectl port-forward --namespace monitoring deployment/cost-monitor 9090`

There seems to be a correlation between error rate and the amount of data being transferred. I see the following error message initially:

`E0225 15:20:06.212139   26392 portforward.go:363] error copying from remote stream to local connection: readfrom tcp6 [::1]:9090->[::1]:57794: write tcp6 [::1]:9090->[::1]:57794: write: broken pipe`

These errors are oftentimes followed by timeout messages but necessarily immediately:

`E0225 15:22:30.454203   26392 portforward.go:353] error creating forwarding stream for port 9090 -> 9090: Timeout occured`

**What you expected to happen**:
No error messages or major degradation in transfer rate.

**How to reproduce it (as minimally and precisely as possible)**:
Connect via port-forward and transfer ~5 mb over several minutes. 

**What else?**:
We have multiple HTTP requests being made at any given time on this port-forward connection. 

**Environment**:
Experiencing on both AWS kops and GKE 

// kops
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-04T04:48:03Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:25:46Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

// GKE
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-04T04:48:03Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.11-gke.1", GitCommit:"5c4fddf874319c9825581cc9ab1d0f0cf51e1dc9", GitTreeState:"clean", BuildDate:"2018-11-30T16:18:58Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}