sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/go: add support for "contains:" patterns to go list
Labels: NeedsInvestigation,FeatureRequest

cc @rsc @bcmills @suzmue @ianthehat 

`go/packages.Load` allows users to supply contains:<filepath> as a pattern argument. All other patterns supplied to `Load` are accepted by `go list` and it would be helpful if contains: could be also. That would allow `go/packages.Load` to always make a single `go list` call.

go list contains:<file> would list the packages containing the given file. This is an operation that tools commonly need, and have approximated in the past by determining the directory of the package.
Repository: TypeScript
Issue: In JS, bogus noImplicitAny error on some this-property assignments
Labels: Bug,checkJs

Discovered while looking at the puppeteer user test:

```js
class EmulationManager {
  constructor() {
    this._emulatingMobile = false;
  }

  /**
   * @param {boolean} viewport
   */
  emulateViewport(viewport) {
    if (this._emulatingMobile !== viewport)
        return true;
    this._emulatingMobile = viewport;
  }
}
```

**Expected behavior:**
No error with noImplicitAny, and `this._emulatingMobile: boolean`.

**Actual behavior:**
Error on `this._emulatingMobile = false`, "implicitly has type 'any' because it is referenced directly or indirectly in its own initialiser, and `this.emulatingMobile: any`.
Repository: go
Issue: cmd/go: cache hit takes too long on a test that opens many files
Labels: help wanted,ToolSpeed,NeedsInvestigation,GoCommand

### What version of Go are you using (`go version`)?
go1.10.2

### Does this issue reproduce with the latest release?
Yes.
```
ijt$ time go1.11beta1 test .                                                                                                                                                                                                                                                                                                 
ok      github.com/google/go-cloud/wire/internal/wire   38.037s

real    1m10.576s
user    1m22.899s
sys     0m52.377s
ijt$ time go1.11beta1 test .
ok      github.com/google/go-cloud/wire/internal/wire   (cached)

real    0m30.822s
user    0m11.384s
sys     0m20.135s
```

### What operating system and processor architecture are you using (`go env`)?
```
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/issactrotts/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/issactrotts/gopath"
GORACE=""
GOROOT="/Users/issactrotts/homebrew/Cellar/go/1.10.2/libexec"
GOTMPDIR=""
GOTOOLDIR="/Users/issactrotts/homebrew/Cellar/go/1.10.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/9z/3vhqmj_j18v6vsk1q2jr486r001n0v/T/go-build330802734=/tmp/go-build -gno-record-gcc-switches -fno-common"
```

### What did you do?
```
m=github.com/google/go-cloud
go get $m
cd $(go list -f '{{.Dir}}' $m)
cd wire/internal/wire
# Run tests once.
time go test -v .
# Run tests again. This time the result is cached, but it still takes over 30s on a 2015 Macbook pro laptop.
time go test -v .
```

### What did you expect to see?
The second test run should have taken under 1s since nothing changed.

### What did you see instead?
It took over 30s.

@zombiezen suggested that the slowness arises from the wire tests opening many packages under `$GOROOT` for type checking, making `go test` spend a lot of time checking their hashes when deciding whether there is a cache hit.
Repository: pytorch
Issue: [Caffe2]  Implementing CoordConv layer
Labels: caffe2

## Issue description

