sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/link: TestDWARF failing under all.bash on OSX 10.13.6
Labels: OS-Darwin,NeedsInvestigation,compiler/runtime

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.5 darwin/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tham/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tham/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/tham/opt/go"
GOTMPDIR=""
GOTOOLDIR="/Users/tham/opt/go/pkg/tool/darwin_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=/var/folders/jw/jl09r8zn7yxcg04glntytrl07k6c17/T/go-build179495697=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

### What did you do?
Try to build go from source. 
1. Clone from github mirror
2. checkout 52d020260
3. run all.bash from src directory
<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->



### What did you expect to see?
successful build


### What did you see instead?
--- FAIL: TestDWARF (3.88s)
    --- FAIL: TestDWARF/testprogcgo (1.95s)
        dwarf_test.go:98: decoding dwarf section info at offset 0x0: too short
FAIL
FAIL    cmd/link        5.179s
--- FAIL: TestRuntimeTypeAttrExternal (1.02s)
    dwarf_test.go:945: error reading DWARF: decoding dwarf section info at offset 0x0: too short
FAIL
FAIL    cmd/link/internal/ld    2.336s
Repository: flutter
Issue: video_player Image Thumbnail
Labels: c: new feature,a: video,p: video_player,package,c: proposal,team-ecosystem,P2,triaged-ecosystem

The video_player plugin does not document how you can use it with image thumbnails to implement an image thumbnail from a video frame within the video to display as an image cover like YouTube and Instagram does for videos
Repository: TypeScript
Issue: Upgrading from 3.0.3 to 3.1.1 breaks underscore type definition
Labels: Bug

<!-- 🚨 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.1 up to the latest 3.3.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
underscore TS2339 property does not exist

**Code**

```ts
// have @types/underscore installed
_.each([1,2,3,4], x => console.log(x));
```

**Expected behavior:**

Compile successfully

**Actual behavior:**
In TS 3.0.3, compile successfully
In TS 3.1.1, compile failed with error

     error TS2339: Property 'each' does not exist on type 'typeof _'.
Repository: javascript
Issue: Documentation conflicts with object-property-newline setting?
Labels: pull request wanted

