sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: runtime: signal handling: sighandler crash due to race with signal.Ignore
Labels: NeedsInvestigation,compiler/runtime

In reviewing @ianlancetaylor's [CL 46003](https://golang.org/cl/46003) (addressing #14571), I noticed what I believe to be a rare race-condition that could result in unexpected termination of a Go program.

I attempted to write a reproducer for the race in question, which would cause the program to erroneously exit if a `_SigKill` or `_SigThrow` signal arrives in between a call to `signal.Notify` and `signal.Ignore` for that signal. The symptom I was looking for is a termination with the same signal number (for `_SigKill`) or a goroutine dump (for `_SigThrow`).

Unfortunately, I am unable to reproduce the race in question because the program instead crashes with a `SIGSEGV` in `runtime.sigfwd`.

sigrace/sigrace.go:
```go
package main

import (
	"os"
	"os/signal"
	"runtime"
	"syscall"
)

func main() {
	signal.Ignore(syscall.SIGHUP)

	go func() {
		runtime.LockOSThread()
		pid := os.Getpid()
		tid := syscall.Gettid()
		for {
			syscall.Tgkill(pid, tid, syscall.SIGHUP)
		}
	}()

	c := make(chan os.Signal, 1)
	for {
		signal.Notify(c, syscall.SIGHUP)
		signal.Ignore(syscall.SIGHUP)
	}
}
```

```
$ go version
go version devel +c4e0e81653 Wed Jun 21 15:54:38 2017 +0000 linux/amd64
$ go build sigrace && ./sigrace
Segmentation fault (core dumped)
```

Investigation with GDB gives the following stack trace:
```
#0  0x0000000000000001 in ?? ()
#1  0x0000000000452a6d in runtime.sigfwd ()
    at /home/bcmills/go/src/runtime/sys_linux_amd64.s:245
#2  0x000000c420053b18 in ?? ()
#3  0x000000000043b665 in runtime.sigfwdgo (sig=1, info=0xc420053d70, ctx=0xc420053c40, ~r3=false)
    at /home/bcmills/go/src/runtime/signal_unix.go:606
#4  0x000000000043a83b in runtime.sigtrampgo (sig=1, info=0xc420053d70, ctx=0xc420053c40)
    at /home/bcmills/go/src/runtime/signal_unix.go:272
#5  0x0000000000452ac3 in runtime.sigtramp ()
    at /home/bcmills/go/src/runtime/sys_linux_amd64.s:265
#6  0x0000000000452bb0 in ?? ()
    at /home/bcmills/go/src/runtime/sys_linux_amd64.s:349
#7  0x0000000000000000 in ?? ()
```

The faulting instruction in `runtime.sigfwd` is the `CALL` instruction that invokes `fwdSig[sig]`

(CC @aclements)
Repository: flutter
Issue: Flutter should respect proxy settings on Windows during Dart SDK download
Labels: tool,platform-windows,P2,team-tool,triaged-tool

I met errors when running flutter doctor. It's related with proxy settings.

## Flutter Doctor
```
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\CNFEHU1>flutter doctor
Checking Dart SDK version...
Downloading Dart SDK 1.24.0-dev.6.7...
Start-BitsTransfer : HTTP status 407: Proxy authentication is required.
At C:\Users\CNFEHU1\Documents\GitHub\flutter\bin\internal\update_dart_sdk.ps1:4
4 char:19
+ Start-BitsTransfer <<<<  -Source $dartSdkUrl -Destination $dartSdkZip
    + CategoryInfo          : InvalidOperation: (:) [Start-BitsTransfer], Exce
   ption
    + FullyQualifiedErrorId : StartBitsTransferCOMException,Microsoft.Backgrou
   ndIntelligentTransfer.Management.NewBitsTransferCommand

Error: Unable to update Dart SDK. Retrying...
```
Repository: go
Issue: encoding/xml: unmarshal only processes first XML element
Labels: NeedsDecision,early-in-cycle

If you Marshal []int{1,2} you get `<int>1</int><int>2</int>`, but then if you Unmarshal it back into a new slice, you get just []int{1}. Unmarshal simply stops after the first top-most XML element, because it is implemented as NewDecoder(bytes.NewReader(data)).Decode(v). When v is not a slice, this makes sense. But if v is a slice there's an argument that maybe Unmarshal should repeat the Decode calls until it reaches the end of the data. That's maybe easier said than done, and also maybe not a compatible change, but we should at least consider it. The Decoder itself is right to process only a single element, since it is processing an arbitrary input stream that might block if one reads too far. But Unmarshal, holding a []byte, has perfect knowledge of the remainder of the stream and might be able to do better. Or perhaps Unmarshal should return an error.

