sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: cmd/compile: optimize unaligned load-XOR-store on byte slices
Labels: Performance,compiler/runtime

It would be nice if the following sets of code were equivalent on platforms that support unaligned loads/stores (386, amd64, arm64,  ppc64le, s390x...). I've used XOR in these examples but it is also true for the other logical operators:

(1)
```go
binary.LittleEndian.PutUint32(dst, binary.LittleEndian.Uint32(src) ^ x)
```

(2)
```go
dst[0] = src[0] ^ byte(x)
dst[1] = src[1] ^ byte(x>>8)
dst[2] = src[2] ^ byte(x>>16)
dst[3] = src[3] ^ byte(x>>24)
```

(3) [less important]
```go
x ^= uint32(src[0])
x ^= uint32(src[1]) << 8
x ^= uint32(src[2]) << 16
x ^= uint32(src[3]) << 24
binary.LittleEndian.PutUint32(dst, x)
```

Currently (1) is optimal on platforms with unaligned loads and (2) is optimal on other platforms. It would be nice if the compiler could optimize (2) into (1). I've added (3) as an additional case where the current rules are suboptimal.

If this is ever done it will help simplify the generic `golang.org/x/crypto/internal/chacha20` implementation.
Repository: TypeScript
Issue: Compiler API: Expose More from typescript.d.ts
Labels: Suggestion,Help Wanted,API

**TypeScript Version:**  2.9.0-dev.20180426

