sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: net: Don't unlink unix socket on server.close()
Labels: help wanted,net

* **Platform**: Linux

Right now before an unix socket is closed [its file is also unlinked by libuv](https://github.com/nodejs/node/blob/master/deps/uv/src/unix/pipe.c#L125). This behavior seems to go against the [current docs](https://nodejs.org/api/net.html#net_identifying_paths_for_ipc_connections), which explicitly mention that the socket would persist until unlinked (seems to imply this doesn't happen automatically).

This behavior has already been discussed multiple times in past, and every time the result
of the conversation appears to have been that it is a [bad](https://github.com/nodejs/node-v0.x-archive/issues/3686) [idea](https://github.com/nodejs/node-v0.x-archive/issues/3540).

Some problems this behavior causes:
- It makes restarts with little downtime very hard to implement, since normally
  you would unlink the old socket in your new process immediately before listening to your new one.
 However, if your old process calls ``server.close()`` afterwards, it will unlink your *new* socket. Bummer.
- A simple workaround would be *not* calling ``server.close()``, however now you lose the ability
  to wait for old connection to die before exiting, and also the ability to not accept new connections before
  you exit.

The best way to work around this problem I've found so far appears to be this ``safeListen``:

```js
// Edit: Replaced old workaround with a better one. Now we
// just rename the socket after creating it, so libuv can't know
// about the new path and thus can't unlink it.
const fs = require('fs');

function safeListen(httpServer, path, callback) {
    callback = callback || function(error) {
        if (error) {
            httpServer.emit('error', error);
        }
    };

    const tmpPath = path + '.' + process.pid + '.tmp';

    httpServer.listen(tmpPath, (error) => {
        if (error) {
            return callback(error);
        }
    
        fs.rename(tmpPath, path, (error) => {
            if (error) {
                httpServer.close(() => {});
                return callback(error);
            }

            callback(null, httpServer);
        });
    });
};
```
Repository: godot
Issue: Particles with "one shot" enabled gets "emitting" turned off 
Labels: enhancement,topic:editor,confirmed,topic:particles

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
[098c7ba4f9c49b472b9417819144378081996874](url)
(current master)

**Issue description:**
<!-- What happened, and what was expected. -->
When using the node Particles2D or Particles, and having both properties "Emitting" and "One Shot" enabled, if saving the configuration somehow (for instance by moving the focus away from the node), "Emitting" becomes false *in the editor*, and does not play when the game is run either. See also the GIF below:

![particles_emitting_one_shot_bug_2018-04-01_2](https://user-images.githubusercontent.com/26661991/38174695-a5f9cae0-35d1-11e8-9c12-083287cb5c1a.gif)

**Proposed fix**
I think the regression happened in https://github.com/godotengine/godot/commit/1f609b7a8221f623ae0c051cbaf44f955c8d97bb. I do not know what the purpose of that commit was; it seems a pure regression AFAICT. That said, I do not know Godot or its particle system very well, so this might be wrong. I have tested a simple reversion, and that seemed to work: In the editor, "emitting" was kept and not discarded, and "one shot" worked when running the game.
Repository: rust
Issue: Cryptic LTO-related error message when performing `include_bytes!` on large files
Labels: A-codegen,A-diagnostics,T-compiler,C-bug

When trying to include a large (> 500MiB) binary in a program, the compiler crashes with an error message relating to LTO (Link time optimization?)

I tried this code:

```rust
fn main() {
	// the file below was generated with
	// $ dd if=/dev/urandom of=output.dat  bs=1M  count=640
	let v = include_bytes!("../output.dat").to_vec();
    println!("{}", v.len());
}
```

I expected to see this happen: 
MWE to compile and run correctly with `cargo run --release`  and output `671088640`

Instead, this happened: 
Cargo emits error:
```
$ cargo run --release
   Compiling mwe v0.0.0 (file:///home/noxim/repos/mwe)
error: failed to prepare thin LTO context: Malformed block

error: aborting due to previous error

error: Could not compile `mwe`.
```

## Meta

Rustc:
```
rustc 1.25.0 (84203cac6 2018-03-25)
binary: rustc
commit-hash: 84203cac67e65ca8640b8392348411098c856985
commit-date: 2018-03-25
host: x86_64-unknown-linux-gnu
release: 1.25.0
LLVM version: 6.0
```

Backtrace and --verbose:
```
$ RUST_BACKTRACE=1 cargo run --release --verbose
   Compiling mwe v0.0.0 (file:///home/noxim/repos/mwe)
     Running `rustc --crate-name mwe src/main.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C metadata=b0f84b8595e7a39c -C extra-filename=-b0f84b8595e7a39c --out-dir /home/noxim/repos/mwe/target/release/deps -L dependency=/home/noxim/repos/mwe/target/release/deps`
error: failed to prepare thin LTO context: Malformed block

error: aborting due to previous error

error: Could not compile `mwe`.

Caused by:
  process didn't exit successfully: `rustc --crate-name mwe src/main.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C metadata=b0f84b8595e7a39c -C extra-filename=-b0f84b8595e7a39c --out-dir /home/noxim/repos/mwe/target/release/deps -L dependency=/home/noxim/repos/mwe/target/release/deps` (exit code: 101)
```
Repository: vue
Issue: Provide a way to define different name for prop attribute
Labels: feature request

### What problem does this feature solve?
In most of cases, it's not really comfortable to use `initialProp` as prop name, for example, or have `normalizedProp` inside a component, which takes some passed prop and transforms it. Code looks bloated and reminds more workaround than a good solution.

Having ability to change attribute name of prop would be great. Something like:
```javascript
rawProp: { attributeName: "prop" }
```

### What does the proposed API look like?
```html
<component size="md"> ... </component>
```
```javascript
computed: {
  size: {
    switch (this.rawSize) { ... } // returns something in case blocks
  }
},
props: {
  rawSize: {
    attributeName: "size",
    type: String
  }
}
```

Thus, using any of proposed solutions above, `this.size` inside component would return transformed value (for example, `h4` or just `4`).

I believe having this feature would be very awesome and help us to write cleaner code.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: youtube-dl
Issue: Add Support for https://login.gci.com/ Adobe SSO
Labels: account-needed

- [X] I've **verified** and **I assure** that I'm running youtube-dl **2018.03.26.1**

### Before submitting an *issue* make sure you have:
- [X] At least skimmed through the [README](https://github.com/rg3/youtube-dl/blob/master/README.md), **most notably** the [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [X] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
- [X] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

### What is the purpose of your *issue*?
- [ ] Bug report (encountered problems with youtube-dl)
- [ ] Site support request (request for adding support for a new site)
- [X] Feature request (request for a new functionality)
- [ ] Question
- [ ] Other

I would appreciate assistance in adding support for the cable provider "GCI". With paid cable services they offer access to various apps and content websites just like most other cable providers. 

Their page showing what a paid user can access can be found here:
https://www.gci.com/tv/tv-everywhere/now-available

I have my login that I can give out for testing. My account has full access to every cable service offered on their plan page above.

I can be reached at omg@orionsbelt.space

Thank you for your time.
Repository: rust
Issue: The NonZero types don't tell LLVM that they're non-zero on get
Labels: A-LLVM,I-slow,C-enhancement,A-codegen,T-compiler,WG-llvm,C-optimization

Repro: https://play.rust-lang.org/?gist=0981601dda9c5800e353e31b22682bb5&version=nightly&mode=release
```rust
pub fn foo(x: std::num::NonZeroU32) -> bool {
    x.get() != 0
}
```
Actual:
```llvm
  %0 = icmp ne i32 %x, 0
  ret i1 %0
```
Expected:
```llvm
  ret i1 true
```
cc https://github.com/rust-lang/rust/issues/49137
Repository: godot
Issue: Abrupt slide off on platform
Labels: enhancement,documentation,topic:physics

<!-- 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

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Ubuntu 17.10

**Issue description:**
<!-- What happened, and what was expected. -->
When using a kinematic body, when the body goes over the edge, instead of smoothly falling, it abruptly drops very quickly. This is unrelated to gravity, as changing the gravity constant has no effect. Also, when the character jumps, the gravity works as expected.

**Steps to reproduce:**
Have a platform with a collision box and a static body. Have a kinematic body, with a script for movement (using move_and_slide) and gravity, go over the edge of the platform.

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[Test.zip](https://github.com/godotengine/godot/files/1867081/Test.zip)
Repository: go
Issue: x/text: ianaindex returns no encoding for gb2312
Labels: NeedsFix

Using the `golang.org/x/text/encoding/ianaindex` package.

```
        encoding, err := ianaindex.MIME.Encoding("gb2312")
        fmt.Println(encoding, err) // prints <nil> <nil>
```

I believe it should be returning simplifiedchinese.HZBG2312.

cc @mpvl
Repository: go
Issue: cmd/compile: document emitptrargsmap onebitwalktype1 calls
Labels: Documentation,NeedsFix,compiler/runtime

Perhaps I'm missing something, but this sequence of calls in emitptrargsmap looks suspect:

```go
	if fn.IsMethod() {
		onebitwalktype1(fn.Type.Recvs(), 0, bv)
	}
	if fn.Type.NumParams() > 0 {
		onebitwalktype1(fn.Type.Params(), 0, bv)
	}
```

If I'm reading it correctly, this will overwrite the Recvs bitmap with the Params bitmap.

Also, after emitting that bitmap, we do:

```go
	if fn.Type.NumResults() > 0 {
		onebitwalktype1(fn.Type.Results(), 0, bv)
		off = dbvec(lsym, off, bv)
	}
```

But we don't clear bv first, so any set bits from recvs/params will still be set.

emitptrargsmap is only called from assembly functions, which are unlikely to have methods and which are often nosplit, which is possibly why this hasn't caused visible problems yet (?).

cc @mdempsky -- does this code look right to you, and if so, what am I missing?
Repository: rust
Issue: E0582 on valid HRTB code
Labels: A-lifetimes,A-trait-system,A-associated-items,T-lang,T-compiler,C-bug,T-types,A-higher-ranked

The compiler rejects this code with E0582.

```rs
trait MyTrait
{
    type T;
}

fn foo<T>(t: T)
   where for<'x> &'x T: IntoIterator, for<'x> <&'x T as IntoIterator>::Item: MyTrait<T = &'x i32>
{}
```

The code is obviously valid.
Repository: flutter
Issue: Get rid of frontend-server standalone executable, call frontend-server/compiler as in-process dart package directly.
Labels: team,tool,framework,c: proposal,P3,team-framework,triaged-framework

frontend-server was built to run as standalone executable because flutter tools and engine were running on different versions of dart sdk. Few months back the change was made to run flutter tools and engine on the same dart sdk. That means that there is no need to have frontend-server as standalone process, compiler can be invoked directly from flutter tools.
Repository: go
Issue: cmd/compile: eliminate empty switch cases
Labels: Performance,NeedsFix,compiler/runtime

```go
package p

var y int

func f(x int) {
	switch x {
	case 1:
	case 2:
		y = 1
	}
}
```

This compiles to:

```
"".f STEXT nosplit size=31 args=0x8 locals=0x0
	0x0000 00000 (x.go:5)	TEXT	"".f(SB), NOSPLIT, $0-8
	0x0000 00000 (x.go:5)	FUNCDATA	$0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0000 00000 (x.go:5)	FUNCDATA	$1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0000 00000 (x.go:5)	MOVQ	"".x+8(SP), AX
	0x0005 00005 (x.go:7)	CMPQ	AX, $1
	0x0009 00009 (x.go:7)	JNE	12
	0x000b 00011 (<unknown line number>)	RET
	0x000c 00012 (x.go:8)	CMPQ	AX, $2
	0x0010 00016 (x.go:8)	JNE	11
	0x0012 00018 (x.go:9)	MOVQ	$1, "".y(SB)
	0x001d 00029 (x.go:6)	JMP	11
```

Note that we're pointlessly testing whether x == 1 at 0x0005. We should be able to eliminate that test. Probably the easiest place is when lowering the switch statement; if there is no default case, then any cases with empty bodies can be removed. (Taking care to evaluate the case expressions if necessary, of course, and taking care with pointless fallthroughs from the previous case.) Another possibility, probably more powerful, is to detect the unnecessary branch somehow in SSA form.

This kind of code arises naturally when wanting to make it clear to the reader that a particular case has been considered by the code author. It also shows up in generated code.
Repository: neovim
Issue: Memory leak in shada_read_next_item / STRING_KEY
Labels: robustness

```
==13127==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 142 byte(s) in 3 object(s) allocated from:
    #0 0x558e911f89b1 in malloc (/home/user/.local/opt/neovim/bin/nvim+0x9909b1)
    #1 0x558e91c269b1 in try_malloc …/Vcs/neovim/build/../src/nvim/memory.c:87:15
    #2 0x558e91c26bc9 in xmalloc …/Vcs/neovim/build/../src/nvim/memory.c:121:15
    #3 0x558e91c271af in xmallocz …/Vcs/neovim/build/../src/nvim/memory.c:196:15
    #4 0x558e91c2732b in xmemdupz …/Vcs/neovim/build/../src/nvim/memory.c:214:17
    #5 0x558e922597c0 in shada_read_next_item …/Vcs/neovim/build/../src/nvim/shada.c:3787:9
    #6 0x558e9222365a in shada_read_when_writing …/Vcs/neovim/build/../src/nvim/shada.c:2150:22
    #7 0x558e921fbecb in shada_write …/Vcs/neovim/build/../src/nvim/shada.c:2904:39
    #8 0x558e921efaad in shada_write_file …/Vcs/neovim/build/../src/nvim/shada.c:3163:35
    #9 0x558e91b34cce in getout …/Vcs/neovim/build/../src/nvim/main.c:636:5
    #10 0x558e9187a6b8 in ex_quit …/Vcs/neovim/build/../src/nvim/ex_docmd.c:5998:7
    #11 0x558e918155c7 in do_one_cmd …/Vcs/neovim/build/../src/nvim/ex_docmd.c:2232:5
    #12 0x558e917f8b3a in do_cmdline …/Vcs/neovim/build/../src/nvim/ex_docmd.c:601:20
    #13 0x558e915258fa in call_user_func …/Vcs/neovim/build/../src/nvim/eval.c:21339:3
    #14 0x558e914f27ee in call_func …/Vcs/neovim/build/../src/nvim/eval.c:6366:11
    #15 0x558e91506d9c in get_func_tv …/Vcs/neovim/build/../src/nvim/eval.c:6128:11
    #16 0x558e914ffc37 in ex_call …/Vcs/neovim/build/../src/nvim/eval.c:2735:9
    #17 0x558e918155c7 in do_one_cmd …/Vcs/neovim/build/../src/nvim/ex_docmd.c:2232:5
    #18 0x558e917f8b3a in do_cmdline …/Vcs/neovim/build/../src/nvim/ex_docmd.c:601:20
    #19 0x558e91d753b4 in nv_colon …/Vcs/neovim/build/../src/nvim/normal.c:4558:18
    #20 0x558e91d602eb in normal_execute …/Vcs/neovim/build/../src/nvim/normal.c:1137:3
    #21 0x558e923adb6e in state_enter …/Vcs/neovim/build/../src/nvim/state.c:67:26
    #22 0x558e91d1f4e5 in normal_enter …/Vcs/neovim/build/../src/nvim/normal.c:467:3
    #23 0x558e91b219c9 in main …/Vcs/neovim/build/../src/nvim/main.c:567:3
    #24 0x7fa17dd90f49 in __libc_start_main (/usr/lib/libc.so.6+0x20f49)

SUMMARY: AddressSanitizer: 142 byte(s) leaked in 3 allocation(s).
```

Code: https://github.com/neovim/neovim/blob/60e96a45b4f41ff73ba59fec9c9bfa87195d1207/src/nvim/shada.c#L3787

```
NVIM v0.2.3-955-g60e96a45b
Build type: Debug
LuaJIT 2.0.5
Compilation: /usr/bin/clang -Wconversion -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I…/Vcs/neovim/build/config -I…/Vcs/neovim/src -I/usr/include -I…/Vcs/neovim/build/src/nvim/auto -I…/Vcs/neovim/build/include
Compiled by user@a.example.com

Features: +acl +iconv -jemalloc +tui 
```

/cc @ZyX-I
Repository: go
Issue: x/tools: document how golang.org is deployed
Labels: Documentation,NeedsInvestigation,Tools

Agniva de Sarker and I were trying to figure out how an error in a recent godoc commit made it to golang.org. This required reverse engineering the deployment procedure for golang.org.

The instructions for tip.golang.org are (fairly) clear - there's a `cmd/tip` binary in the x/tools project with several YAML config files in it. 

The instructions for golang.org deployment are less clear. Does it still involve the bash script in the x/tools repository? Which commit is used for deployment? To where is it deployed?
Repository: opencv
Issue: opencv_highgui  compiler error
Labels: bug,priority: low,category: build/install

<!--
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 => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => new
- Operating System / Platform => Windows10 64 Bit
- Compiler => Visual Studio 2015

##### Detailed description
Window_QT.cpp:
line 57:
  #ifdef HAVE_QT_OPENGL
      #if defined Q_WS_X11 /* Qt4 */ || defined Q_OS_LINUX /* Qt5 */
          #include <GL/glx.h>
      #endif
  #endif

HAVE_QT_OPENGL is effect, but Platform is Windows, so 
 #include <GL/glx.h> 
not contain.

line 3227:
void OpenGlViewPort::initializeGL()
{
    glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);
}

compiler error.
GL_PERSPECTIVE_CORRECTION_HINT is not define.
(I use QT5.10.1)


<!-- your description -->

##### Steps to reproduce

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
Repository: electron
Issue: Rename and deprecate focusOnWebView
Labels: enhancement :sparkles:

`focusOnWebView` is not accurately named as an API 😄 

Ref: https://github.com/electron/electron/pull/12507#issuecomment-378263960

Requires some review as to what to rename it to and potentially where to move it, in particular, the difference in its effect compared to [`mainWindow.focus()`](https://github.com/electron/electron/blob/200388ff96b577359da7a6b1957c6a9045218a52/atom/browser/native_window_views.cc#L364) and [`mainWindow.webContents.focus()`](https://github.com/electron/electron/blob/master/atom/browser/api/atom_api_web_contents.cc#L1521), both of which utilize a different code path to [`focusOnWebView()`](https://github.com/electron/electron/blob/200388ff96b577359da7a6b1957c6a9045218a52/atom/browser/api/atom_api_browser_window.cc#L813).

/cc @brenca
Repository: angular
Issue: Outer element animates on different timing curve from child
Labels: type: bug/fix,area: animations,freq2: medium,P4

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
<!-- Describe how the issue manifests. -->
I'm animating the height of an element inside a `height:auto` container, and the outer element lags visibly behind the child element.

## Expected behavior
<!-- Describe what the desired behavior would be. -->
In any given animation frame, the containing element's height should be determined by the height of its child.

## Minimal reproduction of the problem with instructions
<!--
For bug reports please provide the *STEPS TO REPRODUCE* and if possible a *MINIMAL DEMO* of the problem via
https://stackblitz.com or similar (you can use this template as a starting point: https://stackblitz.com/fork/angular-gitter).
-->
[Stackblitz](https://stackblitz.com/edit/angular-m8uezc) with exaggerated timing to emphasize the effect.

## Environment

<pre><code>
Angular version: 5.2.8, forked from current Stackblitz example project

Browser:
- [X] Chrome (desktop) version 65
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [X] Firefox version 59
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
</code></pre>
Repository: vscode
Issue: Ctrl+Alt+Down (selecting lines) and Alt+Up (moving them) moves only 1 line
Labels: feature-request,editor-multicursor,editor-contrib

<!-- Do you have a question? Please ask it on https://stackoverflow.com/questions/tagged/vscode. -->

<!-- Use Help > Report Issue to prefill these. -->
- VSCode Version: 1.22.0-ins
- OS Version: win7x64

![ctrl alt down](https://user-images.githubusercontent.com/24613274/38259340-6b4a1ac4-376d-11e8-8bec-71e042b44726.gif)
Repository: react
Issue: Provide a way to detect infinite component rendering recursion in development
Labels: Type: Feature Request

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**
- Feature (possibly bug?)

**What is the current behavior?**

I've been trying out the new Context API in my project and it's awesome. However, in my haste to start using it, I managed to stumble into a situation where every time I would try and render a certain component which was making use of a few different contexts, the app would completely freeze, and the only thing that would let me get out of this error state was to forcefully kill the process via the chrome task manager.

Nothing would be logged to the console, the app would just completely freeze, and when I opened up the task manager and saw the CPU spiked up every time i would go to this component, and the only way I could stop it was to crash the tab. 

I finally threw some `console` statements in and saw that it had just entered into an infinite loop between these providers. I managed to get the app to stop crashing, but I'm still unsure as to why exactly this was happening. I'm sure I was just using this API incorrectly somehow, but this was a very confusing problem to diagnose, and some error checking here would be incredibly useful

**What is the expected behavior?**

It would be very beneficial to have some sort of checks in place, similar to what happens with too many `setState` calls happening too closely when you call it from `componentDidUpdate`, for example. That way, instead of freezing everything up permanently, the app could at least crash and report some sort of information and help me realize where I'd gone wrong.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**
- React `16.3.0`
- Chrome `65.0.3325.181`