sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Rustc should be able to unify `<T as A<'static>>::B>` with `<T as A<'a>>::B>` for all `'a`, given `A::B: 'static`
Labels: C-enhancement,A-trait-system,T-compiler

I had to use [this trick](https://github.com/rust-lang/rfcs/pull/1598#issuecomment-215962891) to work around the [lack of working GATs](https://github.com/rust-lang/rust/issues/50115):
Ended up with this code: https://play.rust-lang.org/?gist=5f14fd0600bf0b1e1e9eac2c8a3d194a&version=stable
It works but to be able to do 
```rust
pub struct AppMgr<T: for<'a> DeviceApp<'a>> {
	device: Option<T::Dev>,
	app: T,
	// ...
}
```

I had to split up my trait
```rust
pub trait DeviceApp<'a> {
	type Dev: Device;
	// ...
```
into two
```rust
pub trait DeviceSpecific {
	type Dev: Device;
}

pub trait DeviceApp<'a>: DeviceSpecific {
	// ...
```
to pull `Dev` out of the quantification scope of `'a`.

I thought it should work if I put `Dev` back inside `DeviceApp` but make it `: 'static` so that `rustc` can infer that it's the same for all `'a`:
```rust
/*
pub trait DeviceSpecific {
	type Dev: Device;
}

pub trait DeviceApp<'a>: DeviceSpecific {
*/
pub trait DeviceApp<'a> {
	type Dev: Device + 'static;

// ...

pub struct AppMgr<T: for<'a> DeviceApp<'a>> {
	// device: Option<T::Dev>,
	device: Option<<T as DeviceApp<'static>>::Dev>, // because Dev: 'static, i thought it will be unifyable with any 'a
	app: T,
	// ...
}
```

But it doesn't work. Now I get this error:
```
error[E0495]: cannot infer an appropriate lifetime for lifetime parameter 'a in function call due to conflicting requirements
  --> src/main.rs:79:53
   |
79 |             device.frame(now, |device, input| { app.process(device, input, v) })
   |                                                     ^^^^^^^
   |
note: first, the lifetime cannot outlive the lifetime 'a as defined on the method body at 75:5...
  --> src/main.rs:75:5
   |
75 |     pub fn process<'a>(&mut self, now: u64, msgs: Vec<<T as DeviceApp<'a>>::Msg>, v: &'a mut <T as DeviceApp<'a>>::BorrowedState) -> Vec<<T as DeviceApp<'a>>::Event> {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   = note: ...so that the expression is assignable:
           expected &mut <T as DeviceApp<'_>>::BorrowedState
              found &mut <T as DeviceApp<'a>>::BorrowedState
   = note: but, the lifetime must be valid for the static lifetime...
   = note: ...so that the expression is assignable:
           expected &mut <T as DeviceApp<'_>>::Dev
              found &mut <T as DeviceApp<'static>>::Dev
