sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/text/encoding: Go's reuse of character sets causes incorrect decoding of invalid input
Labels: NeedsInvestigation

<!-- 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 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?
amd64, linux

### What did you do?

1. Call charset.Lookup("us-ascii") to get an encoding
https://godoc.org/golang.org/x/net/html/charset#Lookup

e, _ := charset.Lookup("us-ascii")

2. Call encoding.NewDecoder().String(string([]byte{0x80})) and get the result

res, _ := e.NewDecoder().String(string([]byte{0x80}))

3. Print the result

### What did you expect to see?
I expect to see a � character, since the value is outside of the range of US-ASCII (most significant bit is 1)

### What did you see instead?
I will see the character € from the Windows 1252 encoding instead. This is caused because go is re-using Windows 1252 for US-ASCII. Similar issues arise for out of bounds characters in other charactersets, for example tis-620 maps to windows874. Now if I want to correctly parse the text I need to read through the decoded runes and test if any of them are out of bounds. If I want to use windows874 for just tis-620 characters, I would have to do a similar manual exclusion of out of bounds characters. I do not know of a way to create my own characterset so that these problems can be avoided.
Repository: godot
Issue: External text editor does not open unless Godot quits
Labels: bug,topic:core,confirmed

<!-- 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.2 branch at commit 68013d23932688e57b489600f4517dd280edc464

**OS/device including version:**
<!-- Specify GPU model and drivers if graphics-related. -->
Arch Linux x86_64 - gcc (GCC) 8.2.1 20181127


**Issue description:**
<!-- What happened, and what was expected. -->
After trying to run the Finite State Machine example in the demos, which currently has faulty GDScript code, I expected my external editor to run but this was not the case. I placed some debugging code in `OS_Unix::execute` and turns out that the `execvp` attempt is actually another command:

```
Attempting to execute: /opt/godot/bin/godot.x11.opt.tools.64 --path /home/wilson/gitrepos/godot-demo-projects/2d/finite_state_machine --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 1863 --position 320,180 (null)
```

For some reason, whether the project was not stopped (i.e. if F8 is not pressed) or not, and Godot quits, the next time Godot opens, it attempts to run my external editor:

```
Attempting to execute: xterm -bg black -fg white -sl 100000 -e vim +"call cursor(0, 0) /home/wilson/gitrepos/godot-demo-projects/2d/finite_state_machine/player/weapon/sword.gd (null)
```

For some reason I also had to escape that `+` symbol with a backslash `\` in the argument list within the editor.

For what is worth, here's the code I placed right before the `execvp` call in `OS_Unix::execute`:

```cpp
		fprintf(stderr, "Attempting to execute:");
		for (int i = 0; i < args.size(); i++)
			fprintf(stderr, " %s", args[i]);
		fprintf(stderr, "\n");
