sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/tools/present: editable code is not sync'd between main slide and presenter slide
Labels: NeedsInvestigation,Tools

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version go1.10.2 linux/amd64

### Does this issue reproduce with the latest release?
yes

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

### What did you do?
Using go "present -notes" to show editing some codes in the editable .code/.play presentation slides  with presenter notes window active.

### What did you expect to see?
The edited codes are synced between the main window and the presenter window.

### What did you see instead?
The edited code is not synced between the two windows. The changes are only shown in the active window, i.e. If editing process in the main window, the codes in the presenter window do not change, and vice versa.

### Notes:
Bug in golang.org/x/tools/cmd/present/static/slides.js
Function setupPlayCodeSync adds EventListener in a loop using variable index i (probably expecting the inputHandler function is instantiated for each Listener).
It is not, there is only one instant of inputHandler, and the variable i will contain the last value of i, which is play.length.

One solution to this is as follow (Javascript coders probably could give better solution):

```
--- golang.org/x/tools/cmd/present/static/slides-orig.js	2017-09-20 21:24:06.052672029 +0700
+++ golang.org/x/tools/cmd/present/static/slides.js	2018-07-02 17:41:45.431850356 +0700
@@ -578,9 +578,10 @@
     var play = document.querySelectorAll('div.playground');
     for (var i = 0; i < play.length; i++) {
       play[i].addEventListener('input', inputHandler, false);
+      play[i].setAttribute('play-index', i);
 
       function inputHandler(e) {
-        localStorage.setItem('play-index', i);
+        localStorage.setItem('play-index', e.target.getAttribute('play-index'));
         localStorage.setItem('play-code', e.target.innerHTML);
       }
     }
```
Repository: rust
Issue: panic! source location information does not account for macro expansion
Labels: A-debuginfo,C-enhancement,T-compiler