```
https://play.rust-lang.org/?gist=d4084c0a87890d4ed17d0491e453565b&version=stable

Why can't `rustc` unify `<T as DeviceApp<'static>>::Dev>` with `<T as DeviceApp<'a>>::Dev>` for all `'a`, when it **KNOWS** that `Dev: 'static` (the type doesn't depend on `'a`, so it can only be the same for all `'a`)?

It should be able to infer it..
Repository: pytorch
Issue: [feature request] More `index_*_` functionality and/or lambda functionality
Labels: feature,triaged,module: scatter & gather ops

Could additional index-based functions be added to the tensor library? Specifically I am thinking of an `index_mean_` and `index_max_` or `index_min_`? In the first case, all that I foresee being required is an extra counter per index. In the latter, it's just a matter or replacing element-wise addition with an element-wise binary comparator. Even better would be an `index_lambda_` function in which a user can implement their own index-wise operation.

If I could find the source code, I'd take a stab at a PR, but I am not sure where to find these implementations (all I found was aten/Tensor.h), nor am I CUDA proficient if they are implemented in that way. Hence, I'm making a feature request and am hoping someone can take the ball and run with it.

cc @nikitaved @pearu @cpuhrsch @aocsa @mruberry
Repository: rust
Issue: Work out the actual policy for macros across editions wrt dependencies updating
Labels: C-enhancement,T-lang,WG-epoch

I don’t think we’ve adequately worked out what we _want_ for macros with editions.


Are we okay with a Rust 2015 crate that exposes a macro updating to Rust 2018 (including new idioms) with a minor bump? I.e. should our edition hygiene account for this? Or are macro authors instructed to do major bumps when they

Taking a hypothetical: if `dyn` were something we _only_ exposed on Rust 2018, and a macro crate upgraded to the new edition, should _we_ do the heavy lifting of ensuring that crates on Rust 2015 can use macros from crates on Rust 2018 that use 2018-only features? Or do we require the crate author to do a major version bump?


Similarly, what level of trouble are we okay with for crates attempting to upgrade to the 2018 edition that use macros from 2015 crates?

cc @rust-lang/lang
Repository: pytorch
Issue: [caffe2] Understanding WorkFlow for Training and Testing
Labels: caffe2

hello, 
I am trying to compare all c++ framework(caffe2, tiny-dnn, etc.) with NNPACK.
the comparison that i do: Speed (exclude image loading), Memory size, and Code size.

I am new in caffe/caffe2 and worked with pytorch.

I looking a good way to learn caffe2(i already read the tutorial), the current is not sufficient.

some open issues from my side:
1. Can i stream images and labels and change the input at runtime?(do back-propagation on the mini-batch)
2. Why i need to use db input and why it's need to duplicated the data? can i avoid it?
3. How the back-propagation work? where the forward/backward implementation? when the gradients are summit? 
4. How can i insert labels for loss function on the minibatch input(i tried with tensorCPU input det as "data" and vectors of int's to "label" i get exception so it's probably not the best way)

5. Why there isn't interface like in other framework that simply run train on image:
for example in tiny- dnn i simply runed 
                        nn->train<tiny_dnn::cross_entropy>(optimizer, minibatch, labels,minibatch.size(), 1); 
where 
			std::vector<tiny_dnn::vec_t> minibatch;
			std::vector<tiny_dnn::label_t> labels;

6. I tried to switch engine to NNPACK - does it work(implement) only on arm or at intel process as well(i avoiding MKL), i get some warning that some operators are not supported - what is the fallback can i defined it?

some warning that i am not sure what im doing wrong about the input size.


I would be very happy to help!
All done in c++.

Thanks,
Liron
Repository: rust
Issue: Public "stdcall" symbol not exported on cdylib on i686-pc-windows-gnu
Labels: A-linkage,A-FFI,T-compiler,O-windows-gnu,C-bug,O-x86_32

I'm making a cdylib crate which exports a function in the following manner:
```rust
#[no_mangle]
pub extern "system" fn SomeFunction() {}
```
The library is then supposed to be loaded by another program at runtime and the function dlsym'd from it.

This works everywhere (32/64-bit Linux, macOS, 32/64-bit Windows MSVC, 64-bit Windows GNU) _except_ the `i686-pc-windows-gnu` target where the function isn't being exported from the resulting DLL for some reason.

Minimal example is the code above in a clean crate with `crate-type = ["cdylib"]`.

Possibly related: #50007, although for me the bug occurrs in both debug and release.

Rust: stable (1.25.0), beta, nightly.
Repository: pytorch
Issue: [Caffe2] Android NNApi integration bugs.
Labels: caffe2

## Issue description
I found a few bugs in NNApi integration while running benchmarks.
## Code example
Bug 1:  Invalid size is passed for tensors.
Caffe2 seems to be passing invalid size for tensors in setInput and setOutput.
If I am not wrong, they should be passing tensor->nbytes() instead of tensor->bytes()
https://github.com/caffe2/caffe2/blob/master/caffe2/mobile/contrib/nnapi/nnapi.cc#L659
In ANeuralNetworksExecution_setInput the length parameter is number of bytes, not number of elements in the tensor.
https://developer.android.com/ndk/reference/group___neural_networks.html#gaf5540f8785a31b550ba7e7a78eed6a85

Bug 2: The scale is only supported for Quantized int8 tensors and should be 0 otherwise.
https://github.com/caffe2/caffe2/blob/master/caffe2/mobile/contrib/nnapi/nnapi.cc#L517
NNApi::addTensorOperand should assign scale conditionally.
Repository: go
Issue: x/tools: unify I/O semaphores
Labels: NeedsDecision,Tools

grepping for the word "semaphore" reveals five separate I/O semaphores in x/tools. Some of them could easily be used in the same executable, e.g. those in `go/loader`, `go/buildutil`, `refactor/importgraph`, and `cmd/guru`. This makes them less effective.

I suggest we add a single exported semaphore to x/tools, which all x/tools packages can import and use, thus providing an actual process-wide limit on I/O concurrency. It could be in an internal package or not; I don't feel strongly.

cc @bradfitz @alandonovan @kevinburke for opinions
Repository: rust
Issue: Tracking issue for Cell::update
Labels: T-libs-api,B-unstable,C-tracking-issue,disposition-merge,finished-final-comment-period,Libs-Tracked,Libs-Small

This issue tracks the `cell_update` feature.

The feature adds `Cell::update`, which allows one to more easily modify the inner value.
For example, instead of `c.set(c.get() + 1)` now you can just do `c.update(|x| x + 1)`:

```rust
let c = Cell::new(5);
let new = c.update(|x| x + 1);