```


**Steps to reproduce:**
- Change external editor after opening project using `godot -e` from within the project path
- Attempt to run Finite State Machine from the [official demos](https://github.com/godotengine/godot-demo-projects/tree/master/2d/finite_state_machine) (press F5), if the scene runs fine, place some faulty GDScript code.
- When the faulty GDScript code is detected, the external editor should have opened at the offending line but it doesn't.
- Close Godot
- Reopen the project and attempt to run Finite State Machine demo again after opening project using `godot -e` from within the project path, the external editor still doesn't open after detecting the faulty GDScript code.

**Minimal reproduction project:**
See the Finite State Machine example in the `godot-demo-repository` repository at commit eb27a35a2d5212abfc516aa3c8fcb76c907155f0
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
Repository: vscode
Issue: Scroll bar visibility should be configurable
Labels: feature-request,workbench-os-integration

### VSCode Version

![vs code version](https://user-images.githubusercontent.com/9283914/50669766-7194da80-0fc7-11e9-929a-6181fcc45f62.png)

### Steps to Reproduce

1. Open Visual Studio code and open a large text file

### Current Behaviour

In Visual Studio Code, editors' scroll bars auto hide, thereby thwarting targeting the scroll bar handle when moving the mouse.

### Expected Behaviour

Visual Studio Code should follow the Windows system setting `Settings > Ease of Access > Display > Automatically hide scrollbar in Windows`

![scrollbar-always-visible-windows10](https://user-images.githubusercontent.com/9283914/50670087-6b9ff900-0fc9-11e9-91ac-b2d1e032ddfe.jpg)

### Does this issue occur when all extensions are disabled?
- [x] Yes
- [ ] No
Repository: vscode
Issue: Intellisense's 'Suggest selection' should keep working when you have typed something
Labels: feature-request,suggest,under-discussion

VSCode has a feature that remembers recent completions the user has selected and then automatically choosen those completions for them the next time. 
The problem is that it behaves quite oddly, and here is an example that illustrates why:

- Create a new Typescript file.
- Type `console.` vscode will suggest all of the available methods of `console`.
 - Choose `exception`.
- Type `console.` again. Vscode will immediately suggest `exception`, as expected.
And now here is the weird part: Type `e`, and instead of still suggesting `exception`, it will suggest `error`!

The problem here is that once you type anything after the suggestion came, vscode will completely disregard your completion history and will just give you the best match lexicographically. Even if in the example you have completed `exception` by typing an `e` and then having it complete it, the same thing will occur.
My suggestion is that when you have already typed something, the 'suggest selection' will just be filtered by what you have typed, instead of stop working. So in the example, after you have typed `e`, it will still suggest `exception`.

_"Switch the Suggest Selection settings to "recentlyUsedByPrefix" and it will work!"_
Yes it does make it sometimes work but overall it makes the situation much worse. For example if you type just `console.` it won't suggest exception no matter what you have done before.
Repository: go
Issue: x/tools/go/packages: unhelpful when it returns nil, nil
Labels: NeedsInvestigation,Tools

at tip, packages.Load can return an empty list without any errors. While this might be the correct result sometimes (as when a pattern doesn't match) it gives the user nothing to work with. It might be more helpful to report some sort of error from the underlying build tool.
Repository: angular
Issue: Dot segments from path not removed
Labels: type: bug/fix,freq1: low,area: router,state: confirmed,router: URL parsing/generation,P5

# 🐞 bug report

### Affected Package
@angular/router

### Is this a regression?
No

### Description
By RFC3986 (https://tools.ietf.org/html/rfc3986#page-33) dot segments should be removed from path.

When accessing `localhost:4200/segment/./segment` by browser navigator, browser strips the dot segments and Angular router recieves `localhost:4200/segment/segment`. Everything works as expected.

When programmatically routing to `'./segment/./segment'`, Angular throws an error (404).
Browser navigator still shows URI with dot segments *stripped* (`localhost:4200/segment/segment`).

## 🔬 Minimal Reproduction
https://stackblitz.com/edit/angular-d2kk5q?file=src%2Findex.html

## 🔥 Exception or Error
Cannot match any routes. URL Segment: 'segment/./segment'

## 🌍  Your Environment
**Angular Version:**
7.0.1

## Extra
I'm not sure if I would call this a bug, but it's definitely not consistent with browser routes.
Repository: go
Issue: x/tools/go/packages/packagestest: cleanup fails silently and leaves test junk
Labels: NeedsInvestigation,Tools

The `Exported.Cleanup` function from `x/tools/go/packages/packagestest` can fail silently and leave temporary files around - currently running `go test` in `x/tools/import` results in around 75MB of test junk being left behind (at least under OpenBSD and I would suspect most other BSD/Unix like platforms), the majority being from `TestSimpleCases`.

The cause of the issue is that one of the sub-directories is created as 0555, which means that the subsequent `os.RemoveAll` call fails due to insufficient permissions:

```
$ ls -l /tmp/TestSimpleCases_import_grouping_not_path_dependent_no_groups_Modules592366644/modcache/pkg/mod/ 
total 20
drwxr-xr-x  6 joel  joel  512 Jan  1 23:53 github.com/
drwxr-xr-x  3 joel  joel  512 Jan  1 23:53 golang.org/
dr-xr-xr-x  3 joel  joel  512 Jan  1 23:53 local.com@v1.0.0/
dr-xr-xr-x  6 joel  joel  512 Jan  1 23:53 manypackages.com@v1.0.0/
dr-xr-xr-x  3 joel  joel  512 Jan  1 23:53 rsc.io@v1.0.0/
```

There are possibly three separate issues here:

1. Either these directories need to be created with permissions 0755, or the `Exported.Cleanup` function needs to `chmod u+w` before trying to `os.RemoveAll`.

2. The `Exported.Cleanup` function should not really fail silently, since these kinds of issues go undetected until a disk fills up.

3. There may be an issue with the code that is creating these directories (which should be using 0755 instead of 0555), if it is outside the test harness.
Repository: go
Issue: cmd/go: clean GOCACHE based on disk usage
Labels: NeedsDecision,FeatureRequest,GoCommand

The GOCACHE appears to lack a disk size limit - this is a problem in a space constrained environment and/or when running go on a disk that is nearing capacity. For example, on the openbsd/arm builder (which runs on a USB stick), the `~/.cache/go-build` directory runs past several GB in a very short time, which then leads to various failures (`git clone` or go builds). The only option that I currently appear to have is to run `go cache -clean` regularly, in order to keep the cache at a respectable size. It seems that having a configurable upper bound would be preferable and/or free disk space based checks that prevent writes (e.g. evict then write) to the cache from failing when the disk is full due, partly due to a large GOCACHE:

```
[gopher@cubox ~ 102]$ du -csh ~/.cache/go-build                                                                                                                                                                                 
2.2G    /home/gopher/.cache/go-build
2.2G    total
[gopher@cubox ~ 103]$ df -h /home
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/sd1m      9.0G    8.5G   -6.0K   100%    /home
[gopher@cubox ~ 104]$ go build -o /tmp/main /tmp/main.go

