sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react-native
Issue: Elevation does not animate when it is inside a view which animates its opacity (Android P)
Labels: Help Wanted :octocat:,Ran Commands,Issue: Author Provided Repro,Platform: Android,Bug

## Environment
```
  React Native Environment Info:
    System:
      OS: macOS 10.14.1
      CPU: x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
      Memory: 40.65 MB / 16.00 GB
      Shell: 5.6.2 - /usr/local/bin/zsh
    Binaries:
      Node: 10.11.0 - ~/.nvm/versions/node/v10.11.0/bin/node
      Yarn: 1.13.0 - ~/.nvm/versions/node/v10.11.0/bin/yarn
      npm: 6.5.0 - ~/.nvm/versions/node/v10.11.0/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3
      Android SDK:
        Build Tools: 23.0.1, 26.0.2, 26.0.3, 27.0.2, 27.0.3, 28.0.1, 28.0.2, 28.0.3
        API Levels: 22, 23, 24, 25, 26, 27, 28
    IDEs:
      Android Studio: 3.3 AI-182.5107.16.33.5199772
      Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.6.3 => 16.6.3
      react-native: 0.59.0 => 0.59.0
    npmGlobalPackages:
      react-native-cli: 2.0.1
```

## Description
What described in the title works in any Android but not on Android P. See the differences:

### Android P:
![androidp](https://user-images.githubusercontent.com/774577/51485870-6d2a3900-1d9f-11e9-908e-cf89d5b37adf.gif)

### Below Android P:
![notandroidp](https://user-images.githubusercontent.com/774577/51485873-70252980-1d9f-11e9-8469-271b43f87c8f.gif)

## Reproducible Demo
https://snack.expo.io/@satya164/elevation-issue---android-p

This can affect libraries like `react-navigation` when a new screen comes in animating its opacity. See https://github.com/react-navigation/react-navigation/issues/5535.

Can be found here also https://github.com/ferrannp/react-native-elevation-animation-android-pie with react-native 0.59.X.
Repository: go
Issue: cmd/vet: false positive printf detection for URL-encoded `/` (`%2F`) in string literal
Labels: NeedsDecision,Analysis

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?
<pre>
$ go version
go version go1.11 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/msl21dp/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/msl21dp/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/msl21dp/.gvm/gos/go1.11"
GOTMPDIR=""
GOTOOLDIR="/Users/msl21dp/.gvm/gos/go1.11/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/msl21dp/gomod/homedepot.com/vulcancore/go.mod"
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/4y/g8py5x0x0rx2qxlpxls23gnw0000gn/T/go-build585874623=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

### What did you do?
Using the logging library github.com/spf13/jwalterweatherman, I have this line in our logs:
```
logging.INFO.Println("Logs can be viewed at https://console.cloud.google.com/logs/viewer?project=redacted&logName=projects%2Fredacted%2Flogs%redacted")
```
This is supposed to print a URL to console that the user can click to go to the logs.  Since the URL includes a slash-separated string as a parameter, those slashes have to be URL-encoded, which for a forward slach is `%2F`.  

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->



### What did you expect to see?
No vet error


### What did you see instead?
vet fires an error:
```
Logger.Println call has possible formatting directive %2F
```

Normally this wouldn't be an issue, but as of Go 1.10, `go test` now runs `go vet` natively with a hardcoded list of checks, and the only option is to either convert this to a Printf and doubling the percent signs to escape them, or disable `go vet` during `go test`, neither of which is a fantastic solution.

### Recommendations / possible resolutions:
- Figure out how to filter out situations like this.  In this situation, the possible formatting directive is A) uppercase, and B) in a Print call with no arguments to take the place of that directive (which would mean I would have had to have improperly use a formatting directive in a non-`f` call _and_ neglected to include the value to replace it with in the formatted string).
- Allow specific tests to be disabled in the `go test` automatic run of `go vet`, possibly via a flag like `-vetflags="-printf=false"`.  This would also allow any of the other vet-specific flags to be passed down to it.
Repository: TypeScript
Issue: Intellisense should inherit documentation for Interfaces.
Labels: Suggestion,Experience Enhancement