assert_eq!(new, 6);
assert_eq!(c.get(), 6);
```
Repository: kubernetes
Issue: Enable RealProxier in 5k-node kubemark
Labels: kind/bug,sig/scalability,lifecycle/frozen

Our kubemark-5k job (https://k8s-testgrid.appspot.com/sig-scalability-kubemark#kubemark-5000) started failing sometime mid- last week. E.g failed runs:
- https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-kubemark-gce-scale/963
- https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-kubemark-gce-scale/964
- https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-kubemark-gce-scale/965

From run-964's build-log for e.g, I'm finding that quite some pods weren't started by hollow-nodes during the load test:

```
I0419 22:36:53.886] I0419 22:36:53.882724   15900 runners.go:176] Pod load-medium-1232-9bpsg    hollow-node-kmznc       Running <nil>
I0419 22:36:53.886] I0419 22:36:53.882733   15900 runners.go:176] Pod load-medium-1232-9stph    hollow-node-2lq5z       Pending <nil>
I0419 22:36:53.887] I0419 22:36:53.882742   15900 runners.go:176] Pod load-medium-1232-btvw9    hollow-node-7bqx9       Running <nil>
...
I0419 22:36:53.892] Apr 19 22:36:53.882: INFO: Unexpected error occurred: Only 29 pods started out of 30
```

My suspicion is that some hollow-nodes are dying due to resource starvation and hence not able to run pods that are assigned to those.
It's quite likely related to @krzysied 's change adding kube-dns to kubemark (which I think merged around that time).

cc @kubernetes/sig-scalability-bugs @wojtek-t
Repository: flutter
Issue: Transitioning a TabBarView manually doesn't honor the duration and curve
Labels: framework,f: material design,a: fidelity,has reproducible steps,P3,found in release: 2.8,found in release: 2.9,team-design,triaged-design

## Steps to Reproduce
Calling `TabController.animateTo` with a duration and curve doesn't affect the behavior of the `TabBarView` animation. Although it's correctly affecting the behavior of the `TabPageSelector` and the `TabBar` animations.

Sample: https://gist.github.com/osama-lionheart/bab886d774f4e87b77104835edffbc49
Video: https://youtu.be/FzRBgflZrR4

## Flutter Doctor
```
[✓] Flutter (Channel master, v0.3.3-pre.10, on Mac OS X 10.13.4 17E199, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)
[✓] iOS toolchain - develop for iOS devices (Xcode 9.3)
[✓] Android Studio
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
[✓] Android Studio (version 3.1)
[✓] VS Code (version 1.22.2)
[✓] Connected devices (1 available)