While [Traversing the TypeScript AST](https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API#traversing-the-ast-with-a-little-linter) of a source file, there have been a number of helpful things I've found by extending `ts.*` from `typescript.d.ts` and I would like it if these could be exposed (or not marked `/* @internal */`).

**Search Terms:** 
typescript.d.ts
Node.locals
Symbol.parent
getContainingFunction
isAssignmentTarget

**Code**

```ts
declare namespace ts {
    interface Node {
        /* @internal */ readonly locals?: SymbolTable; // Locals associated with node (initialized by binding)
    }

    interface Symbol {
        /* @internal */ readonly parent?: Symbol; // Parent symbol
    }

    function getContainingFunction(node: Node): SignatureDeclaration | undefined;

    function isAssignmentTarget(node: Node): boolean;
}
```

Note:
*  Added `readonly` for `Node#locals` & `Symbol#parent`
*  For `Symbol#parent`, the goal is: given the symbol for a method (e.g., `methodSymbol` for `Number#toString`) find where that method is defined (e.g., `Number`)... maybe `program.getTypeChecker().getSymbolAtLocation(methodSymbol.valueDeclaration.parent)` is what is "supposed" to be used instead?
*  For `ts.getContainingFunction()` it seems more appropriate to have a return type of `SignatureDeclaration | undefined` instead of `SignatureDeclaration`

**Related Issues:**
#15841
Repository: go
Issue: cmd/compile: prove pass doesn't draw signed int conclusions from range checks
Labels: Performance,compiler/runtime

This might be fixed by outstanding prove CLs, but just in case, consider this snippet from math/expm1.go:

```go
	var k int

	// ...

	switch {
	case k == -1:
		return 0.5*(x-e) - 0.5
	case k == 1:
		if x < -0.25 {
			return -2 * (e - (x + 0.5))
		}
		return 1 + 2*(x-e)
	case k <= -2 || k > 56: // suffice to return exp(x)-1
		y := 1 - (e - x)
		y = Float64frombits(Float64bits(y) + uint64(k)<<52) // add k to y's exponent
		return y - 1
	}
	if k < 20 {
		t := Float64frombits(0x3ff0000000000000 - (0x20000000000000 >> uint(k))) // t=1-2**-k
		y := t - (e - x)
		y = Float64frombits(Float64bits(y) + uint64(k)<<52) // add k to y's exponent
		return y
	}
```

Note the switch case `k <= -2 || k > 56`. The compiler rewrites this into a single unsigned comparison: `uint(x) > 57`. See `func walkinrange` in walk.go.

After the `k < 20` check (in particular, when considering `uint64(k)<<52`, the prove pass has signed limits of [-9223372036854775808, 19] for k and no unsigned limits. But I believe that we should know that k is in [-2, 19].

I might have the culprit/analysis wrong...but in any case, we should know more about `uint64(k)` here.

Noticed while exploring #25087.

cc @rasky
Repository: TypeScript
Issue: Some overloaded signatures never be choose when explicit type parameters are specified
Labels: Bug

**TypeScript Version:**  2.7.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** 

**Code**

```ts
    then<TResult1 = T, TResult2 = never>(onfulfilled?: undefined | null, onrejected?: undefined | null): Promise<T>;
    then<TResult1 = T, TResult2 = never>(onfulfilled?: ((value: T) => TResult1 | PromiseLike<TResult1>) | undefined | null, onrejected?: ((reason: any) => TResult2 | PromiseLike<TResult2>) | undefined | null): PromiseLike<TResult1 | TResult2>;
    then<TResult1 = T, TResult2 = never>(onfulfilled?: undefined | null, onrejected?: undefined | null): Promise<T>;
```

```ts
Promise.resolve(0).then<string>();
```

**Expected behavior:**

```ts
Promise.resolve(0).then<string>(); // T is number from the first or third signature
```

**Actual behavior:**

```ts
Promise.resolve(0).then<string>(); // T is string from the second signature
```

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior --> 

**Related Issues:** #23364
Repository: pytorch
Issue: [Caffe2] LT and GT cannot be exported to ONNX
Labels: caffe2

When I try to export a simple network using LT (or GT) to ONNX, I get the following error:

## Error log
```
Traceback (most recent call last):
...
  File "/home/masato/repo/pytorch/build/caffe2/python/onnx/frontend.py", line 346, in caffe2_net_to_onnx_model
    model = make_model(cls.caffe2_net_to_onnx_graph(*args, **kwargs),
  File "/home/masato/repo/pytorch/build/caffe2/python/onnx/frontend.py", line 262, in caffe2_net_to_onnx_graph
    checker.check_graph(graph_def)
  File "/home/masato/repo/onnx/onnx/checker.py", line 45, in checker
    proto.SerializeToString(), ctx)
onnx.onnx_cpp2py_export.checker.ValidationError: No Schema registered for LT with domain_version of 6

==> Context: Bad node spec: input: "in_data_0" input: "bias_0" output: "out_data_1" name: "" op_type: "LT
```

## Sample Code

```python
#!/usr/bin/env python
import onnx
import caffe2.python.onnx.frontend as oc2f
import caffe2.python.predictor.predictor_exporter as pe
import caffe2.python.predictor.mobile_exporter as c2me
from caffe2.python import model_helper, workspace, brew, utils
IN_DATA_NAME = "in_data"
IN_BIAS_NAME = "bias"
OUT_DATA_NAME = "out_data"

WIDTH = 3
HEIGHT = 4
CHAN = 2
AXIS = 1
DATA_SHAPE = (1, CHAN, HEIGHT, WIDTH)

model = model_helper.ModelHelper(name="less_net")
model.net.LT([IN_DATA_NAME, IN_BIAS_NAME], OUT_DATA_NAME)
model.param_init_net.UniformFill([], IN_DATA_NAME, shape=DATA_SHAPE)
model.param_init_net.UniformFill([], IN_BIAS_NAME, shape=DATA_SHAPE)
workspace.RunNetOnce(model.param_init_net)

init_net, predict_net = c2me.Export(workspace, model.net, [IN_DATA_NAME, IN_BIAS_NAME])

value_info = {
}
onnx_model = oc2f.caffe2_net_to_onnx_model(
        predict_net,
        init_net,
        value_info)
onnx.checker.check_model(onnx_model)
print(onnx_model)
outname = "less_no_broadcast.onnx"
with open(outname, 'wb') as f:
    f.write(onnx_model.SerializeToString())
```

## Possible Fix?
If I change Caffe2 like the following, it works. The error seems to be coming from `LT` not being converted to its appropriate ONNX counterpart name `Less`

```diff
diff --git a/caffe2/python/onnx/frontend.py b/caffe2/python/onnx/frontend.py
index c96b86143..b5106d337 100644
--- a/caffe2/python/onnx/frontend.py
+++ b/caffe2/python/onnx/frontend.py
@@ -54,6 +54,8 @@ class Caffe2Frontend(object):
         'AveragePool1D': 'AveragePool',
         'AveragePool2D': 'AveragePool',
         'AveragePool3D': 'AveragePool',
+        'LT': 'Less',
+        'GT': 'Greater',
     }

     # caffe2 arguments that are completely removed in onnx
```

## System Info
- OS: Ubuntu 16.04.4 x86_64
- pytorch: 2e156f3eabb6fa4ae88c2e831aea7da344cf43a3
- onnx: b8c423889b3d15825e90fd5bd8fa1766ba2200ce
- Python: 3.5.2
Repository: rust
Issue: E0210 Disallows theorietically legal implementation, or is misleading
Labels: C-enhancement,A-diagnostics,T-compiler

Hi all,

Had posted this on the internals forums as a potential improvement but didn't get any responses there. I'm fairly confident the following scenario should be allowed:

```rust
trait CenterOriginRect {
  fn center(&self) -> Point;
  fn width(&self) -> Meters;
  fn height(&self) -> Meters;
}

impl<'a, T: CenterOriginRect> From<&'a T> for Rect {
  fn from(r: &T) -> Rect {
    Rect {
      x: r.center().x - r.width() / 2.0,
      y: r.center().y - r.height() / 2.0,
      w: r.width(),
      h: r.height(),
    }
  }
}
```

Here, Rect is external to my crate, but, CenterOriginRect obviously isn't, and isn't exposed publicly either. Therefore, no one could define a conflicting implementation, but compiling results in E0210.

At minimum, the error message seems either wrong or irrelevant, but seems to me this is a scenario the compiler could allow. Is that true? 

Thanks! Love Rust! Would be happy to contribute a fix if this is in fact legal.

edit: [Link to forum post](https://internals.rust-lang.org/t/pre-rfc-allowing-generic-impls-of-external-traits-when-bounds-prevent-re-impl/7296)
Repository: go
Issue: cmd/compile: regalloc's liveness analysis is quadratic
Labels: ToolSpeed,compiler/runtime

This is a known, difficult issue. It has been around since the SSA compiler was first merged. This is a tracking issue for it.
Repository: pytorch
Issue: [feature request] norm argument for RNNCells
Labels: module: rnn,triaged,enhancement

Hey there pyTorch Community,

I am currently working with RNNs and realized, that it would be great to have a norm argument for RNNCells which enables LayerNormalization for them. I implemented it for the LSTMCell and it should be straight forward to apply to the other ones as well.
I think it would be worthwhile to implement it and I would be happy to do so, as it allows first time users to utilize a layer norm without going down to torch/nn/functions_/rnn.
What do you think?

Cheers,

Jendrik

cc @zou3519
Repository: vscode
Issue: Does the watch view support auto completions?
Labels: feature-request,debug

_From @yaohaizh on April 8, 2018 14:37_

In the debug view, the auto completions is supported in the debug console, but it doesn't support in the watch view when typing expression for evaluation. 

_Copied from original issue: Microsoft/vscode-debugadapter-node#171_
Repository: pytorch
Issue: [Compilation] how to disable caffe2? 
Labels: module: build,triaged

Hi
I have to compile and build pytorch from the source due to my geforce 920mx card. 
Now with merging caffe2 into pytorch the compilation time gets multipled beside the error i get when i try building it with `gcc-6` (i also get error near the end of building for gcc-5: `gcc-5: error: unrecognized command line option ‘-fno-plt’`).
So is there any flag or switch to **not** include and compile caffe2 with pytorch?
Thanks.
Repository: rust
Issue: HRTB variants are missing a std::fmt::Pointer impl
Labels: C-enhancement,A-trait-system,E-needs-test,T-libs-api,T-types,A-higher-ranked

It seems that there is a missing implementation of `std::fmt::Pointer` on some function pointers:

function pointers like `fn test() -> f32` can be passed as argument to `println!("{:p}", ...)`
but function pointers like `fn test(Vec<T> a) -> f32` can't because it's a HRTB variant.

see [https://users.rust-lang.org/t/display-function-pointer/17073](url) for more details.
Repository: vscode
Issue: Merge results from multiple DocumentHighlightProviders
Labels: feature-request,editor-symbols

as discussed in here:

https://github.com/Microsoft/vscode-languageserver-node/issues/318

I would love to see VS Code to support the document highlights from multiple extensions simultaneously, much in the same way hovers can be provided from multiple extensions and are displayed in the same hover popup.

The background for this is:
I have a language server based extension for VS Code that can deliver documentHighlight information for Java code, but as long as the Java language extension itself is installed and active, my documentHighlights are never shown (but the ones from the Java extension instead).

The purpose of my language server is to provide additional functionality for Java source code, not to replace the existing Java language tooling. Therefore I benefit from the ability to run multiple language servers for the same language (file type) and that the results from both are merged (which is the case for content assist and hover information, for example). I need the same mechanics for documentHighlight requests/responses... :-)
Repository: go
Issue: cmd/compile: take into account that floating point special cases (NaN, Inf) are unlikely
Labels: Performance,help wanted,compiler/runtime

`math.IsNaN` and `math.IsInf` are very unlikely to return true. It would be nice to use this information for code layout.

I have hacked together a prototype using SSA rules but there is probably a better way to do it. The prototype is here: https://go-review.googlesource.com/c/go/+/64191. Feel free to take that and improve it.
Repository: TypeScript
Issue: Tooltip for function overloaded to mimic variadic types infers wrong overload when called with trailing comma
Labels: Bug,Help Wanted,Domain: Quick Info

**TypeScript Version:**  2.7.0-dev.20180418

**Search Terms:** Intellisense overload, tooltip overload

**Code**

```ts
function test<A>(a: A): true;
function test<A, B>(a: A, b: B): false;
function test<T>(...values: T[]): boolean {
    return values.length === 1;
}

declare function assertTrue(truth: true): void;

const noComma = test( // test<string>(a: string): true
    'foo'
)
assertTrue(noComma);

const withComma = test( // test<string, {}>(a: string, b: {}): false, but withComma: true
    'foo',
);
assertTrue(withComma);

assertTrue(test( // test<string, {}>(a: string, b: {}): false, but no error
    'foo',
));
```

**Expected behavior:**
The inferred version of `test` (as shown in hover-over tooltip) for `noComma`, `withComma`, and directly passed to `assertTrue` is the `test<A>(a: A): true` version.

**Actual behavior:**
The inferred version of `test` for the `withComma` and directly-passed versions is the `test<A, B>(a: A, b: B): false`, specifically `test<string, {}>(a: string, b: {}): false`.

Despite this, `withComma` has type `true`, and no error is reported for the call to `assertTrue` with it or when directly passed.

**Playground Link:** [here](http://www.typescriptlang.org/play/index.html#src=function%20test%3CA%3E(a%3A%20A)%3A%20true%3B%0D%0Afunction%20test%3CA%2C%20B%3E(a%3A%20A%2C%20b%3A%20B)%3A%20false%3B%0D%0Afunction%20test%3CT%3E(...values%3A%20T%5B%5D)%3A%20boolean%20%7B%0D%0A%20%20%20%20return%20values.length%20%3D%3D%3D%201%3B%0D%0A%7D%0D%0A%0D%0Adeclare%20function%20assertTrue(truth%3A%20true)%3A%20void%3B%0D%0A%0D%0Aconst%20noComma%20%3D%20test(%0D%0A%20%20%20%20'foo'%0D%0A)%0D%0AassertTrue(noComma)%3B%0D%0A%0D%0Aconst%20withComma%20%3D%20test(%0D%0A%20%20%20%20'foo'%2C%0D%0A)%3B%0D%0AassertTrue(withComma)%3B%0D%0A%0D%0AassertTrue(test(%0D%0A%20%20%20%20'foo'%2C%0D%0A))%3B%0D%0A)

**Related Issues:** #7279
Repository: vscode
Issue: Surface customized task proper in the API.
Labels: api,tasks,debt

See https://github.com/Microsoft/vscode/issues/48831 for all the details. In the API the task should be the original provided task and it should contain a pointer to its customization from the tasks.json (not the other way around like it is today in the implementation).
Repository: go
Issue: cmd/compile: eliminate more dead stores
Labels: Performance,binary-size,compiler/runtime

### What version of Go are you using (`go version`)?
Trunk
go version devel +3470321 Tue Apr 24 15:26:21 2018 -0500 linux/amd64

### What did you do?
go build following program:
```
package test

//go:noinline
func f(x ...interface{}) {
}

func g() {
        var x string
        f(&x)
}
```

When looking into generated code I see that autotmp_1 is zeroed and than immediately overwritten

```
v27    00003 (8)       XORPS   X0, X0
 v7     00004 (8)       MOVUPS  X0, "".x-32(SP)
 v13    00005 (9)       MOVUPS  X0, ""..autotmp_1-16(SP) // zeroing
 v23    00006 (9)       LEAQ    type.*string(SB), AX
 v35    00007 (9)       MOVQ    AX, ""..autotmp_1-16(SP) // followed by 2  stores
 v34    00008 (9)       LEAQ    "".x-32(SP), AX
 v21    00009 (9)       MOVQ    AX, ""..autotmp_1-8(SP)
 v36    00010 (9)       LEAQ    ""..autotmp_1-16(SP), AX
```

dse pass already eliminates dead stores, including zeroing, so it should also handle this case.
Repository: go
Issue: x/mobile/cmd/gomobile: iOS app built with gomobile-build freezes after switching apps
Labels: mobile

### What version of Go are you using (`go version`)?

```
go version go1.10 darwin/amd64
```

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

```
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hajimehoshi/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hajimehoshi/go"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7t/qw3np69559591s1v0mk5_p1m0000gn/T/go-build572694656=/tmp/go-build -gno-record-gcc-switches -fno-common"
```

### What did you do?

1. `gomobile build -target=ios -bundleid=com.hajimehoshi.gomobiletest -work golang.org/x/mobile/example/basic`
2. Open the Xcode project in the work directory
3. Fix the singing to be able to install the app
4. Install and run the 'basic' app
5. Try to switch to another app and go back to the basic app

### What did you expect to see?

The app continues to run

### What did you see instead?

The app freezes
Repository: pytorch
Issue: CuDNN version not supported
Labels: todo,module: build,module: cudnn,module: cuda,triaged

My OS is ubuntu 16.04, previously installed cuda-8.0 and cudnn-5. Now I want to install the latest PyTorch and I choose to install with souce code. I made some preparetions: 
install cuda-9.0 and cudnn-7
set these env-variables in my ~/.bashrc:
`export CUDNN_include_DIR=/usr/local/cuda-9.0/include
export PATH=/usr/local/cuda-9.0/bin:$PATH
export LD_LIB_PATH=/usr/local/cuda-9.0/lib64:$LD_LIB_PATH`

I have tried many ways:
`export C_INCLUDE_PATH=/usr/local/cuda-9.0/include:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=/usr/local/cuda-9.0/include:$CPLUS_INCLUDE_PATH`

However, it still comes with error: cudnn v5. 
How can I solve it? Many others have to use old versions, so remove cudnn 5 is my last choice.
Repository: pytorch
Issue: "Undefined symbols for architecture arm64" when linking libcaffe2.a for iOS
Labels: caffe2

## Issue description

I am linking the caffe2 library to my iOS project using the built libraries after compiling for iOS and I'm getting "Apple Mach-O Linker errors, with all of them being "undefined symbols for architecture arm64"

## System Info
- PyTorch or Caffe2: Caffe2
- How you installed PyTorch (conda, pip, source): source
- Build command you used (if compiling from source): ./scripts/build_ios.sh
- OS: iOS
- PyTorch version: master
- Python version: 3.6.4
- CUDA/cuDNN version: NA
- GPU models and configuration: NA
- GCC version (if compiling from source): Apple LLVM version 9.1.0 (clang-902.0.39.1)
- CMake version: 3.11.1
- Versions of any other relevant libraries:
Repository: pytorch
Issue: [feature request] Provide Caffe2 CUDA dockerfile with USE_REDIS=ON
Labels: caffe2

It seems the Redis operator support in Caffe2 is off by default. When I compiled the source code with the option USE_REDIS=ON using  [this dockerfile](https://github.com/pytorch/pytorch/blob/master/docker/caffe2/ubuntu-16.04-cuda8-cudnn6-all-options/Dockerfile), I ended up with an error complaining about being unable to find libhiredis.so.
After some debugging, it turns out that the base image nvidia/cuda:8.0-cudnn6-devel-ubuntu16.04 has set the environment variable LIBRARY_PATH already while hiredis relies on it to install the generated libhiredis.so correctly.
root@e7530e488c01:/# echo $LIBRARY_PATH 
/usr/local/cuda/lib64/stubs:

To get around this issue, I simply reset it to lib as below in my dockerfile.
ENV LIBRARY_PATH lib 

I think it will be helpful to put a comment on this in the dockerfile just in case anyone else gets stuck with the same error.
Repository: pytorch
Issue: LBFGS contribution 
Labels: awaiting response (this tag is deprecated),module: optimizer,triaged

LBFGS implementation is not proper. 
Could you please go through the following link and respond to this?
https://discuss.pytorch.org/t/lbfgs-not-functioning-the-way-it-is/16705
I would like to contribute for this algorithm. 
Could you please respond soon?






cc @vincentqb
Repository: rust
Issue: Tracking issue for eRFC 2318, Custom test frameworks
Labels: B-RFC-approved,T-lang,T-dev-tools,T-cargo,A-libtest,C-tracking-issue,WG-embedded,F-custom_test_frameworks,S-tracking-design-concerns

This is tracking the `#[bench]` and `#[test_case]` attributes and the `custom_test_frameworks` lang item as well as the libtest crate. There is currently no plan/RFC for stabilizing them.

**Old issue description.**

<details>

This is a tracking issue for the eRFC "Custom test frameworks" (rust-lang/rfcs#2318).

**Documentation:**
* Implementation proposal: https://www.jrenner.net/rust/testing/2018/08/06/custom-test-framework-prop.html
* https://doc.rust-lang.org/nightly/unstable-book/language-features/custom-test-frameworks.html

**Steps:**

- [ ] Implement the RFC (cc @rust-lang/dev-tools @rust-lang/cargo -- can anyone write up mentoring instructions?)
- [ ] 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

**Unresolved questions:**

- [ ] [Integration with doctests](https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md#integration-with-doctests)
- [ ] [Standardizing the output](https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md#standardizing-the-output-1)
- [ ] [Namespacing](https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md#namespacing)
- [ ] [Runtime dependencies and flags](https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md#runtime-dependencies-and-flags)
- [ ] [Naming](https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md#naming)
- [ ] [Bencher](https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md#bencher)
- [ ] [Cargo integration](https://github.com/rust-lang/rfcs/blob/master/text/2318-custom-test-frameworks.md#cargo-integration)

**Notes:**

- Destabilization of `#[bench]`: https://github.com/rust-lang/rust/issues/63798#issuecomment-526593504

**Implementation history:**
* Initial implementation: #53410

</details>