```
package main

import (
	"encoding/xml"
	"fmt"
	"log"
)

func main() {
	x1 := []int{1, 2}
	out, _ := xml.Marshal(x1)
	fmt.Println("XML:", string(out)) // <int>1</int><int>2</int>

	x2 := []int{3}
	if err := xml.Unmarshal(out, &x2); err != nil {
		log.Fatal(err)
	}
	fmt.Println(x2) // [3 1] not [3 1 2]
}
```

In contrast, the equivalent input given to json.Unmarshal produces an error:

```
package main

import (
	"encoding/json"
	"fmt"
	"log"
)

func main() {
	out := []byte("[1] [2]")
	x2 := []int{3}
	if err := json.Unmarshal(out, &x2); err != nil {
		log.Fatal(err) // invalid character '[' after top-level value
	}
	fmt.Println(x2)
}
```

This is more justified in the case of JSON, since Marshaling []int{1,2} does not produce `[1] [2]`.
Repository: three.js
Issue: Soft particles
Labels: Suggestion

Hi guys, I was looking for soft particles for my project, but I did not find anything on that.

Having spent a little time and energy, I still managed to make soft particles and decided to suggest introducing it into the library as a plug-in or something like that.

All the code and how it works I wrote here.
https://discourse.threejs.org/t/soft-particles-render/504/3?u=korner

It would be cool if you could do so

```
material.soft = true;
material.softDistance = 50;
```

But the problem as I understand that it will be necessary to constantly render the texture of the depth.
It is possible to make a condition for rendering

`renderer.softRender = true;`

I think there is little change, you can add it to the library :)
Repository: flutter
Issue: Flutter doctor should tell you that updates to the Android SDK are available
Labels: platform-android,tool,P3,a: plugins,team-android,triaged-android

Currently, it's hard for Flutter users to learn about updates to the Android SDK. This can get them into strange error situations: E.g. if they pull in a plugin that depends on the latest SDK, building your Flutter app will fail with the unhelpful error message: `Could not find com.google.firebase:firebase-auth:11.0.1`. This error can easily be resolved by updating the "Google Repository" component in the Android SDK to the latest version (except the error doesn't tell you to do this).

People, who rarely start Android Studio, don't really have a way of learning about updates to the Android SDK. Maybe we can have a `flutter doctor` check that tells you: BTW, there is an update to the Android SDK available. You should probably download it. (maybe with a link to https://developer.android.com/studio/intro/update.html#sdk-manager)

Bonus points: We could also implement a `flutter update-android` command that brings everything upto date. This could be implemented via the `sdkmanager` CLI from the Android SDK (see https://developer.android.com/studio/command-line/sdkmanager.html#update_all_installed_packages). Or just point to `sdkmanager --update` (if sdkmanager is in the path by default).

/cc @tvolkert @collinjackson @mit-mit
Repository: TypeScript
Issue: ThisType for Ember.computed and Ember.observer
Labels: Suggestion,Needs Proposal

**TypeScript Version:**  2.3.4

Thanks for your work on this great project :)

**Context**
_We are experimenting with TypeScript 2.x in Ember, and the new TypeScript 2.x features really enable us to type most of our Ember code. There is however one thing we came across that doesn't seem like something we can solve in our interfaces/declarations:_

It seems that there currently is no way to get the `this` context inside the Ember.computed and Ember.observer pattern.

**`ThisType` not compatible with Ember.computed and Ember.observer?**

