sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Particles still emit at old location when emission is turned off, moved and turned back on
Labels: bug,topic:rendering,confirmed,topic:particles

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

Godot 3.0.5
Windows 10 64 bits
GeForce GTX 1060 6GB/PCIe/SSE2

Repro:
1) Place world space particles at position A and enable emission. Wait some time.
2) Disable emission
3) Move particles at position B
4) Enable emission: see a few particles are still wrongly emitted from A
5) Next particles are correctly emitted from B

Test project:
[ParticlesEmissionBug.zip](https://github.com/godotengine/godot/files/2195239/ParticlesEmissionBug.zip)
Use left and right arrow keys to emit from left or right

I use this in my game to emit sparks when scrapping walls, and this bug makes them appear sometimes at the wrong place instead of the contact point.
Repository: rust
Issue: Macros 2.0: macro defined and used in same function-like scope can't resolve its own items
Labels: A-resolve,T-compiler,A-macros-2.0,F-decl_macro

Maybe this is just a misunderstanding of hygiene, but if a macro 2.0 is defined and used in the same function-like scope (function/const) then it can't resolve its own items:

```Rust
#![feature(decl_macro)]

trait Tr { fn foo(self); }

const C: () = {
    macro implit {
        () => {
            fn doit() { println!("Hi"); }
            impl ::Tr for () {
                fn foo(self) {
                    doit();
                }
            }
        }
    }
    
    
    #[cfg(works)]
    const T: () = { implit!(); () }; // this works with no error
    
    #[cfg(not(works))]
    implit!(); //~ ERROR cannot find function `doit` in this scope
};

fn main() {
    ().foo();
}
```

## Expected Result

`doit()` should resolve to the `fn doit` in the scope of the macro, printing `Hi!`

## Actual Result

Resolution error.

Note that
1. Having the macro defined *and used* in a module (i.e., if `const C: ()` was a `mod _xyz`) does work.
2. Having the macro defined in 1 function-like scope, and used in a child scope of it (see `cfg(works)`) also works. This error only occurs if the macro is defined and used in the *same* scope.

cc @petrochenkov @nrc
Repository: rust
Issue: Custom derive: can't use const as attribute value
Labels: A-attributes,A-macros,T-compiler,C-bug,A-proc-macros

I'm using serde to implement deserialization for a custom protocol. To keep the code dry, I've pulled all relevant strings into constants, but that creates a problem when trying to use the constants as attributes values in serde's derive macro.

Here's a playground with a minimal example to reproduce the problem: http://play.rust-lang.org/?gist=47230ae9671b24b312bef9540e520ddf&version=stable&mode=debug&edition=2015

The check that seems to produce the error is part of `libsyntax`: https://github.com/rust-lang/rust/blob/0db03e635a5e38ebc7635637b870b8fbcc8a7e46/src/libsyntax/parse/attr.rs#L261-L263

With my very basic knowledge of the rust compiler, I can see two potential ways this could be made possible:

1) Run derive macros after the constants have been expanded. This would be transparent to the macros (they could treat the expanded constants as literals), however this might be a no-go due to the way that the passes are ordered within rustc?

2) Relax the check in `libsyntax` (and possibly other places) to allow for identifiers to be valid attribute values on the syntax level, so that custom derive macros could use the identifier as part of their code gen (this wouldn't work for all macros, but at least for serde it looks like it'd be good enough).

If possible, could you give an indication as to whether this is something that you'd like in the compiler (in which case I'd be interested in working on a PR or RFC for it), or whether you think this is either impossible or undesirable for any reason?
Repository: rust
Issue: Default impls cannot take into account associated types
Labels: T-lang,A-specialization,C-bug,F-specialization