• No issues found!
```
Repository: pytorch
Issue: [Bug] VS reports unresolved external symbol from caffe2 observer
Labels: caffe2

## Issue description

VS 2017 complains about error LNK2001 unresolved symbols when enable caffe2 observer.
This is due to the missing import/export hint for creating DLL.

## System Info

- PyTorch or Caffe2: Caffe2
- Build command you used (if compiling from source): CMake
- OS: Win10
- Python version: 3.6
- Visual Studio version (if compiling from source): VS 2017 15.6
- CMake version: 3.11
Repository: opencv
Issue: MKL_WITH_TBB failed to found the latest TBB 2018 on Windows
Labels: feature,category: build/install

##### System information (version)
- OpenCV => master
- Operating System / Platform => Windows 10 64 Bit
- Compiler => Visual Studio 2015

##### Detailed description

Failed to found TBB from OpenCVFindMKL.
The latest TBB 2018 is installed to places like `C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\tbb\lib\intel64\vc14` by default, which has the compiler version "vc14" (and also vc12, vc_mt...)

Currently `OpenCVFindMKL.cmake` is using `${MKL_ROOT_DIR}/../tbb/lib/${MKL_ARCH}` which is incorrect in this case.

##### Steps to reproduce

Install the latest MKL and TBB and make sure you don't have other version on your system.
Also make sure OpenBLAS is not installed.
Do a CMake build with "-DMKL_WITH_TBB=ON", and you'll see LAPACK failed because there's no BLAS.
The MKL is found first but then failed while adding tbb in the following code
```
if(NOT ${lib})
        mkl_fail()
    endif()
```
Repository: go
Issue: runtime: android backtraces do not include go backtrace
Labels: OS-Android,NeedsInvestigation,compiler/runtime

The android native backtrace always goes back to the abort() call, and does not include the more useful go backtrace. Therefore, in the Google Play Console, we're left with very unhelpful backtraces like:

![image](https://user-images.githubusercontent.com/10643/39159270-023e05a6-4765-11e8-84f7-9e95ef611a89.png)

It would be useful to have the backtrace here include information from Go's backtrace.
Repository: TypeScript
Issue: Have QuickInfo use import types to display type aliases that are not in scope
Labels: Suggestion,Awaiting More Feedback,Domain: Quick Info

**Search Terms:** 
type alias, import, display, quickinfo, intellisense

**Code**

```ts
// @Filename: file1.ts
export type ComplicatedType<T, U> = { [K in Exclude<keyof T, U>]: T[K] } // could be anything here
export declare function getComplicatedType<T, U extends keyof T>(arg: T, exclude: U): ComplicatedType<T, U>

