sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Enums and interfaces do not have definitions in quick info/tooltips
Labels: Suggestion,Help Wanted,Domain: Quick Info,Experience Enhancement

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

The issue might be related to [this one](https://github.com/Microsoft/TypeScript/issues/24409), but mine is not about version 3.0, and is not solely about imports.

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->
enum, description, definition, pop-up, tooltip, vs code, interface, suggestion

## Suggestion

<!-- A summary of what you'd like to see added or changed -->
Hovering over enums and interfaces, should show their definition, i.e. I have this enum (or an interface):
```
enum enumName {
    ONE = 1;
    TWO = 2;
    THREE = 3;
}
```

If I hover over this enum, wherever I use it (whether it is imported to another file or used locally where it is declared), I would like to see what this enum is all about (essentially what are the properties).

This is what I see right now when I hover over enums or interfaces:
![image](https://user-images.githubusercontent.com/23742868/43146584-303df7c0-8f6a-11e8-8e23-6ba8644428b4.png)
![image](https://user-images.githubusercontent.com/23742868/43146615-46645468-8f6a-11e8-8c05-5a5265b43162.png)

As a workaround, I currently need to add this type of JSDoc comments right above the enum declaration.

```
/** Props:
*    @param ONE 1;
*    @param TWO 2;
*    @param THREE 3;
*/
```

Which yields to:
![image](https://user-images.githubusercontent.com/23742868/43146843-883b7d08-8f6a-11e8-81a9-eb9b4bcfc1df.png)


## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->
This feature would save time & effort.
The shortcoming of the current approach is that either need to add `${2+numberOfEnumProperties} lines` of comments or go to the file, where enum is declared, locate the enum there and then familiarize myself with its properties.

## Examples

<!-- Show how this would be used and what the behavior would be -->
![image](https://user-images.githubusercontent.com/23742868/43147585-0e979642-8f6c-11e8-95c0-741794192d57.png)

## Checklist
I am not that experienced to be able to answer the questions below.
* [ ] This wouldn't be a breaking change in existing TypeScript / JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code
* [ ] This could be implemented without emitting different JS based on the types of the expressions
* [ ] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: rust
Issue: Macro checks thwart `unreachable_pub` lint
Labels: C-enhancement,A-lints,A-macros,T-compiler,A-suggestion-diagnostics,L-unreachable_pub,A-edition-2018

Recently we [landed a change](https://github.com/rust-lang/rust/pull/52467) which squashes all lints tied to foreign macros, but this can thwart lints like `unreachable_pub` in unusual fashions. The `unreachable_pub` lint can't be fixed unless *all* its warnings are fixed, which means the following examples fails to compile after being fixed:

```rust
// bar.rs
#![crate_type = "lib"]

#[macro_export]
macro_rules! a {
    (pub static ref $name:ident : $t:ty = $val:expr) => (
        pub struct $name { _wut: () }
        pub static $name: $t = $val;
    )
}
```

and then 

```rust
// foo.rs
#![crate_type = "lib"]
#![feature(rust_2018_preview)]
#![warn(rust_2018_idioms)]

#[macro_use]
#[allow(macro_use_extern_crate)]
extern crate bar;

mod m1 {
    pub struct Foo;
}

mod lookup {
    use crate::m1::Foo;

    a!(pub static ref F: Foo = Foo);
}

pub fn f() {
    drop(&lookup::F);
}
```

compiled with:

```
$ rustc +nightly bar.rs
$ rustc +nightly foo.rs -L .
warning: unreachable `pub` item
  --> foo.rs:10:5
   |
10 |     pub struct Foo;
   |     ---^^^^^^^^^^^^
   |     |
   |     help: consider restricting its visibility: `crate`
   |
note: lint level defined here
  --> foo.rs:3:9
   |
3  | #![warn(rust_2018_idioms)]
   |         ^^^^^^^^^^^^^^^^
   = note: #[warn(unreachable_pub)] implied by #[warn(rust_2018_idioms)]
   = help: or consider exporting it for use by other crates
```

but the corrected code doesn't compile!

This is a reuced example where `a!` is `lazy_static!`, but I believe the issue here is that the lints behind the `lazy_static!` invocation are being ignored which means that `Foo` *is* actually fully public (because `F` is) and the lint is no longer applicable as a result.

cc @Manishearth, @oli-obk
Repository: TypeScript
Issue: Improve errors for potential arrow functions
Labels: Bug,Help Wanted,Effort: Moderate,Domain: Error Messages

There are certain locations where arrow functions don't parse

```ts
var x = window.foo || () => {}
```

In these instances, it would be nice if users could get a better error message as to avoid issues like #25897.

Ideally this should not be an invasive change.

* The change should be limited in scope.
* The parser should continue erroring in those locations.
* The change must not introduce change how existing valid code is parsed.
Repository: flutter
Issue: Drawer width should vary based on device size
Labels: framework,f: material design,customer: mulligan (g3),c: proposal,P2,team-design,triaged-design

The drawer width is too narrow on the small iPhone screens (iPhone SE, 5, etc) and leaves only a narrow tap section on the right side of the screen to close. The user can still swipe to close but it may not be obvious to them, especially if they opened the menu by tapping instead of swiping.

The width is hardcoded at 304.0 right now https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/drawer.dart#L41

I found this TODO for the drawer
https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/drawer.dart#L28 

```
// TODO(eseidel): Draw width should vary based on device size:
// http://material.google.com/layout/structure.html#structure-side-nav

// Mobile:
// Width = Screen width − 56 dp
// Maximum width: 320dp
// Maximum width applies only when using a left nav. When using a right nav,
// the panel can cover the full width of the screen.

// Desktop/Tablet:
// Maximum width for a left nav is 400dp.
// The right nav can vary depending on content.
```
Repository: go
Issue: x/text: panic of index out of range in language.Matcher
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
go 1.9

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
amd64, darwin and linux.

### What did you do?

language.MustParse accepts "lang_ZZ", e.g. en_ZZ, es_ZZ, etc. and returns a valid tag.
but m.Match(such a language tag) triggers a panic of "index out of range" at this lookup table: https://github.com/golang/text/blob/master/language/tables.go#L50

Sample code to reproduce the issue:
```
package main

import (
	"fmt"
	"golang.org/x/text/language"
)

func main() {
	supportedLanguages := []language.Tag{
		language.English,
		language.Arabic,
		language.BritishEnglish,
		language.Spanish,
		language.French,
		language.Italian,
		language.Japanese,
		language.Korean,
		language.Portuguese,
		language.Russian,
		language.SimplifiedChinese,
		language.TraditionalChinese,
	}

	tl := language.MustParse("en_ZZ")
	fmt.Printf("target language: %v\n", tl)

	m := language.NewMatcher(supportedLanguages)
	_, idx, _ := m.Match(tl)

	fmt.Printf("index matched: %v\n", idx)
}
```

Output:
```
target language: en-ZZ
panic: runtime error: index out of range

goroutine 1 [running]:
golang.org/x/text/language.regionGroupDist(0x139005701650135, 0x1650139)
	/Users/yb/go_root/src/golang.org/x/text/language/match.go:677 +0x13d
golang.org/x/text/language.(*bestMatch).update(0xc42003fbf0, 0xc4200722d0, 0x1650139, 0x0, 0x0, 0x101650057)
	/Users/ybi/go_root/src/golang.org/x/text/language/match.go:622 +0x28d
golang.org/x/text/language.(*matcher).getBest(0xc420072270, 0xc42000adc0, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0)
	/Users/yb/go_root/src/golang.org/x/text/language/match.go:504 +0x4a0
golang.org/x/text/language.(*matcher).Match(0xc420072270, 0xc42000adc0, 0x1, 0x1, 0x0, 0x0, 0x1161220, 0xc420072270, 0x2d952e1a19cc2e08)
	/Users/yb/go_root/src/golang.org/x/text/language/match.go:83 +0xd4
main.main()
	/Users/yb/test.go:28 +0x4d5
exit status 2
```

### What did you expect to see?

either
(1) language.MustParse rejects "lang_ZZ" and throws an error;
or
(2) language.MustParse parses "lang_ZZ" to a tag of just "lang", similar to "lang_UND", e.g. language.MustParse of "en_ZZ" and "en" should return the *identical* result.
or
(3) language.Matcher supports ZZ country code and works properly. 

### What did you see instead?

language.MustParse accepts ZZ, but language.Matcher crashes on that.
Repository: go
Issue: cmd/vendor/github.com/google/pprof/internal/binutils: TestObjFile failure
Labels: help wanted,NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version go1.10.3 linux/amd64

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
bash-3.2$ ld --version
GNU ld (GNU Binutils) 2.22

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jhart/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jhart/go"
GORACE=""
GOROOT="/home/jhart/temp/temp/go"
GOTMPDIR=""
GOTOOLDIR="/home/jhart/temp/temp/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build636359804=/tmp/go-build -gno-record-gcc-switches"


### What did you do?
```
cd temp
tar xf go1.4-bootstrap-20171003.tar.gz
cd go/src
export CGO_ENABLED=0
su
cd /var
mkdir tmp
chmod go+w tmp
exit
./make.bash
### Installed Go for linux/amd64 in /home/jhart/temp/go
### Installed commands in /home/jhart/temp/go/bin
unset CGO_ENABLED
export GOROOT_BOOTSTRAP=/home/jhart/temp/go
cd ../../
mkdir temp
cd temp
git clone https://go.googlesource.com/go
cd go
git describe --tags # go1.11beta1-226-ge161b1e
git checkout go1.10.3
cd src
./all.bash
```

### What did you expect to see?
All tests should have been passed successfully

### What did you see instead?
```
ok      cmd/trace       0.028s                                                                                                                                                                                     
--- FAIL: TestObjFile (0.17s)                                                                                                                                                                                      
        binutils_test.go:237: SourceLine for main: expect [{main /tmp/hello.c 3}]; got [{main  0}]                                                                                                                 
FAIL                                                                                                                                                                                                               
FAIL    cmd/vendor/github.com/google/pprof/internal/binutils    0.371s                                                                                                                                             
```
Repository: godot
Issue: Export arrays in singleton end up shared if initialized to same value (fixed in `master`)
Labels: bug,topic:gdscript,confirmed

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

**Godot version:**
Godot v3.0.5.stable.official.6a88e22 win64

**OS/device including version:**
Windows 10 Pro v.1803 (on 2 different pc)

**Issue description:**
Loading values in a two-dimensional array has different results if the array is local or global.

On a new project, I added a script (g.gd) as autoload-singleton enabled with the following code:
extends Node
```gdscript
extends Node
export var gridTiles = []
export var gridStat = []
```
I create a new scene assigned as main scene on project setting, on the root node added a script with the following code:
```gdscript
extends Node
func _ready():
	var x
	var y
	var gridTiles = []
	var gridStat = []

	for y in range(3):
		gridTiles.append([])
		gridStat.append([])
		for x in range(4):
			gridTiles[y].append(null)
			gridStat[y].append(0)

	gridStat[0][0] = 1	
	print(gridStat)
	print(gridStat.size(), " x ", gridStat[0].size())
	print(gridTiles)
	print(gridTiles.size(), " x ", gridTiles[0].size())
	
	for y in range(3):
		g.gridTiles.append([])
		g.gridStat.append([])
		for x in range(4):
			g.gridTiles[y].append(null)
			g.gridStat[y].append(0)

	g.gridStat[0][0] = 2
	print(g.gridStat)
	print(g.gridStat.size(), " x ", g.gridStat[0].size())
	print(g.gridTiles)
	print(g.gridTiles.size(), " x ", g.gridTiles[0].size())
```
The resulting output is:
```
[[1, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]]
3 x 4
[[Null, Null, Null, Null], [Null, Null, Null, Null], [Null, Null, Null, Null]]
3 x 4
[[2, 0, Null, 0, Null, 0, Null, 0], [Null, 0, Null, 0, Null, 0, Null, 0], [Null, 0, Null, 0, Null, 0, Null, 0], [], [], []]
6 x 8
[[2, 0, Null, 0, Null, 0, Null, 0], [Null, 0, Null, 0, Null, 0, Null, 0], [Null, 0, Null, 0, Null, 0, Null, 0], [], [], []]
6 x 8
```
Is it a bug or my poor knowledge of gdscript (python)?
Thanks for the attention.
Repository: TypeScript
Issue: Special characters in 'enum' type will be compiled to unicode by default
Labels: Bug



<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.9.1

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** typescript unicode, typescript enum unicode

**Code**

```ts

export const TestObject = {
  WELCOME: '你好',
  TEST: 'тест',
}

export enum TestEnum {
  WELCOME = '你好',
  TEST = 'тест',
}

```

**Expected behavior:**
Fields in `TestObject` and `TestEnum` ought to be compiled to a consistent encoding format (utf8).

**Actual behavior:**
Special characters in `Object` were compiled to utf8 while those in `Enum` were compiled to unicode.

**Playground Link:** 
[Official Playground](https://www.typescriptlang.org/play/#src=%0D%0Aconst%20TestObject%20%3D%20%7B%0D%0A%20%20WELCOME%3A%20'%E4%BD%A0%E5%A5%BD'%2C%0D%0A%20%20TEST%3A%20'%D1%82%D0%B5%D1%81%D1%82'%2C%0D%0A%7D%0D%0A%0D%0Aenum%20TestEnum%20%7B%0D%0A%20%20WELCOME%20%3D%20'%E4%BD%A0%E5%A5%BD'%2C%0D%0A%20%20TEST%20%3D%20'%D1%82%D0%B5%D1%81%D1%82'%2C%0D%0A%7D%0D%0A)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
https://github.com/Microsoft/TypeScript/issues/10498
Repository: vscode
Issue: Allow syntax colouring in parameters for SignatureHelp
Labels: feature-request,editor-parameter-hints

There are a couple of issues that looked like they might cover this:

- https://github.com/Microsoft/vscode/issues/11877
- https://github.com/Microsoft/vscode/issues/26241

However as far as I can tell, it's not possible to get highlighting in the parameter names in the signature. I've tried various combinations of `string/MarkdownString` in the `documentation` properties with no luck. The string being rendered here is `SignatureInformation.label` which is only a `string`:

![screen shot 2018-07-25 at 12 15 50 pm](https://user-images.githubusercontent.com/1078012/43197858-7e408510-9004-11e8-996c-39e8e0bbdfed.png)

Here the main signature line in the tooltip is just all white. It would be much more readable if the types were coloured like they are in the editor.
Repository: opencv
Issue: Linker Error LNK2022 of dnn module in CLR project
Labels: 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)
- OpenCV => 3.4.2
- Operating System / Platform => Windows 7 64 Bit
- Compiler => Visual Studio 2015

##### Detailed description

 I am trying to use opencv dnn module in a project having common language runtime support (C++/CLI).  I get the following compile error when I want to load a network model stored in TensorFlow framework's format:
**error LNK2022: metadata operation failed (8013119F) : A TypeRef exists which should, but does not, have a corresponding TypeDef: (Impl): (0x0100001f).** 

##### Steps to reproduce
Loading the frozen graphs as follows in a CLR project produces the above mentioned compile error

cv::dnn::Net my_net;
my_net = cv::dnn::readNetFromTensorflow("frozen_inference_graph.pb", "Config.pbtxt");

but in the following case no error is produced. However in this case I do not have global access to my_net object.

cv::dnn::Net my_net = cv::dnn::readNetFromTensorflow("frozen_inference_graph.pb", "Config.pbtxt");
Repository: rust
Issue: Doc-tests are not ignored when no changes have been made
Labels: A-testsuite,C-enhancement,T-bootstrap,E-needs-investigation

Running the entire test suite will ignore most files after nothing relevant has been changed (e.g. another test), but doc-tests will be re-run each time. I tested this for stage 2 tests, but it seems likely it occurs for other stages too.
Repository: rust
Issue: {i386,x86_64}-apple-ios targets pass too many thousands of arguments to the linker
Labels: A-linkage,O-macos,O-ios,O-x86_64,T-compiler,C-bug,O-x86_32

To reproduce:

```sh
git clone https://github.com/rust-lang-nursery/packed_simd
cd packed_simd
# Get Rust target:
rustup target add x86_64-apple-ios
# Build cargo runner:
export RUSTFLAGS='-C link-args=-mios-simulator-version-min=7.0'
rustc ./ci/deploy_and_run_on_ios_simulator.rs -o ios_cargo_runner --verbose
export CARGO_TARGET_X86_64_APPLE_IOS_RUNNER=$(pwd)/ios_cargo_runner
# Build library:
cargo build --target=x86_64-apple-ios
# Build and run tests:
cargo test --target=x86_64-apple-ios
```

Produces this output (too long to put it here, gist: https://gist.github.com/gnzlbg/4ff458a32ebd56e4d8930aaf766178b4). Linking fails. This is rust-lang-nursery/packed_simd issue: https://github.com/rust-lang-nursery/packed_simd/issues/26

cc @michaelwoerister @alexcrichton this might be related to incremental compilation, I see a lot of rcgus.
Repository: TypeScript
Issue: Improve completions with --checkJs turned off
Labels: Suggestion,Domain: Completion Lists,Awaiting More Feedback

**TypeScript Version:**  3.1.0-dev.20180725

**Code**

```ts
/**
 * @typedef {object} I
 * @property {number} m
 */

/** @returns {I} */
function f() { return { x: 0 }; }
const x = f();
x.
```

**Expected behavior:**

Get completion for `m` only.

**Actual behavior:**

Get completions for `I`, `f`, and `x`. None of which are properties.
Repository: vscode
Issue: Show Opening Tag when Closing Tag Selected
Labels: feature-request,editor-bracket-matching

intelliJ / PHP Storm / etc. have this nifty little feature. When your cursor is at the end of a tag, if the opening tag is off the screen it will show it in a little floating window.

![Example of being able to see a line that is off the screen](https://user-images.githubusercontent.com/40297408/43215220-89fe0742-9009-11e8-841a-de5c054c9fd8.png)

This makes it incredibly easy to keep track of exactly which closing tag you're at, especially useful for when you have to work in heavily nested templates.
Repository: flutter
Issue: TextInputType.emailAddress should imply autoCorrect: false
Labels: a: text input,c: new feature,framework,a: fidelity,P2,team-framework,triaged-framework

## Steps to Reproduce

Create a textfield like this:

```dart
TextField(
  keyboardType: TextInputType.emailAddress
)
```

Run this on iOS. (I didn't check on Android yet.)

You get something like this: ` _______ `

Start typing an email address beginning with a well-known name.

` jim_______ `

Type ".", and notice that the name gets capitalized.

` Jim.______ `

For me, this was unexpected.

To get the behaviour I expected, that is an email address wouldn't autocorrect words, I had to additionally and explicitly do:

```dart
TextField(
  keyboardType: TextInputType.emailAddress,
  autocorrect: false
)
```

I don't think it ever makes sense to autoCorrect on an email field. So, I'm proposing that setting `keyboardType: TextInputType.emailAddress` should imply setting `autocorrect: false` unless `autocorrect` is explicitly set to `true`.


```
[✓] Flutter (Channel dev, v0.5.7, on Mac OS X 10.13.5 17F77, locale en-GB)
    • Flutter version 0.5.7 at /Users/steve/code/flutter
    • Framework revision 66091f9696 (2 weeks ago), 2018-07-09 12:52:41 -0700
    • Engine revision 6fe748490d
    • Dart version 2.0.0-dev.63.0.flutter-4c9689c1d2

[✓] Android toolchain - develop for Android devices (Android SDK 28.0.1)
    • Android SDK at /Users/steve/Library/Android/sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.1
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)
    • All Android licenses accepted.

[✓] iOS toolchain - develop for iOS devices (Xcode 9.4.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 9.4.1, Build version 9F2000
    • ios-deploy 1.9.2
    • CocoaPods version 1.5.3

[✓] Android Studio (version 3.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)

[✓] VS Code (version 1.25.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 2.16.0

[✓] Connected devices (1 available)
    • iPhone X • 9655AB90-1BE3-43D8-B65C-937C0D5F86E7 • ios • iOS 11.4 (simulator)

• No issues found!
```