Suppose I have some trait with a default method:
```rust
trait Foo {
  fn bar(&self, isize) { .. }
}
```
and I want to add an associated type:
```rust
trait Foo {
  type Baz = isize;
  fn bar(&self, Self::Baz);
}
```
This is a breaking change unless I move the old default method to a new `default impl`. But there is no way to condition the `default impl` on choice the choice of associated type. For example:
```rust
default impl<A: Foo<Baz = isize>> Foo for A {
  fn bar(&self, isize) { .. }
}
```
is prohibited, and both 
```rust
default impl<A> Foo for A {
  type Baz = isize;
  fn bar(&self, Self::Baz);
}
```
and
```rust
default impl<A> Foo for A {
  default type Baz = isize;
  fn bar(&self, Self::Baz);
}
```
do the wrong thing.
Repository: TypeScript
Issue: Duplicated synthetic comment emit on module declarations
Labels: Bug

**TypeScript Version:**  master as of 2018-07-12

**Search Terms:** module enum declaration synthetic comment

**Code**

As a patch for `unittests/transform.ts`:

```ts
diff --git a/src/testRunner/unittests/transform.ts b/src/testRunner/unittests/transform.ts
index 6c74c558b1..a39522b204 100644
--- a/src/testRunner/unittests/transform.ts
+++ b/src/testRunner/unittests/transform.ts
@@ -296,6 +296,36 @@ namespace ts {
                 }
             }
         });
+^M
+        testBaseline("transformAddCommentToModule", () => {^M
+            return transpileModule(`// Comment on module^M
+module TestModule {^M
+    export const x = 1;^M
+}^M
+`, {^M
+                transformers: {^M
+                    before: [addSyntheticComment],^M
+                },^M
+                compilerOptions: {^M
+                    target: ScriptTarget.ES5,^M
+                    newLine: NewLineKind.CarriageReturnLineFeed,^M
+                }^M
+            }).outputText;^M
+^M
+            function addSyntheticComment(context: TransformationContext) {^M
+                return (sourceFile: SourceFile): SourceFile => {^M
+                    return visitNode(sourceFile, rootTransform, isSourceFile);^M
+                };^M
+                function rootTransform<T extends Node>(node: T): VisitResult<T> {^M
+                    if (isModuleDeclaration(node)) {^M
+                        setEmitFlags(node, EmitFlags.NoLeadingComments);^M
+                        setSyntheticLeadingComments(node, [{ kind: SyntaxKind.SingleLineCommentTrivia, text: " comment!", pos: -1, end: -1, hasTrailingNewLine: true }]);^M
+                        return node;^M
+                    }^M
+                    return visitEachChild(node, rootTransform, context);^M
+                }^M
+            }^M
+        });^M
     });
 }

diff --git a/tests/baselines/reference/transformApi/transformsCorrectly.transformAddCommentToModule.js b/tests/baselines/reference/transformApi/transformsCorrectly.transformAddCommentToModule.js
new file mode 100644
index 0000000000..11e988f96e
--- /dev/null
+++ b/tests/baselines/reference/transformApi/transformsCorrectly.transformAddCommentToModule.js
@@ -0,0 +1,6 @@
+// Comment on module^M
+var TestModule;^M
+// comment!^M
+(function (TestModule) {^M
+    TestModule.x = 1;^M
+})(TestModule || (TestModule = {}));^M
```

**Expected behavior:**

See above, `// comment!` should be emitted once, either on the `var ...` line, or on the immediately invoked function expression.

**Actual behavior:**

`// comment!` gets emitted on both:

```
// Comment on module^M
// comment!^M
var TestModule;^M
// comment!^M
(function (TestModule) {^M
    TestModule.x = 1;^M
})(TestModule || (TestModule = {}));^M
```

From the code, I suspect the same happens for `enum`s.

**Related Issues:**

This is somewhat similar to #17594, but effectively the opposite: because two nodes as marked as the original node for the module declaration, synthetic comments get emitted twice.
Repository: react
Issue: Investigate IE/Edge select rendering bug
Labels: Browser: IE,Component: DOM,Type: Needs Investigation