/home: write failed, file system is full

/home: write failed, file system is full

/home: write failed, file system is full

/home: write failed, file system is full

/home: write failed, file system is full

/home: write failed, file system is full

/home: write failed, file system is full

/home: write failed, file system is full

/home: write failed, file system is full
[gopher@cubox ~ 105]$ du -csh ~/.cache/go-build          
2.2G    /home/gopher/.cache/go-build
2.2G    total
[gopher@cubox ~ 106]$ df -h /home                        
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/sd1m      9.0G    8.5G   -6.0K   100%    /home
```
Repository: TypeScript
Issue: "Pick" or "Exclude" constructor from class type
Labels: Suggestion,Needs Proposal

<!-- 🚨 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.

-->

## Search Terms
`intersect`, `type`, `intersect constructor`, `pick new`, `pick constructor`

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion

```ts
class C1 {
  static S1 = 'foo';
  bar = 'bar';
  constructor(p1, p2, p3) {}
}
type T1 = Pick<typeof C1, new>;
// could simply be also:
type Only<T, K extends keyof T> = Pick<T, { [P in keyof T]: P extends K ? P : never }[keyof T]>;
type T2 = Only<typeof C1, 'constructor'>;

const clazz: T1 = null; // `null` could be anything
new clazz(); // should throw error because of missing params
new clazz(null, null, null); // should work
new clazz(null, null, null).bar; // should throw error because `bar` doesn't exist
clazz.S1; // should throw error because `S1` doesn't exist
```

## Use Cases
It could be useful in class type intersection and/or for multiple inheritance (like PHP Trait, or Java default methods in interface).
And make mixins more "clean" imho.
One of my goal is to make a "type mixin" without a "value mixin".

## Examples

For example:
```ts
class C1 {
    public bar: string;
    constructor(p1: string) {}
    public foo() {}
}

class C2 {
    public constructor() {}
    public baz() {}
}

type T1 = typeof C1 & typeof C2;

const a: T1 = null;
a.prototype.foo(); // ok
a.prototype.bar; // ok
a.prototype.baz(); // ok
new a(); // ok (return C2)
new a(''); // ok (return C1)
new a().foo() // error
new a('').baz(); // error

type T2 = typeof C1 & Exclude<typeof C2, new>

