sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: math/rand: tests are too weak due to misuse of statsResults.maxError
Labels: Testing,help wanted,NeedsFix

The math/rand tests use the function `nearEqual` to compare floats:

```go
func nearEqual(a, b, closeEnough, maxError float64) bool {
	absDiff := math.Abs(a - b)
	if absDiff < closeEnough { // Necessary when one value is zero and one value is close to zero.
		return true
	}
	return absDiff/max(math.Abs(a), math.Abs(b)) < maxError
}
```

A bit of thought suggests that `maxError` should always be pretty small, if this function is ever to return false. However, maxError is usually scaled everywhere it is used (e.g. stddev * 0.08), and in practice it frequently ends up >> 2.

As a result, many of the math/rand tests have no teeth. An extreme example of this is TestReadUniformity, which requires (among other things) that the mean of just 2 randomly selected bytes must be very near 255.0/2, a test which should almost always fail, but which currently succeeds, due to a large value of maxError. (Related: [CL 51310](https://go-review.googlesource.com/c/51310/).)

Replacing maxError with a constant `0.08` causes most math/rand tests to pass, except TestReadUniformity when called with small n (in which case it should fail).

However, I don't have enough domain expertise to know whether this is reasonable or whether an alternative bound would be better. Advice requested.

golang.org/s/owners lists no one for math/rand, so I'll guess and cc: @rsc @aclements @robpike
Repository: rust
Issue: Bors: 422 Update is not a fast forward
Labels: A-spurious,T-infra,C-tracking-issue,A-CI

Periodically we'll see bors not manage to push the built PR into master for some reason.

This is possibly because of submodules not being synchronized? Wild stab in the dark.
Repository: TypeScript
Issue: Expose serializers from TypeScript transformer (ts.ts)
Labels: Suggestion,Needs Proposal,API

With the introduction of the Transform API some of the logic in [transformers/ts.ts](https://github.com/Microsoft/TypeScript/blob/30d973bdcbbe2b39723345448cb457ebbc41ae03/src/compiler/transformers/ts.ts) needs to be exposed. (and maybe from other places...)

I'll explain by example:
```ts
@SomeDecorator()
export class MyClass {
  constructor(public myInterface: MyInterface, public myClass: MyOtherClass) {}
}
```

If I want to transform the code so all **parameter** type metadata will be on a static property of the class. (this is angular DI)

```ts
@SomeDecorator()
export class MyClass {
  constructor(public myInterface: MyInterface, public myClass: MyOtherClass) { }

  static ctorParams: [Object, MyOtherClass];
}
```
 
This operation is currently impossible.

To get the right identifier for each type I need to serialize the type with some logic so **MyInterface** will become **Object** since it's not really a value.

The native **TypeScript** transformer has a lot of code for handling the logic of type serialization and it's not something one will want to copy, its huge.

Even if someone decided to replicate the logic, there's not access to the `EmitResolver` which is the "type checker" used by the native transformer to serialize the types.

`TransformationContext.getEmitResolver()` is `@internal`

The workaround is to actually run another `Program` process to get access to a `TypeChecker`.
It's not even possible to get a hold of the current running `Program` instance since `TransformerFactory` does not get access to it.

Is it possible to expose the serializatoin logic in the TypeScript transformer? I know it's complex, recursing and state dependant (scope) but it seems like not being able to serialize a type to create a literal is something basic
Repository: go
Issue: plugin: -buildmode=plugin not supported on linux/mips
Labels: Documentation,NeedsFix,compiler/runtime

According to https://golang.org/pkg/plugin/ plugins under Linux should be supported.

### What version of Go are you using (`go version`)?
go version go1.8.3 linux/amd64
go version devel +ac29f30dbb Fri Jul 28 00:29:08 2017 +0000 linux/amd64

### What did you do?
GOOS=linux GOARCH=mips ./go build -a -buildmode=plugin main.go

### What did you expect to see?
Successfully building mips(32) plugin

### What did you see instead?
"-buildmode=plugin not supported on linux/mips"
Repository: rust
Issue: Tracking issue for tweaks to dyn compatibility (RFC 2027)
Labels: A-trait-system,T-lang,B-unstable,B-RFC-implemented,C-tracking-issue,F-dyn_compatible_for_dispatch,S-tracking-needs-summary

This is the tracking issue for RFC 2027, tweaks to dyn-compatibility[^1] (rust-lang/rfcs#2027)

* [x] Implement (https://github.com/rust-lang/rust/pull/57545)
* [ ] Document
* [ ] Stabilize

[^1]: Formerly known as "object safety".
Repository: go
Issue: x/crypto/acme/autocert: Hooks for "CertAcquired", "CertRenewed"
Labels: NeedsInvestigation

My use-case for ACME / LetsEncrypt is to setup a TLS Listener that isn't a HTTP/HTTPS endpoint. e.g: IRC, or something else.

The code in x/crypto/acme/autocert doesn't make it very obvious how one can identify whether a cert was successfully acquired or renewed. The only solution I've come up with in poking at this is to "watch" for changes to the file system with a file-system implementation of the `Cache` interface.

Is this something we can add or is there a more recommended way to handle this?
Repository: rust
Issue: Xcode Instruments can not read Rust source code automatically.
Labels: O-macos,A-debuginfo,T-compiler,E-help-wanted,C-bug

Since I almost completely misunderstood the issue, I update it.
I am not quite sure if it is related with rustc or not...

In the past, adding `debug = true` into Cargo.toml seemed to enable Rust source code profiling on Xcode Instruments (on macOS).
But at present, it does not work.
Instruments seems to read dSYM file correctly (you can check it via File->Symbols...), but Instruments seems not to know source code path.

Who has a responsibility about the source code path?

[ORIGINAL]
Hi.

In the past, adding `debug = true` into Cargo.toml seemed to enable Rust source code profiling on Xcode Instruments (on macOS).
But at present, it does not work.
Trying to add dSYM path causes the following error.

    No new libraries to symbolicate
    The specified path didn't locate a dSYM for any of the selected libraries.

I will appreciate very much if anyone let me know workarounds or Rust team resolves it kindly.
Thanks.
Repository: kubernetes
Issue: Support httpHead for pod livenessProbe
Labels: sig/node,kind/feature,needs-triage

/kind feature

**What happened**:
The docs for [http liveness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-http-request) only reference `httpGet`, but a http `HEAD` request is better for healthchecks as no data is returned so it is lighter weight.

**What you expected to happen**:
I would expect a httpHead directive to exist. It would perform a request such as:

```
HEAD / HTTP/1.1
```

vs `httpGet`, which does something like:

```
GET / HTTP/1.1
```

**How to reproduce it (as minimally and precisely as possible)**:

Create a livenessProbe and be :disappointed:  that `HEAD` requests aren't available.
Repository: TypeScript
Issue: cannot redeclare exported variable
Labels: Bug,Domain: JavaScript

<!-- BUGS: Please use this template. -->
<!-- QUESTIONS: This is not a general support forum! Ask Qs at http://stackoverflow.com/questions/tagged/typescript -->
<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

**TypeScript Version:**  2.4.2

**Code**

```js
// @ts-check

exports.foo = function() {};
exports.foo = _.memoize(exports.foo);
```

**Expected behavior:**

no errors since this is a commonjs file (`tsconfig.json` configured appropriately) and this is an ok behaviour in Node.js.

**Actual behavior:**

error: cannot redeclare exported variable foo
Repository: electron
Issue: Feature request: <webview> app-manifest-updated event
Labels: enhancement :sparkles:,component/webview

The Electron `<webview>` has events for notifying its parent when web page metadata changes including:
* `page-title-updated` for `<title>` changes
* `page-favicon-updated` for `<link rel=icon>` changes
* `did-change-theme-color` for `<meta name=theme-color>` changes

I'd like to propose a new event which is dispatched when a web app manifest link relation changes:
* `app-manifest-updated` for `<link rel=manifest>` changes

...as defined by [W3C Web App Manifest](https://www.w3.org/TR/appmanifest/) specification and used by modern progressive web apps.

The payload of the event could simply be the URL of the manifest as with icon link relations, or it could be the manifest JSON content itself with Electron responsible for fetching the manifest in a fully spec compliant way (e.g. using the correct browsing context and supporting HTTP authenticated manifests etc).

For prior art, see the vendor-prefixed [`mozbrowsermanifestchanged` event](https://developer.mozilla.org/en-US/docs/Web/Events/mozbrowsermanifestchange) in Gecko's Browser API (similar to Electron's Webview API).

The use case of this event is to detect when the current web page is part of a web app that can be installed, and use the manifest metadata to install the web app into a web app runtime.

The event name could be different to what I propose here, but note that a web app manifest applies to a whole web app or website which may consist of multiple pages, it it not strictly page metadata in the way that a `<title>` is.
Repository: rust
Issue: Final link failed (with CARGO_INCREMENTAL)
Labels: A-linkage,T-compiler,A-incr-comp,C-bug

Sometimes (it's not always reproducible and it doesn't happen with some specific code), I get a linker error complaining undefined references to rust functions in my project, something like this:

```
  = note: /home/vorner/work/pakon/aggregator/target/debug/deps/aggregator-57e8a9355952fffd.aggregator-keeper-query-tests.o: In function `aggregator::keeper::query::tests::time_to_system':
          /home/vorner/work/pakon/aggregator/src/keeper/query.rs:414: undefined reference to `aggregator::keeper::query::Time::to_absolute::h1a0a7dea62a07bb1'
          /home/vorner/work/pakon/aggregator/src/keeper/query.rs:421: undefined reference to `aggregator::keeper::query::Time::to_absolute::h1a0a7dea62a07bb1'
          /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /home/vorner/work/pakon/aggregator/target/debug/deps/aggregator-57e8a9355952fffd: hidden symbol `_ZN10aggregator6keeper5query4Time11to_absolute17h1a0a7dea62a07bb1E' isn't defined
          /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value
          collect2: error: ld returned 1 exit status
```

They don't go away even when I modify the sources and try to compile again. These things help:
* Running `cargo clean` and trying again.
* Running the compilation *without* CARGO_INCREMENTAL (I have it set in my environment).

Therefore, I believe sometimes rustc produces and stores part of the compilation without the function present and tries to reuse it next time. I further suspect this might happen when the function is unused at the first compilation, but then I add a test that uses it ‒ maybe some kind of optimisation producing the module (or struct's impl) without the code for the unused function and caching it, not noticing it is missing the next time.

It happens more often when I code with `cargo watch --no-restart -x test --all` in a separate terminal and save the file often (maybe simply because the compilation is run more often).

```
$ rustc --version --verbose
rustc 1.21.0-nightly (aac223f4f 2017-07-30)
binary: rustc
commit-hash: aac223f4f5d5ca979c694b614d4db37a7200528d
commit-date: 2017-07-30
host: x86_64-unknown-linux-gnu
release: 1.21.0-nightly
LLVM version: 4.0
```
Repository: TypeScript
Issue: File altered by before transform does not remove new unused imports
Labels: Bug,API,Domain: Transforms

**Description of the bug:**  

When using a before transform that makes an import unused, the import will not be removed by TypeScript.

So if I have:
```ts
import { unused } from 'unused-module';
import { something } from 'some-module';
const value = something;
```

And replace `const value = something` with
```ts
import { somethingElse } from 'some-other-module';
const value = somethingElse;
```

The `import { unused } from 'unused-module';` statement will be removed, but `import { something } from 'some-module';` will remain:

```ts
import { something } from 'some-module';
import { somethingElse } from 'some-other-module';
const value = somethingElse;
```

**TypeScript Version:**  2.4.2

**Code**

```ts
import { unused } from 'unused-module';
import { something } from 'some-module';
const value = something;
```
Reproduction of this bug requires using the transforms API.

I have prepared a repository with a simple reproduction that runs this file: https://github.com/filipesilva/ts-transform-import-bug/blob/master/test.ts

```
git clone https://github.com/filipesilva/ts-transform-import-bug
cd ts-transform-decorator-bug
npm install
npm test
```

**Expected behavior:**
All unused imports are removed.
```ts
import { somethingElse } from 'some-other-module';
const value = somethingElse;
```

**Actual behavior:**
Only imports there were unused before the transformed are removed.
```ts
import { something } from 'some-module';
import { somethingElse } from 'some-other-module';
const value = somethingElse;
```

/cc @rbuckton
Repository: vscode
Issue: macOS: Copying text to clipboard does not preserve tabs
Labels: bug,macos,editor-clipboard

This might be an Electron problem rather than VS Code, but copying text to the clipboard does not preserve tabs. Instead, it converts the tabs to an appropriate number of non-breaking space characters.

Here is `settings.json`:

```javascript
{
    "editor.fontFamily": "'SFMono Light', Hack, Menlo, Monaco, 'Courier New', monospace",
    "editor.minimap.enabled": false,
    "editor.fontSize": 15,
    "editor.renderIndentGuides": true,
    "terminal.integrated.fontSize": 14,
    "editor.insertSpaces": false,
    "editor.autoIndent": false,
    "editor.detectIndentation": false
}
```

- VSCode Version: Code 1.14.2 (cb82febafda0c8c199b9201ad274e25d9a76874e, 2017-07-19T23:22:50.650Z)
- OS Version: Darwin x64 16.7.0
- Extensions: 

Extension|Author (truncated)|Version
---|---|---
EditorConfig|Edi|0.9.4
angular1-code-snippets-johnpapastyle|lpe|0.1.0
guides|spy|0.8.4
---

Steps to Reproduce:

1. Insert text with tabs
2. Copy text to clipboard
3. Clipboard contents have non-breaking spaces instead of tabs

<!-- Launch with `code --disable-extensions` to check. -->
Reproduces without extensions: Yes
Repository: rust
Issue: Tracking issue for oom=panic (RFC 2116)
Labels: B-RFC-approved,A-allocators,T-lang,T-libs-api,C-tracking-issue,Libs-Tracked,S-tracking-ready-to-stabilize

**Update:** This now the tracking issue for a mechanism to make OOM / memory allocation errors panic (and so by default unwind the thread) instead of aborting the process. This feature was accepted in RFC https://github.com/rust-lang/rfcs/pull/2116.

It was separated from https://github.com/rust-lang/rust/issues/48043, which tracks another feature of the same RFC, since the two features will likely be stabilized at different times.

**Blockers**

This should be blocked until we can audit all places in the code that allocate to ensure they safely handle unwinding on OOM.

- [x] https://github.com/rust-lang/rust/issues/123369
- [ ] https://github.com/rust-lang/unsafe-code-guidelines/issues/506

**Steps:**

- [ ] Implement the RFC
  - [ ] `std::alloc::set_allocation_error_hook` (tracked at https://github.com/rust-lang/rust/issues/51245) could potentially be this mechanism, but that hook is currently document as not allowed to unwind.
- [ ] Adjust documentation ([see instructions on forge][doc-guide])
- [ ] Stabilization PR ([see instructions on forge][stabilization-guide])

[stabilization-guide]: https://forge.rust-lang.org/stabilization-guide.html
[doc-guide]: https://forge.rust-lang.org/stabilization-guide.html#updating-documentation


Original feature request:

----

Several users who are invested in the "thread is a task" model that Rust was originally designed around have expressed a desire to unwind in the case of OOM. Specifically each task has large and unpredictable memory usage, and tearing down the first task that encounters OOM is considered a reasonable strategy.

Aborting on OOM is considered unacceptable because it would be expensive to discard all the work that the other tasks have managed to do.

We already (accidentally?) specified that all allocators can panic on OOM, including the global one, with the introduction of generic allocators on collections. So in theory no one "should" be relying on the default `oom=abort` semantics. This knob would only affect the default global allocator. Presumably there would just be a function somewhere in the stdlib which is cfg'd to be a panic or abort based on this flag?

This is not a replacement for proper fallible allocation handling routines requested in #29802 because most of the potential users of **that** API build with `panic=abort`. Also the requesters of **this** API are unwilling to go through the effort to ensure all their dependents are using fallible allocations everywhere.

I am dubious on this API but I'm filling an issue so that it's written down and everyone who wants it has a place to go and assert that it is in fact good and desirable.
Repository: vscode
Issue: multiCursorModifier should be ctrlCmd by default for *nix users
Labels: feature-request,editor-multicursor

- VSCode Version: Code - Insiders 1.15.0-insider (6328bae2bf8382fd4abd054c14976548eaea66cf, 2017-07-27T07:00:51.592Z)
- OS Version: Linux x64 4.10.0-28-generic
- Extensions: none
---

Following on the heels of #21506, I feel that the default click action for *nix users should not be alt-click, but ctrl-click.

What's odd is I only see references to ctrl-click in the issue, but somehow...

![selection_017](https://user-images.githubusercontent.com/923011/28844323-423fc932-76d2-11e7-8d30-12afd24e0370.png)

Alt-click is mapped by default in Ubuntu window manager to move windows, so alt-click in this case does nothing (or rather, it moves the vscode window)

Perhaps this is more a question than a bug, but:

1. Is this configurable in `settings.json`, so it is ctrl-click?
2. If not, can the default be changed to ctrl-click so it functions on Ubuntu at least?
Repository: flutter
Issue: Would like to be able to avoid asset load errors at runtime
Labels: tool,framework,a: assets,P3,team-framework,triaged-framework

Currently with Flutter it's very easy to end up with asset load errors at runtime since assets are keyed off of strings, which are not in any way validated at analyze time (or generated/provided by the system).

Posse's currently most common crash in their live app is a failed asset string load.

They also have a manual file of string constants that they maintain from their pubspec.yaml (presumably could be autogenerated pretty easily).

This just seems like a pattern we could help with. This bug is about finding ideas to reduce the likelihood of this kind of failure.

FYI @yjbanov
Repository: rust
Issue: Confusing mismatched type error
Labels: C-enhancement,A-diagnostics,T-compiler,D-confusing,D-newcomer-roadblock

If you forget to put a semicolon after the last expression in the body of a function that returns no values, `rustc` will infer that the type of the expression should be `()`. If the programmer didn't intend to return a value, but merely forgot to type a semicolon, the resulting error can be confusing. Consider, for example, the following [toy program](https://play.rust-lang.org/?gist=0bf5eb6df01e8b850d0a413e56cc59b8&version=stable):

```rust
use std::ptr;

fn main() {
    let a = 0;
    ptr::read(&a)
}
```

This produces the following error message:

```text
error[E0308]: mismatched types
 --> src/main.rs:5:15
  |
5 |     ptr::read(&a)
  |               ^^ expected (), found integral variable
  |
  = note: expected type `*const ()`
             found type `&{integer}`
```

In this simple example, it may be obvious, but in the somewhat more complicated code I was working with that led me to this issue, I spent a decent amount of time trying to figure out why I was supposedly passing a pointer to `()` to `mem::replace`, thus causing the type of the second argument to `replace` to fail to unify. It took me a while to figure out that this was actually the culprit.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: "failed to run cargo build" on powerpc64 when installing rust 1.19.0
Labels: I-crash,O-PowerPC,C-bug

After downloading the latest Rust release tarball, 1.19.0, running ./configure, and then make, I get the following, after a few tarballs are downloaded successfully:

```
aperez@debian-sid-ppc64:~/rust-1.19.0$ make -j4
downloading https://static.rust-lang.org/dist/2017-06-08/rust-std-1.18.0-powerpc64-unknown-linux-gnu.tar.gz
######################################################################## 100.0%
extracting /home/aperez/rust-1.19.0/build/cache/2017-06-08/rust-std-1.18.0-powerpc64-unknown-linux-gnu.tar.gz
downloading https://static.rust-lang.org/dist/2017-06-08/rustc-1.18.0-powerpc64-unknown-linux-gnu.tar.gz
######################################################################## 100.0%
extracting /home/aperez/rust-1.19.0/build/cache/2017-06-08/rustc-1.18.0-powerpc64-unknown-linux-gnu.tar.gz
downloading https://static.rust-lang.org/dist/2017-06-08/cargo-0.19.0-powerpc64-unknown-linux-gnu.tar.gz
######################################################################## 100.0%
extracting /home/aperez/rust-1.19.0/build/cache/2017-06-08/cargo-0.19.0-powerpc64-unknown-linux-gnu.tar.gz
failed to run: /home/aperez/rust-1.19.0/build/powerpc64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/aperez/rust-1.19.0/src/bootstrap/Cargo.toml
Build completed unsuccessfully in 0:00:51
Makefile:24: recipe for target 'all' failed
make: *** [all] Error 1

```
Repository: electron
Issue: Register URL pattern as bypassing CSP?
Labels: enhancement :sparkles:

Since `v0.30.3` we can register URL schemes (`http`, `file`, `chrome-extension`.. ) as bypassing CSP via `webFrame.registerURLSchemeAsBypassingCSP`.

Is there a way to register URL patterns (like `https://mydomain.com/trusted-scripts/*`) as bypassing CSPs?
If no, would it make sense to add such an API (`webFrame.registerURLPatternAsBypassingCSP` I guess)?
Any idea where I should start the implementation from on Chromium side?