This is a follow up from an issue related to change events on selects in IE/Edge (https://github.com/facebook/react/issues/4672). It looks like this is no longer an issue, but there's a visual regression on IE/Edge that might be avoidable.

**Reproduction**

https://codepen.io/nhunzaker/pen/qybxmz

**Observation**

From @jasonwilliams (https://github.com/facebook/react/issues/4672#issuecomment-404534681):

> change and MouseUp both fire for me in Microsoft Edge 42.17134.1.0 @nhunzaker
Although, the rendering of the select box is weird, it doesn't appear to expand when i click on it

**We need to:**

- [ ] Capture a GIF of the behavior for documentation purposes (this can just live in this thread)
- [ ] Reproduce the test case outside of React, so that we can isolate the mechanics involved
- [ ] Fix it :)
Repository: rust
Issue: Weird span for `#[bench]` method error
Labels: C-enhancement,A-diagnostics,T-compiler

Given
```
#[bench]
fn bar(x: isize) { }
```
The current output is suboptimal:
```
error[E0308]: mismatched types
  --> $DIR/issue-12997-2.rs:16:1
   |
LL | fn bar(x: isize) { }
   | ^^^^^^^^^^^^^^^^^^^^ expected isize, found mutable reference
   |
   = note: expected type `isize`
found type `&mut __test::test::Bencher`
```
Repository: pytorch
Issue: Windows CPU version much slower than Unix versions
Labels: module: windows,triaged

Actually, this was first detected when we tried to build 0.4 packages and do some benchmarking. At first, I thought the reason may be that `OpenMP` is not well supported. But recently, when I managed to build PyTorch CPU version with Intel C++ Compiler, it was still much slower in some of the complex networks like SqueezeNet and MobileNet. So I tried to use `Intel Advisor` to locate the problems. And here is the screenshot: (I tried to get the log but it keeps crashing...)
![image](https://user-images.githubusercontent.com/9998726/42740291-19d4b278-88d8-11e8-8af8-047519399392.png)
It actually detected the potential problems for us. But I just don't know whether these loops should be vectorized or remain the scalar version. @cpuhrsch , may be you can shed some light for me?
Repository: vue
Issue: When a getter is defined that does not define a setter, no recursive reactive is made.
Labels: has workaround

### Version
2.5.17-beta.0

### Reproduction link
[https://jsfiddle.net/ts0307/pd8zr3sk/](https://jsfiddle.net/ts0307/pd8zr3sk/)

### Steps to reproduce
Run JSFiddle snippet

### What is expected?
I expect, the result is shown as {"bar": "b"} instead of {"bar": "a"}

### What is actually happening?
  if ((!getter || setter) && arguments.length === 2) {
    val = obj[key]
  }

  let childOb = !shallow && observe(val)

My example is that the data object defines that the getter does not define a setter, causing the above judgment to fail, val is not evaluated, and no recursive reactive is made.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: kubernetes
Issue: Prevent mass livenessProbe failures from taking down all pods in a Deployment
Labels: sig/scheduling,sig/node,kind/feature,sig/apps,lifecycle/frozen

> /kind feature

**What happened**:

A livenessProbe failed across all pods in a deployment, which took the application down. Given it affected all pods, it would have been better in this instance for the application to continue in a degraded state versus being hard down. However, if this type of failure happened only on a subset of pods, then having the pods restart would have been the right behavior.

Because of this behavior, it is tricky to strike the right balance between an agressive livenessProbe that detects and (effectively) remediates unhealthy pods and one that is safe enough to not take a whole deployment down.

**What you expected to happen**:

Thinking out loud, one way Kubernetes could stop this type of cascading failure is by honoring the "maxUnavailable" of the PodDisruptionBudge and stoping further livenessProbe actions once the constraint is violated (and we could alert when a deployment gets into this state).

At the very least,  the "Configure Liveness and Readiness Probes" documentation should be updated to highlight this edge case since it can cause a catastrophic failure. 

**How to reproduce it (as minimally and precisely as possible)**:

Create a scenario that causes the liveness check to fail on all pods of a deployment at once.

**Environment**:
- Kubernetes version (use `kubectl version`): 1.9.4
- Cloud provider or hardware configuration: on-prem
- OS (e.g. from /etc/os-release): RHEL 7
Repository: rust
Issue: better error message for wrong lifetime annotations?
Labels: C-enhancement,A-diagnostics,A-parser,T-compiler,A-suggestion-diagnostics

This was my code
````rust
pub(crate) fn parse_rev<'a>(repo: &<'a>Repository, rev_raw: &str) -> Revspec<'a> { ... }
````

Obviously this should have been
````rust
pub(crate) fn parse_rev<'a>(repo: &'a Repository, rev_raw: &str) -> Revspec<'a> { ... }
````
(````<'a>````  =>  ````'a````)
but the error message had me thinking that something was wrong with the argument itself which was confusing

````
error: expected type, found `'a`
  --> src/git.rs:26:37
   |
26 | pub(crate) fn parse_rev<'a>(repo: &<'a>Repository, rev_raw: &str) -> Revspec<'a> {
   |                                     ^^