// @Filename: file2.ts
import { getComplicatedType } from "./file1"
interface SomeInterface {
    a: string
    b<T>(arg: T): T,
    c: { c2: string } | { c3: number },
    d?: boolean
}
declare const test: SomeInterface
const result = getComplicatedType(test, "a") // quickinfo on result currently displays something like:
/* const result: {
    b: <T>(arg: T) => T;
    c: {
        c2: string;
    } | {
        c3: number;
    };
    d: boolean | undefined;
} */
```

**Current behavior:**
The quick info type shown for `result` is a fully expanded anonymous type because `ComplicatedType` is not in scope in `file2`. Importing `ComplicatedType` in `file2` makes quick info display `const result: ComplicatedType<SomeInterface, "a">`, but I don't think it's common to import a type alias purely for the quick info benefit if it isn't actually used anywhere in the file.

While the example above isn't that bad, in some cases (#18754, #23458) the fully expanded types can be so large that they actually cause a performance issue for the language service.

**Suggested behavior:**
Use `import` types from #22592 to display an accurate qualified reference to `ComplicatedType`. So in the example above quick info for `result` could instead display something like:

```ts
const result: import("./file1").ComplicatedType<SomeInterface, "a">
```
Which, although a little verbose, would be much more readable than many fully expanded types.

**Related Issues:**
#22592 added `import` types.

#18754, #23458, #6070, #13095 - Various issues related to the display of types.
Repository: flutter
Issue: Possibility to give Widgets a name in the view hierarchy (so the Play Store "Pre-launch report" Sign-in credentials can be configured)
Labels: c: new feature,platform-android,framework,engine,customer: crowd,dependency: android,a: release,P2,team-android,triaged-android

I was looking into the "Pre-launch Report" Sign in credentials configuration in the Play Store console. 

I pulled open Android Device Monitor while running the app on the login-screen, and did not expect to get a valid view XML snapshot returned, that's actually pretty nice work! 

It appears however that it is not possible to give a widget a 'resource name', as required by the pre-launch report Sign-in credentials configuration. 

Will it become possible at some point to set this value? I guess once its there, it would allow developers to use all kinds of automated testing tools on their apps.
Repository: react-native
Issue: InputAccessoryView doesn't update its height when multiline TextInput grows in height
Labels: Component: TextInput,📮Known Issues,Bug,Never gets stale

I'm using an InputAccessoryView to create a sticky TextInput. When using a growing multiline TextInput, the TextInput's height increases and grown down _behind_ the keyboard.

## Environment
Environment:
  OS: macOS High Sierra 10.13.4
  Node: 9.11.1
  Yarn: 1.5.1
  npm: 5.6.0
  Watchman: 4.9.0
  Xcode: Xcode 9.3 Build version 9E145
  Android Studio: 3.0 AI-171.4443003

Packages: (wanted => installed)
  react: 16.3.1 => 16.3.1
  react-native: 0.55.2 => 0.55.2

## Steps to Reproduce
Add `multiline` to a TextInput wrapped inside an InputAccessoryView.

## Expected Behavior
InputAccessoryView's bottom edge is always sticky to the keyboard top and does not grow behind the keyboard.

## Actual Behavior
![multiline](https://user-images.githubusercontent.com/779321/39171273-82e33ed6-479e-11e8-9938-cee8b26ccd6f.gif)
Repository: pytorch
Issue: [Caffe2] cudnn versions compatibility issue.
Labels: module: cudnn,caffe2

## Issue description
For any cudnn update (minor or patch level) user have to rebuild caffe2. This is wrong from cudnn7 and on. Please, take a look: https://github.com/tensorflow/tensorflow/issues/17566#issuecomment-372749050
In short:
cudnn 7.0.x is backward compatible with cudnn 7.0.1. cudnn 7.1.x is also backward compatible down to cudnn 7.0.1.

This code from caffe2/core/common_cudnn.h is root of problem:

```
// report the version of cuDNN Caffe2 was compiled with
inline size_t cudnnCompiledVersion() {
  return CUDNN_VERSION;
}
// report the runtime version of cuDNN
inline size_t cudnnRuntimeVersion() {
  return cudnnGetVersion();
}

// Check compatibility of compiled and runtime cuDNN versions
inline void CheckCuDNNVersions() {
  // Version format is major*1000 + minor*100 + patch
  // Major, minor and patch versions must all match
  bool version_match = cudnnCompiledVersion() == cudnnRuntimeVersion();
  CAFFE_ENFORCE(version_match,
                "cuDNN compiled (", cudnnCompiledVersion(), ") and "
                "runtime (", cudnnRuntimeVersion(), ") versions mismatch");


}

```

For now we have a little bit hackish workaround for this:

```
diff --git a/caffe2/core/context_gpu.cu b/caffe2/core/context_gpu.cu
index 46e73f3..56a4ed5 100644
--- a/caffe2/core/context_gpu.cu
+++ b/caffe2/core/context_gpu.cu
@@ -183,8 +183,10 @@ static void Caffe2InitializeCuda() {
   RegisterTensorInfoFunction(
       TypeMeta::Id<Tensor<CUDAContext>>(), GetCUDATensorInfo);
 
+#if CUDNN_MAJOR < 7
   // Check the versions of cuDNN that were compiled and linked with are compatible
   CheckCuDNNVersions();
+#endif
 }
 
 #ifdef CAFFE2_USE_CNMEM