const b: T2 = null;
b.prototype.foo(); // ok
b.prototype.bar; // ok
b.prototype.baz(); // ok
new a(); // error <<<
new a(''); // ok (return C1 with C2 prototype)
new a('').foo() // ok (from C1)
new a('').baz(); // ok (from C2) <<<
```

## 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
* [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: Beta Distribution values wrong for a=b---> 0
Labels: module: distributions,triaged

## 🐛 Bug

#### When concentration parameters a, b are equal and go to 0, sample values are wrong.

## To Reproduce

Steps to reproduce the behavior:

copy paste the following in a notebook:

```
import torch
from scipy.stats import beta as beta_sp
from torch.distributions import Beta as beta_t
from matplotlib import pyplot as plt

device = torch.device('cuda:0' if torch.cuda.is_available() else 'cpu')
dtype = torch.float32

a = 1e-2
b = 1e-2
size = [10000]

x1 = beta_sp.rvs(a, b, size=size)
x2 = beta_t(torch.tensor(a, device=device, dtype=dtype), 
            torch.tensor(b, device=device, dtype=dtype)).sample(torch.Size(size))

def plot_compare(x1, x2):
    plt.hist([x1, x2.cpu().numpy()], label=['scipy', 'pytorch'], density=True, alpha=0.75);
    plt.legend(loc='best')
    plt.title('Beta distribution for values a=b=%.3f' % a)
    plt.show()
    
# wrong as a=b --> 0, starting at 1e-2
plot_compare(x1, x2)
```
(1) for `device = cpu`, there is an error peak around 0.55  
![cpu_beta](https://user-images.githubusercontent.com/7077018/50701764-17d7f300-104f-11e9-869c-a3700f3c11e5.png)
(2) for `dvice = cuda`, there is a bias towards 1.
![cuda_beta](https://user-images.githubusercontent.com/7077018/50701763-17d7f300-104f-11e9-8a69-002f0e87f945.png)

## Expected behavior

see the `scipy` output for expected values.

## Environment
 - PyTorch Version (e.g., 1.0): 1.0
 - OS (e.g., Linux): mac
 - How you installed PyTorch: `conda`
 - Python version: 3.6
 - CUDA/cuDNN version: 9.0
 - GPU models and configuration: TitanX

cc @vincentqb @fritzo @neerajprad @alicanb @vishwakftw
Repository: flutter
Issue: Bad error message when Android toolchain isn't installed
Labels: platform-android,tool,P2,team-android,triaged-android

If the Android toolchain isn't installed (I had the wrong path set in `ANDROID_HOME`), 
`flutter run` and `flutter devices` report 
```
No devices detected
```
instead of 
```
Can't find adb / Android tools.
```
Repository: create-react-app
Issue: HTTPS in Development
Labels: issue: proposal

A workaround has been commented below, see: https://github.com/facebook/create-react-app/issues/6126#issuecomment-570763433

---

Right now there's just the general acceptance that the SSL Certificate will cause some friction.

> Note that the server will use a self-signed certificate, so your web browser will almost definitely display a warning upon accessing the page.
>
> Source: [Create React App Website](https://facebook.github.io/create-react-app/docs/using-https-in-development)

React's website (and the development world really) has been gifted with [Gatsby](https://github.com/gatsbyjs/gatsby), and I think they got it right.

When you run a gatsby website in development mode with the `--https` flag, it will leverage the package [devcert-san](https://github.com/davewasmer/devcert). It's (near) frictionless, handles trusting the CA and gets you a proper lock on the browser bar.

I don't think it's really a high priority but wanted to bring it up.

> Just to follow up, I also found this but haven't worked with it (yet).
>
> https://github.com/FiloSottile/mkcert

---

**EDIT:**

> a PR implementing this feature has been open for a long time now: #5845
Repository: go
Issue: x/build/cmd/gerritbot: auto-reviewers are not applied for some GitHub CLs
Labels: help wanted,Builders,NeedsFix

When a PR is created by an author that has a Gerrit account, they are added as a reviewer to their own CL. Since the CL has a reviewer, gerritbot then does not apply autoreviewers.

For example: https://go-review.googlesource.com/c/go/+/156297

Maybe the answer is to add them as CC, not as reviewers. I'm not sure why that's the current behavior, but it might be an automatic Gerrit behavior, similarly to how it adds reviewers if it detects them listed manually as Reviewed-By.

/cc @andybons
Repository: vscode
Issue: [css][html] SVG language support
Labels: feature-request,css-less-scss,html

Currently, we have no SVG support:

- In HTML, SVG tags don't receive auto completion
- In CSS, SVG attributes don't receive auto completion
- Syntax highlighting are problematic for both SVG tags/attributes in HTML/CSS
- Emmet do not get SVG completions

However, with custom tag/property support in HTML/CSS, we should be able to trivially write a SVG package that describes the set of tags/attributes for SVG, and let HTML/CSS language services do the support work.

- https://github.com/Microsoft/vscode/issues/62976
- https://github.com/Microsoft/vscode/issues/64164
Repository: go
Issue: cmd/compile: many new no-ops as a result of mid-stack inlining
Labels: NeedsFix

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?
latest

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
ppc64le and ppc64

### What did you do?
I was inspecting code for another reason and I saw a lot of new no-ops in unexpected places.  For example in runtime.cgoCheckTypedBlock:
```
       return mheap_.arenas[ai.l1()][ai.l2()].spans[(p/pageSize)%pagesPerArena]
  0x13d08               3fe0002b                ADDIS $0,$43,R31        
  0x13d0c               e8ff3728                MOVD 14120(R31),R7      
  0x13d10               8be70000                MOVBZ 0(R7),R31         
        s := spanOfUnchecked(uintptr(src))
  0x13d14               7c000378                OR R0,R0,R0             
  0x13d18               7c000378                OR R0,R0,R0             
  0x13d1c               7dc87378                OR R14,R14,R8           
        ai := arenaIndex(p)
  0x13d20               7c000378                OR R0,R0,R0             
  0x13d24               7c000378                OR R0,R0,R0             
        return mheap_.arenas[ai.l1()][ai.l2()].spans[(p/pageSize)%pagesPerArena]
  0x13d28               7c000378                OR R0,R0,R0             
  0x13d2c               7c000378                OR R0,R0,R0             
  0x13d30               7c000378                OR R0,R0,R0             
  0x13d34               7c000378                OR R0,R0,R0             
        return arenaIdx((p + arenaBaseOffset) / heapArenaBytes)
  0x13d38               79c93682                RLDICL R14,$38,$26,R9   
