sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: brand: presentation theme: black background for source code is a problem
Labels: Documentation,NeedsFix

Please look at [this slide](https://docs.google.com/presentation/d/1Gib9XvcWW_FG9QT_5egNigJX9By7LFEpe69eu37k5Us/edit#slide=id.g33148270ac_0_429). While black background looks cool on the electronic displays (computers, TVs), and at the large conference screens in the dark environment, it will not work with typical equipment found at the meetup sites – projectors and white screens: they can't project black on the white screen, and switching off the lights and closing the curtains is not always possible (and also typically lead to tired gophers to snore).

I propose to add another template with the light background.

/cc @spf13
Repository: TypeScript
Issue: Verbose computed property transpilation
Labels: Suggestion,Help Wanted,Domain: Transforms

**TypeScript Version:**  2.7.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** 

**Code**

```ts
const p1 = 0;
const p2 = 1;
class A {
  [p1] = 0;
  [p2]() {}
}
```

**Expected behavior:**

```js
const p1 = 0;
const p2 = 1;
class A {
    constructor() {
        this[p1] = 0;
    }
    [p2]() { }
}
```

**Actual behavior:**

```js
const p1 = 0;
const p2 = 1;
class A {
    constructor() {
        this[_a] = 0;
    }
    [(_a = p1, p2)]() { }
}
var _a;
```

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> 

**Related Issues:**
Repository: go
Issue: x/mobile/cmd/gomobile: iOS app built with gomobile-build consumes memory and never frees
Labels: mobile

### What version of Go are you using (`go version`)?

```
go version go1.10 darwin/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="/Users/hajimehoshi/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hajimehoshi/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/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/7t/qw3np69559591s1v0mk5_p1m0000gn/T/go-build916245002=/tmp/go-build -gno-record-gcc-switches -fno-common"
```

### What did you do?

1. Run `gomobile build -target=ios -bundleid=com.hajimehoshi.gomobiletest -work golang.org/x/mobile/example/basic`
2. Open the generated `main.xcodeproj`
3. Install it on a device (iPhone 6 in my case)
4. Run the app via Instruments memory profiler (Zombie)

### What did you expect to see?

The app runs without memory increase.

### What did you see instead?

The memory usage is increased monotonically:

[![Screenshot from Gyazo](https://gyazo.com/63bfab74bebcc3a74e063076a47a7cb5/raw)](https://gyazo.com/63bfab74bebcc3a74e063076a47a7cb5)

It looks like `_IOAccelResourceAlloc` allocates memory and it is never disposed? I'm not sure this is an actual leak.
Repository: go
Issue: fmt: State could be a little friendlier
Labels: NeedsInvestigation,FeatureRequest

### What version of Go are you using (`go version`)?

1.10

### Does this issue reproduce with the latest release?

yes.

### What operating system and processor architecture are you using (`go env`)?

linux/amd64, but seems irrelevant

### What did you do?

Tried to use Formatter efficiently.

https://play.golang.org/p/sHI8UPe_f98

### What did you expect to see?

I don't honestly know. I was hoping for a reasonably straightforward way to express "use this format string for several things that I wish to format".

### What did you see instead?

See playground example.

In this specific use case, a fair bit of what I want could be accomplished much more easily if fmt.State had a member `Format []bytes` such that fmt.Sprintf(s.Format, value) would replicate the format specifier that created the fmt.State. (But with, for instance, a * width or precision already baked in.)

It also almost feels like fmt.State arguments could be used with Printf, etc., as a sort of meta-specifier. Consider a hypothetical %S format specifier, which consumes two arguments, the first being a fmt.State and the second being a value. So, once you *have* a format.State which specifies a given width/precision/flags, you could do something like:

`fmt.Fprintf(s, "[%S, %S, %S]", s, x0, s, x1, s, x2)`

(There's an interesting line of inquiry with casting the members to a type that has a custom formatting function, but because you can't nest functions, you can't declare the type and its formatter inside the Format() function for the containing type, and if the formatter is outside it, you can't have different goroutines simultaneously printing objects using different formats.)

(It might also be useful to mention explicitly in the fmt docs that Formatter can be used with arbitrary runes, as long as they're not %, T, or v.)
Repository: go
Issue: x/sys/windows: port CL 106275 into x/sys/windows
Labels: compiler/runtime

@aclements said https://github.com/golang/go/issues/21376#issuecomment-382445433

> we could even move all of the crypto APIs from syscall to internal/syscall/windows and tell people to use x/sys/windows instead (which we also need to fix).

This issue is so we do not forget to fix crypto APIs in x/sys/windows.

Austin, lets also decide if we want to remove broken crypto APIs and how we will decide which ones to remove before go1.11 is released. So we don't make breaking changes in syscall twice. Maybe not in this issue.

Thank you.

Alex
Repository: go
Issue: encoding/json: include property name for marshal errors
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

```
$ go version
go version go1.10 linux/amd64
```

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

```
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dominic/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/dominic/dev"
GORACE=""
GOROOT="/usr/lib/go-1.10"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.10/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-build203824871=/tmp/go-build -gno-record-gcc-switches"
```

### What did you do?

When encountering an error using `json.Marshal()` (and related functions) the error returned gives no indication where the error was encountered. The only included metadata is about the type of the value that was being encoded, but that is usually insufficient to narrow down problems without the original input value. (which may not always be at hand)

### What is being proposed?

The proposal would be to add the property name for marshal errors (using dot notation to signify hierarchy). For example:

> json: error calling MarshalJSON for type time.Time: Time.MarshalJSON: year outside of range [0,9999]

would be updated to be more specific:

> json: error calling MarshalJSON for timestamp (type time.Time): Time.MarshalJSON: year outside of range [0,9999]

and in the case of a more complex/nested data structure:

> json: error calling MarshalJSON for events.[0].timestamp (type time.Time): Time.MarshalJSON: year outside of range [0,9999]

### Why is this useful?

I use Go to do a lot of data processing, which is generally from 3rd-parties (aka: customers) so the structure of data is not usually known ahead of time, not to mention weird values being sent due to programming errors and a host of other problems.

Last week, I encountered the first error message above and needed to do some extra work just to determine which property was causing the error, when the encoder should be able to communicate that to the caller.
Repository: go
Issue: cmd/compile: emit variable byte-sized bit tests on amd64
Labels: Performance,compiler/runtime

Conversation moved from CL 109716.

Consider this code from the runtime:

```go
// Information from the compiler about the layout of stack frames.
type bitvector struct {
	n        int32 // # of bits
	bytedata *uint8
}

// ptrbit returns the i'th bit in bv.
func (bv *bitvector) ptrbit(i uintptr) uint8 {
	b := *(addb(bv.bytedata, i/8))
	return (b >> (i % 8)) & 1
}
```

ptrbit should generate a BTL instruction on amd64, but instead it generates RSH and AND. (Related work: CL 105037.) IIRC, we intentionally don't generate BTL instructions for constant-offset bit tests for bytes, since the equivalent TEST instruction is shorter or faster.

cc @rasky
Repository: pytorch
Issue: Fail to import Caffe2Backend
Labels: caffe2

## Issue description
After install Caffe2 from its source following the instruction on a clean VM (CPU only), I can run this [example](https://github.com/caffe2/tutorials/blob/master/Toy_Regression.ipynb). However, the following line produces an error.

home:~/repos/pytorch/build$ python
Python 2.7.14 (default, Sep 23 2017, 22:06:14)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from caffe2.python.onnx.backend import Caffe2Backend
WARNING:root:This caffe2 python run does not have GPU support. Will run in CPU only mode.
WARNING:root:Debug message: No module named caffe2_pybind11_state_gpu
Segmentation fault (core dumped)


## System Info
- PyTorch or Caffe2: Caffe2
- How you installed PyTorch (conda, pip, source):
- Build command you used (if compiling from source): source
- OS: Ubuntu
- PyTorch version:
- Python version: 2.7
- CUDA/cuDNN version: NO GPU
- GPU models and configuration:
- GCC version (if compiling from source): 7.2.0
- CMake version: 3.9.1
- Versions of any other relevant libraries:
Repository: react
Issue: onMouseDown causes splash on real ios browsers
Labels: Type: Bug,Browser: Safari,Component: DOM

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**

*bug*

**What is the current behavior?**

unexpected **grey splash** caused by `onMouseDown` on real ios device's browsers, both safari and chrome.
[Please checkout this **grey splash** issue first](https://github.com/mui-org/material-ui/issues/11154)
I did some trial later, and find out that vanilla html `<button onmousedown="">btn</button>` doesn't cause **grey splash**, but with React's jsx `<button onMouseDown={()=>{}}></button>`, there is a noticeable **grey splash**

**What is the expected behavior?**

who wants a splash?

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

"react": "^16.3.2"
Repository: go
Issue: cmd/compile: use bounded shift information on non-amd64 architectures
Labels: Suggested,Performance,help wanted,compiler/runtime

CL 109776 optimized some shifts on amd64. We should apply the same straightforward optimization rule changes to other architectures.

Might be a good starter SSA issue.

cc @mundaym @cherrymui
Repository: go
Issue: cmd/compile: detect bounded shifts in generic rules
Labels: Performance,compiler/runtime

CL 109776 introduced a mechanism for marking a shift value as being bounded, and used it in the prove pass. @mundaym suggested marking others during generic optimization rule application. This issue is a reminder to follow up on that suggestion.

cc @rasky @mundaym
Repository: go
Issue: cmd/compile: detect bounded shifts of the form (bits-var) in prove
Labels: Performance,compiler/runtime

This is a reminder issue for a suggestion in the review of CL 109776: https://go-review.googlesource.com/c/go/+/109776/1/src/cmd/compile/internal/ssa/prove.go#797.
Repository: rust
Issue: Specialization: assigning associated type in default trait implementation leads typecheck to fail with weird error
Labels: T-lang,A-specialization,A-inference,C-bug,requires-nightly,F-specialization

I have a trait `NodeTrait` that I implemented for `Node` with a default implementation and a specialized one.
The trait has an associated type `Item`.
If I assign the type of `Item` in the specialized implementation, everything works.
If I specify it in the default implementation, I get a weird type check error.


here is the code ([playground](https://play.rust-lang.org/?gist=e2e5a88851eeb52b576d7113a586d906&version=nightly&mode=debug))
```rust
#![feature(specialization)]
use std::marker::PhantomData;

struct Node<T>(PhantomData<T>);
struct Foo;

trait NodeTrait {
    type Item;
    fn foo(&self, a: Self::Item);
    fn bar();
}

default impl<T> NodeTrait for Node<T> {
    type Item = u32; // if you comment this one

    default fn foo(&self, a: Self::Item) {
    }
}

impl NodeTrait for Node<Foo> {
    //type Item = u32; // and uncomment this one, it works
    fn bar(){}
}

fn main() {
    let a = Node::<Foo>(PhantomData);
    a.foo(0u32);
}
```
and the error
```
27 |     a.foo(0u32);
   |           ^^^^ expected associated type, found u32
   |
   = note: expected type `<Node<Foo> as NodeTrait>::Item`
              found type `u32`
```

FYI, my understanding of specialization is still very light, it might be expected behavior and not a bug.
Repository: rust
Issue: Linking dylib with "lto = true": assertion failed: !is_full_lto_enabled(sess)
Labels: A-linkage,I-ICE,T-compiler,C-bug

Approximate file tree:
```
├── Cargo.lock
├── Cargo.toml
├── src
│   └── main.rs
└── test_dylib
    ├── Cargo.toml
    └── lib.rs
```

Top-level Cargo.lock:

```
[profile.release]
lto = true

[dependencies]
test_dylib = { path = "test_dylib" }
```

test_dylib/Cargo.toml:

```
[lib]
path = "lib.rs"
crate-type = ["dylib"]

[profile.release]
lto = true
```

Snippet of output from `RUST_BACKTRACE=1 cargo build --release --verbose`:

```
Running `rustc --crate-name test_package src/main.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C metadata=7e778ca5edc7bd6e -C extra-filename=-7e778ca5edc7bd6e --out-dir /src/test_package/target/release/deps -L dependency=/src/test_package/target/release/deps --extern test_dylib=/src/test_package/target/release/deps/libtest_dylib.so -L native=/src/test_package/target/release/build/ring-9d649aa185d933e6/out`
thread 'rustc' panicked at 'assertion failed: !is_full_lto_enabled(sess)', librustc_trans/back/link.rs:1318:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:380
   3: std::panicking::default_hook
             at libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:576
   5: std::panicking::begin_panic
   6: rustc_trans::back::link::link_args
   7: rustc_trans::back::link::link_natively
   8: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::join_trans_and_link::{{closure}}
   9: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::join_trans_and_link
  10: rustc_driver::driver::compile_input
  11: rustc_driver::run_compiler

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.25.0 (84203cac6 2018-03-25) running on x86_64-unknown-linux-gnu

error: Could not compile `test_package`.

Caused by:
  process didn't exit successfully: `rustc --crate-name test_package src/main.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C lto -C metadata=7e778ca5edc7bd6e -C extra-filename=-7e778ca5edc7bd6e --out-dir /src/test_package/target/release/deps -L dependency=/src/test_package/target/release/deps --extern test_dylib=/src/test_package/target/release/deps/libtest_dylib.so -L native=/src/test_package/target/release/build/ring-9d649aa185d933e6/out` (exit code: 101)

```
Repository: TypeScript
Issue: Cannot use variable from common deconstruction into the initialising expression of another one when strictNullChecks is on
Labels: Bug

**TypeScript Version:**  2.8.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- deconstruction with initialzers 
- strictNullCheck

**Code**
If I use `tsc --strictNullChecks` I will get the following errors
```ts
// strictNullCheck should be enabled

// deconstruction of an array
const arr: number[] = [1];
const [a, b = a] = arr; // Variable 'a' is used before being assigned.

// deconstruction of an object
const obj: { x: number, y?: number } = { x: 1 };
const { x, y = x } = obj; // Variable 'x' is used before being assigned.
```

**Expected behavior:**
No errors as in the case when strictNullChecks is off.

**Actual behavior:**
The compiler raises the errors about unassigned variables using in initialising expressions.

**Playground Link:** [demo code](https://www.typescriptlang.org/play/index.html#src=%2F%2F%20strictNullCheck%20should%20be%20enabled%0D%0A%0D%0A%2F%2F%20deconstruction%20of%20an%20array%0D%0Aconst%20arr%3A%20number%5B%5D%20%3D%20%5B1%5D%3B%0D%0Aconst%20%5Ba%2C%20b%20%3D%20a%5D%20%3D%20arr%3B%20%2F%2F%20Variable%20'a'%20is%20used%20before%20being%20assigned.%0D%0A%0D%0A%2F%2F%20deconstruction%20of%20an%20object%0D%0Aconst%20obj%3A%20%7B%20x%3A%20number%2C%20y%3F%3A%20number%20%7D%20%3D%20%7B%20x%3A%201%20%7D%3B%0D%0Aconst%20%7B%20x%2C%20y%20%3D%20x%20%7D%20%3D%20obj%3B%20%2F%2F%20Variable%20'x'%20is%20used%20before%20being%20assigned.%0D%0A) - `strictNullChecks` should be enabled
Repository: angular
Issue: Service Worker: Hash Mismatch
Labels: feature,area: service-worker,feature: under consideration

I'd like to use this to start a discussion based upon a topic I talked about with @gkalpak at ng-conf 2018.

As mentioned in #21288, the service worker implementation checkes the hashes of the cached files and if they don't match, it just serves the data from the network (which is like having no service worker).

The problem is that every proxy on the web can manipulate the files downloaded. This is especially the case for mobile providers that are minifying and inlining a lot of stuff on the fly to save bandwith. But also tools like live-server change the index.html (and so they can be used to reproduce this issue).

As one of the big use cases for PWAs are areas with low bandwith, this is somehow conflicting.

Perhaps one way to solve this is to provide an exchangeable HashCheckStrategy. In cases where I as the programmer wants to take the responsiblity for not checking the hashes in order to bypass this issue, I could write sth like this:

```
export class BruceWillisHashCheckStrategy implements HashCheckStrategy {
     check(currentHash, expectedHash, fileName) {
         return true;
     }
}
```
Repository: flutter
Issue: provide terse, actionable, flutter doctor output
Labels: tool,t: flutter doctor,P2,team-tool,triaged-tool

As a follow-up to https://github.com/flutter/flutter/pull/14173#issuecomment-384990179, I think we should:
- unify the `flutter doctor` and `flutter doctor -v` output, and
- remove the `-v` option

We see issues coming in w/o the `-v` text, and it would be good to have the default output of the tool be the one that is useful for diagnosing problems and attaching to issues. I believe the motivation for creating the summary version of the output was that the default version became too long. If so, we should just look to condense the longer version - make sure that it doesn't produce more than a page of output on a typical terminal window.

/cc @jcollins-g
Repository: go
Issue: cmd/go: support ldflags -X with gccgo
Labels: NeedsFix

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
1.10

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/dma2/Code/go"
GORACE=""
GOROOT="/home/dma2/Code/go/src/github.com/cloudflare/tls-tris/_dev/go1.10"
GOTOOLDIR="/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1"
GCCGO="/usr/bin/gccgo"
CC="/usr/bin/gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build074293983=/tmp/go-build -gno-record-gcc-switches"
CXX="/usr/bin/g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

### What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

This works:
go build
go build -compiler gccgo

This doesn't:
go build -compiler gccgo -gccgoflags "-X main.gbBuildTime=$(date +'%Y.%m.%d.%H%M%S') -X main.gbCommitHash=$(git log --pretty=format:'%h' -n 1) -X main.gbGitVersionTag=$(git describe) -X main.gbMfwlibGitVersionTag=$(git --git-dir ../mfwlib/.git describe)"

### What did you expect to see?
No errors.  I wish to set some go variable using gccgoflags as I would use them with -ldflags.
I also wish more documentation as to how to set go variables when using gccgo and gccgoflags rather than go and ldflags.

### What did you see instead?
# github.com/go-sql-driver/mysql
gccgo: error: main.gbBuildTime=2018.04.30.102007: No such file or directory
gccgo: error: main.gbCommitHash=770fe0e: No such file or directory
gccgo: error: main.gbGitVersionTag=v1.14: No such file or directory
gccgo: error: main.gbMfwlibGitVersionTag=v1.55: No such file or directory
gccgo: error: unrecognized command line option ‘-X’
gccgo: error: unrecognized command line option ‘-X’
gccgo: error: unrecognized command line option ‘-X’
gccgo: error: unrecognized command line option ‘-X’