Minimal working example ([playground](https://play.rust-lang.org/?gist=87760b03b9820a3b4e8226998cc72e4e&version=stable&mode=debug&edition=2015)): 

```rust
macro_rules! foo {
    ($e:expr) => {
        bar!($e);
        baz!($e);
    }
}
macro_rules! bar {
    ($e:expr) => { assert!($e); }  // line 8
}
macro_rules! baz {
    ($e:expr) => { assert!(!$e); }  // line 11
}

fn main() {
    foo!(true);  // line 15
}
```

produces the following run-time error:

```
thread 'main' panicked at 'assertion failed: !true', src/main.rs:15:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```

Notice how the `panic!` points at line 15, but the error happens at line 11.

Enabling `RUST_BACKTRACE=1` does not help:

```
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
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:463
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:397
   6: playground::main
             at src/main.rs:15
   7: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
   8: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
   9: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
  10: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:374
             at libstd/rt.rs:58
  11: std::rt::lang_start
             at /checkout/src/libstd/rt.rs:74
  12: main
  13: __libc_start_main
  14: _start
```

---

It would be better for `assert!` and similar macros to not construct the error message from a `file:line:col`, but to use something better instead (like a macro-expansion API). 

A much more useful error message would have been:

```
thread 'main' panicked at 'assertion failed: !true', 
  src/main.rs:15:5: foo!(true);
  src/main.rs:11:19: assert!(!$e); 
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
Repository: vscode
Issue: User profile
Labels: feature-request

What am going to ask is huge. I know it might take a lot of work. It is not a small thing but very important for me.

I am using VS Code from day one. And during that time I have few OS reinstalled and one PC change. Every time when that happens I need to install all plugins and configure VS Code again.

Now I've realized that I use VS Code without reinstall for quite a while. 

1. I have pretty much nice setup, which was made through 1-2 years. But I do not remember all changes I made in configuration or all extensions. I remember one day accidentally I found an article that recommended to use some cool font, I followed procedure to install and activate it. Also I've went through so many themes before I've found the one I like.

   But if my PC crashes, I am not sure I'll ever get back to the same setup. Because I do not remember all extensions I have now, and where to look the name of that font and how to activate it. I do not remember name of the theme. So PC crush it will be pretty much devastating experience in terms of IDE setup.

2. I have PC at work and at home and laptop. I have VS Code installed everywhere, I often jump between PCs doing same job and sync through github. But my setup is different on every PC. And it is not something that I like. I cannot find that cool article about that cool font. So I just resigned that this is how it works. Sometimes I want to run a tool and discover it is not here because I did not yet installed it on this VS Code instance.

3. Sometimes I have to code few lined on the PC of other people as a supervisor. But setup of those users completely turn me off. I just cannot work on their color theme and without tools I love and depend on.

4. VS Code become a very advanced, versatile and flexible tool. МЫ Code setup for PHP developer looks and feel different then setup of JS developer or Markdown writer. For instance when I edit markdown files I want wrap lines at 80, when edit JS files I want to wrap limes at 160. And so on.
 
**feature request**

Allow users lo login to VS Code with live ID, and create cloud profile, and VS code not only restore configuration, key map, themes but also installs all extensions I have. If I install something new on PC one, when I open PC two it will automatically update. Also user can create few profiles for example one for working with PHP with needed extensions and theme, another for documentation work with markdown and such. not only user can restore environment, user can have different environments and quickly switch between them.

So I could have uniform experience, where ever I am. Even if I am in internet cafe on the edge of the universe, just install VS Code to write few lines, login, and here we are, MY VS Code. My. Only my, exactly like it was last time i'd opened it on the other edge of the universe.
Repository: rust
Issue: Doc-comments inside using groups 
Labels: T-rustdoc,A-attributes,T-compiler,C-feature-request

The following is currently not permitted:
```rust
pub use third_party::{
    /// Doc-comment explaining reexported entity.
    some_function,
    // Normal comments are allowed, though.
    some_other_function,
};
```

I'm very fond of group usings, so I prefer to use them everywhere, but it is impossible in situations where the documentation is needed (we have encountered this problem [here](https://github.com/exonum/exonum/pull/756/files#diff-db51f3139619c4526a5967fac3ee28d9R42), by the way).
Repository: vscode
Issue: [json] don't suggest top level snippet if there's already an object
Labels: feature-request,json


Issue Type: <b>Bug</b>

- Open one of the user snippets JSON files
- Type " to bring up the empty snippet suggestion
- Tab to insert it

The provided snippet inserts top-level curly braces, which (I don't know JSON) an existing snippet file already has, making the new snippet invalid.

```JSON
// Valid
{
	"Existing Snippet": {
		"prefix": "my_snippet",
		"body": "this is a snippet",
		"description": "I'm an existing snippet"
	}
}

// "End of file expected" warning on the next line
{       
	"snippetName": {
		"prefix": "prefix",
		"body": "snippet",
		"description": "description"
	}
}
```

VS Code version: Code 1.24.1 (24f62626b222e9a8313213fb64b10d741a326288, 2018-06-13T17:51:32.889Z)
OS version: Windows_NT x64 6.3.9600

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz (8 x 2395)|
|GPU Status|2d_canvas: enabled<br>flash_3d: enabled<br>flash_stage3d: enabled<br>flash_stage3d_baseline: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>native_gpu_memory_buffers: disabled_software<br>rasterization: disabled_software<br>video_decode: enabled<br>video_encode: enabled<br>vpx_decode: unavailable_software<br>webgl: enabled<br>webgl2: enabled|
|Memory (System)|15.95GB (10.49GB free)|
|Process Argv|C:\Program Files\Microsoft VS Code\Code.exe|
|Screen Reader|no|
|VM|0%|

</details><details><summary>Extensions (2)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-lua|gcc|0.1.2
color-highlight|nau|2.3.0

(1 theme extensions excluded)

</details>
<!-- generated by issue reporter -->
Repository: go
Issue: gccgo: syscall.Syscall error result is not reliable
Labels: NeedsInvestigation

The implementation of syscall.Syscall in the Go frontend version of the library sets `errno` to `0`, calls the C library function `syscall`, and then checks `errno`.  If the final value of `errno` is not `0`, then `syscall.Syscall` returns a non-nil `error` value.  This is the only documented way to check whether the C `syscall` function failed.  Unfortunately, it is not reliable if a signal handler runs on the thread while `syscall` is executing.  The signal handler may happen to set `errno` to a non-zero value while it executes.  We should figure out a more reliable way to determine whether `syscall` failed.  This may require writing assembly code.
Repository: TypeScript
Issue: Generic methods with type parameters in generic constraints cannot be overridden
Labels: Bug

**TypeScript Version:**  3.0.0-dev.20180630

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** generic method, subclass, override, type parameter constraint

**Code**
```ts
class A {
    m<T, U extends T>(t: T, u: U) { }
}

class B extends A {
    m<T, U extends T>(t: T, u: U) { } 
//  ﹋ error
}
```

**Expected behavior:**
No errors; the `m` method in the subclass has exactly the same signature as the method it is overriding.  

**Actual behavior:**
The compiler warns on the method override `B.m`:
```Property 'm' in type 'B' is not assignable to the same property in base type 'A'.
Type '<T, U extends T>(t: T, u: U) => void' is not assignable 
  to type '<T, U extends T>(t: T, u: U) => void'.
Two different types with this name exist, but they are unrelated.
Types of parameters 'u' and 'u' are incompatible.
Type 'U' is not assignable to type 'T'.
Type 'T' is not assignable to type 'T'. 
Two different types with this name exist, but they are unrelated.
```

Note that even if you change the names of the type parameters in method `B.m`, as in:
```ts
class B extends A {
  m<T2, U2 extends T2>(t: T2, u: U2) { }
}
```
you still get the error `Type 'T' is not assignable to type 'T'. Two different types with this name exist, but they are unrelated.`

If you remove the `extends T` generic constraint, it compiles.

**Playground Link:** 
[here](https://www.typescriptlang.org/play//#src=class%20A%20%7B%0D%0A%20%20m%3CT%2C%20U%20extends%20T%3E%28t%3A%20T%2C%20u%3A%20U%29%20%7B%20%7D%0D%0A%7D%0D%0A%0D%0Aclass%20B%20extends%20A%20%7B%0D%0A%20%20m%3CT%2C%20U%20extends%20T%3E%28t%3A%20T%2C%20u%3A%20U%29%20%7B%20%7D%0D%0A%7D)

**Related Issues:** 
Nothing obviously related;  #23960 maybe?

---

So, is this a compiler bug?  Or is it intended, and if so, what's the reasoning for it?  This issue is inspired by [a Stack Overflow question](https://stackoverflow.com/questions/51137379/override-abstract-method-typescript) that left me scratching my head.
Repository: TypeScript
Issue: Infer project references from common monorepo patterns / tools
Labels: Suggestion,In Discussion,Scenario: Monorepos & Cross-Project References

Genesis: see section "Repetitive configuration" in https://github.com/Microsoft/TypeScript/issues/3469#issuecomment-400439520

## Search Terms

monorepo infer project references automatically yarn lerna workspace package.json

## Suggestion

For common monorepo managers, we should natively understand cross-project references declared in `package.json` as if they were declared in `tsconfig.json`

Open questions:
 * Which formats (lerna, yarn, pnpm, etc) would be supported? Can all of them be consistently detected, or would you need to opt in to a specific "monorepo format" to enable a specific resolution algorithm?
 * How do we find the `tsconfig.json` file? This data is actually not present in the current (non-tsconfig) dependency graph. We could assume it to be in the package root; what if it's elsewhere?
 * Would you need to opt in? Would there be a way to opt out? What should that look like?

## Use Cases

 * Monorepos of all (supportable) flavors

## Examples

https://github.com/RyanCavanaugh/learn-a

This repo has a fair bit of duplication where projects need to write down their dependencies in package.json *and* as references (with different syntax) in `tsconfig.json`.

## 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
* [x] This isn't a runtime feature (e.g. new expression-level syntax)
Repository: flutter
Issue: Material splash persists after leaving/reopening app
Labels: framework,f: material design,customer: mulligan (g3),has reproducible steps,P2,found in release: 3.3,found in release: 3.5,team-design,triaged-design

Internal: b/292548233

If the user leaves the app during a touch interaction, then reopens the app from the device home screen, the material splash is still visible. Instead, I would expect the splash to be completely gone when the app reopens.

This can happen naturally if the user taps a link in the app which bounces them out to a different app. Or a little less naturally, if the user hits the home button while their finger is already resting on the screen.

Some observations:
- It doesn't matter how long the user has been away from the app; if they left with a splash intact then they will briefly see it upon returning.
- Usually the splash fades away upon returning, but sometimes I've gotten it stuck on screen until the next tap interaction.

## Steps to Reproduce

1. Rest your finger on a widget with a material splash and let the splash grow.
2. With your finger still on the screen, press the device's home button to exit the app.
3. Open the app again (and lift your finger off the screen). The splash will still be visible in the app.

For instance, with this layout:
```dart
Widget build(BuildContext context) {
    return Material(
      child: InkWell(
        child: Center(child: Text('hello')),
        onTap: () {},
      ),
    );
```
I captured this screenshot after returning to the app as noted in step 3 above, with no fingers on the screen:
![img_0031](https://user-images.githubusercontent.com/33165921/42188262-08e9d23e-7e08-11e8-9f1d-4e3f0a06d7f6.png)
Repository: godot
Issue: Deleting textures. Scene editor doesn't update sprite which was using it
Labels: enhancement,discussion,topic:editor

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.1.dev.custom_build.ecee0c9
<!-- Specify commit hash if non-official. -->

**OS/device including version:** Windows 10 x64
<!-- Specify GPU model and drivers if graphics-related. -->

**Issue description:** As in issue title. Only updates after restarting.
<!-- What happened, and what was expected. -->

**Steps to reproduce:** Add texture. Create scene with Sprite. Assign texture to the Sprite. Delete texture from FileSystem view(dock). Additionally you can delete it from .import folder (for some reason it won't delete imported version of the texture, also not sure if it's intended). Look at Sprite in Scene editor.
Repository: pytorch
Issue: [Caffe2] Error running net train when running resnet50
Labels: caffe2

## Issue description
I am getting the following error when training resnet50:

E0703 14:25:24.046447 34382 prefetch_op.h:110] Prefetching error basic_string::_M_construct null not valid
E0703 14:25:24.046572 34336 prefetch_op.h:83] Prefetching failed.
E0703 14:25:24.046938 34336 net_simple.cc:68] Operator failed: input: "train_reader" output: "imonaboat/data_nhwc" output: "imonaboat/label" name: "" type: "ImageInput" arg { name: "std" f: 128 } arg { name: "scale" i: 256 } arg { name: "cudnn_exhaustive_search" i: 0 } arg { name: "crop" i: 224 } arg { name: "is_test" i: 0 } arg { name: "use_cudnn" i: 1 } arg { name: "batch_size" i: 32 } arg { name: "mirror" i: 1 } arg { name: "mean" f: 128 } device_option { device_type: 1 cuda_gpu_id: 0 }

## Code example
The error is here: workspace.RunNet(train_model.net.Proto().name)

I am following this tutorial: https://github.com/caffe2/tutorials/blob/master/Multi-GPU_Training.ipynb

- Caffe2:
Repository: flutter
Issue: Row/Column with CrossAxisAlignment.stretch is unclear 
Labels: framework,d: api docs,P2,team-framework,triaged-framework

By answering a lot on stackoverflow I realized many peoples struggle to correctly use `CrossAxisAlignment.stretch` when we want `Row/Column` to take the least amount of cross axis size.



The solution is quite straightforward 

```dart
IntrinsicHeight(
  child: Row(
    crossAxisAlignment: CrossAxisAlignment.stretch,
     ...
  )
)
```

and same thing but with `IntrinsicWidth` for `Column`. But  there's a catch :

This isn't intuitive. It's hard to find `IntrinsicWidth/Height` and understand why and when we should use them. And the warning :
> This class is relatively expensive

adds a layer of fear on the top of the unknown. 

I'll admit even myself when I started flutter spent a few hours in hell trying to achieve such layout.

_____


Taking this into consideration, I think it would be great to either make it more intuitive  or help newcomers discover `IntrinsicHeight/Width`



This could be a new property on `Flex`  such as `crossAxisSize: CrossAxisSize.min` or something similar.

We can also think of a cookbook. Or adding the example from above inside [IntrinsicHeight](https://docs.flutter.io/flutter/widgets/IntrinsicHeight-class.html) documentation as an usage example.
Repository: javascript-algorithms
Issue: Translate to russian
Labels: enhancement

Hello.

I want to translate all README into Russian, are there any rules for translation?
Repository: go
Issue: gccgo: export data linked into binary
Labels: NeedsFix

With gccgo,
```
$ go version
go version go1.10.3 gccgo (GCC) 9.0.0 20180622 (experimental) linux/amd64
$ gccgo --version
gccgo (GCC) 9.0.0 20180622 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```

```
$ go build -gccgoflags="-static-libgo" hello.go
$ objdump -h hello

hello:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
...
 31 .go_export    000363b8  0000000000000000  0000000000000000  002b460b  2**0
                  CONTENTS, READONLY
...
```

Dumping out the .go_export section, it looks like indeed export data. I think it is not needed at run time. It probably should not be linked into the binary.

`-static-libgo` is just for demonstration. The export data also present in the default dynamically linked binary, or completely `-static` binary, though the size varies.

With some big binaries, like kubernetes, the export data can be quite big (over 40% of the binary size).

cc @ianlancetaylor
Repository: go
Issue: cmd/compile: debug info for inlined funcs are sometimes lost
Labels: NeedsInvestigation,Debugging,compiler/runtime

with go version devel +23ce272bb1 Mon Jul 2 17:50:00 2018 +0000 linux/amd64

<pre>
$ cat main.go
package main

import "fmt"

func main() {
        x := &X{Foo: 10}
        y := InlineThis(x, "bar")
        fmt.Printf("Y = %+v\n", y)
}

type X struct {
        Foo int
}

func InlineThis(x *X, s string) int {
        y := x.Foo + len(s)
        return y
}
</pre>

With go1.11, I expected debug info for the InlineThis would be present in the (default) optimized binary,
but it doesn't.

With `--gcflags="-N"`, I could see some trace of InlineThis in the binary.

<pre>
 <1><732df>: Abbrev Number: 3 (DW_TAG_subprogram)
    <732e0>   DW_AT_name        : main.InlineThis
    <732f0>   DW_AT_inline      : 1     (inlined)
    <732f1>   DW_AT_external    : 1
</pre>

@heschik
Repository: go
Issue: runtime: status of relative filenames in //line directives unclear
Labels: Documentation,NeedsFix,compiler/runtime

I'd like to be able to specify relative paths in `//line` directives, but it's unclear whether this is permitted. Experimentally, it seems as though they are not. #3335 and #24183 are both related in terms of trying to specify what's allowed in the directive, but I haven't seen this specific issue mentioned.

(For `runtime.Caller` info, it seems to expect that the filename is an absolute path.)

#### What did you do?

```shell
$ mkdir foo
$ cat > foo/foo.go
package main

func main() {
    asdf
}
$ cat > foo/bar.go
package main

//line baz.go:1234
func quux() {
    asdf
}
$ go build ./foo
```

#### What did you expect to see?

```
# foo
foo/baz.go:1235:5: undefined: asdf
foo/foo.go:4:5: undefined: asdf
```

#### What did you see instead?

```
# foo
baz.go:1235: undefined: asdf
foo/foo.go:4:5: undefined: asdf
```

#### System details

```
go version go1.10.3 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/light/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/light"
GORACE=""
GOROOT="[redacted]"
GOTMPDIR=""
GOTOOLDIR="[redacted]"
GCCGO="gccgo"
CC="clang"
CXX="[redacted]"
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=/tmp/go-build576788924=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.10.3 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.10.3
uname -sr: [redacted]
/lib/x86_64-linux-gnu/libc.so.6: [redacted]
gdb --version: [redcated]
```