error[E0425]: cannot find value `repo` in this scope
  --> src/git.rs:29:21
   |
29 |     let obj = match repo.revparse(rev_raw) {
   |                     ^^^^ not found in this scope

````

It would be awesome if rustc could suggest ````'a```` instead of ````<'a>```` here instead of telling that the something with the repo is missing in the function arguments.
It's already pointing to the right place in the first message but maybe there's a way to improve this even further =)

rustc 1.29.0-nightly (31f1bc7b4 2018-07-15)
Repository: opencv
Issue: Opencv system crash  with Java program in Mat.n_delete() w/ libc
Labels: priority: low,category: java bindings,incomplete,needs investigation

[hs_err_pid20872.log](https://github.com/opencv/opencv/files/2197931/hs_err_pid20872.log)
##### System information (version)
OpenCV => 3.4
Operating System/Platform => Ubuntu 16.04 64-bit
Complier => OpenCV built with GNU 5.4.0 and Java 1.8.0.171

##### Detailed description

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007f540e0eaef2, pid=15373, tid=0x00007f53d584d700

JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 1.8.0_171-b11)
Java VM: Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode linux-amd64 compressed oops)
Problematic frame:
C  [libc.so.6+0x7fef2]

Core dump written. Default location: /media/projects/obstruction/core or core.15373

An error report file with more information is saved as:
 media/projects/obstruction/hs_err_pid15373.log
Compiled method (nm) 2719603 1397     n 0       org.opencv.core.Mat::n_delete (native)
 total in heap  [0x00007f53f942bcd0,0x00007f53f942c018] = 840
 relocation     [0x00007f53f942bdf8,0x00007f53f942be40] = 72
 main code      [0x00007f53f942be40,0x00007f53f942c010] = 464
 oops           [0x00007f53f942c010,0x00007f53f942c018] = 8

If you would like to submit a bug report, please visit:
   http://bugreport.java.com/bugreport/crash.jsp
 The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.


Java program performing a number of different imaging operations with Mat data structures core dumps in Finalizer at org.opencv.core.Mat.n_delete()

Crashes at different spots in the Java code, seems to be timing dependent. 

##### Steps to reproduce
You would need to set up the code at https://github.com/mrobbeloth-wright-state/obstruction .
I'll attach the core dump file, it may be easier to debug using that.
Repository: opencv
Issue: Rect_<Tp> operator & return wrong result
Labels: bug,priority: low,category: core

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 
- Operating System / Platform => 
- Compiler => 
-->

- OpenCV => 3.2
- Operating System / Platform => Ubuntu 16.04.10
- Compiler => g++ 5.4.0

##### Detailed description

Rect_<_Tp> operator & (const Rect_<_Tp>& a, const Rect_<_Tp>& b)
returns a wrong result for `Rect_<unsigned>, Rect_<unsigned long>`.
For example, the intersection of x=0,y=0,w=1,h=1 and 2,2,1,1 should be zero, but I get 1. The intersection variable gets a very large width and height: 4294967295 for both. 

##### Steps to reproduce

	cv::Rect_<unsigned> r1(0,0,1,1);
	cv::Rect_<unsigned> r2(2,2,1,1);
	auto intersection = r1 & r2;
	auto area = intersection.area();
Repository: go
Issue: runtime/race: complete race detector on netbsd/amd64 
Labels: help wanted,OS-NetBSD,NeedsFix,compiler/runtime

The new netbsd/amd64 race detector support is not 100% done yet, per https://github.com/golang/go/issues/19273#issuecomment-349474852

