sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Editor crashes with custom C++ DLL module built under MSVC
Labels: bug,topic:buildsystem,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. -->
3.0.6-stable

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Windows 10 1803
Python 3.6.4
pywin32 224
scons 3.0.1
Visual Studio 2015 14.0.25431.01 Update 3

**Issue description:**
<!-- What happened, and what was expected. -->

After building tools with custom C++ module in a `dll` configuration.  The editor would crash when starting up.

The error starts at this line:
https://github.com/godotengine/godot/blob/8ac39d886307d76c286e804e027fc39f6b5aaac6/core/string_db.cpp#L287

Then crashes at this line due to `OS::get_singleton()` returning NULL:
https://github.com/godotengine/godot/blob/8ac39d886307d76c286e804e027fc39f6b5aaac6/core/error_macros.cpp#L84

**Steps to reproduce:**

- Clone `3.0.6-stable` from git repository
- Setup build environment as above
- Extract attached zip file to `modules/`
- Run the following command line from `VS2015 x64 Native Tools Command Prompt`
```sh
scons -j8 platform=windows tools=yes target=debug
```
- Run built editor with the proper work directory.

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->

[saturn.zip](https://github.com/godotengine/godot/files/2805674/saturn.zip)
Repository: rust
Issue: really bad error messages for trying to `use` a macro from a module
Labels: C-enhancement,A-diagnostics,A-resolve,A-macros,T-compiler

If you read up on new-style macro imports in the [edition guide](https://rust-lang-nursery.github.io/edition-guide/rust-2018/macros/macro-changes.html) and miss the tiny note that it doesn't work for macros in modules in your own crate (why not?!), you might try this:

```rust
mod has_a_macro {
    macro_rules! a_macro { () => {} }
}

use crate::has_a_macro::a_macro;

fn main() {
    a_macro!();
}
```

**BIG MISTAKE.**

```
error[E0432]: unresolved import `crate::has_a_macro::a_macro`
 --> src/main.rs:6:5
  |
6 | use crate::has_a_macro::a_macro;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `a_macro` in `has_a_macro`

error: cannot determine resolution for the macro `a_macro`
 --> src/main.rs:8:5
  |
8 |     a_macro!();
  |     ^^^^^^^
  |
  = note: import resolution is stuck, try simplifying macro imports

error: aborting due to 2 previous errors
```

OK, two errors here, neither of which are helpful.

The first one simply says the macro doesn't exist when it obviously does, this is just the compiler gaslighting the user. Next!

The second one is fairly hilarious (this is already the simplest situation possible) and unactionable.

Let's see... I know that in the past you used to put `#[macro_use]` above the `mod` declaration to do this. Adding that nets a different second error:

```
error[E0659]: `a_macro` is ambiguous (`macro_rules` vs non-`macro_rules` from other module)
 --> src/main.rs:9:5
  |
9 |     a_macro!();
  |     ^^^^^^^ ambiguous name
  |
note: `a_macro` could refer to the macro defined here
 --> src/main.rs:3:5
  |
3 |     macro_rules! a_macro { () => {} }
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: `a_macro` could also refer to the unresolved item imported here
 --> src/main.rs:6:5
  |
6 | use crate::has_a_macro::a_macro;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = help: use `crate::a_macro` to refer to this unresolved item unambiguously
```

This is... really confusing. I can see that the compiler knows exactly which macro I want to call, but it refuses to do it, and for some reason it says it's ambiguous with the statement trying to import it. The `` `macro_rules` vs non-`macro_rules` `` word salad doesn't help matters.

Also, the suggestion doesn't work, you just get the original `import resolution is stuck` error back.

So, the eventual solution is to remove the `use` statement, leaving only `#[macro_use]`, but this isn't discoverable from the mess of errors. Can we take off the compiler-colored glasses and make better diagnostics for this situation? I can't imagine I'm the only person who tried this.
Repository: deno
Issue: WebRTC Integrating
Labels: cli,suggestion

Reference:
[WebRTC Native API](https://webrtc.googlesource.com/src/+/master/native-api.md)
[samples client & server both side](https://webrtc.googlesource.com/src/+/master/examples)
Repository: pytorch
Issue: caffe2 softmaxwithloss problem
Labels: caffe2

my output label is  batch_size x  10 （for 10 labels）
 blob_out = model.FC(  blob_out, 'pred', dim_in, 10)
softmax, loss = model.SoftmaxWithLoss(  [blob_out, labels], ['softmax', 'loss'], scale=scale)   
 but SoftmaxWithLoss report error like this:
 what():  [enforce fail at softmax_ops.cu:307] T.size_from_dim(canonical_axis) == 1. 10 vs 1 Error from operator: 
input: "gpu_0/pred" input: "gpu_0/labels" output: "gpu_0/softmax" output: "gpu_0/loss" name: "" type: "SoftmaxWithLoss" arg { name: "scale" f: 1 } device_option { device_type: 1 cuda_gpu_id: 0 }
0 0 0 1 0 0 0 1 0 0 *** Aborted at 1548750491 (unix time) try "date -d @1548750491" if you are using GNU date ***
PC: @     0x7f89558a1428 gsignal
Repository: flutter
Issue: precacheImage should return bool instead of void
Labels: framework,a: quality,a: images,c: proposal,P2,team-framework,triaged-framework

https://docs.flutter.io/flutter/widgets/precacheImage.html should return a `bool` instead of void indicating if loading the image succeeded.

Currently I use

```dart
bool isSuccess = true;
await precacheImage(..., onError: () => isSuccess = false);
if(isSuccess) {
  ...
}
```

which is ugly and should instead allow

```dart
if(await precacheImage(...) {
  ...
}
```


```
[✓] Flutter (Channel master, v1.1.10-pre.205, on Mac OS X 10.14.3 18D42, locale en-AT)
    • Flutter version 1.1.10-pre.205 at /Users/zoechi/flutter/flutter
    • Framework revision e38efc890b (4 hours ago), 2019-01-28 19:55:01 -0800
    • Engine revision 9b6d5031a3
    • Dart version 2.1.1 (build 2.1.1-dev.3.2 a5030ed92f)
```

See also https://github.com/flutter/flutter/issues/16592#issuecomment-427180769
Repository: vscode
Issue: [folding] Show tooltip on hovering collapse markers
Labels: feature-request,editor-folding

It would be nice to be able to hover the `⊞` and `⊟` symbols in the left gutter of the editor and see a tooltip saying what will happen if they're clicked\*, and showing which keyboard shortcut (if any) is assigned to the action, thus making the UI behavior more discoverable.

<sub>\* This may sound superfluous, but IMO it would help with promoting consistent nomenclature throughout the interface, e.g. "collapse"/"expand" vs. "fold"/"unfold" vs. "hide"/"show", etc.</sub>
Repository: godot
Issue: Navigation Polygon Instance editing to conform to other polygon instance editing
Labels: enhancement,topic:editor,usability

**Godot version:**
3.1 beta 2


**OS/device including version:**
Windows but any should do.


**Issue description:**
Navigation poly editing currently looks like this 
![image](https://user-images.githubusercontent.com/420072/51900048-2d4bee80-2369-11e9-9423-047a9adb9f71.png)

and thus has to be done by hand in the editor for "exact" numbers.

**Expected**
Navigation Poly editing should look like this
![image](https://user-images.githubusercontent.com/420072/51900122-540a2500-2369-11e9-8e0b-796c1ced9182.png)
which would conform to other poly editing that is already existing.



**Steps to reproduce:**
Open editor

Create Nav Poly

Painfully try to get accurate pixels on a 16 by 16 poly and unable to zoom at the correct level because its so tedious.

**Minimal reproduction project:**
Blank Project should work for starting.
Repository: vscode
Issue: Support filter on type should in search tree
Labels: feature-request,search

Testing #67274

![kapture 2019-01-29 at 13 58 41](https://user-images.githubusercontent.com/10746682/51909935-17244980-23ce-11e9-9046-34da3c672d64.gif)
Repository: flutter
Issue: [proposal] ValueKey<String>.toString should return the actual value without inserting quotes
Labels: framework,c: proposal,P2,team-framework,triaged-framework

Not trying to nitpick, but I just lost a lot of time debugging and I wanted to double check that others agreed this is intentional.  Maybe this is a convention in Dart or Flutter, but coming from many other languages I was surprised that quotes were sometimes being inserted into the String representation of the ValueKey.  I spent some time debugging, especially since sometimes the exact type could be determined at runtime and other times not.  But behavior would have been as I expected if these quotes were not getting inserted. 

`final String valueString = T == String ? '<\'$value\'>' : '<$value>';`

[https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/foundation/key.dart#L77](https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/foundation/key.dart#L77)
Repository: pytorch
Issue: TorchConfig.cmake always sets _GLIBCXX_USE_CXX11_ABI
Labels: module: build,triaged

Some libraries, namely pybind11, check for the presence of this macro to determine the compiler version; see https://github.com/pybind/pybind11/blob/master/include/pybind11/numpy.h#L286.

When using TorchConfig.cmake and TORCH_CPP_FLAGS or the torch imported target, this definition is added even if the compiler doesn't support it. This breaks compability with those libraries.
Repository: go
Issue: cmd/compile: variable read should not be optimized when using -gcflags="all=-N -l"
Labels: NeedsFix,Debugging,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.4 windows/amd64
go version go1.12beta2 windows/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\florin\AppData\Local\go-build
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=D:\go
set GOPROXY=
set GORACE=
set GOROOT=C:\Go1.12
set GOTMPDIR=
set GOTOOLDIR=C:\Go1.12\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\awesomeProject9\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\florin\AppData\Local\Temp\go-build732947326=/tmp/go-build -gno-record-gcc-switches
</pre></details>

### What did you do?

- create a project using Go Modules support and the code from https://play.golang.org/p/nnDfvOVbWk9
- run go-delve/delve@b0056ebc97d8d43a13050839521a2110655fc7eb ` dlv debug blah.go `
- place a breakpoint on line 22
- run the application and make a request with ` curl -i http://localhost:8080/ `
- run ` set returnStatus = 404 ` in delve then resume the application


### What did you expect to see?
The debugger should be able to change the value of the function parameter before the call happens.


### What did you see instead?
The debugger was unable to change the value and the old value was used.

My expectation is that if I compile the application using ` -gcflags="all=-N -l" ` such optimization is removed and I can do what I need to do with my program to debug it.

I also noticed that if I swap lines 22 and 23 and keep the breakpoint on line 22 then the result is the expected one. So the optimization applied here is not consistently applied either (should I open a separate bug for it?).

According to @aarzilli in the original issue, https://github.com/go-delve/delve/issues/1473#issuecomment-458530025:

that line compiles to:

```
  blah.go:22		0x750931		488b8424e0000000		MOVQ 0xe0(SP), AX		
  blah.go:22		0x750939		8400				TESTB AL, 0(AX)			
  blah.go:22		0x75093b		488b4028			MOVQ 0x28(AX), AX		
  blah.go:22		0x75093f		488b8c24e8000000		MOVQ 0xe8(SP), CX		
  blah.go:22		0x750947		48890c24			MOVQ CX, 0(SP)			
  blah.go:22		0x75094b		48c7442408c8000000		MOVQ $0xc8, 0x8(SP)		
  blah.go:22		0x750954		ffd0				CALL AX				
```

the instruction of interest is 0x75094b which sets one of the function arguments directly to the constant 0xc8 (200). The compiler noticed that the value of the variable is constant and optimized the read away.
Repository: godot
Issue: Unstable RigidBody when adding/applying forces/torque
Labels: bug,confirmed,topic:physics

**Godot version:**
3.0/3.1 Bullet physics engine (Godot internal doesn't even work)

**Issue description:**
Applying torque on a RigidBody leads into strange behavior, tested using Cylinder and Sphere collision shapes. The wheel (rigidbody) that I want to simulate rolls normally at first while trying to go threw the flat surface ground (big cube) which is strange enough, then it starts to jump and sometimes just snap in place and start to dance and never stops.
Here are two videos I recorded for the problem:
[Wheel alone](https://youtu.be/Y7Aq0qi46I4)
[A Vehicle with 4 wheels and Joints](https://youtu.be/K6MBtzQZ4gg)


**Steps to reproduce:**
Add a RigidBody with cylinder collision shape to the world with a flat static ground, then apply torque.


**Minimal reproduction project:**
[rigidbody_physics_bug.zip](https://github.com/godotengine/godot/files/2808588/rigidbody_physics_bug.zip)
Repository: go
Issue: net: better documentation of UNIX sockets
Labels: ExpertNeeded,Documentation,NeedsFix

The documentation on how to use the various net.Unix* features is rather thin. I don't mind reading man pages for the underlying system calls, but it's often unclear what the abstractions actually do in terms of those system calls. Some substantial examples would help, including ones that show how to pass a file descriptor from one process to another, and which combinations of read/write functions are appopriate for stream, datagram, and packet-oriented sockets.
Repository: pytorch
Issue: The word "ints" is not rendered correclty in docs.
Labels: todo,module: docs,triaged

## 📚 Documentation

See attached image. "Tuple of ints" is rendered as "Tuple of python:ints" instead of "int" being converted into a cross-reference.


<img width="536" alt="image" src="https://user-images.githubusercontent.com/1893159/51939676-10053780-23de-11e9-80e2-7fa091ea4396.png">

<!-- A clear and concise description of what content in https://pytorch.org/docs is an issue. If this has to do with the general https://pytorch.org website, please file an issue at https://github.com/pytorch/pytorch.github.io/issues/new/choose instead. If this has to do with https://pytorch.org/tutorials, please file an issue at https://github.com/pytorch/tutorials/issues/new -->


cc @brianjo @mruberry
Repository: kubernetes
Issue: StatefulSetStatus CurrentRevision doesn't update with OnDelete update strategy
Labels: kind/bug,sig/apps,needs-triage

Note: This may be an enhancement request, but I'm writing it up as a bug since it took me by surprise given how Status was being updated for certain fields and not for others.

**What happened**: I have a statefulset with the `OnDelete` strategy and I deleted the pods, which successfully restarted with the correct, updated controller-revision-hash. However, the StatefulSetStatus was left with the old CurrentRevision, rather than be updated with the UpdatedRevision.

**What you expected to happen**: A `RollingUpdate` will complete with a call to the `completeRollingUpdate` func, which updates the Status:
https://github.com/kubernetes/kubernetes/blob/7f23a743e8c23ac6489340bbb34fa6f1d392db9d/pkg/controller/statefulset/stateful_set_utils.go#L375-L382

The StatefulSetStatus keeps track of the currentReplicas and updatedReplicas even when using the `OnDelete` update strategy, so wouldn't it make sense to call a status updater to update the CurrentRevision?

**How to reproduce it (as minimally and precisely as possible)**:
a) Create a statefulset with the `OnDelete` strategy
b) Delete the pods and wait for them to restart -- notice that the controller-revision-hash label is updated and note that the StatefulSetStatus keeps track of the updatedReplicas count
c) Notice that the StatefulSetStatus CurrentRevision does not get updated

**Environment**:
- Kubernetes version (use `kubectl version`):
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T21:07:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:31:33Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Repository: go
Issue: sizeof: new package with constants for Int, Uint, Uintptr, Int8, Float64, etc
Labels: help wanted,Proposal,Proposal-Accepted,Proposal-Hold

See the tail of the (closed) proposal #5602. There I suggested that instead of making unsafe.Sizeof a safe thing, which it still kinda isn't in general, we solve 90% of the problem by add easy-to-use constants to a safe package, such as:

```
package reflect

const (
  SizeofInt = <size on this machine>
  SizeofUint = SizeofInt
  SizeofBool = 1
  SizeofFloat64 = 8
  //...
)
```

These would be defined for primitive types only, not slices, maps, etc. You'd still need the unsafe package to handle them.
Repository: kubernetes
Issue: predictable memory usage by reflector
Labels: sig/scalability,sig/api-machinery,kind/feature,priority/important-longterm,lifecycle/frozen

**What would you like to be added**:

Predictable memory usage by reflector. I mean, the memory used by reflector does not have to be linear to the total number of objects in apiserver, since the list call can be paged, so I would expect the memory used should just be enough to handle a single page ideally.

**Why is this needed**:

Considering when a controller starts up, the reflector tries to list from apiserver, now if the initial data size is pretty huge(300+MB?), the memory used to decode objects could be huge, I can see that CoreDNS implements something that converts the object to a trimmed version with important fields only, but in my opinion, it does not help much during initialization phase, as the initial memory still has to be allocated, as a result, the application can consume more than 1G memory initially while it only needs 300MB(or less as what is done in CoreDNS) once the list is done. More generally, the question is: is there a possibility that we make sure the memory is bounded even during `list`phase? Maybe something like a shared memory for decoding(a single page at most?), and then trimmed it down for event handlers to consume?
Repository: create-react-app
Issue: Discussing Advanced Configuration Options
Labels: issue: proposal

I believe there's a great need for CRA to support advanced configuration. [React-app-rewired](https://github.com/timarney/react-app-rewired) was the first to let users patch their CRA configs. Then CRA changed (2.0+ and the merging of dev & prod builds). So... I made [Rescripts](https://github.com/harrysolovay/rescripts), which similarly patches react-scripts. These tools work... but they're subject to break whenever CRA changes. Not to mention, they operate via node's require cache and can lag (big time).

**I agree with everything that's been said about prioritizing simplicity for beginners.** Nevertheless, **there's a missed opportunity to provide better DX for experienced devs** (who should also be a priority). No experienced devs want to miss out on updates to react-scripts... but they also don't want to miss out on a lot of the beautiful tooling that hasn't made its way into CRA.

CRA is––for many––the go-to starter (~1.75 million downloads this week alone according to react-scripts npm stats). I feel a little guilty as I ask this question (for what is surely the trillionth time maintainers have heard it), but why can't there be a built-in mechanism––that isn't ejection––for overriding the config?

I'd be more than happy to build this into CRA as an optional back door for manipulating the Webpack config. Something simple, where users can define a function which takes in, operates on, and returns the config object. This way, there's no need to use a 3rd party patching tool, nor would there be a need to eject in most cases.

Beginner devs stay happy. Other devs become overjoyed. Thoughts?
Repository: pytorch
Issue: Error with setting tensors to use cpu in packed_padded_sequence when CUDA tensor is set as default
Labels: module: rnn,module: cuda,triaged

## 🐛 Bug
@ptrblck  helped me diagnose the issue

<!-- A clear and concise description of what the bug is. -->

if Default tensors are set to gpu, setting length to cpu for pack_padded_sequence doesn't work
## To Reproduce

Steps to reproduce the behavior:
`import torch`
`torch.set_default_tensor_type(torch.cuda.FloatTensor)`
`lengths, _ = torch.sort(torch.randint(1, 100, (10,)), descending=True)`
`lengths = torch.as_tensor(lengths.cpu(), dtype=torch.int64)`
`lengths.type()`
this results in a torch.cuda.LongTensor instead of a torch.Longtensor

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->
This is due to the following line in RNN.py"
[line](https://github.com/pytorch/pytorch/blob/21193bf12314f9d1be5ea36cbce3162c54b35225/torch/nn/utils/rnn.py#L195)

## Expected behavior
Expected behaviour will be to accept the move to cpu.

## Environment

PyTorch version: 1.0.0
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: Ubuntu 18.04.1 LTS
GCC version: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
CMake version: version 3.13.3

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 9.1.85
GPU models and configuration: GPU 0: GeForce RTX 2080 Ti
Nvidia driver version: 410.79
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] Could not collect
[conda] blas                      1.0                         mkl  
[conda] cuda100                   1.0                           0    pytorch
[conda] mkl                       2019.1                      144  
[conda] mkl-service               1.1.2            py37he904b0f_5  
[conda] mkl_fft                   1.0.6            py37hd81dba3_0  
[conda] mkl_random                1.0.2            py37hd81dba3_0  
[conda] pytorch                   1.0.0           py3.7_cuda10.0.130_cudnn7.4.1_1  [cuda100]  pytorch
[conda] torchvision               0.2.1                      py_2    pytorch