sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/compile: eliminate runtime.conv* calls with unused results
Labels: Performance,NeedsFix,binary-size

### What version of Go are you using (`go version`)?
`go version go1.9.2 linux/amd64`

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
`linux/amd64`

### What did you do?
I'm using the following file (`noop.go`):

```go
package main

import "fmt"

func debug(data ...interface{}) {}

func op() {
  fmt.Println("Op")
}

func main() {
  debug("123")
  op()
}
```

I compile the file using: `go tool compile noop.go`.
Then I inspect the object file using: `go tool objdump noop.o`.

### What did you expect to see?
Ideally I expect to see no traces of the `debug` function.
In a non-ideal, but a good outcome I expect to see no calls to the `debug` function.

### What did you see instead?
A call to the `debug` function.

```
noop.go:12 0x569 e800000000 CALL 0x56e [1:5]R_CALL:%22%22.debug
noop.go:13 0x56e e800000000 CALL 0x573 [1:5]R_CALL:%22%22.op
```

### Additional information
If I replace signature of the `debug` function to:

```go
func debug(data string) {}
```

I get the "good" scenarion:

* the `debug` function is present
* no calls to the `debug` function exist
Repository: node
Issue: Use %TypedArray%.prototype.subarray for Buffer.prototype.slice
Labels: buffer,v8 engine,performance

* **Version**: master
* **Platform**: all
* **Subsystem**: buffer

