sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Assorted issues in Caffe2's Metal ops
Labels: caffe2

I've been playing around with Caffe2's Metal ops in the iOS contrib module on macOS and have noticed a few issues. I'm not certain if some of these can be attributed to the differences in macOS vs iOS; however, it's probably worth a quick review by someone familiar with it.

**1. Potentially incorrect texture write in concat op**

For the texture2d write call here: https://github.com/pytorch/pytorch/blob/v0.4.1/caffe2/mobile/contrib/ios/mpscnn/MPSCNN.metal#L954 , I believe the correct call should omit the final `gid.z` argument (which is the `lod` arg according to the Metal language spec). On macOS this is a hard compilation error as `lod` is constrained to be 0.

**2. Uninitialized member variables**

A number of ops have uninitialized member vars (eg: https://github.com/pytorch/pytorch/blob/v0.4.1/caffe2/mobile/contrib/ios/mpscnn/mpscnn.mm#L1776) that are lazily initialized based on their uninitialized value (https://github.com/pytorch/pytorch/blob/v0.4.1/caffe2/mobile/contrib/ios/mpscnn/mpscnn.mm#L1701).

These can and do (at least on macOS) lead to segfaults.

**3. Assorted minor inconsistencies in comments/messages/etc...**

Examples:

In `MPSCNNNormalizePlanarYUVOp`:
```
VLOG(2) << "InstanceNorm took: " << t.MilliSeconds();
```

In `MPSCNNConcatOp`:
```
// Only handle three inputs for now.
OPERATOR_NEEDS_FEATURE(Inputs().size() <= 4, "MPSCNNConcat only handles up to four inputs");
```
Repository: TypeScript
Issue: Error output: Don't deep compare to native objects
Labels: Suggestion,Committed,Domain: Error Messages,Rescheduled

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.1.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

Currently if we assign not assignable type to a variable, ts shows a deep 'not assignable' error with mark all not compatible fields. Even for a native objects like Array, Promise, Date etc...
But I think this is too noisily. All I want to know is that my type in not assignable to Array. Don't try to compare guts of Array with my type.

**Code**

```ts
type A = {a: string}
var y:A = {a: ''}
var x0: string = y; // Type 'A' is not assignable to type 'string'.  -- it's ok!
var x1: A[]  = y; // Property 'length' is missing in type 'A'.
var x2: Promise<A> = y; // Property 'then' is missing in type 'A'.
var x3: Date = y; // Property 'toDateString' is missing in type 'A'.
var x4: Node = y; // Property 'baseURI' is missing in type 'A'.

```

**Expected behavior:**

**Actual behavior:**

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: godot
Issue: Mono_logs folder gobbles up disk space
Labels: bug,confirmed,topic:dotnet

**Godot version:**
3.1 Alpha Mono

**OS/device including version:**
KDE Neon

**Issue description:**
After some months of using Godot, I noticed I suddenly ran out of disk space. Using k4dirstat, I found the culprit: the folder `~/.local/share/godot/mono/mono_logs` grew to a whopping 6.18 GB, filled with nothing but text files containing logs:
![mem](https://user-images.githubusercontent.com/31383123/45264649-28c97c80-b440-11e8-8c7a-e841f4d9aa5c.png)


**Steps to reproduce:**
Not sure, it seems to be triggered by using Godot Mono for a while.
Repository: go
Issue: runtime: feature request: Support for ASLR with the heap
Labels: NeedsInvestigation,compiler/runtime

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
```go version go1.11 freebsd/amd64```

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/shawn/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOOS="freebsd"
GOPATH="/home/shawn/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_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=/tmp/go-build851003260=/tmp/go-build -gno-record-gcc-switches"
```


### What did you do?

Run a go application

### What did you expect to see?

The heap mapped at a non-fixed location.

### What did you see instead?

The heap mapped at a fixed location.

### More information:

I've read through a previous discussion in 2012 about golang's use of deterministic memory allocations here: https://groups.google.com/forum/#!msg/golang-nuts/Jd9tlNc6jUE/qp2oyfEEfjQJ

Back then, -buildmode=pie didn't exist back then, so I figured a revisit of the topic might be warranted.

Go 1.11 introduced -buildmode=pie for FreeBSD, which HardenedBSD is able to take advantage of, given HBSD's PaX ASLR implementation. HardenedBSD is a hardened derivative of FreeBSD.

When applying -buildmode=pie with gitea, I wanted to verify that golang was able to take full advantage of HardenedBSD's robust ASLR implementation. I noticed a fixed mapping at 0xc000000000. I restarted the process, looked at the memory mappings again (`procstat -v $PID`) and saw 0xc000000000 again. Grepping through the golang 1.11 codebase revealed that Go allocates its heap at a fixed address, starting at 0xc000000000.

With the heap being allocated at a fixed mapping, golang applications are still not able to really utilize ASLR. Thus, -buildmode=pie is moot.

Given that the reason to implement PIE support is to take advantage of ASLR, I'm curious if perhaps updating the heap management code for ASLR support was overlooked. Or perhaps it wasn't, and this is deliberate. Or perhaps a totally different reason. Either way, could someone shed some light on this?

I submitted a post on the golang-nuts mailing list, asking the same questions. It can be found here: https://groups.google.com/d/msg/golang-nuts/pAGcmRA_V5s/2NnOPDEcBgAJ
Repository: godot
Issue: FileDialog type ahead does not position to file or directory in editor
Labels: enhancement,topic:gui

**Godot version:**
![screen shot 2018-09-09 at 12 33 39 pm](https://user-images.githubusercontent.com/930478/45266720-75578c80-b42d-11e8-987c-4d4e35f0b6ae.png)

**OS/device including version:**
MacBook Pro (15-inch, Mid 2012)
10.13.6  (High Sierra)

**Issue description:**
Cannot type ahead to locate file or folder. This may be a widespread issue with Open File appears. Load Custom Font for a Button

![screen shot 2018-09-09 at 12 31 56 pm](https://user-images.githubusercontent.com/930478/45266785-9076cc00-b42e-11e8-9492-b49613839740.png)

Install an Asset from the online Asset Library
![screen shot 2018-09-09 at 12 50 13 pm](https://user-images.githubusercontent.com/930478/45266802-fcf1cb00-b42e-11e8-9573-e2c2d5452b9f.png)

**Steps to reproduce:**
Try to open a file or select directory by typing first letter. It will not position there. Also should be case insensitive.
Repository: vscode
Issue: Allow text-shadow to be used in themes
Labels: feature-request,tokenization,editor-theming

I used to use a neon theme in brackets that had really awesome glowing neon text

See below:
https://github.com/remonbonbon/brackets-theme-neon-sign

I tried making a similar theme in vscode but didn't realise the CSS property text-shadow was not supported. 

I know this is a very small and low priority request but it would totally make my day if we could implement glowing text in our themes. 

Thank you for your awesome work!
Repository: go
Issue: cmd/compile: BCE optimizes less for string than slice
Labels: Performance,NeedsInvestigation,compiler/runtime

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?

go version go1.11 linux/amd64

### Does this issue reproduce with the latest release?

yes

### What did you do?

```golang
package main

type T = string
// type T = []int

func NumSameBytes_1(x, y T) int {
	if len(x) > len(y) {
		x, y = y, x
	}
	for i := 0; i < len(x); i++ {
		if x[i] != y[i] { // y[i] needs bound check
			return i
		}
	}
	return len(x)
}

func NumSameBytes_2(x, y T) int {
	if len(x) > len(y) {
		x, y = y, x
	}
	
	y = y[:len(x)] // this line doesn't work
	for i := 0; i < len(x); i++ {
		if x[i] != y[i] { // y[i] still needs bound check (line 25)
			return i
		}
	}
	return len(x)
}

func NumSameBytes_3(x, y T) int {
	if len(x) > len(y) {
		x, y = y, x
	}
	if len(x) <= len(y) { // this line works
		for i := 0; i < len(x); i++ {
			if x[i] != y[i] { // bound check elimated for y[i]
				return i
			}
		}
	}
	return len(x)
}

func main() {}
```

### What did you expect to see?

For `T` is either `string` or `[]int`,  the bounds check for `y[i]` at line 25 should be eliminated.
But this is only true for `T` is `[]int`.

### What did you see instead?

When `T` is `string`, the bounds check for y[i] at line 25 is still needed.

```
$ go build -gcflags="-d=ssa/check_bce/debug=1" main.go
# command-line-arguments
./main.go:11:15: Found IsInBounds
./main.go:23:7: Found IsSliceInBounds
./main.go:25:15: Found IsInBounds
```
Repository: pytorch
Issue: High leverage TH operations to port to ATen
Labels: triaged,module: porting,better-engineering,module: tensor creation

Now that the THTensor/THStorage structs live directly in ATen, this unlocks some core tensor operations which we should port to ATen sooner rather than later. Here is an incomplete list:

- [ ] Copying/tensor conversions, e.g., `THByteTensor_copyByte`
- [ ] Basic storage functionality in `THStorage.h`
- [ ] Basic tensor functionality in `THTensor.h`. Of particular importance (e.g., these are exercised when you call `at::empty()`):
  - [ ] `THTensor_(newWithSize)`
  - [ ] `THTensor_(newWithStorage)`
  - [ ] `THTensor_(setStorageNd)`
  - [ ] `THTensor_resizeNd`

Rewrites should NOT use raw pointers (use smart pointers instead). There may also be some macro-level organization that makes sense; for example, it probably doesn't make too much sense for `setStorageNd` to also know how to allocate storages.

cc @gchanan @mruberry
Repository: go
Issue: x/build/cmd/gopherbot: auto-Subscribe owners to reported issues based on directory
Labels: Builders

We now have an owners file which assigns various Gophers as owners/cc'd on issues for different directories.

It would be good to match incoming issues and auto-subscribe the relevant people, e.g. to do in an automatic fashion what @bcmills is doing manually here. https://github.com/golang/go/issues/27524#issuecomment-419147447
Repository: rust
Issue: Make codegen treat inline fns the same as regular fns in non-opt builds
Labels: A-codegen,I-compiletime,T-compiler,A-incr-comp,WG-compiler-performance,WG-llvm

See https://github.com/rust-lang/rust/pull/53963#issuecomment-419472343 and following. There's no need to create private duplicates of `#[inline]` functions in debug builds, since we don't even run an inlining pass there.
Repository: vscode
Issue: [html] Automatically delete HTML closing tag when converting to self-closing tag
Labels: feature-request,html

A simple but useful feature would be to automatically delete an HTML or a JSX closing tag when converting to a self-closing tag.

In the latest version of VS Code (1.27.1), in order to go from

```
<App><App>
```

to


```
<App />
```
,

I need to do the following:

```
<App /></App>
```

and then manually delete the closing tag. It would be great if, at this point, VS Code would do that automatically.

I think it's simple enough and would be a nice feature especially for web developers who use Emmet. Therefore, it could be a core feature.

I tried searching for an extension that does this, but I was not able to find any. If an extension already exists, please link it here.

*This is not a duplicate of any of the issues linked by the experimental duplicate detection.*
Repository: TypeScript
Issue: ConstructorOf<T> wrapper to declare type of constructor of type parameter
Labels: Suggestion,In Discussion

so if I have
```ts
class MyClass {
}
```
Then the type of `MyClass.prototype` is `MyClass` 
And the type of `MyClass` is `typeof MyClass`

If I want these two functions
```ts
function takesPrototype(p: MyClass) { /* ... */ }
function takesClass(p: typeof MyClass) { /* ... */ }
```
I can call them as
```ts
takesPrototype(MyClass.prototype)
takesClass(MyClass)
```

But what if `MyClass` was defined as a type parameter. 
For example if I want to have a function that of this type - 

```ts
const mod = getModule(ModuleClass)
// mod should be of type ModuleClass
```

I would like to define this as such
```ts
function getModule<M extends Module>(moduleClass: typeof M): M {
 // something like a getInstance() pattern
}
```

The problem with this is `typeof M` will complain that **I am trying to use M as a value while it is a type**. 

So I suggest a type wrapper of this type

```ts
type ConstructorOf<C> = { new( ...args: any[] ): C }
```

Now I can define my function as such
```ts
function getModule<M extends Module>(moduleClass: ConstructorOf<M>): M {
 // something like a getInstance() pattern
}
```
Repository: go
Issue: proposal: encoding/json: "nonil" struct tag to marshal nil slices and maps as non-null
Labels: Proposal,Proposal-Hold

There have been many reports about encoding a nil slice or map as `[ ]` or `{ }` respectively.

See: https://github.com/golang/go/issues/2278

Currently it is encoded as `null`. This is a source of bugs in many non-theoretical cases (eg consumers of JSON APIs). There are many issues on Google about others falling into this pitfall so it is at least not uncommon.

It would be nice if a struct tag can be used to signify that we intend the nil slice or map to be treated as an empty slice or map respectively for the purposes of marshalling.

Current solutions include: https://github.com/helloeave/json. This is not a nice solution because it requires the assistance of a third-party package.

This is how it's implemented in third party lib: https://github.com/helloeave/json/commit/7b6e442cca931fedb7c01443aaaa23aea0585062

**My PR can be found here: https://github.com/golang/go/pull/27813** (subject to an agreed struct tag name, which when decided, can be updated in the PR)
Repository: godot
Issue: bad polygon! error when changing TextureProgress value from 0 to 1
Labels: bug,topic:gui

latest master. compiled last night.

in any event. this bug is pretty weird. took me a while to track it down  

steps:
 - create TextureProgress
 - give it texture **progress** texture
 - create a tween in the scene
 - attach gdscript file

put in gdscript:
```
tween.interpolate_property(texture_progress, "value", 100, 0,  2, 0, 0)
tween.start()
```

and look at the error:
![](https://i.gyazo.com/b02b14a5e2ef50bda459c555efb2057b.png)

full error: https://github.com/godotengine/godot/blob/cf834a22dc78950a9fba484a7f9db98da84cae59/servers/visual/visual_server_canvas.cpp#L692
```
0:00:04:0775 - Bad Polygon!
----------
Type:Error
Description: Bad Polygon!
Time: 0:00:04:0775
C Error: Method/Function Failed, returning: 
C Source: servers\visual\visual_server_canvas.cpp:692
C Function: VisualServerCanvas::canvas_item_add_polygon
```
Repository: TypeScript
Issue: Error output: difficult to understand multistorey errors
Labels: Suggestion,Needs Proposal

### Incompatible type

```ts
var foo = {a: {b: {c: {d: 3}}}};
var bar: {a: {b: {c: {d: {e: number}}}}} = foo;
```
Instead of 
```
Type '{ a: { b: { c: { d: number; }; }; }; }' is not assignable to type '{ a: { b: { c: { d: { e: number; }; }; }; }; }'.
  Types of property 'a' are incompatible.
    Type '{ b: { c: { d: number; }; }; }' is not assignable to type '{ b: { c: { d: { e: number; }; }; }; }'.
      Types of property 'b' are incompatible.
        Type '{ c: { d: number; }; }' is not assignable to type '{ c: { d: { e: number; }; }; }'.
          Types of property 'c' are incompatible.
            Type '{ d: number; }' is not assignable to type '{ d: { e: number; }; }'.
              Types of property 'd' are incompatible.
                Type 'number' is not assignable to type '{ e: number; }'.
```

Print something like that
```
Type '{ a: { b: { c: { d: number; }; }; }; }' is not assignable to type '{ a: { b: { c: { d: { e: number; }; }; }; }; }'.
  Property 'a.b.c.d: number' is not assignable to 'a.b.c.d: {...}'
```



### Missing property
```ts
var foo = {a: {b: {c: {d: 3}}}};
var bar: {a: {b: {c: {d: number, e: number}}}} = foo;
```

```
Type '{ a: { b: { c: { d: number; }; }; }; }' is not assignable to type '{ a: { b: { c: { d: number; e: number; }; }; }; }'.
  Types of property 'a' are incompatible.
    Type '{ b: { c: { d: number; }; }; }' is not assignable to type '{ b: { c: { d: number; e: number; }; }; }'.
      Types of property 'b' are incompatible.
        Type '{ c: { d: number; }; }' is not assignable to type '{ c: { d: number; e: number; }; }'.
          Types of property 'c' are incompatible.
            Type '{ d: number; }' is not assignable to type '{ d: number; e: number; }'.
              Property 'e' is missing in type '{ d: number; }'.
```
vs
```
Type '{ a: { b: { c: { d: number; }; }; }; }' is not assignable to type '{ a: { b: { c: { d: number; e: number; }; }; }; }'.
  Property 'a.b.c.e: number' is missing
```

### Incompatible function parameter
```ts
var foo = {a: {b: {c: {d(y: number, x: string, z: number) {}}}}};
var bar: {a: {b: {c: {d(y: number, x: number, z: number):void}}}} = foo;
```

```
Type '{ a: { b: { c: { d(y: number, x: string, z: number): void; }; }; }; }' is not assignable to type '{ a: { b: { c: { d(y: number, x: number, z: number): void; }; }; }; }'.
    Parameter 'a.b.c.d(...,x: string,...)' is not compatible to 'a.b.c.d(...,x: number,...)'
```

### Incompatible function return
```ts
var foo = {a: {b: {c: {d(x: number) {}}}}};
var bar: {a: {b: {c: {d(x: number):Date}}}} = foo;
```

```
Type '{ a: { b: { c: { d(x: number): void; }; }; }; }' is not assignable to type '{ a: { b: { c: { d(x: number): Date; }; }; }; }'.      
   Return type of 'a.b.c.d(...): void' is not compatible to 'a.b.c.d(...): Date'
```
Repository: rust
Issue: You can never call your own `fn borrow(&mut self, ...)` method if you `use std::borrow::Borrow;`
Labels: C-enhancement,A-diagnostics,A-trait-system,P-low,T-compiler,A-suggestion-diagnostics,D-papercut,D-newcomer-roadblock

https://play.rust-lang.org/?gist=c36d8c617e66862b7bcaee05752ad313&version=stable&mode=debug&edition=2015
```rust
fn main() {
    use std::borrow::Borrow;
    struct S;
    impl S { fn borrow(&mut self, _: ()) {} }
    let mut s = S;
    s.borrow(())
}
```
(Just noticed that this might be the intended behaviour, since `std::clone::Clone` acts the same. But still, the error message here might need to be improved)
Repository: rust
Issue: fix "bivariant wf" bug in the NLL subtyping code
Labels: A-trait-system,P-medium,T-compiler,A-NLL,C-bug,NLL-sound

https://github.com/rust-lang/rust/pull/53873 generalized the NLL subtyping code to handle subtyping and the like, but I think it is vulnerable to a similar flaw as the one from <https://github.com/rust-lang/rust/issues/41677>. I didn't want to block that PR so I am filing this issue to follow-up.
Repository: create-react-app
Issue: Allow to opt-in React DOM profiling without ejecting
Labels: tag: new feature

### Is this a bug report?

No

### Expected Behavior

CRA should be able to opt-in to React DOM profiling without ejecting.

### Actual Behavior

Need to eject to enable React DOM profiling, as mentioned in https://gist.github.com/bvaughn/25e6233aeb1b4f0cdb8d8366e54a3977#create-react-app
Repository: godot
Issue: Animation Player doesn't execute end node automatically
Labels: enhancement,topic:animation

Alpha 3.1

**Issue description:**
The issue is on the **AnimationTreePlayer** with a state machine that doesn't execute the node marked as "end" automatically.

Would be useful to always call the end node when the focus go outside of StateMachine in all cases.

![screenshot from 2018-09-10 17-44-38](https://user-images.githubusercontent.com/8342599/45310298-2b9e9d00-b526-11e8-9f6c-5a8c8b8e16b5.png)


Here a minimal reproducible project:
[anim.zip](https://github.com/godotengine/godot/files/2367432/anim.zip)
Repository: TypeScript
Issue: Unexpected result of declaration emit while namespace is shared between two @types
Labels: Bug,Help Wanted,Effort: Moderate,Domain: Declaration Emit

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  2.9.2, 3.0.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** declaration, namespace, @types, import, angular, angular-mocks

**Code (index.ts)**

```ts
import angular from "angular";

export class RandomService {
  constructor(
    private $interval: angular.IIntervalService
  ) {

  }
}
```

```json
{
  "compilerOptions": {
    "allowJs": false,
    "esModuleInterop": true,
    "alwaysStrict": true,
    "declaration": true,
    "declarationDir": "./types",
    "module": "commonjs",
    "noImplicitAny": true,
    "outDir": "./dist",
    "sourceMap": false,
    "strictNullChecks": true,
    "target": "ESNext"
  },
  "include": [
    "src/**/*"
  ]
}
```
It requires to have two @types that share same namespace I guess, in this case its `@types/angular` and `@types/angular-mocks` which lead to unexpected result of declaration emit.

**Expected behavior (index.d.ts):**
Since we have import I don't expect to have `reference types="angular-mocks"` annotation here.
```ts
import angular from "angular";
export declare class RandomService {
    private $interval;
    constructor($interval: angular.IIntervalService);
}
```

**Actual behavior (index.d.ts):**
```ts
/// <reference types="angular-mocks" />
import angular from "angular";
export declare class RandomService {
    private $interval;
    constructor($interval: angular.IIntervalService);
}
```
**Playground Link:**

https://github.com/falsyvalues/typescript-playground