sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Typescript Autocompletion Not Working For Function Overloads
Labels: Suggestion,Help Wanted,Experience Enhancement

_From @MartinLoeper on August 29, 2018 13:27_

<!-- Please search existing issues to avoid creating duplicates. --> 
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
- VSCode Version: 1.25.1 1dfc5e557209371715f655691b1235b6b26a06be x64
- OS Version: Linux version 4.15.0-32-generic Ubuntu

Steps to Reproduce:   
I provided a small example of the issue (see screenshot below).

1. Create a function with two overloads
2. Try to invoke this function
3. Once you typed in the first parameter, the IDE recognizes that it matches the first overload's signature.
However, the auto-completion suggest the literals for both overloads.

I expect the auto-completion to show "BW" and "BY" only!

![_005](https://user-images.githubusercontent.com/5209395/44790221-18dbae00-ab9f-11e8-8d80-2dca57cbd5a1.png)

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

The code:
```ts

export class MomentHolidayFactory {
    public a(input: Germany, second: GermanState): string;
    public a(input: Austria, second: AustrianState): string;

    public a(input: Country, second: State): string {
        return "test";
    }

    public holidays() {
        this.a("de", ""
    }
}

type Country = Germany & Austria;
type Germany = "de" | "De" | "DE" | "germany";
type Austria = "Au" | "au" | "AU" | "austria";

type State = GermanState & AustrianState;
type GermanState = "BW" | "BY";
type AustrianState = "Stmk" | "Vbg";
```


_Copied from original issue: Microsoft/vscode#57509_
Repository: vue
Issue: Style binding: implicitly assign 'px' as the default unit for numeric values for certain css properties
Labels: feature request,discussion

### What problem does this feature solve?
When assigning values to a CSS property via style binding like

````html
    <div class="d-inline-block" :style="{width : width}"></div>
````

or using the shorthand syntax...

````html
    <div class="d-inline-block" :style="{width}"></div>
````

this will actually not gonna work because we need to explicitly set the `unit`:

````html
    <div class="d-inline-block" :style="{width : width + 'px'}"></div>
````

or via interpolation...

````html
    <div class="d-inline-block" :style="{width : `${width}px`}"></div>
````

Now our code becomes more verbose. Combining all the number of occurrences of such binding, it's becoming ridiculous.

I'm not sure if currently there is an elegant solution for this, but if there is. It would be also good if it is referenced in in the [docs](https://vuejs.org/v2/guide/class-and-style.html).

In React, this is the default behavior. It will add 'px' if the `unit` is not specified.

### What does the proposed API look like?
For common css properties like `width` and `height`, having vue implicitly assign 'px' to the value it would definitely make our code much more cleaner.

This code...

````html
    <div class="d-inline-block" :style="{width}"></div>
````

will be interpreted as:

````html
    <div class="d-inline-block" :style="{width : width + 'px'}"></div>
````

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: go
Issue: syscall: misleading documentation for linux SysProcAttr.Pdeathsig
Labels: Documentation,help wanted,NeedsInvestigation,compiler/runtime

Currently, the [documentation](https://github.com/golang/go/blob/0e9f1de0b7c934d9061f05f4781994fbd3ebd301/src/syscall/exec_linux.go#L33) says:

> // Signal that the process will get when its parent dies (Linux only)

However, according to the [prctl man page](http://man7.org/linux/man-pages/man2/prctl.2.html):

> Warning: the "parent" in this case is considered to be the thread that created this process. In other words, the signal will be sent when that thread terminates (via, for example, pthread_exit(3)), rather than after all of the threads in the parent process terminate.

I got bit by this in a python program -- started a new program on one thread, and tried to wait for it on another thread, and the child process kept dying and it took awhile to figure out what was going on. While I haven't ran into it in go yet, because in go threads and goroutines aren't one to one, I imagine if one ran into this sort of bug it would only occur intermittently.

Thinking about it, it seems like a user might want to call [runtime.LockOSThread](https://golang.org/pkg/runtime/#LockOSThread) when using this?

It's not clear to me whether the docs should have a larger warning in them -- but I think at the minimum the documentation should be updated to say 'parent thread' or 'parent goroutine' instead of just 'parent'.
Repository: pytorch
Issue: How to simulate multi-node using single-node with 8 GPUs
Labels: caffe2

As title stated.
Repository: pytorch
Issue: How to re-shuffle lmdb per epoch in the caffe2 training process
Labels: caffe2

as title stated
Repository: vscode
Issue: Allow to set a file association for files with no extension
Labels: feature-request,workbench-editors,languages-guessing

```
{
	"files.associations": {
		"*": "mydefaulttype"
	}
}
```

This changes the file association for absolutely all files. Should be possible to set a file association only for files that have no extension. So it would match `somefilename` but not `somefilename.txt` and not even `.somefilename`.
Repository: vue
Issue: Key Event wrongly triggered for unknown Modifier/Alias/Keycode on every Key in Safari 9
Labels: improvement

### Version
2.5.17

### Reproduction link
[https://codepen.io/cb109/pen/xarvBZ](https://codepen.io/cb109/pen/xarvBZ)





### Steps to reproduce
Please open the codepen link in Safari 9 on iOS, which is where I observed the bug (works fine in Chrome 68 on Ubuntu 18).





### What is expected?
There are two inputs, the first working as expected, the second showing some weird behaviour:

The first textfield has a handler to fire only when pressing escape. Typing should work as expected, pressing escape while focused should clear the input.

The second textfield has a handler for an unknown key code by using an unknown key modifier alias. Typing should work the same as for the first input.

### What is actually happening?
Typing into the second input in Safari 9 on iOS it will always trigger the `@keyup` handler, thus clearing the input while typing. This feels wrong.

IMHO this should not happen. If a key modifier-alias/code is not recognized, it should not be triggered by any key.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: rustdoc: Improve the navigation experience
Labels: C-enhancement,A-rustdoc-ui,T-rustdoc-frontend

In the current situation, users navigates either with links from the overview, or by collapsing all descriptions and searching through what they want.

They both have their own problems:
![screenshot_2018-09-05 std option option - rust](https://user-images.githubusercontent.com/12389383/45089271-99be1b00-b146-11e8-9902-37a01fc9ca58.png)

And I often resort to "Find in page" which is bad on accuracy.

We need a better navigation system, and in either way we should ditch the collapse feature. I have two ways in mind:

- Use a right sidebar. Sidebar allows you to collapse things by group not per item. It also has a smaller font size, allowing more items to fit in the screen.
- Make the brief link to everything available in the page. Rust pseudocode is easier to read for some people (including me).

To compare these two approaches, sidebar is more suitable for continuously navigating items without caring the backstack, while the brief is more like "navigate, read, back, navigate, read, back".

Related: #39952
Repository: go
Issue: x/mobile/app: gobind crash 'app.Run called on thread xxx, but app.init ran on xx'
Labels: mobile

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

go version go1.11 darwin/amd64

### Does this issue reproduce with the latest release?

YES.

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN="/Users/ntop/tools/go"
GOCACHE="/Users/ntop/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/ntop/workspace/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/t6/8417qy4n2zn3lb370499nrl00000gn/T/go-build892512347=/tmp/go-build -gno-record-gcc-switches -fno-common"

### What did you do?

I'm building a Go game for iOS. I use GoMobile's `x/mobile/app` package to write the game, but I didn't use `gomobile build` to build an `.app`. Since `gomobile build` just build a simple iOS app, if I want to use more native features, that's impossible. So I use `gomobile bind` to build a `.framework`, and invoke the 'Start' function in XCode's `main` method. But it will result in the exception - 'gobind app.Run called on thread xxx, but app.init ran on xx'. In the 'Start' function, I did't use any go routines, just call `app.Main()` to start the game. I printed thread-id both in `init` function and the `app.Main()` function, the thread-id is truely different. It seems that the `.framework` built with gomobile will not init package in the same thread as the calling function. 

### What did you expect to see?

The `.framework` build with `gomobile bind` can work successfully in my iOS project.
PS:  only code use `x/mobile/app` will crash, because the checking code stay there.

### What did you see instead?

The app crashed and print the message as above.
Repository: flutter
Issue: Make CurveTween curve a regular parameter
Labels: c: new feature,framework,a: animation,c: API break,P3,team-framework,triaged-framework

Right now the `CurveTween` constructor looks like this:

```dart
  /// Creates a curve tween.
  ///
  /// The [curve] argument must not be null.
  CurveTween({ @required this.curve })
    : assert(curve != null);
```

Usage currently looks like this:
```dart
CurveTween(curve: Curves.easeInOut);
```

There is a single required parameter, and I think it's quite certain that a `CurveTween` needs a `Curve` to function.

I propose to make it a regular parameter to make usage easier and a bit more fail-safe:

```dart
CurveTween(Curves.easeInOut);
```

If this is approved by the Flutter team, I will create a PR.
Repository: react
Issue: Consider stopping auto-adding `px` to number style values (except for a small whitelist)
Labels: Component: DOM,Type: Discussion

<!--
  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*?**

A removal of a feature, in a sense.

**What is the current behavior?**

React automatically adds the `px` suffix for numerical values passed to the `style` prop. As some CSS properties accept unitless values, React maintains a blacklist of properties that shouldn't get `px` auto-appended.

The problem is that this solution doesn't scale. It requires us to add more & more properties to the list as CSS specs expand and recently the list grows faster; Flexbox & Grid added quite a few of them. What's more confusing, some of those props would work both with & without the `px` suffix and that changes the meaning (`lineHeight` is suffering from that).

Although I'm a React newbie I'm quite familiar with this issue due to being a member of the jQuery Core team. jQuery has the same logic as React here and we keep having to add to the list. We've actually exposed the list at [jQuery.cssNumber](https://api.jquery.com/jQuery.cssNumber/) so that people don't always have to wait for us to add support for a property and do a release.

That's why we decided that in jQuery 4 we'll drop the auto-prefixing blacklist and turn to a whitelist that lists only a few most common properties to which we want to auto-append `px` (mostly because they're extremely common and we don't want to break the world too much); we plan to _not_ expand that list unless we missed something really common. You can see the current plan in my PR: https://github.com/jquery/jquery/pull/4055. In particular, see the proposed whitelist in a (visualized) regexp in:
https://github.com/jquery/jquery/blob/03e9dba3882868e1ee79f1fb0504326da925644f/src/css/isAutoPx.js.

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

**What is the expected behavior?**

I propose that React could do the same thing jQuery is planning to and switch the ever-expanding blacklist of CSS props that shouldn't have the `px` suffix applied to a small whitelist that should have the suffix applied.

This topic has been initially described in #13550.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

All browses & OSs. I don't know how old this logic is in React.
Repository: TypeScript
Issue: JS should allow merging/expando properties on imports
Labels: Suggestion,In Discussion,Domain: JavaScript

```js
// Filename: mod.js
export const Ns = function () { }

// @Filename: use.js
import { Ns } from './mod'
Ns.expando = 1
```

**Expected behavior:**
No error, and Ns has property 'expando'

**Actual behavior:**
Error, 'expando' not found on 'Ns'.

This merge shouldn't be allowed in Typescript, but it will work in Javascript, so it should be allowed there.
Repository: TypeScript
Issue: Control flow analysis should "work" in unreachable code
Labels: Bug

**TypeScript Version:**  master

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** unreachable throw return narrowing

**Code**

```ts
function fn() {
    // TODO: Finish writing this function!
    return;

    const h = Math.random() > 0.5 ? 'h' : undefined;

    if (h) {
        // Error, wat
        const a: string = h;
    }
}
```

**Expected behavior:** No error

**Actual behavior:** Error - h is possibly undefined

We get "bug" reports like this every once in a while, and it's hard to understand why the narrowing just stops working because the code isn't reachable. This also makes it difficult to insert debugging throws/returns earlier in the function.

e.g. https://twitter.com/aendrew/status/1037301561062514688

**Playground Link:** http://www.typescriptlang.org/play/#src=function%20fn()%20%7B%0A%20%20%20%20%2F%2F%20Not%20done%20yet%0A%20%20%20%20return%3B%0A%0A%20%20%20%20const%20h%20%3D%20Math.random()%20%3E%200.5%20%3F%20'h'%20%3A%20undefined%3B%0A%20%20%20%20const%20d%20%3D%20(arg%3A%20string)%20%3D%3E%20arg%3B%0A%0A%20%20%20%20if%20(h)%20%7B%0A%20%20%20%20%20%20%20%20const%20a%20%3D%20d(h)%3B%0A%20%20%20%20%7D%0A%7D%0A

**Related Issues:** Believe there's one out there somewhere
Repository: TypeScript
Issue: Allow intersection type guards for multiple parameters
Labels: Suggestion,Awaiting More Feedback

## Search Terms

type guard multiple parameters
## Suggestion

I'd like to write a type guard that takes two parameters and changes the type of both of them.

## Use Cases

My specific use case is to try to make the following pattern (somewhat) more type-safe:

```ts
class Foo<TFeature, TOther> {
    // If featureCtor is null, TFeature will never be used.
    constructor(private readonly featureCtor: { new(): TFeature } | null) { }

    isFeature(thing: any): thing is TFeature {
        return !!this.featureCtor && thing instanceof this.featureCtor;
    }

    bar(thing: TFeature|TOther) {
        if (this.isFeature(thing)) {
            // Type guard should prove that this.featureCtor is not null
            new this.featureCtor();
        } else {
            // Type guard should prove this
            const x: TOther = thing;
        }
    }    
}
```

## Examples

    isFeature(thing: any, ctor: { new(): TFeature } | null): (thing is TFeature)&(ctor is { new(): TFeature }) {
        return !!this.featureCtor && thing instanceof this.featureCtor;
    }

It would be even nicer to allow type guards to operate on readonly fields, so I wouldn't need to pass `this.featureCtor` as a parameter.

I also tried

    constructor(private readonly featureCtor: TFeature extends never ? null : { new(): TFeature }) { }

But that didn't work.


## 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: noImplicitAny+prototype assignment causes incorrect error on prototype methods
Labels: Bug,Domain: JavaScript

Note that this is only true with noImplicitAny on. The bug does not manifest with it off.
This is a regression in 3.1. It does not manifest in 3.0.

```js
// @noImplicitAny: true
/** @constructor */
var Multimap = function() {
    this._map = {};
};

Multimap.prototype = {
  x() { }
}

Multimap.prototype.lol = function() {
}

var mm = new Multimap();
mm._map
mm.x
mm.lol
```

**Expected behavior:**
No error on `Multimap.prototype.lol`, and `_map`, `x` and `lol` are properties on Multimap.

**Actual behavior:**
Error: 'lol' does not exist on type '{ x(): void }'. But all 3 **are** properties on Multimap.
Repository: rust
Issue: Do not apply `#[macro_use]` to implicitly injected `extern crate std;`, use standard library prelude instead
Labels: A-resolve,T-libs-api

Macros like `vec` or `println` are currently automatically available to user code through injected standard library
```
#[macro_use]
extern crate std;
```
`#[macro_use]` puts all the macro names into macro prelude, so they are available in inner modules without additional imports.

It would be good to avoid this, especially given that `#[macro_use]` is going to be gradually deprecated.
We have analogous way to put things into prelude for non-macro namespaces - standard library prelude `std::prelude::v1`, all stable library macros can be reexported through it instead of `#[macro_use]` in backward-compatible way.
Undesirable unstable macros like `select` can be removed from prelude in the process.

The only issue is that several imports for several macros (`env`, `vec`, `panic`) would also import corresponding modules from the standard library (`std::env`, `std::vec`, `std::panic`) and put them into prelude. This is certainly not desirable.

The solution is to come up with some way for a `use` item to import the name only in the single selected namespace, something like
```rust
use a::b in type;
use a::b in macro;
use a::b in value;
```

Alternatively, this can be done with [hacks](https://github.com/rust-lang/rust/issues/36837) for cross-crate scenarios (stdlib prelude is indeed a cross-crate scenario).

(All of this is applicable to libcore as well.)
Repository: vscode
Issue: new settings UI: possible to undo a setting change?
Labels: feature-request,settings-editor,undo-redo

<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
when one accidentally clicked some where in the new settings UI, thus made an unexpected change, allow user to undo that change, by pressing ctrl-z or cmd-z
Repository: flutter
Issue: Adding some plugins to a Flutter module causes the whole app to fail to build
Labels: tool,t: gradle,P2,a: plugins,team-tool,triaged-tool

## Steps to Reproduce

1. Check out https://github.com/mjohnsullivan/dof
2. Build with Android Studio, see that everything runs as expected.
3. Edit flutter_dof/pubspec.yaml to add `fluwx: ^0.1.3` in the `dependencies` section.
4. run `flutter packages get` while standing in the flutter_dof directory.
5. Attempt to run the Android program in Android Studio. Cry. (Kidding. Actually you'll see `Error:Failed to notify project evaluation listener.`) 

Now, technically to *use* this plugin I need to make some changes to the build.gradle files and such. You can see those changes [here](https://github.com/efortuna/insta_flutter/commit/82f533177fa63e8e8fb1535a0ae2b44788aef06c) and [here](https://github.com/efortuna/insta_flutter/commit/0791817024dc70a3768c3aba3961887305f4c61d),
but that shouldn't matter. I think adding a dependency, regardless of whether it's used or not shouldn't prevent me from building the app. 

I suspect other plugins may cause this behavior, but I haven't tested others yet.

<!-- Finally, paste the output of running `flutter doctor -v` here. -->

```
[✓] Flutter (Channel master, v0.7.6-pre.56, on Linux, locale en_US.UTF-8)
    • Flutter version 0.7.6-pre.56 at /usr/local/google/home/efortuna/googleio/flutter
    • Framework revision 409baff3ac (4 hours ago), 2018-09-05 21:31:29 +0100
    • Engine revision de4c7a53f2
    • Dart version 2.1.0-dev.3.0.flutter-760a9690c2

[✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)
    • Android SDK at /usr/local/google/home/efortuna/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 27.0.3
    • Java binary at: /opt/android-studio-3.0/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)
    • All Android licenses accepted.

[✓] Android Studio (version 3.0)
    • Android Studio at /opt/android-studio-3.0
    • Flutter plugin version 23.2.1
    • Dart plugin version 171.4424
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)

[✓] IntelliJ IDEA Community Edition (version 2018.1)
    • IntelliJ at /opt/intellij-ce-2018.1
    • Flutter plugin version 27.0.2
    • Dart plugin version 181.4892.1

[✓] IntelliJ IDEA Community Edition (version 2017.3)
    • IntelliJ at /opt/intellij-ce-2017.3
    • Flutter plugin version 26.0.1
    • Dart plugin version 173.4700

[✓] VS Code (version 1.25.1)
    • VS Code at /usr/share/code
    • Flutter extension version 2.18.0

[✓] Connected devices (1 available)
    • Pixel 2 XL • 711KPAE0891080 • android-arm64 • Android 8.1.0 (API 27)

• No issues found!
```