Currently, [our implementation](https://github.com/nodejs/node/blob/9fb390a1c66c91796626fe199176619ce4a54f62/lib/buffer.js#L992-L1014) of [`Buffer.prototype.slice()`](https://nodejs.org/api/buffer.html#buffer_buf_slice_start_end) operates identically to [`TypedArray.prototype.subarray()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/subarray) ([spec](https://tc39.github.io/ecma262/#sec-%typedarray%.prototype.subarray)) down to the last minutia (with the assumption that `this` is indeed a `Buffer`, and `Buffer[Symbol.species]` has not been tampered with). Ideally, we should just set `Buffer.prototype.slice` to `Uint8Array.prototype.subarray` instead of reimplementing it. The only problem is performance: `subarray()` is much slower than `slice()`:

<details><summary>diff</summary>

```diff
diff --git a/lib/buffer.js b/lib/buffer.js
index b56c032f9e..112dc22d69 100644
--- a/lib/buffer.js
+++ b/lib/buffer.js
@@ -989,29 +989,7 @@ Buffer.prototype.toJSON = function toJSON() {
 };
 
 
-function adjustOffset(offset, length) {
-  // Use Math.trunc() to convert offset to an integer value that can be larger
-  // than an Int32. Hence, don't use offset | 0 or similar techniques.
-  offset = Math.trunc(offset);
-  // `x !== x`-style conditionals are a faster form of `isNaN(x)`
-  if (offset === 0 || offset !== offset) {
-    return 0;
-  } else if (offset < 0) {
-    offset += length;
-    return offset > 0 ? offset : 0;
-  } else {
-    return offset < length ? offset : length;
-  }
-}
-
-
-Buffer.prototype.slice = function slice(start, end) {
-  const srcLength = this.length;
-  start = adjustOffset(start, srcLength);
-  end = end !== undefined ? adjustOffset(end, srcLength) : srcLength;
-  const newLength = end > start ? end - start : 0;
-  return new FastBuffer(this.buffer, this.byteOffset + start, newLength);
-};
+Buffer.prototype.slice = Uint8Array.prototype.subarray;
 
 
 function checkOffset(offset, ext, length) {
```
</details>

```
$ ./node-master benchmark/buffers/buffer-slice.js 
buffers/buffer-slice.js n=1024 type="fast": 11,632.49754936561
buffers/buffer-slice.js n=1024 type="slow": 11,584.90297078093
$ ./node benchmark/buffers/buffer-slice.js 
buffers/buffer-slice.js n=1024 type="fast": 6,675.602412489698
buffers/buffer-slice.js n=1024 type="slow": 6,487.594815897296
```

I'd like to work with the V8 team to resolve the performance problem, and eventually use the language built-in for `Buffer.prototype.slice`.

/cc @bmeurer
Repository: rust
Issue: method-probing machinery can false-positive
Labels: A-diagnostics,T-compiler,C-bug,WG-diagnostics

[While working on improving method suggestions](https://github.com/rust-lang/rust/issues/42929#issuecomment-345914556), it was discovered that the return value of `probe_for_return_type`—at least, a slightly altered version thereof that passes `ProbeScope::AllTraits` to `probe_op` rather than [`ProbeScope::TraitsInScope` (as on master at issue-filing time)](https://github.com/rust-lang/rust/blob/088f328e/src/librustc_typeck/check/method/probe.rs#L186-L195)—could include methods that don't actually return the desired type. Most notably, this happened with `core::convert::Into::into`.

The root cause _seems_ to be that when we [try to resolve type variables](https://github.com/rust-lang/rust/blob/088f328e/src/librustc_typeck/check/method/probe.rs#L1084), we might [find that the return type of the trait method still needs to be resolved](https://github.com/rust-lang/rust/blob/088f328e/src/librustc/infer/mod.rs#L1282-L1284), and that unresolved type variable is [considered to fulfill the required return type](https://github.com/rust-lang/rust/blob/78fcf3388/src/librustc_typeck/check/method/probe.rs#L1089)?? (I regret my difficulty to provide a better report than this.)
Repository: rust
Issue: method-probing machinery can false-negative because it doesn't know about associated types
Labels: C-enhancement,A-diagnostics,T-compiler,S-needs-repro

As part of [the endeavor](https://github.com/rust-lang/rust/issues/42929#issuecomment-345914556) that also prompted #46459, it was noticed that we never generated a suggestion for `.to_owned()` even where it would be appropriate. Some strategic logging in `matches_return_type` revealed that the result being returned [by `.can_sub`](https://github.com/rust-lang/rust/blob/16ba459/src/librustc_typeck/check/method/probe.rs#L708) was—

```
Err(
    Sorts(
        ExpectedFound {
            expected: <_ as std::borrow::ToOwned>::Owned,
            found: std::string::String
        }
    )
)
```

But in this case, `ToOwned::Owned` should have [_been_](https://github.com/rust-lang/rust/blob/16ba4591d/src/liballoc/str.rs#L187) `String`.
Repository: rust
Issue: Moving some code around results in linking error with incremental comp
Labels: T-compiler,A-incr-comp,C-bug

I've had this happen 3 times now today. It's fixed by `cargo clean`, so is not a critical issue, but still is a moderately interesting incremental compilation bug. The change was moving the trait `query_dsl::OffsetDsl` to `query_dsl::methods::OffsetDsl`. The code in question that is failing was importing `OffsetDsl::offset` from `diesel::prelude` instead, the `x.offset` is now resolving to `query_dsl::QueryDsl::offset`, which simply calls `OffsetDsl::offset`, and is exported from prelude.

Anyway, this is the error
<img width="1360" alt="screen shot 2017-12-03 at 11 07 06 am" src="https://user-images.githubusercontent.com/1529387/33528246-9d44600a-d81a-11e7-889c-374ee6b3f195.png"> and the patch that caused it is https://gist.github.com/sgrif/8bb17b2a143d482e060fc3fd08705067

`rustc --version`: rustc 1.24.0-nightly (73bca2b9f 2017-11-28)
Repository: pytorch
Issue: Raise an error when using magma built against wrong version of cuda
Labels: module: binaries,module: build,triaged

Previous instances of this: https://github.com/pytorch/pytorch/issues/3018

I myself was affected by this bug when a server I was working on upgraded from cuda 8 to cuda 9. I dutifully rebuilt PyTorch but forgot to uninstall magma-cuda80: instant hang on CUDA initialization.
Repository: rust
Issue: Proc macro hygiene regression
Labels: P-medium,A-macros,T-compiler,regression-from-stable-to-stable,C-bug,A-hygiene

Something in the range https://github.com/rust-lang/rust/compare/bb42071f6...f9b0897c5, likely https://github.com/rust-lang/rust/pull/46343 (CC @jseyfried), broke Servo.

We have a `#[dom_struct]` attribute implemented in a `dom_struct` crate like this:

```rust
#[proc_macro_attribute]
pub fn dom_struct(args: TokenStream, input: TokenStream) -> TokenStream {
    if !args.is_empty() {
        panic!("#[dom_struct] takes no arguments");
    }
    let attributes = quote! {
        #[derive(DenyPublicFields, DomObject, JSTraceable, MallocSizeOf)]
        #[must_root]
        #[repr(C)]
    };
    iter::once(attributes).chain(iter::once(input)).collect()
}
```

Each of the derives is defined in a respective crate. The `script` crate depends on all of these crates and uses `#[dom_struct]`. Some of the derives generate code that reference items defined in `script`. For example, `#[derive(DomObject)]` implements the `script::dom::bindings::refector::DomObject` trait.

Since rustc 1.24.0-nightly (f9b0897c5 2017-12-02), every use of `#[dom_struct]` fails with:

```rust
error[E0433]: failed to resolve. Could not find `js` in `{{root}}`
  --> components/script/dom/attr.rs:28:1
   |
28 | #[dom_struct]
   | ^^^^^^^^^^^^^ Could not find `js` in `{{root}}`

error[E0433]: failed to resolve. Could not find `dom` in `{{root}}`
  --> components/script/dom/attr.rs:28:1
   |
28 | #[dom_struct]
   | ^^^^^^^^^^^^^ Could not find `dom` in `{{root}}`

error[E0433]: failed to resolve. Could not find `js` in `{{root}}`
  --> components/script/dom/attr.rs:28:1
   |
28 | #[dom_struct]
   | ^^^^^^^^^^^^^ Could not find `js` in `{{root}}`

error[E0433]: failed to resolve. Could not find `malloc_size_of` in `{{root}}`
  --> components/script/dom/attr.rs:28:1
   |
28 | #[dom_struct]
   | ^^^^^^^^^^^^^ Could not find `malloc_size_of` in `{{root}}`
```

I suppose that these errors come from code generated by the derives, and that `{{root}}` refers to the root of the `dom_struct` crate where the `#[derive(…)]` tokens come from. Indeed, the `js` and `dom` are not an cannot be available there, they’re in the `script` crate which depends on `dom_struct`.

We can work around this by erasing hygiene data in the `#[derive(…)]` tokens:

```diff
--- a/components/dom_struct/lib.rs
+++ b/components/dom_struct/lib.rs
@@ -17,7 +17,9 @@ pub fn dom_struct(args: TokenStream, input: TokenStream) -> TokenStream {
     let attributes = quote! {
         #[derive(DenyPublicFields, DomObject, JSTraceable, MallocSizeOf)]
         #[must_root]
         #[repr(C)]
     };
+    let attributes = attributes.to_string().parse().unwrap();
     iter::once(attributes).chain(iter::once(input)).collect()
 }
```

… but this seems like a valid pattern that shouldn’t necessitate such hacks.
Repository: create-react-app
Issue: Symlink behaviour
Labels: issue: proposal

If I add a symlink in my src directory to another directory, and then include files from that path, create-react-app gives an error:

> Module parse failed: Unexpected token
> You may need an appropriate loader to handle this file type.

I assume create-react-app wants to have this import already built/transpiled. I would expect this to be the case for imports outside the src directory (node_modules for example). But since the symlink resides in the src directory, I would assume create-react-app would fetch these files as if they were truly in src directory.

Is this a bug, or expected behaviour? It makes it really hard to extract common components.
Repository: rust
Issue: Rustc segfaults with -C passes=livestacks
Labels: I-crash,A-LLVM,T-compiler,C-bug

How to reproduce:

```
mkdir /tmp/repro
cd /tmp/repro
cargo init --bin
mkdir .cargo
echo '[build]\nrustflags = ["-C", "passes=livestacks"]' > .cargo/config
cargo build --verbose
```
Output:
```
   Compiling repro v0.1.0 (file:///tmp/repro)
     Running `rustc --crate-name repro src/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=10c9440624901274 -C extra-filename=-10c9440624901274 --out-dir /tmp/repro/target/debug/deps -L dependency=/tmp/repro/target/debug/deps -C passes=livestacks`
error: Could not compile `repro`.

Caused by:
  process didn't exit successfully: `rustc --crate-name repro src/main.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=10c9440624901274 -C extra-filename=-10c9440624901274 --out-dir /tmp/repro/target/debug/deps -L dependency=/tmp/repro/target/debug/deps -C passes=livestacks` (signal: 11, SIGSEGV: invalid memory reference)
```

The `livestacks` pass is listed by `rustc -C passes=list`.

Reproduces on 1.21 and nightly:
```
rustc --version
rustc 1.21.0 (3b72af97e 2017-10-09)
rustc +nightly --version
rustc 1.24.0-nightly (1956d5535 2017-12-03)
```
Repository: godot
Issue: Configure Snap menu should use vector input for grid, and number input for rotation
Labels: enhancement,topic:editor

**Operating system or device, Godot version, GPU Model and driver (if graphics related):**
Godot 3.0 Beta 1

**Issue description:**
Currently the configure snap menu uses two input fields for grid offset and grid size. I think it would be better if it used the vector input like node properties use. The rotation inputs should also use the same number input that the node properties have, with a range of 0 to 360. The "px" and "deg" should probably be labels outside of the number boxes, not inside them. These changes would make setting the numbers quicker and easier.

![](https://i.imgur.com/h2JzcS3.png)
Repository: go
Issue: x/net/publicsuffix: ICANN flag returned not aligned with public suffix location in the list
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
go version go1.9.2

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
goos: darwin
goarch: amd64

### What did you do?
Call PublicSuffix with input domain "transurl.be"
https://play.golang.org/p/SLdVLEzpk4

### What did you expect to see?
ICANN flag set to true

List contains "be" within the ICANN delimiters:
// be : https://en.wikipedia.org/wiki/.be
// Confirmed by registry <tech@dns.be> 2008-06-08
be
ac.be

and "*.transurl.be" outside.

// TransIP : htts://www.transip.nl
// Submitted by Rory Breuk <rbreuk@transip.nl>
*.transurl.be
*.transurl.eu
*.transurl.nl

### What did you see instead?
ICANN flag set to false

I am not sure if this behaviour is expected. Should transurl.be match *.transurl.be, given it doesn't have a 3rd level domain?
Also, since the public suffix domain returned is "be" , I would expect for that rule to be the one being matched, and therefore having ICANN set to true.

There are more occurrences of this scenario, such as "0emm.com".
Repository: rust
Issue: Unreachable code warning for std::unreachable!
Labels: C-enhancement,A-lints

Presently, rustc will emit a warning when it detects unreachable code. Ordinarily, this is great, but in the case of `std::unreachable!`, it isn't particularly helpful.

For example, consider the following code:

```
#![deny(unreachable_code)]

fn main() {
    return;
    
    unreachable!();
}
```
([Playground link](https://play.rust-lang.org/?gist=5fd1d9f2b23cc75b8419120513406274&version=stable))

This results in:
```
error: unreachable statement
 --> src/main.rs:6:5
  |
6 |     unreachable!();
  |     ^^^^^^^^^^^^^^^
  |
note: lint level defined here
 --> src/main.rs:1:9
  |
1 | #![deny(unreachable_code)]
  |         ^^^^^^^^^^^^^^^^
  = note: this error originates in a macro outside of the current crate
```

In this case the warning isn't particularly helpful given that I've explicitly marked the code as unreachable. It seems like it would be reasonable to avoid emitting a warning in this case.

In particular, this is problematic because `#![deny(unreachable_code)]` is implied by `#![deny(warnings)]`. I'm working in a large codebase that makes heavy use of `#![deny(warnings)]`. As a result, I'm not able to use `std::unreachable!()` without explicitly allowing unreachable code, which isn't desirable. 

Oftentimes I'd like to use `std::unreachable!()` in places where unreachability is statically provable, but not intuitively obvious to a human reading the code. For now I've settled on just using comments instead.
Repository: flutter
Issue: Secondary isolates should get dart:ui bindings.
Labels: engine,dependency: dart,c: proposal,P2,team-engine,triaged-engine

Secondary isolates currently do not have access to any of the window bindings that back `dart:ui`. Clients that attempt to use parts of the Flutter API that depend on the same run into exceptions because of this.

It is theoretically safe for secondary isolates to get some `dart:ui` bindings already. However, there are some dart callbacks that are made after traversing threads. This includes scheduling frames in response to vsync pulses. If a secondary thread were to get access to the Dart UI bindings, it would be able to schedule frames that the root isolate would then have to respond to. So making all secondary isolates get the UI binding is a no-go. 

We can attempt to address this issue in one of two ways:
* Wait for the shell refactor to land. This allows each isolate to have its own set of task runners. Frame scheduling attempted by the secondary isolates would be a no-op because its platform and GPU task runners are null.
* Design a `dart:ui` lite variant of bindings that are safely accessible by secondary isolates.
* Make the Flutter API resilient to uninitialized items in the `dart:ui` and don't support UI bindings on secondary threads at all.
Repository: angular
Issue: [Animations] params not evaluated when transitioning to void state (e.g. ngIf :leave)
Labels: type: bug/fix,area: animations,freq2: medium,P3

## I'm submitting a...
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request 
</code></pre>

## Current behavior
I want to animate an element which is being added and removed with *ngIf. I need to pass a parameter to the animation at run-time, which I am doing like this: 

```HTML
<!-- app.component.html -->
<div *ngIf="show" [@myTrigger]="triggerParams">
  Hello.
</div>
```
```TypeScript
@Component({
  selector: 'my-app',
  templateUrl: `./app.component.html`,
  animations: [
    trigger('myTrigger', [
      state('*', style({ opacity: '{{ opacity }}' }), { params: { opacity: 0 } }),
      state('void',  style({ opacity: '{{ opacity }}' }), { params: { opacity: 0 } }),
      transition('void => *', animate('1000ms')),
      transition('* => void', animate('1000ms'))
    ]),
  ]
})
export class AppComponent {
  show = false;

  get triggerParams(): any {
    return {
      value: '',
      params: {
        opacity: this.show ? 1 : 0
      }
    };
  }
}
```

Currently, the `triggerParams` getter is being evaluated during the transition from `void => *`, but not the other way around, with the result that the div fades in, but does not fade out.

## Expected behavior
I would expect the `triggerParams` getter to be evaluated also when the div transitions from `* => void` so that the param is set to `{ opacity: 0 }` and it fades out.


## Minimal reproduction of the problem with instructions
https://stackblitz.com/edit/repro-for-20796?file=app/app.component.ts

## What is the motivation / use case for changing the behavior?
So that I can animate *ngIf with dynamic params.


## Environment

<pre><code>
Angular version: 4.4.6, 5.0.5, 5.1.0-rc.1 (tested all 3)

Browser:
- [x] Chrome (desktop) version 62
 
For Tooling issues:
- Node version: 8.9.1
- Platform:  Windows 10
</code></pre>
Repository: angular
Issue: feat: allow HTTP param encoder to vary for arrays
Labels: feature,freq1: low,area: common/http,P3,feature: under consideration

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION.
-->

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>[x] Bug report
</code></pre>

## Current behavior
When I send url data parameter which is an array on a GET request, only the first element is sended.
```
let testParams = {key: 'value', array: ['v1','v2']};
this.http.get(`url`, {params: testParams}).subscribe();
```

> http://127.0.0.1/url?key=value&array=v1

## Expected behavior
The whole array parameters must be send like that:
> http://127.0.0.1/url?key=value&array[]=v1&array[]=v2

## Environment

<pre><code>
Angular version: 5.0.2
<!-- Check whether this is still an issue in the most recent Angular version -->

Browser:
- [x] Chrome (desktop) version 62.0.3202.94
 
For Tooling issues:
- Node version:  8.9.1
- Platform:  win32 x64

</code></pre>
Repository: angular
Issue: Query through components are not working
Labels: type: bug/fix,area: animations,freq3: high,P3

## I'm submitting a...
<pre><code>[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request</code></pre>

## Current behavior
Cannot query for a leave animation which is inside a child component.


## Expected behavior
The parent animation should be able to query for leave animations which are multiple level below in the component tree.


## Minimal reproduction of the problem with instructions
https://stackblitz.com/edit/angular-nfr1yb
Here if the `ParentComponent` gets removed it does not wait for the `ChildComponent` leave animation.


## Environment

<pre><code>Angular version: 7.1.0</code></pre>
Repository: vue
Issue: Establish a standard way to document component and its props
Labels: discussion

### What problem does this feature solve?
https://github.com/vuejs/vetur/issues/276

Currently, Vetur offers auto-completion & hover info for custom components defined in ElementUI, OnsenUI and Bootstrap-Vue. However, hand-maintaining such json files seem to be a lot of work. Also not co-locating the doc and the component definition can make updating component challenging.

Helper-json repos at:

- https://github.com/ElementUI/element-helper-json
- https://www.npmjs.com/package/vue-onsenui-helper-json
- https://github.com/bootstrap-vue/bootstrap-vue-helper-json

This feature makes it possible to write the doc in the SFC / js component file, and auto-generate a helper json that can be used for enhancing editing experience or auto-generating API / doc website.

### What does the proposed API look like?
Two more optional attributes on the default export:

```js
export default {
  name: 'v-card',
  description: 'A card component',
  props: ['width', 'height'],
  propsDescription: [
    'width of the rendered card component',
    'height of the rendered card component'
  ]
}
```

I was thinking maybe using a custom block for it, but then that only applies to SFC, not js components. jsdoc might be another option.
Other ideas welcome.

Another idea is similar to the `typings` in package.json, have a `vueTypings` for component libraries. It'll point to the generated helper-json file and editors could pick it up to enhance editing experience.

/cc

@Leopoldthecoder for ElementUI
@masahirotanaka for OnsenUI
@pi0 for Bootstrap-Vue
@rstoenescu for Quasar
@johnleider for Vuetify

Would you be interested in using this feature in the Vue component libraries that you are maintaining? Would you be interested in helping spec'ing a format for the generated json file and the editing experiences that should be enabled by using that file?

<!-- generated by vue-issues. DO NOT REMOVE -->