We also don't have a builder for it.

This is a tracking bug to see it completed.

/cc @krytarowski
Repository: godot
Issue: AudioEffectPitchShift deteriorates sample quality "without being used"
Labels: bug,confirmed,topic:audio

Godot 3.0.2 stable + Windows 10

Continuously playing the same sound through the "Effect" bus in this configuration:
![capture](https://user-images.githubusercontent.com/13801432/42777429-f9b534c2-8931-11e8-82af-afe4ae0d8348.PNG)
...results in the sample changing sound over time, without ever touching `pitch_scale`, i.e. it's always `= 1.0`.
Repository: go
Issue: gollvm: build fail on slackware 14.2 in tools/gollvm/libgo/runtime_sysinfo.go
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What operating system and processor architecture are you using (`go env`)?
x86_64, slackware 14.2

### What did you do?
In my build directory: `cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD="X86" -G "Unix Makefiles" ../llvm && make all -j4` but as far as I can tell, it just happens on my system regardless of other options when I build x86 (use gold linker, build with other targets, etc.)

### What did you expect to see?
Successful build.

### What did you see instead?
```
/[my-build-path]/tools/gollvm/libgo/runtime_sysinfo.go:5966:32: error: expected ')'
/[my-build-path]/tools/gollvm/libgo/runtime_sysinfo.go:5966:32: error: expected '='
/[my-build-path]/tools/gollvm/libgo/runtime_sysinfo.go:5966:32: error: expected ';' or newline after top level declaration
/[my-build-path]/tools/gollvm/libgo/runtime_sysinfo.go:5965:36: use of undefined type 'ext'
make[2]: *** [tools/gollvm/libgo/CMakeFiles/libgotool.dir/build.make:1737: tools/gollvm/libgo/.pic/runtime.o] Error 3
make[1]: *** [CMakeFiles/Makefile2:15851: tools/gollvm/libgo/CMakeFiles/libgotool.dir/all] Error 2
make: *** [Makefile:152: all] Error 2
```
Those lines in `runtime_sysinfo.go` contain:
```go
const ___glibc_clang_has_extension(ext) = 0
const ___glibc_clang_prereq(maj,min) = 0
```
A little investigation seemed to indicate these slipped through libgo/godumpspec/m{parser,tokenizer} because their bodies don't reference their parameters.

If I comment these lines out, and analogous lines in `/[my-build-path]/tools/gollvm/libgo/sysinfo.go` when building syscall, the build errors out while building libgo_shared because ld.gold can't find `__morestack`, `-lgcc`, `crt1.o`, etc. This part superficially has more in common with building gccgo. My binutils use gold, so even when I don't tell CMake to use gold, eventually it gets invoked. I am still investigating this latter part, but the above const/macro stuff seemed reportable.
Repository: rust
Issue: Rust docs should at least have the option of using sans-serif fonts
Labels: T-rustdoc,A-docs,C-feature-request

__Edit__: When I say "docs" I mean the standard library docs. The font in places like "The Book" is absolutely fine.

I'm sure I've seen this brought up in the issues before, but I don't seem to be able to find those issues anymore because I can't remember what I searched,  so I hope you don't mind me creating a new issue for this.

Currently the rust docs only really display all text in a serif style font, which is extremely difficult to read, especially when there are large sections of bold text.

I understand that this may be a deliberate design decision, but unfortunately it makes it hard for people like me (no disabilities, just bad eyesight) to read anything. In my case I don't care about the design, I just want to be able to read the text without straining my eyes.

If the docs can't be changed to a sans-serif font by default, then could an option at least be provided to change the font to a sans-serif one instead?

Even the default `font-family: sans-serif;` is fine. Anything but serif will do for me.

Currently when I open the docs I have to open the inspector in Chrome and apply `font-family: sans-serif;` to the entire site just to get anything done. This works but I shouldn't really have to do this in the first place.

A serif font is fine for short pieces of text, like titles for example, but for the main body of text I hope a sans-serif font option can be seriously considered.

I hope I'm not missing anything. If there's already an option to do this then please let me know.