When implementing an interface the intellisense feature is capable of detecting the description of the interface however it does not carry over any tags such as @param and @returns. 

Below is a picture of an example: 

![image](https://user-images.githubusercontent.com/11773232/51408711-abb8bd00-1b2d-11e9-94d9-0b58d6697b47.png)


You can see that the description is properly shown however the param and returns tag is not. 
What is expected: 

![image](https://user-images.githubusercontent.com/11773232/51408822-f6d2d000-1b2d-11e9-8bb9-522c6080aa57.png)
Repository: TypeScript
Issue: [TypeScript] [JSDoc] Placing documentation for function below a decorator of the function (as opposed to above it) fails to associate with the function
Labels: Bug,Domain: Signature Help

Issue Type: <b>Bug</b>

```
class Foo {

    @test
    /** I do not work  */
    public test1() {}

    /** I do work  */
    @test
    public test2() {}
}
```


VS Code version: Code 1.30.2 (61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8, 2019-01-07T22:54:13.295Z)
OS version: Windows_NT x64 10.0.17763

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Xeon(R) CPU E3-1505M v6 @ 3.00GHz (8 x 3000)|
|GPU Status|2d_canvas: enabled<br>checker_imaging: disabled_off<br>flash_3d: enabled<br>flash_stage3d: enabled<br>flash_stage3d_baseline: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>native_gpu_memory_buffers: disabled_software<br>rasterization: enabled<br>video_decode: enabled<br>video_encode: enabled<br>webgl: enabled<br>webgl2: enabled|
|Memory (System)|31.86GB (17.32GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|

</details><details><summary>Extensions (3)</summary>

Extension|Author (truncated)|Version
---|---|---
references-view|ms-|0.0.21
vscode-icons|rob|8.0.0
vscode-java-dependency|vsc|0.3.0


</details>
<!-- generated by issue reporter -->
Repository: go
Issue: runtime: expose morestack (or equivalent) to make calling into JIT'ed code easier (and less hacky)
Labels: NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.2 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

N/A

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jsonp/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jsonp/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build594946674=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### Context

Existing JITs (where the program generates machine code and then executes it on-the-fly) use a bunch of hacks to get it working from Go (without using cgo - the overhead from cgo kinda defeats the purpose of partially JIT'ing code). One of these hacks is ensuring there is enough stack space for the generated code. It would be nice for the runtime package to expose a method to ensure the stack has at least x bytes remaining for the duration of the current calling frame.

(The existing hacks for managing stack size are rather nasty, and they range from trying to allocate unnecessary slices to grow the stack, to searching ELF symbols to locate runtime.morestack).

There are other issues with calling into JITed code, including setting up the stack maps, ABI etc but those hacks are less subtle (and easier to test IMHO).

### Feature request

Create a `runtime.EnsureMinStack(bytes uint64)` method or similar, that would ensure the current frame has at least x bytes spare stack space (growing it if necessary).
Repository: deno
Issue: QUIC & HTTP/3 support
Labels: public API,suggestion,ext/fetch,ext/http

It would be nice if the Deno standard library had QUIC protocol support out-of-the-box, implemented in Rust underneath. QUIC will likely be the UDP-based alternative to TCP used as the foundation for the Internet Engineering Task Force (IETF)'s upcoming [HTTP3 spec](https://tools.ietf.org/html/draft-ietf-quic-http-17). Essentially QUIC is a more efficient implementation of the combined capabilities of TCP and TLS, and a less mature version of QUIC has been used by Google for years in requests from Chrome to its own webservers. Node.js has [an open issue](https://github.com/nodejs/node/issues/23064) for adding in QUIC support, but based on the discussion there I'm assuming that the priority is low for them. They may not understand the significance of adding support.
Repository: flutter
Issue: The Xcode build process in mac.dart needs tests
Labels: a: tests,platform-ios,tool,platform-mac,P3,team-ios,triaged-ios

See https://github.com/flutter/flutter/pull/26826

We need to test that method.  It may have been assumed that it was tested in devicelab tests that run `flutter build ios` and `flutter run` (for iOS), but those tests were somehow succeeding even though local runs of it failed.
Repository: kubernetes
Issue: Do not remount volume again after it is detached
Labels: kind/bug,sig/storage,lifecycle/frozen

This issue replaces https://github.com/kubernetes/kubernetes/issues/64474.

**What happened**:

Volume may be remounted after it is detached.

**What you expected to happen**:

Volume will not be remounted after it is detached.

**How to reproduce it (as minimally and precisely as possible)**:

See https://github.com/kubernetes/kubernetes/pull/64610.
Repository: go
Issue: cmd/go: 'go list' should not resolve or record modules that are not relevant to the requested output fields
Labels: NeedsDecision,GoCommand,modules

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +4b3f04c63b Thu Jan 10 18:15:48 2019 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rog/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/rog/src/go"
GOPROXY="http://localhost:3000"
GORACE=""
GOROOT="/home/rog/go"
GOTMPDIR=""
GOTOOLDIR="/home/rog/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/m/go.mod"
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-build480679307=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Here is a script that illustrates the issue (reproduce by saving contents to a file and running the testscript command on it (`go get github.com/rogpeppe/go-internal/cmd/testscript`)

	# Create the module and tidy it.
	go mod init m
	go mod tidy
	cmp go.mod go.mod-after-tidy
	
	# Run a `go list` command to list the parent of the used package.
	go list github.com/btcsuite/btcutil
	cmp go.mod go.mod-after-list
	
	# Running `go mod tidy` removes the new dependencies.
	go mod tidy
	cmp go.mod go.mod-after-tidy
	
	-- main.go --
	package main
	
	import _ "github.com/btcsuite/btcutil/base58"
	
	func main() {
	}
	-- go.mod-after-tidy --
	module m
	
	go 1.12
	
	require github.com/btcsuite/btcutil v0.0.0-20180706230648-ab6388e0c60a
	-- go.mod-after-list --
	module m
	
	go 1.12
	
	require (
		github.com/btcsuite/btcd v0.0.0-20190115013929-ed77733ec07d // indirect
		github.com/btcsuite/btcutil v0.0.0-20180706230648-ab6388e0c60a
		golang.org/x/crypto v0.0.0-20181203042331-505ab145d0a9 // indirect
	)

I would not expect `go list` to add dependencies that aren't actually used by the code to `go.mod`.
Repository: youtube-dl
Issue: Export CRID in 
Labels: request

- [x] I've **verified** and **I assure** that I'm running youtube-dl **2019.01.17**
- [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
- N/A Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

### What is the purpose of your *issue*?
- [x] Feature request (request for a new functionality)
---

The ARDBetaMediathek, encoded in its URI paths, encodes information about the CRID of the provided media item. For example, [Die Sendung mit der Maus](https://www.ardmediathek.de/ard/player/Y3JpZDovL3dkci5kZS9CZWl0cmFnLTI1MDYwOThjLTJjNjEtNDJiZS05Mjc4LWUwNWEyNjFhMmM2NA/die-sendung-vom-13-01-2019) contains `Y3JpZDovL3dkci5kZS9CZWl0cmFnLTI1MDYwOThjLTJjNjEtNDJiZS05Mjc4LWUwNWEyNjFhMmM2NA` in its path, which is base64-without-padding for `crid://wdr.de/Beitrag-2506098c-2c61-42be-9278-e05a261a2c64`.

The format of a CRID and its purpose are explained in [RFC4078](https://tools.ietf.org/html/rfc4078), and that those identifiers can be used to correlate downloaded episodes with other sources of information, eg. the [checkeins metadata on the same episode](https://www.checkeins.de/die-sendung-mit-der-maus-vom-20-01-2019-100~playerXml.xml?t=19-01-20-03-08).

Please consider exporting the CRID in a dedicated field in exported JSON files for backends on which that information is available (so far, I'm only aware of this on ARDBetaMediathek).
Repository: go
Issue: cmd/compile: unnecessary bounds check
Labels: Performance,help wanted,NeedsInvestigation

### What did you do?
I compiled the following program to see its assembly code: https://godbolt.org/z/OcRvPE

### What did you expect to see?
I expected the access to the slice to not be bounds checked

### What did you see instead?
A bounds check was generated by the Go compiler
Repository: vue
Issue: Function-type props broken in TypeScript
Labels: typescript

### Version
2.5.22

### Reproduction link
[https://jsfiddle.net/keegan_openbay/gehkx7pf/10/](https://jsfiddle.net/keegan_openbay/gehkx7pf/10/)  
[https://jsfiddle.net/keegan_openbay/018rs3ae/11/](https://jsfiddle.net/keegan_openbay/018rs3ae/11/)

(More explanation in the fiddle, but keep in mind that JSFiddle doesn't show TS errors)

### Steps to reproduce
1. Declare a prop of type `Function`, and with a default function that returns some value; e.g.,

```ts
// ...
  props: {
    fooFn: {
      type: Function,
      default: () => true,
    },
  },
// ...
```

2. Try to use that function elsewhere in your component options; e.g.,

```ts
// ...
  methods: {
    useFooFn(): void {
      const bar = this.fooFn();
      // ...
    },
  },
// ...
```

### What is expected?
```ts
type FooFn = typeof this.fooFn; // Function
this.fooFn(); // no errors
```

### What is actually happening?
```ts
type FooFn = typeof this.fooFn; // boolean | Function
this.fooFn();
// Cannot invoke an expression whose type lacks a call signature.
// Type 'boolean | Function' has no compatible call signatures.
```

---
Vue version: 2.5.22
TypeScript version: 3.0.3

tsconfig.json:

```json
{
  "compilerOptions": {
    "declaration": false,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "lib": ["es7", "dom"],
    "module": "es2015",
    "moduleResolution": "node",
    "sourceMap": true,
    "target": "es5",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "baseUrl": "./app/javascript",
    "noImplicitThis": true
  },
  "include": [
    "app/javascript/**/*.ts",
    "app/javascript/**/*.tsx",
    "app/javascript/**/*.vue"
  ],
  "exclude": [
    "**/*.spec.ts",
    "node_modules"
  ],
  "compileOnSave": false
}
```

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: go
Issue: cmd/cgo: _GoString_ is a reserved identifier
Labels: help wanted,NeedsFix,compiler/runtime

(Removing the template since this is not really a code bug or so.)

https://golang.org/cmd/cgo/#hdr-Go_references_to_C explains that there's a type `_GoString_`. However, that name is reserved (see https://en.cppreference.com/w/c/language/identifier#Reserved_identifiers), and using it is technically undefined behavior. I'd suggest renaming the type to just `GoString` in future versions, with the old name as undocumented and deprecated alias.
Repository: go
Issue: cmd/cgo: map sized integer types to C equivalents
Labels: help wanted,NeedsFix,compiler/runtime

(Removing the template since this is an enhancement proposal)

The type mappings at https://golang.org/cmd/cgo/#hdr-Go_references_to_C don't state which Go types the sized C integer types `int8_t` etc. are mapped to. In C, these types have the same requirements as the corresponding Go types: they are not allowed to have padding bits and have to use two's complement representation, see https://en.cppreference.com/w/c/types/integer. Therefore, these types are guaranteed to have the same domain and representation as the corresponding Go types. So I propose to always represent these types with each other and formally document that fact. It would reduce the need for casts and would make it more obvious that there's no chance of data loss.
Repository: TypeScript
Issue: type predicate-ness lost when using Function.prototype.bind
Labels: Suggestion,Help Wanted,Domain: lib.d.ts,Experience Enhancement

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.4 or @next as of 2019-01-22

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
const isArray: typeof Array.isArray = Array.isArray.bind(Array);
```

**Expected behavior:**
Compiles.

**Actual behavior:**

Error message:

```ts
error TS2322: Type '(arg: any) => boolean' is not assignable to type '(arg: any) => arg is any[]'.
  Signature '(arg: any): boolean' must be a type predicate.
```

What seems to be happening is that the type predicate-ness of Array.isArray is lost when .bind is used. I tested with a few type predicate functions, and always get the same error.


**Playground Link:** 

Not reproducible on playground, because it depends on a higher TS version.

[In the playground](https://www.typescriptlang.org/play/index.html#src=%0D%0Aconst%20isArray%20%3D%20Array.isArray.bind(Array)%3B%0D%0A%0D%0A%0D%0A%0D%0A), the type of the RHS is `any`, so there is no compilation error.

**Related Issues:**

- Typings for `Function.prototype.bind` were discussed in https://github.com/Microsoft/TypeScript/issues/212 but I couldn't find any mention of type predicates.

- [Discussion on StackOverflow](https://stackoverflow.com/questions/54316578/type-predicate-ness-lost-when-using-function-prototype-bind?noredirect=1#comment95453581_54316578)
Repository: TypeScript
Issue: tsserver signals TS7017 incorrectly when using a symbol-indexed property
Labels: Bug,Domain: TSServer

When declaring a symbol-indexed property on an existing interface, attempting to use it gives error TS7017 in VSCode. `tsc`, however, compiles it without complaint, implying a bug in `tsserver`.

**TypeScript Version:**  3.3.0-dev.20190119

**Search Terms:** TS7017 tsserver symbol property

**Code**

```ts
const additionalProp = Symbol();

interface Document {
	[additionalProp]?: number;
}

document[additionalProp] = 42; // TS7017 in tsserver/vscode (but not tsc)
console.log(document[additionalProp]); // same
```

**`tsconfig.json`:**

```json
{
"compilerOptions": {
	"strict": true,
	"charset": "UTF-8",
	"target": "es6",
	"module": "es6",
	"lib": ["es6", "dom"]
}
}
```

**Expected behavior:**

The above code does not have any error highlights.

**Actual behavior:**

There is an error highlight. The hover says: “Element implicitly has an 'any' type because 'Document' has no index signature. ts (7017)”

[**Playground Link**](https://www.typescriptlang.org/play/#src=const%20additionalProp%20%3D%20Symbol()%3B%0D%0A%0D%0Ainterface%20Document%20%7B%0D%0A%09%5BadditionalProp%5D%3F%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Adocument%5BadditionalProp%5D%20%3D%2042%3B%20%2F%2F%20TS7017%20in%20tsserver%20(but%20not%20tsc)%3A%20type%20'Document'%20has%20no%20index%20signature%0D%0Aconsole.log(document%5BadditionalProp%5D)%3B%0D%0A) — The Playground also shows the incorrect error highlight.

**Related Issues:** None, as far as I can tell.
Repository: godot
Issue: AnimationPlayer "Loop" property working sporadically
Labels: bug,topic:core,confirmed

**Godot version:**
3.1 beta 2


**OS/device including version:**
Windows 10


**Issue description:**
AnimationPlayer not respecting the "loop" setting. Plays animation only once. I've tried setting the loop property via code as well to no avail.


**Steps to reproduce:**
Setup an animation that is supposed to loop. Seems to work sporadically. Sometimes it will loop correctly, but most times it will not.

**Minimal reproduction project:**
I noticed it while going through this tutorial, so here's the project I've got so far.
[Zeldalike-Tutorial.zip](https://github.com/godotengine/godot/files/2785846/Zeldalike-Tutorial.zip)
Repository: go
Issue: x/text/language: matcher doesn't match en-SG exactly to en
Labels: NeedsInvestigation

#### What version of Go are you using (go version)?
`go version go1.11 darwin/amd64`

#### What operating system and processor architecture are you using (go env)?
amd64, macOS Sierra 10.12.6

#### What did you do?
```go
package main

import (
	"fmt"

	"golang.org/x/text/language"
)

func main() {
	preferredTags := []language.Tag{language.English, language.Malay}
	matcher := language.NewMatcher(preferredTags)

	locale := "en-SG;q=1.0, zh-Hant-HK;q=0.9, ms-SG;q=0.8, ja-SG;q=0.7, zh-Hans-SG;q=0.6, en-GB;q=0.5"
	tags, _, _ := language.ParseAcceptLanguage(locale)

	match, _, confidence := matcher.Match(tags...)
	fmt.Printf("Matched %v with confidence %v", match, confidence)
}
```

#### What did you expect to see?
```
Matched en with confidence Exact
```

#### What did you see instead?
```
Matched ms-u-rg-sgzzzz with confidence High
```

If you replace `en-SG` with `en-US` in the `locale` string, then it does indeed exactly match to `en` (`en-u-rg-uszzzz`)