```

### What did you expect to see?

I should only see no-ops where they are expected.

### What did you see instead?

Lots of no-ops in unexpected places. In the test for bytes there are almost 9000 extra no-ops with this commit.

>cd src/bytes
>go test -c
objdump -D bytes.test | grep mr | grep r0,r0 | wc -l
Using go version devel +c043fc4 Fri Dec 28 04:17:55 2018 +0000 linux/ppc64le
347
Using go version devel +69c2c56 Fri Dec 28 20:55:36 2018 +0000 linux/ppc64le
9193

I have not found runtime breakage because of this but performance could be affected depending where the unnecessary no-ops occur.
Repository: go
Issue: cmd/compile: reuse boxed primitive in slice literals of interfaces
Labels: Performance,NeedsInvestigation

Using `go1.12`

Consider the following snippet:
```go
func main() {
	lit := []interface{}{
		0, 0, 0, 0, 0,
	}
	type ifaceHeader struct{ Type, Data unsafe.Pointer }
	for i := range lit {
		fmt.Printf("%+v\n", *(*ifaceHeader)(unsafe.Pointer(&lit[i])))
	}
}
```

This currently prints:
```
{Type:0x4962e0 Data:0x4c95c0}
{Type:0x4962e0 Data:0x4c95c8}
{Type:0x4962e0 Data:0x4c95d0}
{Type:0x4962e0 Data:0x4c95d8}
{Type:0x4962e0 Data:0x4c95e0}
```

Which is indicative that each boxed integer is getting it's own heap allocated element (since the data pointer is different for every element). It seems that the compiler should be able to reuse boxed elements that are of the same value.

Furthermore, I would expect this work across different types with the same underlying kind. Thus, I would also expect:
```go
type EnumC int32
type EnumB int32
type EnumC int32
lit := []interface{EnumA(0), EnumB(0), EnumC(0)} 
```
to all share the same boxed element since all three types are of the `int32` kind.

\cc @randall77