```
Repository: vscode
Issue: [folding] fold all but comments
Labels: feature-request,editor-folding,editor-comments

Now that we have syntax aware folding, I wonder if we could prevent comments from being folded (configurable, if wanted).

This would enable to get an overview of a file very quickly.

**Now**
```
/** ...
reload() { ...
}
```

**Desired**
```
/**
 * This important comment documents the signature of `reload()`
 * @param force Enforce reloading
 */
reload(force: boolean) { ...
}
```
Repository: pytorch
Issue: [Caffe2] [feature request] Dilations in grouped convolutons
Labels: caffe2

`caffe2/operators/conv_pool_op_base.h` has the following check:
```cpp
    if (group_ != 1) {
      for (int dim = 0; dim < kernel_.size(); ++dim) {
        CAFFE_ENFORCE_EQ(
            dilation_[dim],
            1,
            "When group is used, dilation should not be set at the same time.");
      }
    }
```
Why is there such condition and is it possible to add support for dilated grouped convolutions?
Repository: pytorch
Issue: [Caffe2] Flatten Layer in caffe2
Labels: caffe2

I'm having trouble building my inceptionv3 model.
I build my model by following the diagram from netscope for caffe as shown below.
https://dgschwend.github.io/netscope/#/preset/inceptionv3
I came to almost the last layer, where i need implement a flatten layer.
I tried to use brew, but it seems that flatten isn't registered in brew.
Can anybody show me a code example of building a flatten layer?
Repository: go
Issue: cmd/compile/internal/types: lazy/incremental type expansion
Labels: ToolSpeed,compiler/runtime

The compiler now supports an indexed data format for package export data that enables efficient random-access of package data. We already use this to implement lazy expansion of declarations and inline bodies, but we still currently fully expand types whenever they're referenced. I expect in larger projects that a lot of deeply nested details are never needed and we could avoid reading that data into memory.

I think the steps are largely:

1. Hide remaining Type fields behind setter/getter methods.
2. Create a new TSTUB Type with a way to register an expander function that rewrites the Type into a real Go type.
3. Add a `Type.expand` method that checks for Etype==TSTUB and calls the expander function.
4. Insert calls to `expand()` at the top of every(?) public Type method.
5. Update iimport.go to create TSTUB types instead of normal types.

Another useful (but non-critical) step would be to review the Type API and try to prune/simplify unnecessary methods. This would reduce how many places we need to instrument with `expand` calls.
Repository: vscode
Issue: Add support for bulk actions in extensions list view
Labels: feature-request,extensions,papercut :drop_of_blood:

We currently support multi-select in the extensions list view but there are no actions a user can take once you have items selected. I would expect the same actions from a single extension be made available (enable/disable/uninstall).

**Example**
An example where I attempt to disable multiple extensions but only one gets disabled.
![ezgif com-video-to-gif 1](https://user-images.githubusercontent.com/35271042/39218393-5b9d7ffe-47d9-11e8-9fa8-6501cf079df2.gif)
Repository: go
Issue: x/build/maintner: GithubIssue.NotExist resurrection does not set Created
Labels: NeedsInvestigation

Noticed while investigating #25031 that in Corpus.processGithubIssueMutation, when an issue is resurrected from NotExist state, its Created field is not set, as that only happens when the issue is first encountered.

No idea when NotExist is set, so not sure if it's an issue, but it looks like that codepath is either unused or broken.

/cc @bradfitz
Repository: pytorch
Issue: Feature request: SSIM/MS-SSIM
Labels: triaged,module: vision,function request

The Structural Similarity Index (SSIM) is generally considered to be a milestone in the recent
history of Image Quality Assessment (IQA). 

It would be nice to see in-build **SSIM/MS-SSIM** function in pytorch.

cc @fmassa @vfdev-5