We have set up some experimental interfaces for Ember.Object.extend() (inspired by Vue.js' type declarations, @ember/types and various other sources) 
https://github.com/draios/ember-typescript2/blob/master/app/types/ember/ember-types.d.ts#L78-L83 
These types/interfaces are working so far; all methods and hooks have the proper `this` type, and class properties are accessible through getters and setters.

However when it comes to computed properties, there seems to be no way to get the proper `this` context inside the function passed to Ember.computed() (see example below).


**Code**
```ts
export default Ember.Object.extend({
  myProp: true,

  myMethod: function() {
     // myProp is accessible because of ThisType
     this.get('someProperty');
  }
  computedProperty: Ember.computed('someProperty', function() {
     // myProp is not accessible, because `this` is set to type <any>
     let myVal = this.get('someProperty');

     // ... both `this` and `myVal` are of type <any>
     // and no way to fix this from an external interface?
  });
});


```

Is this Ember pattern supported somehow in TypeScript?

Thanks!

---

N.B. I tried something like the following, but it doesn't work (X becomes of type `{}`).
```
// the function passed to Ember.computed
type ComputedPropertyFunc<T, X> = (this: X) => T

// Ember.computed with one observed property and a function
function computed<T, X>(observedProperty1: string, fn: ComputedPropertyFunc<T, X>): T & ThisType<X>
```
Repository: rust
Issue: macro_rules! macros do not backtrack
Labels: A-macros,C-feature-request

I'm mainly filing this to be able to close other issues whose problems come down to this. I don't know if we want to fix this or will fix this, but at least there will be a single issue for it.
Repository: go
Issue: proposal: net/http/httputil/v2: split into focused subpackages
Labels: v2,Proposal

This proposal builds on https://github.com/golang/go/issues/7907 (remove deprecated stuff) and https://github.com/golang/go/issues/19660 (refactor `ioutil` to provide a coherent abstraction).

`httputil` currently contains:

* `Dump{Request,RequestOut,Response}`: "It should only be used by servers to debug client requests." These would be clearer in a `net/http/debug` subpackage.
* `NewChunked{Reader,Writer}`: "not needed by normal applications. The http package automatically decodes chunking when reading response bodies." Not obvious why it's exported, but it could easily go in a `net/http/chunked` subpackage.
* `ReverseProxy`: Could easily go in a separate `net/http/proxy` subpackage.
* `BufferPool`: has ~nothing to do with HTTP, and if it is still useful implies a garbage-collector issue that we should address instead.
* `ClientConn`: "We should have deleted it before Go 1."
* `ServerConn`: "We should have deleted it before Go 1."

(@bradfitz)
Repository: rust
Issue: Peer credentials on Unix socket
Labels: T-libs-api,C-tracking-issue

https://github.com/tokio-rs/tokio-uds/pull/13 was recently merged, so I'd like to open an issue of adding same thing to stdlib. TL;DR It allows one to get effective UID and GID of the process which created the remote socket.

I suggest to test it with Tokio now and when there is consensus, we can merge similar change. I need this function, so I'm going to test it anyway.
Repository: kubernetes
Issue: Extract application-based upgrade tests to examples repo
Labels: priority/important-soon,kind/cleanup,sig/apps,sig/testing,lifecycle/frozen

These are the tests that verify real app connectivity during node upgrades.  It's testing a confluence of features, but it's also testing that a particular arrangement of StatefulSet/ReplicaSet and PodDisruptionBudget is actually correct for the app in question.

This was brought up during the review of #47200.

These are e2e tests written our e2e/upgrade framework.  So one question is do we start treating the e2e/upgrade framework more like an API that other repos can consume?  (Maybe we're already doing this?)

@maisem @kargakis @kubernetes/sig-testing-bugs
Repository: rust
Issue: *const T has quite a few methods that seem like they don't need to require T: Sized
Labels: C-enhancement,T-libs-api

Not sure which exactly, but we should evaluate and relax bounds where possible.

See also https://github.com/rust-lang/rust/issues/24794, https://github.com/rust-lang/rust/issues/36952.
Repository: bitcoin
Issue: listsinceblock incorrectly showing some conflicted transactions
Labels: Wallet,RPC/REST/ZMQ

Normally when a transaction is conflicted, listsinceblock will show it as having negative confirmations, representing how long ago it conflicted. However, looking at the results of my listsinceblock shows dozens of conflicted transactions with 0 confirmations (as well as transactions whos parents have long been forgotten by the network).

An example:
```
{
  "account": "",
  "address": "1AM7qmzyzkZecxn5hTPUCbBbog3r3YbVyE",
  "category": "receive",
  "amount": 0.00684870,
  "label": "",
  "vout": 0,
  "confirmations": 0,
  "trusted": false,
  "txid": "f108f58235e35f3eb07d24d9d330f6098234137dd505bbd19ff249d809254f2d",
  "walletconflicts": [
  ],
  "time": 1493696422,
  "timereceived": 1493696422,
  "bip125-replaceable": "unknown"
}
```

Which would make you think it's a pending receive, so lets dive deeper:

```
bitcoin-cli gettransaction f108f58235e35f3eb07d24d9d330f6098234137dd505bbd19ff249d809254f2d
{
  ....
  "hex": "0100000001975c0acaefcc4abc471c5d9fe8de6ee5d6e76e7f01a089466f0a73c5f23dc36c000000006b48304502210088baffcff66ade8770a802888c868071291be4f6c6b7427e9938dbf2c9df6ee6022028a9a1af3e7e0ef4cdf42b3b6cc3113787e4db29922c1b90e182b2f1665be83e012102efdaa4cbd4fb4edd41978403a4343786462fefa514f98cbe1894f7053a1216c2ffffffff0146730a00000000001976a9146687296e39b87666fcbff34738c984eca686451e88ac00000000"
}
```

Decoding that, you'll see it's sourcing:
    ```{ "txid": "6cc33df2c5730a6f4689a0017f6ee7d6e56edee89f5d1c47bc4accefca0a5c97", "vout": 0 }```

Which is a transaction that has not confirmed, nor in my nodes mempool. Fortunately we can find it on [tradeblock](https://tradeblock.com/bitcoin/tx/6cc33df2c5730a6f4689a0017f6ee7d6e56edee89f5d1c47bc4accefca0a5c97
), and see it's conflicted with dd0ab2618d4df044d369b56ce96f6f8d9dca6e04f4c180fa73e8ace20b3653e3 which has long confirmed.

So this means that our original transaction is just sitting in listsinceblock is actually conflicted and impossible to ever confirm, yet not marked as such.
Repository: rust
Issue: Add drain_filter for BinaryHeap
Labels: A-collections,T-libs-api,E-help-wanted,C-feature-accepted

`std::collections::BinaryHeap` is missing a `drain_filter` method (rust-lang/rfcs#2140).

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: Document template files in README.md
Labels: framework,d: api docs,P2,team-framework,triaged-framework

Excerpt from #9882 (by @Hixie):

Before we add more files to the template, I think we should make sure the template contains a README that documents, for each file in the template:

- What the file is for
- Why you would edit that file
- How to verify that the edits are valid
- How to test the file

The template is growing really big and it's not at all clear why some of these files are part of the user code and not just part of the framework.
Repository: angular
Issue: ExpressionChangedAfterItHasBeenCheckedError on ngSubmit
Labels: type: bug/fix,freq2: medium,area: forms,state: confirmed,forms: change detection,P4

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MIGHT BE CLOSED WITHOUT INVESTIGATION.
-->

## I'm submitting a ...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (behavior that used to work and stopped working in a new release)
[ x ] Bug report <!-- Please search github for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
<!-- Describe how the issue manifests. -->

When submitting a form through ngSubmit which has transitive from controls an error is thrown iff the form is submitted by pressing enter in a text box (submitting by button works fine). The error is ExpressionChangedAfterItHasBeenCheckedError of a boolean which toggles in the submit function. I don't exactly know the cause.

## Expected behavior
<!-- Describe what the desired behavior would be. -->

No ExpressionChangedAfterItHasBeenCheckedError.

## Minimal reproduction of the problem with instructions
<!--
For bug reports please provide the *STEPS TO REPRODUCE* and if possible a *MINIMAL DEMO* of the problem via
https://plnkr.co or similar (you can use this template as a starting point: http://plnkr.co/edit/tpl:AvJOMERrnz94ekVua0u5).
-->

- Open the demo: https://plnkr.co/edit/vBszgl7DkIYC7Qw2GVhW?p=preview
- Open Console
- Submit once through button and text box.

## What is the motivation / use case for changing the behavior?
<!-- Describe the motivation or the concrete use case. -->

Using transitive forms allows me to abstract behavior that most forms in my app have:
- showing loading animation during submission
- show notification on error
- guard with a confirm prompt

## Please tell us about your environment

<pre><code>
Angular version: v4.2.4
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- [ X ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Platform: plnkr

Others:
<!-- Anything else relevant?  Operating system version, IDE, package manager, HTTP server, ... -->
</code></pre>
Repository: go
Issue: html/template: parse failures lack sufficient context for debugging
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
Unsure; this is in the Blaze version of "go_binary", "go_library", etc. (I'm having difficulty understanding which particular version of Go that is invoking).

### What operating system and processor architecture are you using (`go env`)?
gLinux (Ubuntu 14.04.5 LTS) and also BuildRabbit

### What did you do?

```
import (
   // ...
  "html/template",
   // ...
)

// ...
func CreateTemplate(name, text string) (*template.Template, error) {
    var newTemplate *template.Template
    newTemplate = template.New(name).Funcs(funcMap)
    parsedTemplate, err := newTemplate.Parse(text)
    if error != nil {
                return nil, status.Errorf(
			status.InvalidArgument,
			"error parsing template: %v")
    }
    return newTemplate, nil
}
// ...
```

### What did you expect to see?

When the parsing fails, I expect the error to include sufficient context to diagnose. For example:

error parsing template: template: body:3 unexpected bad character U+002D '-' in command in the vicinity of "{{end-}}"; expected " " or "}}".

### What did you see instead?

The error does not give any context. For example, it prints:

     error parsing template: template: body:3 unexpected bad character U+002D '-' in command

Or:

      error parsing template: template: body:14 unexpected bad character U+002D '-' in template clause

... but doesn't give any surrounding context to understand what the specific error is.
Repository: vscode
Issue: [Feature request] Hide cursor while typing
Labels: feature-request,editor-core

https://superuser.com/questions/928839/what-does-the-hide-pointer-while-typing-feature-actually-do

Can we get this as an option in VS Code?
Repository: rust
Issue: Tracking issue for future-incompatibility lint `late_bound_lifetime_arguments`
Labels: A-lints,A-lifetimes,T-compiler,C-future-incompatibility,C-tracking-issue,T-types

#### What is this lint about

In functions not all lifetime parameters are created equal.
For example, if you have a function like
```rust
fn f<'a, 'b>(arg: &'a u8) -> &'b u8 { .... }
```
both `'a` and `'b` are listed in the same parameter list, but when stripped from the surface syntax the function looks more like
```rust
for<'a> fn f<'b>(arg: &'a u8) -> &'b u8 { .... }
```
where `'b` is a "true" ("early-bound") parameter of the function, and `'a` is an "existential" ("late-bound") parameter. This means the function is not parameterized by `'a`.
To give some more intuition, let's write a type for function pointer to `f`:
```rust
// PtrF is not parameterized by 'a,
type PtrF<'b> = for<'a> fn(&'a u8) -> &'b u8;
// but it has to be parameterized by 'b
type PtrF = for<'a, 'b> fn(&'a u8) -> &'b u8; // ERROR
```
See more about this distinction in http://smallcultfollowing.com/babysteps/blog/2013/10/29/intermingled-parameter-lists/#early--vs-late-bound-lifetimes

When lifetime arguments are provided to a function explicitly, e.g.
```
f::<'my_a, 'my_b>
```
the first argument doesn't make much sense because the function is not parameterized by `'a`.
Providing arguments for "late-bound" lifetime parameters in general doesn't make sense, while arguments for "early-bound" lifetime parameters can be provided.

It's not clear how to provide arguments for early-bound lifetime parameters if they are intermixed with late-bound parameters in the same list. For now providing any explicit arguments is prohibited if late-bound parameters are present, so in the future we can adopt any solution without hitting backward compatibility issues.

Note that late-bound lifetime parameters can be introduced implicitly through lifetime elision:
```rust
fn f(&u8) {}
// Desugars into
fn f<'a>(&'a u8) {} // 'a is late-bound
```

The precise rules discerning between early- and late-bound lifetimes can be found here: https://github.com/rust-lang/rust/blob/91aff5775d3b4a95e2b0c2fe50785f3d28fa3dd8/src/librustc/middle/resolve_lifetime.rs#L1541-L1700

#### How to fix this warning/error

Just removing the lifetime arguments pointed to by the lint should be enough in most cases.

#### Current status
- [x] https://github.com/rust-lang/rust/pull/42492 introduces the `late_bound_lifetime_arguments` lint as warn-by-default
- [ ] PR ? makes the `late_bound_lifetime_arguments` lint deny-by-default
- [ ] PR ? makes the `late_bound_lifetime_arguments` lint a hard error
Repository: rust
Issue: std::fs::canonicalize returns UNC paths on Windows, and a lot of software doesn't support UNC paths
Labels: O-windows,T-libs-api,C-bug,A-io

Hi, I hope this is the right forum/format to register this problem, let me know if it's not.

Today I tried to use `std::fs::canonicalize` to make a path absolute so that I could execute it with `std::process::Command`. `canonicalize` returns so-called "UNC paths", which look like this: `\\?\C:\foo\bar\...` (sometimes the `?` can be a hostname).

It turns out you can't pass a UNC path as the current directory when starting a process (i.e., `Command::new(...).current_dir(unc_path)`). In fact, a lot of other apps will blow up if you pass them a UNC path: for example, Microsoft's own `cl.exe` compiler doesn't support it: https://github.com/alexcrichton/gcc-rs/issues/169

It feels to me that maybe returning UNC paths from canonicalize is the wrong choice, given that  they don't work in so many places. It'd probably be better to return a simple "absolute path", which begins with the drive letter, instead of returning a UNC path, and instead provide a separate function specifically for generating UNC paths for people who need them.

Maybe if this is too much of an incompatible change, a new function for creating absolute paths should be added to std?  I'd bet, however, that making the change to `canonicalize` itself would suddenly make more software suddenly start working rather than suddenly break.