sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Poor Light2D performance on Radeon GPU
Labels: platform:windows,topic:rendering,confirmed,topic:thirdparty,topic:2d,performance

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.1 c025f526c


**OS/device including version:**
Windows 10: AMD Radeon RX Vega 64
![RX Vega(1)](https://media.discordapp.net/attachments/510024335059320833/510045181178019840/unknown.png?width=1115&height=676)
![RX Vega(2)](https://media.discordapp.net/attachments/510024335059320833/510045636612325377/unknown.png)

Windows 7: AMD Radeon HD 6870
![HD6870(1)](https://i.imgur.com/tBGtai7.png)
![HD6870(2)](https://i.imgur.com/xmxdxiN.png)

MacOSX: Radeon Pro 450 2G


**Issue description:**
I got multiple reports from players claiming poor performance. A common factor seems to be use of Radeon cards. According to spec, these cards should be able to run my game >60FPS. Actual real life performance:

AMD Radeon RX Vega 64: ~10FPS
AMD Radeon HD 6870: ~1FPS
AMD Radeon Pro 450 2G: ~2FPS


**Steps to reproduce:**
Grab a [demo from steam](https://store.steampowered.com/app/846030/V_Rings_of_Saturn/), start game, fly to the left to trigger end-demo sequence.

Might be related to #4151 - i do use lot of Light2D in that scene.
Repository: TypeScript
Issue: Extend tsserver interface to allow refactoring failure reporting
Labels: Suggestion,In Discussion,API,Domain: TSServer

<!-- 🚨 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.

-->

## Search Terms
refactoring report failure fail
<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion
I would like a way to report refactoring failures similar to rename fail report ("You cannot rename this element").
This change improves transparency.

Edit: This might imply changes in VS Code language server extension as well. I'm not familiar with it though.
<!-- A summary of what you'd like to see added or changed -->

## Use Cases
This would be useful to allow refactorings to initially show the refactoring, but when invoking it, an error message should be shown, instead of just not showing the refactoring. This would be confusing to the user. 
<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples
Let's say we want to inline a variable, that is not initialized. This should not be possible. But it is still useful to show the refactoring initially, since the user may be confused why the option doesn't show up.
Then, if the user wants to invoke the refactoring, they get the error message "Cannot inline uninitialized variable."
```
let notInitialized; // should not allow inlining, but tell user why

foo(notInitialized);
```
<!-- Show how this would be used and what the behavior would be -->

## Checklist

My suggestion meets these guidelines:
* [*] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [*] This wouldn't change the runtime behavior of existing JavaScript code
* [*] This could be implemented without emitting different JS based on the types of the expressions
* [*] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: tensorflow
Issue: Move autograph into a separate package and into a separate repo
Labels: stat:awaiting tensorflower,type:feature,WIP,comp:autograph

### System information
- **Have I written custom code (as opposed to using a stock example script provided in TensorFlow)**: no
- **OS Platform and Distribution (e.g., Linux Ubuntu 16.04)**: any
- **Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device**: n/a
- **TensorFlow installed from (source or binary)**: any
- **TensorFlow version (use command below)**: any
- **Python version**: any
- **Bazel version (if compiling from source)**: any
- **GCC/Compiler version (if compiling from source)**: any
- **CUDA/cuDNN version**: any
- **GPU model and memory**: any
- **Exact command to reproduce**: n/a

### Describe the problem

I guess autograph should be moved into a separate package and repo. Because I guess it may be possible to add support of other computation graph frameworks there.
Repository: TypeScript
Issue: Suggestion: compiler option to validate "empty imports"
Labels: Suggestion,In Discussion

<!-- 🚨 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.

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

empy import cannot find module symbols side deffect

## Suggestion

Current behaviour: given an [empty import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#Import_a_module_for_its_side_effects_only) (an import that has side effects and/or does not import any symbols):

``` ts
import './abc';
```

If the module does not exist, there will be no error.

This is unlike other (non-empty) imports, which will error for non-existent modules:

``` ts
import 'foo' from ./abc';
```

I understand this is intended behaviour as per https://github.com/Microsoft/TypeScript/issues/20534#issuecomment-350846017.

I would like to suggest a compiler option for people to opt-in to the stricter behaviour. This could also be added to the `strict` compiler option.

## Checklist

My suggestion meets these guidelines:
* [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: TypeScript
Issue: Better handling for manually created source files and compiler APIs
Labels: Suggestion,Needs Proposal,API

## Search Terms

type checker source file cannot ready property 'members' of undefined

## Suggestion

When a user of the compiler API manually creates a source file with `ts.createSourceFile` instead of retrieving it from their `program`, and then asks the `program` for type inference on a contained node, this can crash. See https://github.com/Microsoft/TypeScript/issues/8136 / https://github.com/vuejs/vue-cli/issues/2712 / https://github.com/angular/tsickle/issues/151 / https://github.com/general-language-syntax/TS-GLS/issues/39.

It seems like one of three interpretations might be best:

* This is explicitly unsupported behavior, but for the sake of performance & simplicity, no checks should happen
* This is explicitly unsupported behavior, and a more explicit error should be thrown
* This should become supported behavior, and the program should dynamically create source files as requested

## Use Cases

Auto-generated TypeScript files, such as `.vue` snippets, still want access to a type checker, such as for TSLint rules.

## Examples

https://github.com/palantir/tslint/issues/4273

## Checklist

My suggestion meets these guidelines:
* [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: go
Issue: net: Resolve{TCP,UDP,IP}Addr returns IPv4 address on host without IPv4 connectivity
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11rc2 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

Linux. The issue doesn't depend on CPU arch and has been reproduced on
ARMv5 and x86-64.

### What did you do?

A minimal repro is this program:

```go
package main

import (
	"log"
	"net"
)

func main() {
	r, _ := net.ResolveUDPAddr("udp", "ping.sunet.se:0") // IPv4 and IPv6 records
	log.Printf("Result of ResolveUDPAddr: %v", r)

	r2, _ := net.ResolveIPAddr("ip", "ping.sunet.se") // IPv4 and IPv6 records
	log.Printf("Result of ResolveIPAddr: %v", r2)

	r3, _ := net.ResolveIPAddr("ip", "ipv6.sunet.se") // Only IPv6 record
	log.Printf("Result of ResolveIPAddr: %v", r3)
}
```

This shows the behavior of ResolveUDPAddr and ResolveIPAddr with dual-stacked
hosts and a IPv6 only host as the last entry. This also applies to ResolveTCPAddr.

### What did you expect to see?

On hosts that have an IPv6 and an IPv4 address, the IPv6 address is preferred
on hosts that has IPv6 only connectivity.

In the program below, the output **should** be something like this on an IPv6-only system:

```
[bluecmd]$ ./ipv6_dial
2018/11/08 16:22:56 Result of ResolveUDPAddr: 2001:6b0:7::14
2018/11/08 16:22:56 Result of ResolveIPAddr: 2001:6b0:7::14
2018/11/08 16:22:56 Result of ResolveIPAddr: 2001:6b0:7::14
```

### What did you see instead?

This is the outcome on an IPv6 only system:

```
[bluecmd]$ sudo ip ro
[bluecmd]$ sudo ip -6 ro
[..]
default via fe80::200:5eff:fe00:265 dev eth0 proto ra metric 100 pref medium
```

Yet ResolveIPAddr prefers IPv4:

```
[bluecmd]$ ./ipv6_dial
2018/11/08 16:22:56 Result of ResolveUDPAddr: 192.36.125.18:0
2018/11/08 16:22:56 Result of ResolveIPAddr: 192.36.125.18
2018/11/08 16:22:56 Result of ResolveIPAddr: 2001:6b0:7::14
```

This is also not dependent on CGO.

For more logs, see [here](https://gist.github.com/bluecmd/7c847fcd22d50bc8ed6f078136c4a6c8).

### Extra information

Problematic code is most likely this part of ipsock.go:

https://github.com/golang/go/blob/7da1f7addf54e55c7b40c1a7bffe5a64989154d8/src/net/ipsock.go#L73-L98

My reading is that the code returns IPv4 unless IPv6 was explicitly asked for.
If the host is IPv6 only, then that host is picked on the fallback return in first().

I would suggest changing the code to not prefer IPv4 addresses if there is no IPv4 connectivity.
Repository: go
Issue: cmd/compile: various low level x86 instruction generation improvements
Labels: Suggested,Performance,help wanted,NeedsInvestigation,compiler/runtime

While reading (to much) go generated assembly code I picked up a few x86 code sequences that seemed sub optimal. I do not remember where I had spotted each of them and some might just come from my imagination, compiler optimization guides or from outside the std library.

Instead of creating an issue per possibility here is a list of some possible low level performance improvements. Note that this does not mean they are common and therefore worth introducing. That can be evaluated. However these can serve to spark ideas for other improvements and for new compiler contributors to try out adding ssa optimization rules or codegen improvements and benchmarking their effects and frequency. UPDATE: CLs should make sure to include statistics/examples of use in std lib and/or generally when introducing optimizations.

Current assembly gc and gccgo create can be quickly checked with https://godbolt.org/.
Given the low level nature there might be oversights in what is possible and whether they are size or performance improvements. As always needs benchmarks and tests.

Many of them should be considered as examples for more general optimizations.

The list:
1. no baseless lea:
There is no lea without a base and only ```index*operandsize``` resulting in ```x+x+x+x``` being compiled to ```leaq+addq``` instead of a single ```leaq[0+x*4]``` with some more combination rules.

2. to many imul
```x*x*x*x``` is compiled as 3 ```imuls``` when 2 are sufficient.

3. set all bits in a register (UPDATE: not generally worth it due to false dependency)
Instead of ```MOVQ $-0x1, Reg``` use ```ORQ $-0x1, Reg``` which is shorter by ~4 bytes for 64bit ints but may create a false dependency as noted by @randall77. 

4. comparing modulo 
```x % 2 == 0``` can be ```andl $1, %eax, testq %rax, %rax``` (or ```btl $0, AX``` ...) instead of ```shift+shift+add+shift+shift+cmp```

5. instead of add use subtract for some powers of 2
```sub -128``` is shorter than ```add 128```. (watch out that flags are not used)

6. for some powers of 2 less equal is better than less of a bit more
```x < 128``` encodes to ```CMPQ $0x80, AX; JG``` which is larger than ```CMPQ $0x7f, AX; JGE```. Should work similar for other comparisons encoding of constants.

7. unsigned division with int
If it is known the int divisor is positive instead of ```CQO+IDIV``` a ```XOR+DIV``` could be used.

8.  optimize modulo with shifts that produce power of 2 
```var x,y uint; x % (1<<y)``` can be replaced with ```x & ((1<<y)-1)```.

@josharian @randall77 @TocarIP @Quasilyte
Repository: go
Issue: x/build/cmd/pubsubhelper: use cloud pubsub for Gerrit instead of email
Labels: Builders

When I wrote pubsubhelper, Gerrit didn't support Cloud Pub Sub, so we had to parse emails to get live notifications out of Gerrit.

But @andybons pointed out that now it does, so we should move to it.

Low priority, but would be a nice cleanup.
Repository: rust
Issue: UdpSocket receive to short buffer behaves differently on Unix and Windows
Labels: T-libs-api,C-bug,A-io

On Unix receiving to a buffer shorter than the incoming payload silently truncates the read. On Windows the read is completed but an error is returned. Not being that familiar with Windows I found this behaviour surprising.

The following comment in [`sys/windows/net.rs`](https://github.com/rust-lang/rust/blob/1d834550d54e4c5211f03f877c1756425f24be98/src/libstd/sys/windows/net.rs#L204-L205) suggests that making Unix and Windows behave the same is (at times) a goal of the standard library:
```
        // On unix when a socket is shut down all further reads return 0, so we
        // do the same on windows to map a shut down socket to returning EOF.
```

If it is I'd like to propose that `WSAEMSGSIZE` be absorbed so that both platforms behave the same.
Repository: pytorch
Issue: [caffe2] test depthwise3x3_conv_op_test fails to run
Labels: caffe2

## 🐛 Bug

The caffe2 test `depthwise3x3_conv_op_test` fails to run when using caffe2 git master in a cpu-only build (with `USE_CUDA:BOOL='OFF'`):
```
Start 84: depthwise3x3_conv_op_test
84/91 Test #84: depthwise3x3_conv_op_test ...............***Failed    0.55 sec
      Start 85: common_subexpression_elimination_test

...

99% tests passed, 1 tests failed out of 91

Total Test time (real) = 249.62 sec

The following tests FAILED:
         84 - depthwise3x3_conv_op_test (Failed)
Errors while running CTest
make: *** [Makefile:86: test] Error 8
```

## To Reproduce

Steps to reproduce the behavior:

1. mkdir -p build
1. cd build
1. [cmake options](https://bpaste.net/show/ca5a7eb99368)
1. make
1. make test

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

The `depthwise3x3_conv_op_test` test should pass.

## Environment

 - PyTorch Version (e.g., 1.0): git master
 - OS (e.g., Linux): Arch Linux x86_64
 - How you installed PyTorch (`conda`, `pip`, source): source
 - Build command you used (if compiling from source): already shown above
 - Python version: 3.7.1
 - CUDA/cuDNN version: disabled in build
 - GPU models and configuration: disabled in build
 - Any other relevant information: compiler is gcc 8.2.1

## Additional context

- All tests passes when using caffe2 git master with `USE_CUDA:BOOL='ON'`
- All tests passes when using caffe2 1.0rc1 with `USE_CUDA:BOOL='ON'`
- Almost all tests fails when using caffe2 1.0rc1 with `USE_CUDA:BOOL='OFF'`
Repository: electron
Issue: Add event that can be used to listen for mouse and scroll events on a <webview>
Labels: enhancement :sparkles:

**Is your feature request related to a problem? Please describe.**
As of Electron 3.0.0 beta 6 mouse, keyboard, and scroll events and the like no longer are able to be listened for.  #14258 , however as seen in that issue "bpasero" used the "before-input-event" event to create an emulated Keypress. As there already is an input event.

**Describe the solution you'd like**
i'd suggest that there be a "before-mouse-event" and "before-scroll-event" so that there can be consistent solution to fix the regression.
Repository: godot
Issue: Window width affects directional shadow resolution (fixed in `master`)
Labels: bug,topic:rendering,confirmed,topic:3d

**Godot version:**
Affects both 3.0.6 and Official 3.1 Alpha 2

**OS/device including version:**
Linux Mint 19 - 64bit
Nvidia GeForce GTX 1060 on driver version: 396.54

**Issue description:**
For some reason the directional shadow resolution decreases as the window width increases, and increases as the width decreases.
Happens in the editor window and also in a running game.
[Video](https://github.com/godotengine/godot/files/2563615/what.flv.zip)

I'm assuming this isn't intended behaviour?
OmniLight and SpotLight do not seem affected.

**Steps to reproduce:**
1. Set up a scene with meshes and a Directional Light with shadows enabled.
2. Decrease and increase the width of the 3D scene window and observe shadows.
Repository: bitcoin
Issue: Can't configure bitocoind to only send tx via Tor but receive clearnet transactions
Labels: Feature,P2P

<!-- Describe the issue -->
There does not seen to be a way to enable onlynet=onion for sending only and regular clearnet for receiving only.

<!--- What behavior did you expect? -->
I expected that onlynet=onion would mean outbound connections from only onion nodes. This sort of works but I need to manually add nodes and then if a node is not open also to the outside I am in an isolate Bitcoin network. I also do not seem to be getting any inbound connections with onlynet=onion is this because my IP is always different under Tor and I need to post my .onion domain somewhere for people to find?

<!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->

<!--- How reliably can you reproduce the issue, what are the steps to do so? -->

<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->
0.17
<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->
Ubuntu 18.04
<!-- Any extra information that might be useful in the debugging process. -->
<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->
Repository: TypeScript
Issue: Issue better error message for binary operations between numbers and bigints
Labels: Suggestion,Domain: Error Messages,Experience Enhancement

```ts
declare let x: bigint;
declare let y: number;

x + y;
y + x;
x - y;
y - x;
x * y;
y * x;
x / y;
y / x;

x += y;
y += x;
```

Each of these gives an error like "Operator '{0}' cannot be applied to types '{1}' and '{2}'". It should *somehow* tell the user that the `number` argument needs to be converted to a `bigint`.
Repository: flutter
Issue: Provide a pagination widget
Labels: c: new feature,framework,f: scrolling,would be a good package,P3,team-framework,triaged-framework

Currently the possible ways to achieve pagination are using ScrollView or ListView.Builder. But need to consider about loading indicator and retry mechanism. Although it's completely possible to create such widget by ourself but it's great if Flutter team able to build this widget.
Repository: rust
Issue: Unexpected doc errors when using --nocapture and compile_fail
Labels: T-rustdoc,C-bug,A-doctests

**Problem**
`cargo test -- --nocapture` outputs error logs for documentation tests even when specifying the `compile_fail` argument. 

**Steps**

1. Create a new project with `cargo new <project name>`
2. Add a `lib.rs` file to `src`
3. Add the following method with documentation and code example which is supposed to fail compilation (the section code will contain invalid Rust code):

```
/// ```compile_fail
/// Input: 123
/// ```
pub fn foo() {
}
```

4. Run `cargo test -- --nocapture`

The output will be:

> Finished dev [unoptimized + debuginfo] target(s) in 0.03s
> Running target/debug/deps/compile_fail-af4564015b61948e
> 
> running 0 tests
> 
> test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
> 
>      Running target/debug/deps/compile_fail-8c19ede40c69c8ad
> 
> running 0 tests
> 
> test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
> 
>    Doc-tests compile-fail
> 
> running 1 test
> error: expected type, found `123`
>  --> src/lib.rs:2:8
>   |
> 3 | Input: 123
>   |        ^^^ expecting a type here because of type ascription
> 
> test src/lib.rs - foo (line 1) ... ok
> 
> test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out


**Notes**

Running `cargo test` presents a different output with no errors:

> Finished dev [unoptimized + debuginfo] target(s) in 0.03s
> Running target/debug/deps/compile_fail-af4564015b61948e
> 
> running 0 tests
> 
> test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
> 
>      Running target/debug/deps/compile_fail-8c19ede40c69c8ad
> 
> running 0 tests
> 
> test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
> 
>    Doc-tests compile-fail
> 
> running 1 test
> test src/lib.rs - foo (line 1) ... ok
> 
> test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Output of `cargo version`:

> cargo 1.30.0 (36d96825d 2018-10-24)
Repository: react
Issue: Input type email bug
Labels: Component: DOM,Type: Needs Investigation

https://codepen.io/anon/pen/GwZeNO

Open this codepen and paste this "example@gmail.com 1"
Then press backspace, notice that the focus changes to the beginning of the input.
Repository: react
Issue: react-test-renderer doesn't support Suspense and lazy nodes
Labels: Type: Bug

Hello. How can I test components with Suspense/Lazy?
now renderer.create(...)toTree() throws
"toTree() does not yet know how to handle nodes with tag=13"

react 16.6.1
react-test-renderer 16.6.1