I am trying to implement a CoordConv layer (https://arxiv.org/pdf/1807.03247.pdf) in caffe2 but I am having problems to concatenate a Tensor due to shape mismatch.

The CoordConv layer consist in concatenating the input blob with two tensors with values ranging from -1 to 1 (that specify the x,y coordinates) followed by a Conv layer.

What is the best approach to create those vectors? As the input blob size will change every time (both dimensions and batch size), it needs to be generated at runtime. For example, if the input blob is 2x256x10x10 (NCHW), I want to generate two vectors of 2x1x10x10 and concatenate them so the output is 2x258x10x10 

I have unsuccessfully tried to generate the vectors using GivenTensorFill() and ResizeLike(). 

Can this be implemented by combining already existing layers? Or it is required to implement a new layer? Has anybody implemented the layer?

Thanks
Repository: rust
Issue: Type Inference not working when indexing with Into<usize> types
Labels: T-lang,T-compiler,A-inference

I have an `enum Dim { X, Y, Z }` that I've implemented `Into<usize>` for, so I can use it instead of `0, 1, 2`, but I get type inference errors when using it. I've narrowed it down to this playground example.

If you change the last line to `let c: i32 = a[i.into()];` then it gives an error about not knowing the type for `i.into()`, despite there only being one type that it can be?
I can use `a[i as usize]` which works fine for this case, but not sure why using `.into()` breaks things so badly.

```rust
enum I {
    X,
    Y,
    Z,
}

impl Into<usize> for I {
    fn into(self) -> usize {
        0
    }
}

fn main() {
    let a = vec![1i32, 2, 3];
    let i = I::X;
    let c = a[0];
    let c = a[i.into()];
}
```

([Playground](https://play.rust-lang.org/?gist=18753b8ff389cd1838c897d05ae682d7&version=stable&mode=debug&edition=2015))

Errors:

```
   Compiling playground v0.0.1 (file:///playground)
error[E0282]: type annotations needed
  --> src/main.rs:17:9
   |
17 |     let c = a[i.into()];
   |         ^
   |         |
   |         cannot infer type for `_`
   |         consider giving `c` a type

error: aborting due to previous error

For more information about this error, try `rustc --explain E0282`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.

```
Repository: TypeScript
Issue: Preserve union type name within larger union
Labels: Suggestion,In Discussion,Domain: Type Display

**TypeScript Version:**  3.1.0-dev.20180731

**Code**

```ts
type Value =
    | { kind: "number", n: number }
    | { kind: "string", s: string };
function f(value: Value | undefined): void {}
f(undefined);
```

**Expected behavior:**

Quick info on `f` shows `function f(value: Value | undefined): void`

**Actual behavior:**

Quick info shows:
```ts
function f(value: {
    kind: "number";
    n: number;
} | {
    kind: "string";
    s: string;
} | undefined): void
```

**Related Issues:** #14662
Repository: godot
Issue: Add eyedropper cursor shape
Labels: enhancement,topic:core

I don't know if Windows and macOS have it, but cursor themes in GNU/Linux do have an eyedropper cursor shape (at least the ones I tested).
Repository: go
Issue: crypto/x509: reduce memory usage when parsing system root certs?
Labels: Performance,NeedsInvestigation

I noticed that loading the x509 system roots and parsing their certificates on Linux takes 526kB of memory.

(by making an HTTPS request for the side-effect of loading them: https://play.golang.org/p/re1rB_Ui1nS then hitting pprof)

I suspect have common subfields that might be able to share memory? Or does our super transparent representation preclude that?

GitHub won't let me upload an SVG, so:
<img width="843" alt="screen shot 2018-07-31 at 7 30 03 pm" src="https://user-images.githubusercontent.com/2621/43497688-46da6728-94f8-11e8-96e1-0ad5d1d26f43.png">

/cc @FiloSottile
Repository: go
Issue: x/tools: suggest sets of build constraints that cover all files in a package
Labels: NeedsDecision,FeatureRequest

https://golang.org/cl/12703044 added `AllTags` to `*go/build.Package` so that "[t]ools scanning packages can use this to decide how many variants there are and what they are."

Since it's often necessary to invoke `go list` rather than use `go/build` directly, I think the same reasoning applies for adding it to `go list`.
Repository: go
Issue: runtime: append is slower than make+assignments for small slices with known length
Labels: Performance,NeedsInvestigation,compiler/runtime

### What version of Go are you using (`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`)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/opennota/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/opennota/gocode"
GORACE=""
GOROOT="/home/opennota/go"
GOTMPDIR=""
GOTOOLDIR="/home/opennota/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-build289966161=/tmp/go-build -gno-record-gcc-switches"

### What did you do?

https://play.golang.org/p/e34FVX-sqQx

`go test -bench=.`

### What did you expect to see?

The ns/op numbers in the two tests are close.

### What did you see instead?

append is 24% slower:

```
BenchmarkAppend-4               20000000                89.9 ns/op
BenchmarkMakeAssign-4           20000000                73.1 ns/op
```
Repository: rust
Issue: Properly document and explain opt-levels s and z
Labels: C-enhancement,P-medium,T-compiler,A-docs,C-optimization

These opt-levels have been stabilized in #50265. If I'm not mistaken, `rustc -C help` still outputs this:

```
    -C            opt-level=val -- optimize with possible levels 0-3, s, or z
```

So not very helpful at all. I think there should be a better explanation for `rustc -C help` (also for levels 0 -- 3). [The rustc guide](https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/codegen-options/index.md#opt-level) has some information, but it's rather hidden.

I'd also suggest to change the current one-line-per-option layout of `-Z help` and `-C help`. Currently it discourages people to add more useful information if they have to crank it into one line. Why not something like:

```
-C debuginfo=val 
    Debug info emission level, 0 = no debug info, 1 = line tables only, 2 = full debug  
    info with variable and type information. And more information here. Lorem ipsum 
    dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt 
    ut labore et dolore magna aliquyam erat, sed diam voluatua. At vero eos et accusam 
    et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata 
    sanctus est Lorem ipsum dolor sit amet.
    
-C opt-level=val 
    Optimize with possible levels 0-3, s, or z. And more information here. Lorem ipsum 
    dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt 
    ut labore et dolore magna aliquyam erat, sed diam voluatua. At vero eos et accusam 
    et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata 
    sanctus est Lorem ipsum dolor sit amet.
```

Or something like that.
Repository: neovim
Issue: :terminal : normal-mode editing for shell prompt
Labels: enhancement,terminal

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: NVIM v0.3.1
- Vim (version: ) behaves differently? no.
- Operating system/version: Arch linux
- Terminal name/version: Alacritty/0.1.0
- `$TERM`: xterm-256color

### Steps to reproduce using `nvim -u NORC`

```
nvim -u NORC +terminal
In the terminal mode go into insert mode, write something.
Go back into normal mode(still in terminal) try to change or delete 
the search terms. 

```

### Actual behaviour
cannot make changes, 'modifiable' is off

### Expected behaviour
do whatever would normally happen to text whenever you use cw, D, dw etc.

----

I could probably solve this by just setting the buffer modifiable, but is there some problems with this since this is the default behavior? is there a preferred way of doing this? And how do i apply it only to the terminal buffer and nothing else all the time?

Thanks.
Repository: go
Issue: doc/install: define minimum supported VCS versions
Labels: Documentation,Proposal,Proposal-Accepted

`cmd/go` shells out to version control binaries to implement `go get`.

[doc/install](https://tip.golang.org/doc/install) currently declares minimum supported OS versions for FreeBSD, macOS, and Windows, but only a minimum kernel version for Linux. Those requirements do not imply any particular version of the supported version control binaries, and those versions do matter in practice: in particular, `git` accrued a large number of flags in between 2.7 and 2.18 (https://github.com/golang/go/issues/26653).

We should be explicit about which versions are supported for use with the `go` command.

(CC: @rsc @ianlancetaylor @bradfitz @myitcv @rogpeppe @trashhalo)
Repository: go
Issue: x/text/unicode/norm: reduce init-time memory usage
Labels: Performance,help wanted,NeedsFix

The golang.org/x/text/unicode/norm package allocs 21.47kB in its init function, regardless of whether the package is ever used.

We should do it lazily, as done in e.g. https://go-review.googlesource.com/c/net/+/127275 and https://go-review.googlesource.com/c/go/+/127075

This would help people who explicitly import it (or import it via golang.org/x/net/http2), as then the std-vendored copy would not need to also allocate the 20KB.

Perhaps some of those tables should be const strings, too, so the linker can put it in read-only sections. Then we can slice into it at runtime to get integers out.

/cc @mpvl
Repository: vscode
Issue: Slow when editing a file with very long lines
Labels: bug,freeze-slow-crash-leak,verification-found,tokenization

Issue Type: <b>Performance Issue</b>

### Steps to reproduce
 1. Open any text file with longer lines (more than 10k characters).
 2. Try to edit the line (remove or add characters in between).

### Observations
 - The cursor movement is extremely slow and character updates take place after a long time.
 - The same behaviour is observed when Word Wrap is on.
 - Gives a warning sometimes
> Tokenization is skipped for lines longer than 20k characters for performance reasons.

### System Information
VS Code version: Code 1.25.1 (1dfc5e557209371715f655691b1235b6b26a06be, 2018-07-11T15:33:29.235Z)
OS version: Darwin x64 17.7.0
Repository: rust
Issue: Long compile times due to initialization of large struct 
Labels: A-LLVM,I-compiletime,T-compiler,C-bug

<short summary of the bug>

I tried fixing erlepereira/x11-rs#90 with [this patch](https://github.com/fintelia/x11-rs/commit/7d6ee99a5482f3cd5b2eaa1a1402e36ec22111a0) that directly instantiates some (very) large structs via a macro. Unfortunately this change caused compile times to drastically increase. Before a build took only a few seconds, but now a debug build takes 40+ seconds and my attempt to do a release build has been going for ~30 minutes~ over an hour.

[~/git/x11-rs/x11-dl$ cargo rustc -- -Z time-passes](https://pastebin.com/DXfRdxkD)

[~/git/x11-rs/x11-dl$ cargo rustc --release -- -Z time-passes](https://pastebin.com/NyVfxSVQ) (incomplete log output, killed after producing no further output for an hour.)

## Meta

rustc --version --verbose:
```
rustc 1.29.0-nightly (e94df4acb 2018-07-31)
binary: rustc
commit-hash: e94df4acb4c3f42fdc224a7164b63a99240add1e
commit-date: 2018-07-31
host: x86_64-unknown-linux-gnu
release: 1.29.0-nightly
LLVM version: 7.0
```
Repository: TypeScript
Issue: Return type inference error with async functions and Promise.reject()
Labels: Bug

**TypeScript Version:**  3.0.1

**Code**

```ts
async function often() {
    if (false) {
        return Promise.reject();
    }
    // code
}

let sometimes = often();
sometimes = Promise.resolve();
```

**Actual behavior:**

    error TS2322: Type 'Promise<void>' is not assignable to type 'Promise<never>'.

**Playground Link:** [here](https://www.typescriptlang.org/play/?#src=%0D%0Aasync%20function%20often()%20%7B%0D%0A%20%20%20%20if%20(false)%20%7B%0D%0A%20%20%20%20%20%20%20%20return%20Promise.reject()%3B%0D%0A%20%20%20%20%7D%0D%0A%20%20%20%20%2F%2F%20code%0D%0A%7D%0D%0A%0D%0Alet%20sometimes%20%3D%20often()%3B%0D%0Asometimes%20%3D%20Promise.resolve()%3B%0D%0A)
Repository: go
Issue: proposal: encoding/xml: add RawXML token
Labels: Proposal,Proposal-Hold

I have recently been experimenting with writing an XML encoder that (given a struct or other similar type) emits `xml.Token`'s instead of bytes. In doing so I discovered that some XML could be encoded using structs that cannot currently be encoded using the `"Encoder".EncodeToken` method and that I couldn't finish my project without occasionally switching over to the struct based API. There is currently no equivalent in the SAX-like API for the `,innerxml` tag on struct fields. This is useful as it both lets us encode invalid XML (which is unfortunately quite common, and it may be desirable to let Go's encoder work with broken XML encoders and decoders in the wild), and lets us encode pre-escaped XML without accidentally double-escaping (eg. if we know we already have valid XML such as `&amp;` we can prevent it from being turned into `&amp;amp;`).
This is similar in spirit to the known safe types in the `html/template` package (eg. [`HTML`] or [`JS`]).

[`HTML`]: https://golang.org/pkg/html/template/#HTML
[`JS`]: https://golang.org/pkg/html/template/#JS

Proposal: https://golang.org/design/26756-rawxml-token
Repository: TypeScript
Issue: No related error spans return for type assignment mismatch
Labels: Suggestion,Domain: Related Error Spans,Experience Enhancement

<!-- 🚨 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.20180802

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- relatedInformation
- related diagnostics

**Code**
For the ts:

```ts
let b: number = 1
b = ''
```

**Expected behavior:**
`relatedInformation` is returned on the assignment of `b = ''` (#25030)

**Actual behavior:**
No `relatedInformation`

**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: flutter
Issue: Material: Overflow action in AppBar should be narrower
Labels: framework,f: material design,a: fidelity,c: proposal,P2,team-design,triaged-design

![flutter_incorrect](https://user-images.githubusercontent.com/22688477/43570500-c7f6c930-963a-11e8-9c7a-91c22e45a038.png)
Repository: pytorch
Issue: error when building caffe2 from source with gcc 7 & cuda gcc 5.5
Labels: caffe2

The error is:
```
/usr/lib/gcc/x86_64-linux-gnu/5/include/avx512pfintrin.h(127): error: argument of type "void *" is incompatible with parameter of type "const long long *"   

/usr/lib/gcc/x86_64-linux-gnu/5/include/avx512pfintrin.h(136): error: argument of type "void *" is incompatible with parameter of type "const int *"

/usr/lib/gcc/x86_64-linux-gnu/5/include/avx512pfintrin.h(145): error: argument of type "void *" is incompatible with parameter of type "const long long *"

/usr/lib/gcc/x86_64-linux-gnu/5/include/avx512pfintrin.h(153): error: argument of type "void *" is incompatible with parameter of type "const int *"
...etc
```
I build caffe2 in ubuntu 18.04 with gcc 7. And I add ```-DCUDA_HOST_COMPILER=/usr/bin/gcc-5``` flag when I run ```build_anaconda.sh```
I think this error is caused by gcc 5.5, but I do not know how to install gcc5.5 in ubuntu 18.04.
I find a [same issue](https://github.com/tensorflow/tensorflow/issues/10220).
Repository: gin
Issue: gin-gonic Middleware Unable to set Header
Labels: question

I am trying to create middlware for gin-gonic that automatically adds a UUID for tracing purposes as a Header to all incoming requests, if one does not already exist. The code is below. However I'm having an issue where c.Header() does not seem to set the header. I have tried it with c.Writer.Header().Set() as well and it still always displays an empty header. 

Looking at various other examples of similar functionality suggests what I'm trying to do should work perfectly fine.

What stupid thing have I done/missing?

```
func Trace() gin.HandlerFunc {
	return func(c *gin.Context) {
		val := c.GetHeader(RequestHeaderName)
		if val == "" {
			log.Info("Missing Trace ID - start of chain")
			val = uuid.New().String()
			log.Infof("Setting Trace Header: %v", val)
			c.Header(RequestHeaderName, val)
		}
		
		log.Infof("Trace Header: %v", c.GetHeader(RequestHeaderName))

		c.Next()
	}
}
```
Repository: godot
Issue: Control's Rect Clip Content doesn't rotate when the control is rotated
Labels: bug,discussion,topic:rendering,confirmed,topic:gui,topic:2d

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
v. 3.0.5


**OS/device including version:**
Windows

**Issue description:**
I'm trying to use **Control** node's Rect "Clip Content" to mask it's content with simple rectangle. While Control node is not rotated - Clip Content works fine. But when I rotate Control node - clipping occurs on bounding box of Control node. Expected to be rotated with control node.


**Steps to reproduce:**
![image](https://user-images.githubusercontent.com/30045982/43578450-7d263b12-9657-11e8-8e4b-c666435e8fd3.png)

**Minimal reproduction project:**
[GodotGame.zip](https://github.com/godotengine/godot/files/2253099/GodotGame.zip)
Repository: godot
Issue: "Always Close Output On Stop" ignored on error
Labels: bug,topic:editor,usability

Godot, 64-bit, 3.06.stable.official.8314054

Windows 10 Home, 64-bit, Version 1803, Build 17134.165

In a project that has an error, when I click stop the output window always closes.  This happens regardless of how Editor Settings/Run/Output/Always Close Output On Stop is set.

If the project has no error, the setting is respected as normal.

To reproduce:
1) Load example project
2) Set Editor Settings/Run/Output/Always Close Output On Stop to false
3) Open the output window
4) Click run
5) Click stop
6) The output window will close, ignoring the setting

This is especially annoying because when there's an error is exactly when I want to see the output the most.  :)

Thanks for everything you do!

[Bug Test.zip](https://github.com/godotengine/godot/files/2253563/Bug.Test.zip)
Repository: go
Issue: x/text/message: better documentation for catalog
Labels: Documentation,NeedsInvestigation

The documentation for this package could be clearer with regard to how catalogs should be used.
Specifically:
* the default catalog is empty.
* how to populate the default catalog (is there a standard way of doing this?)
* document that the default fallback language is English.

Repo commit: b0f49b06765e38644f97dff880167326a7ab0391