It seems like the documentation consistently promotes having a new line for each item in multiline lists, whether it be in a [function invocation](https://github.com/airbnb/javascript#functions--signature-invocation-indentation) or in [an array](https://github.com/airbnb/javascript#arrays--bracket-newline) (both of which mention bad examples of not having each item on a new line).

And even the [object examples](https://github.com/airbnb/javascript#objects--quoted-props) (although not referring to this specific rule) seem to favor this approach.

With that said, what is the reasoning behind [allowing object properties to all appear on the same line](https://github.com/airbnb/javascript/blob/17e0454672f784772c5f5ab052523a93229d9adf/packages/eslint-config-airbnb-base/rules/style.js#L406)?

It would seem more consistent to remove that option for `object-property-newline`. But at the very least, the reasoning and/or use case should probably be documented.
Repository: pytorch
Issue: Support callables in scripted functions
Labels: oncall: jit,jit-backlog

## 🚀 Feature
Allow for callables (notably other scripted functions or ScriptModules) to be passed to scripted functions (Currently fails with `cannot call a value`).

## Motivation

Attempting to tease out fusions from larger codebases (in my case maskrcnn_benchmark) where some blocks of code may not be scriptable, but subsets of those blocks may be. In a concrete example, I have a module which contains loop over sets of inputs & modules, where `z = module(x) + y` is seen. `module` is itself a ScriptModule, and I'd like to be able to add the `+` to a fused group that's already being generated within that ScriptModule. However, there are several things that prevent the outermost module from being scripted. Pulling out the relevant code to a separate function like:

```
@torch.jit.script
def impl(m, x. y):
    return m(x) + y
```
Should allow the desired fusion, but is currently not supported.

## Pitch

Allow callables (at least ScriptModules) to be passed as arguments to scripted functions and called.

## Alternatives

My specific use-case disappears as the scripting supports a certain level of python, but I would expect there to be other use-cases.

## Additional context

This is a proxy code I wrote to make sure that the error I was seeing wasn't from the larger application. This fails with `cannot call a value`. 

```
import torch

class Bias(torch.jit.ScriptModule):
    def __init__(self, num_channels):
        super(Bias, self).__init__()

        self.bias = torch.nn.Parameter(torch.zeros(num_channels))

    @torch.jit.script_method
    def forward(self, x):
        return x + self.bias.reshape(1, -1, 1, 1)

@torch.jit.script
def fwd_impl(b, x, y):
    return b(x) + y

# Note: Not-scriptable in real app
class OuterModule(torch.nn.Module):
    def __init__(self, n):
        super(OuterModule, self).__init__()
  
        self.bias = Bias(n)

    def forward(self, x, y):
        return fwd_impl(self.bias, x, y)

n, c, h, w = 32, 4, 16, 16
x = torch.randn(n, c, h, w).cuda()
y = torch.randn(n, c, h, w).cuda()
m = OuterModule(c).cuda()

with torch.no_grad():
    z = m(x, y)
```


cc @suo
Repository: go
Issue: x/sys/cpu: report core information and speed
Labels: NeedsDecision,FeatureRequest

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

N/A. all of them?

### What did you do?

Tried to use existing packages to get information about CPU core count, clock speed, and so on. Among them, `gopsutil`, `intel-go/cpuid`, and `klauspost/cpuid`. They all do some of what would be desireable.

### What did you expect to see?

A way to get CPU model name (if available), core counts, and ideally some kind of clock speed information.

### What did you see instead?

A tangled mishmash of possibilities. I can't find *anything at all* on Linux that can give the CPU's officially-rated clock speed that isn't "get the brand string and parse it manually". On darwin/freebsd, gopsutil gets reasonable numbers by parsing sysctl output. On Linux, it uses something from /sys, but it gets the "max" CPU speed -- thus, for a 3.00GHz Xeon with a "max" speed of 4.00GHz, it reports 4000MHz. cpuid can accurately report on cores/threads (aka logical cores) for a single chip, but can't tell you how many chips the machine has. gopsutil can report the number of physical cores on a Mac (you would see a single CPU entry with 2 cores for a typical 2-core i5), but can't tell you about threads or logical cores. on Linux, the same machine would show 4 1-core CPUs, but if you used a map to check for unique core ID strings, you could infer that there were two distinct cores available.

This is the sort of thing where the go runtime probably already has decent insight into core count, for instance, and I think the proliferation of not-quite-working methods for getting this information is a problem. I briefly considered writing my own, but I think that would be a very bad idea. I guess I'm sort of half volunteering to implement a simple starting point for this for at least some targets, but I don't have access to a broad enough pool of targets to implement it competently for everything.

For benchmarking-type purposes, I think both logical and physical core counts (or threads/cores, depending on terminology) would be extremely valuable to developers. Clock speed(s) less so, but they can still be a handy reference point for looking at what hardware a given test was run against.
Repository: go
Issue: cmd/go: standard-library vendoring in module mode
Labels: Proposal,Proposal-Accepted,early-in-cycle,modules

This proposal is both a fix for #26924, and a means for users to explicitly upgrade the `golang.org/x` dependencies of the standard library (such as `x/crypto` and `x/net`).

### Proposal

The standard library will ship with three go.mod files: `src/go.mod` (with module path `std`), `src/cmd/go.mod` (with module path `cmd`), and `misc/go.mod` (with module path `misc`).

The `std` and `cmd` modules will have `vendor` directories, containing `modules.txt` files in the usual format and managed using the standard Go 1.13 vendoring semantics (hopefully #30240).

The `std` and `cmd` modules differ somewhat from ordinary modules, in that they do not appear in the build list.
* No module outside `GOROOT/src` may declare its own module path to begin with `std` or `cmd`.
* No module may explicitly `require`, `replace`, or `exclude` any module whose path begins with `std` or `cmd`. (Their versions are fixed to the Go release in use.)

For files within `GOROOT/src` only, when we resolve an import of a package provided by an external module, we will first check the build list for that module.
* If the build list does not contain that module, or if the version in the build list is strictly older than the one required by the standard-library module containing the file, then we will resolve the import to a directory in the standard library, and the effective import path will include the explicit prefix `vendor` or `cmd/vendor`.
   * The explicit prefix ensures that no two packages in the build will have the same import path but different source code.
   * It also ensures that any code loaded from a valid module path has a corresponding module in the build list.
* If the version in the build list is equal to than the one required by `std` or `cmd`, that version is not `replace`d in the main module, and the package exists in the corresponding `vendor` directory, then we will load the package from `vendor` or `cmd/vendor` with its original import path.
   * This eliminates network lookups if the main module is `std` or `cmd` itself (that is, if the user is working within `GOROOT/src`).
   * We assume that the code in `GOROOT/src/vendor` and `GOROOT/src/cmd/vendor` will remain pristine and unmodified.
* If the version in the build list is greater than the version required by `std` or `cmd`, or if the version is equal and the module is `replace`d, then we will load the package from the module cache in the usual way.
   * This may cause substantial portions of the library to be rebuilt, but will also reduce code duplication — which should result in smaller binaries.
Repository: godot
Issue: TextureAtlas doesn't work in shader when passed as sampler2D
Labels: bug,topic:rendering,confirmed

Godot version: 3.0.6


Window 7 Home 64 bit

passed a texture atlas to a shader for palette swapping it seems like the shader ignores the texture atlas crop.

- make a shader material 
- copy the shader code below and paste it as your shader code
- copy the palette image to your project
- create two texture atlases 1 with a rect of 0,0,4,1 and 1 with a rect of 0,1,4,1
- pass these texture atlases as parameters to the shader.
- see that the shader does not update the color.

if you use separate images it works.


    shader_type canvas_item;
	
	uniform sampler2D palette_old; //the color to test against
	uniform sampler2D palette_new; //the target color
	uniform float     threshold; 
	
	//get the texture color
	void fragment()
	{
		vec4  texture_col  = texture    (TEXTURE,     UV);
		int   palette_size = textureSize(palette_old,  0).x;
		
		for (int i = 0; i < 4; i ++)
		{
			vec4 palette_col_old = texelFetch(palette_old, ivec2(i, 0), 0);
			vec4 palette_col_new = texelFetch(palette_new, ivec2(i, 0), 0);
			if (distance(texture_col.rgb, palette_col_old.rgb) < threshold) 
			{
			    texture_col.rgb = palette_col_new.rgb; break;
			}
		}
		COLOR = texture_col;
	}

![pal8](https://user-images.githubusercontent.com/2453707/52828177-9aa39300-307c-11e9-8b6e-711cc4379694.png) <-- palette
Repository: pytorch
Issue: Conv2d layers should accept 4-tuple for padding argument
Labels: module: nn,module: convolution,triaged,enhancement

## 🚀 Feature
Currently Conv2d layers supports int or tuple however tuple is only allowed to be 2-tuple. So this only supports symmetrical padding case. This should be 4-tuple to allow for asymmetrical padding. This will be required anytime we are trying to mix and match odd and even sized inputs and kernels.

## Pitch and Motivation

One of the first issue users coming from TensorFlow encounter is lack of feature `padding='SAME'`. This feature has allowed users to quickly prototype without having to dive into convolutional arithmetic for network design. There have been [some reservations](https://github.com/pytorch/pytorch/issues/3867) for adding this feature despite of strong demand from users. I think the least we can probably do is above simple change that hopefully won't cause any other issues.

## Alternatives

Current alternative for users is to spend time in learning and extracting formulas for convolutional arithmetic, computing neccessory padding and use either `F.pad` or padding layers (which are unfortunately not easily discoverable). 

Another alternative is to discover various threads like [1](https://discuss.pytorch.org/t/padding-for-convolutions/5881/5), [2](https://discuss.pytorch.org/t/utility-function-for-calculating-the-shape-of-a-conv-output/11173/2), [3](https://github.com/pytorch/pytorch/issues/3867) and piece togather some workaround proposed from various answers. 

cc @albanD @mruberry @jbschlosser
Repository: go
Issue: wiki: CodeReviewComments should more thoroughly describe test helper functions
Labels: NeedsDecision

The document already covers testing helper functions, and how to use them. I propose to add instructions how to write testing helper functions. Two things that I thought of are:

1. The first argument should always be `t *testing.T`.
2. The first line of the function should be `t.Helper()`.

The reason for this issue is that currently context is instructed to be the first argument of a function. A testing helper function that I wrote `testCtx(t *testing.T, ctx context.Context)` result in a lint warning - context should always be the first argument. I opened golang/lint#422 and created a fix golang/lint#423, but it was declined for the reason that lint enforces only what's in EffectiveGo and CodeReviewComments.

The current state is that if I want to have this function I should declare it as  `testCtx(ctx context.Context, t *testing.T)` which fills wrong to me.
Repository: vscode
Issue: Restart task fails if task already completed
Labels: feature-request,tasks

We have writ
Issue Type: <b>Bug</b>

Build tasks are often quite long (especially when building for embedded systems) and it's common for them to throw up intermediate errors before completion.  

In this case a typical pattern is ...
- start build task
- spot error report in early build output
- edit offending file
- run build task again 

At this stage if the original build task is still running a dialog is presented giving the option to terminate/restart.  

If 'restart' is chosen but the task completed while the dialog was being presented, you get another error saying the task couldn't be terminated. (Although this may be technically correct, failing to terminate because the task has already closed doesn't really seem like something worth reporting.)

Really the behaviour I want is for CTRL-B to just terminate any current build tasks and start a new one unconditionally.  Perhaps there is a way to customise preferences to get this behaviour?  (Goes off to explore options...)

VS Code version: Code 1.31.1 (1b8e8302e405050205e69b59abb3559592bb9e60, 2019-02-12T02:20:54.427Z)
OS version: Windows_NT x64 10.0.16299

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7 CPU         930  @ 2.80GHz (8 x 2806)|
|GPU Status|2d_canvas: enabled<br>checker_imaging: disabled_off<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: unavailable_off<br>surface_synchronization: enabled_on<br>video_decode: enabled<br>webgl: enabled<br>webgl2: enabled|
|Memory (System)|5.99GB (1.01GB free)|
|Process Argv|--folder-uri file:///j%3A/esp|
|Screen Reader|no|
|VM|0%|

</details><details><summary>Extensions (17)</summary>

Extension|Author (truncated)|Version
---|---|---
Bookmarks|ale|10.2.2
numbered-bookmarks|ale|6.1.0
comments|Ale|1.0.4
vscode-markdownlint|Dav|0.24.0
vscode-instant-markdown|dba|1.4.3
gitlens|eam|9.5.1
json-tools|eri|1.0.2
gc-excelviewer|Gra|2.1.29
mdhelper|jos|0.0.11
python|ms-|2019.1.0
cpptools|ms-|0.21.0
csharp|ms-|1.17.1
PowerShell|ms-|1.11.0
team|ms-|1.144.1
platformio-ide|pla|1.6.0
powerquerymlanguage|sea|1.0.0
vscodeintellicode|Vis|1.1.3


</details>
<!-- generated by issue reporter -->ten the needed data into your clipboard because it was too large to send. Please paste.
Repository: flutter
Issue: Flutter test coverage will not report untested files
Labels: a: tests,c: new feature,tool,dependency: dart,P2,team-tool,triaged-tool

I run the `flutter test --coverage` as follows

![image](https://user-images.githubusercontent.com/12691638/52848118-e91e6380-3148-11e9-9092-22577c7e956e.png)

![image](https://user-images.githubusercontent.com/12691638/52848167-04896e80-3149-11e9-9a35-fd4611ff2ec6.png)

and here are my project's files;

![image](https://user-images.githubusercontent.com/12691638/52848184-0b17e600-3149-11e9-880e-41ad34ac1b55.png)

the generated `Icov.info` looks like this:

```
SF:lib/components/button.component.dart
DA:12,1
DA:29,1
DA:45,1
DA:47,1
DA:48,1
DA:49,1
DA:50,1
DA:51,2
DA:52,1
DA:53,1
DA:56,2
DA:57,1
DA:59,2
DA:60,1
DA:61,1
DA:62,1
DA:63,3
DA:64,2
DA:65,1
DA:66,1
DA:67,1
DA:70,1
DA:71,2
DA:72,1
LF:24
LH:24
end_of_record
SF:lib/components/button.css.dart
DA:4,1
DA:6,2
DA:7,2
DA:8,1
DA:10,1
DA:16,3
DA:53,1
DA:73,0
LF:8
LH:7
end_of_record
SF:lib/environment.dart
DA:6,1
DA:8,2
DA:9,1
DA:11,1
DA:13,2
DA:14,2
DA:15,2
DA:16,1
LF:8
LH:8
end_of_record

```

why coverage didn't include the untested files?

i know how to show coverage by tools like `genHtml` `locv-sumary`

I just want to know how to generate the Locv.info that includes untested files in my projects
Repository: go
Issue: cmd/vet: "possible malformed +build comment" check too strict
Labels: NeedsInvestigation,Analysis

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version devel +ffd096db2b Wed Feb 13 05:35:45 2019 +0000 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What did you do?

I have a go generate line that prepends a +build comment to a C file:

<pre>
//go:generate sed -i "1s;^;// +build linux,!android\\n\\n;" wayland_xdg_shell.c
</pre>

### What did you expect to see?
No warning from `go vet` or `go test`.


### What did you see instead?
Running `go vet` or `go test` on the package results in:

<pre>
os/os_wayland.go:14:1: possible malformed +build comment
</pre>

I admit this is a special case.
Repository: rust
Issue: aarch64 ABI: revisit which ZST fields should be filtered from repr(C)
Labels: A-FFI,T-compiler,A-ABI,A-repr

Spawned off of https://github.com/rust-lang/rust/issues/56877#issuecomment-457490611 and https://github.com/rust-lang/rust/pull/57645#issuecomment-456962622

The issues raised by #56877 were partially addressed by PR #57645 but there may be some followup work to do here.

Based on my current understanding, PR #57645 ended up settling on filtering out *all* ZST's when determining if a type is an instance of a so-called "homogeneous aggregate", and the remaining question is whether we have to deal with architecture/target dependencies when resolving the semantic question of whether the Rust type `[T; 0]` should map to the C type`T[0]` or to `T[]`. 

Namely, it sounds like AArch64 may require us to restrict the filtering we do (for determining whether a type is a homogenous aggregate) to just the Rust ZST's like `PhantomData`.

Anyway, this issue is to tracking that leftover work to resolve that question.
Repository: rust
Issue: lldb doesn't print enums
Labels: A-debuginfo,T-compiler

```Rust
enum E1 { A, B }
enum E2 { A1 { x: i32, y: i32 }, B1(u8), C1 }
fn main() {
    let a = E1::A;
    let aa = E2::A1 { x: 42, y: 123 };
    let bb = E2::B1(10);
    let cc = E2::C1;
}
```
Run lldb (without pretty-printers, lldb-1000.0.38.2)
```
(lldb) p a
(main::E1) $0 = A
(lldb) p aa
(main::E2) $1 = {}
(lldb) p bb
(main::E2) $2 = {}
(lldb) p cc
(main::E2) $3 = {}
```

It affects both stable (1.32.0) and nightly (1.34.0) Rust toolchains.
Repository: rust
Issue: support for implementing "extern" functions required by C code when it's declared in a C header/rust-binding
Labels: A-FFI,C-feature-request

Some C libraries require the user of the lib to implement (platform/sys) functions which are then used by the lib.

The library header usually declares the function so you can implement it wherever you want and get a compiler error if the signature has changed and your implementation is thus wrong now.

If I use bindgen to generate rust bindings for such a library I'm unable to implement such functions using rust, because they already are declared as extern to rust and the compiler treats this as duplicate/mismatching implementations.

If I would just blacklist these functions in bindgen so they'd not be part of the generated bindings there'd be no check if my rust function's signature actually matches the one declared in the C header which is installed on the system.

I think the solution to this would be adding a new function-attribute which lets you explicitly implement an extern function in rust.