sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: ABI compatibility tool
Labels: help wanted,v8 engine,tools

ABI stability is a hard requirement when upgrading V8 within the same Node branch. This is so that native modules that uses V8 APIs and built for a particular Node branch do not need to be rebuilt.

So far, we've been mostly ensured ABI stability through intensive eyeballing of changes to `deps/v8/include/*.h` and by running [CITGM](https://github.com/nodejs/citgm). This is tedious and could yield false positives.

I have played around a bit with this [ABI compliance checker](https://lvc.github.io/abi-compliance-checker/), requiring some [tweaking](https://gist.github.com/hashseed/074be0c9c2889813ad92f95bdef266c7) of V8's build files and an additional GN arg (`use_debug_fission = false`).

Using that tool is fairly inconvenient, *very* slow (took me like some 20 minutes), and the result is not all that useful. It is a [good start](https://i.imgur.com/kWvfCRI.png), but
- does not find differences in the [constants in v8.h](https://github.com/v8/v8/blob/74a2a8f6113bf64c918345c218699e1fd1d85477/include/v8.h#L8877).
- includes changes to all header files in v8, not just ones in `v8/include`.

I'm neither an expert on DWARF nor on binary compatibility, so some contribution and help here would be greatly appreciated. Alternative here is to wait until every native module has migrated to n-api, but in the meantime...
Repository: rust
Issue: Inconsistent inlineing of Iterator Adaptors - Missed Optimizations
Labels: I-slow,C-enhancement,T-libs-api,A-iterators

While profiling some rust code of me, I noticed that the following pattern does not optimize well:

```rust
vec![1,2,3,4]
    .into_iter()
    .map(|v| ...)
    .skip_while(|v| ...)
```

`skip_while` is implemented using `find` and `find` is implemented using `try_fold`. The functions `SkipWhile::next()` and `Iterator::find()` use the `#[inline]` annotation. The function `Map::try_fold()` does not. This means that `Map::try_fold()` will not be inlined.

I started looking at the source code and inlineing of iterators seems to follow no rule. I could not find any bug reports related to this.

* [`Filter::try_fold` is inline](https://github.com/rust-lang/rust/blob/8ff449d505728276e822ca9a80c1e7b2da8288a2/src/libcore/iter/mod.rs#L1396)
* [`Enumerate::try_fold` is inline](https://github.com/rust-lang/rust/blob/8ff449d505728276e822ca9a80c1e7b2da8288a2/src/libcore/iter/mod.rs#L1633)
* [`Rev::try_fold` is not inline](https://github.com/rust-lang/rust/blob/8ff449d505728276e822ca9a80c1e7b2da8288a2/src/libcore/iter/mod.rs#L427)

Some iterators like [`Cloned`](https://github.com/rust-lang/rust/blob/8ff449d505728276e822ca9a80c1e7b2da8288a2/src/libcore/iter/mod.rs#L515) do not have any function marked as inline. Not even `next()` is marked as inline.

The [PR introducing `try_fold`](https://github.com/rust-lang/rust/pull/45595) does not give justification why some `try_fold`s are inline and some are not.

The methods `len` and `is_empty` of `ExactSizeIterator`'s are also not marked as inlineable, even though they are always implemented as pass-through to the underlying iterator.

If desired I can prepare a pull request to mark those functions as inlineable. Is there a list of functions for the iterator traits (e.g., Iterator, ExactSizeIterator) which should be inline/not be inline?
Repository: material-ui
Issue: Dropdown component
Labels: new feature,component: menu

- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

Stemming from discussion in [this bug](https://github.com/mui-org/material-ui/issues/8202), it would be great to have a "Dropdown" component. I see it as a sort of non-modal Popover--it closes in response to clicks outside, but doesn't swallow those clicks, so that you don't have to click twice to activate another interactive element on the page (once to dismiss the open Popover, then again to activate the other element).

My specific use case is that I have a pair of icons next to each other in an AppBar, that each open a small dropdown menu. I would like users to be able to switch between menus (or go to an input/whatever else on the page) without having to click twice.

For reference, I am converting a project of mine from reactstrap to Material UI, and previously I was using reactstrap's [Dropdown](https://reactstrap.github.io/components/dropdowns/) component, which behaves how I would like this to behave. @oliviertassinari linked me to https://material.io/guidelines/components/buttons.html#buttons-dropdown-buttons as the Material UI spec that seems to specify this case.
Repository: godot
Issue: Specular aliasing becomes more visible when depth of field or glow is enabled
Labels: enhancement,topic:rendering,confirmed,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
Godot 3.0 rc1 official 

**OS/device including version:**
Ubuntu 16.04 64 bit
GeForce GTX 750 Ti, NVidia driver 384.111


**Issue description:**
Graphical artifacts are visible (for some viewing angles and zoom levels) when `Dof Far Blur` or `Dof Near Blur` in `environment` is enabled. These artifacts are placed in the areas of "high" reflections (see images). 

**Steps to reproduce:**
Open 3D material_testers demo, enable `Dof Far Blur` and `Dof Near Blur`,  try to zoom in/out, rotate camera. Make the same in the running scene. (artifacts are visible both in editor and in running scene).

Artifacts:
![godot_reflection_artifacts](https://user-images.githubusercontent.com/18085435/34959277-1bd03af6-fa36-11e7-9dfd-fbf3b1dea780.png)
Blur off:
![blur_off](https://user-images.githubusercontent.com/18085435/34959296-29ea22fa-fa36-11e7-8020-058b57fd5247.png)
Blur on:
![blur_on](https://user-images.githubusercontent.com/18085435/34959301-2cffe286-fa36-11e7-9e01-32ee38d4e5b7.png)


**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
Repository: neovim
Issue: Timer callback is not called in inputlist()
Labels: compatibility,complexity:low,event-loop

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`: 0.2.3-dev
- Vim (version: 8.0.0107) behaves differently? Yes
- Operating system/version: macOS High Sierra
- Terminal name/version: zsh
- `$TERM`: tmux-256color

### Steps to reproduce using `nvim -u NORC`

```vim
" test.vim
call timer_start(0, { -> execute('echomsg "Timer has called"', '') })
echomsg 'Before input()'
call input('Promot: ') | redraw
echomsg 'After input()'

call timer_start(0, { -> execute('echomsg "Timer has called"', '') })
echomsg 'Before inputlist()'
call inputlist(['foo', 'bar']) | redraw
echomsg 'After inputlist()'
```

```
nvim -u NORC
:source %
" Hit <CR> twice MANUALLY
:messages
```

### Actual behaviour

```
Before input()
Timer has called
After input()
Before inputlist()
After inputlist()
Timer has called    <--- This is wrong
```

### Expected behaviour

```
Before input()
Timer has called
After input()
Before inputlist()
Timer has called   <--- Should be here
After inputlist()
```

### Problem

Usually I wrap `input()` or `inputlist()` with a function to call `inputsave()` and `inputrestore()` safely like

```vim
function! s:input() abort
  call inputsave()
  try
    return input()
  finally
    call inputrestore()
  endtry
endfunction
```

In this case, calling `feedkeys()` just before `s:input()` does not work as expect so I need to wrap it with `timer_start` to make sure that `feedkeys()` is called during `input()` or `inputlist()` like

```vim
call timer_start(0, { -> feedkeys('Hello World' . "\<CR>", 't') })
let result = s:input('Prompt: ')

if result !=# 'Hello World'
    throw 'FAILED!'
endif
```

But Neovim's `inputlist()` does not call timer callback so I cannot use above hack for `inputlist()`
Repository: rust
Issue: Weird behavior with closure lifetime inference
Labels: A-lifetimes,A-closures,T-compiler,A-inference,C-bug

In the code below, I expect everything to compile, including the commented out code. However, the commented out code does not actually compile. In particular, I believe that adding `let foo = foo` should not affect whether the code compiles, and changing a temporary into a variable should not affect whether the code compiles. (I ran into this problem, or a variant of it, when troubleshooting a problem on the #rust-beginners IRC channel.)

[Playground link](https://play.rust-lang.org/?gist=1768605487cd56aedffc6f7a91e8b58e&version=stable)
```rust
struct Foo;

fn go(x: &mut Foo) -> &mut Foo {x}
fn fix_closure<'a, F: FnOnce() -> &'a mut Foo>(x: F) -> F { x }
fn call<'a, F: FnOnce() -> &'a mut Foo>(x: F) -> &'a mut Foo { x() }
fn id<T>(x: T) -> T { x }

fn good1() {
    let foo = &mut Foo;
    let f = || {let foo = foo; go(foo)};
    f();
}

/*
fn bad1() {
    let foo = &mut Foo;
    let f = || go(foo);
    f();
}
*/

fn good2() {
    let foo = &mut Foo;
    let f = move || {let foo = foo; go(foo)};
    f();
}

/*
fn bad2() {
    let foo = &mut Foo;
    let f = move || go(foo);
    f();
}
*/

fn good3() {
    let foo = &mut Foo;
    call(|| go(foo));
}

/*
fn bad3() {
    let foo = &mut Foo;
    let f = || go(foo);
    call(f);
}

fn bad4() {
    let foo = &mut Foo;
    (|| go(foo))();
}
*/

fn good4() {
    let foo = &mut Foo;
    let f = fix_closure(|| go(foo));
    f();
}

/*
fn bad5() {
    let foo = &mut Foo;
    let f = id(|| go(foo));
    f();
}
*/

fn main() {}
```
Repository: rust
Issue: missed optimization: enum move of the active variant
Labels: I-slow,C-enhancement,T-compiler,C-optimization

This code performs a memcpy of 2064 bytes when 32 bytes would suffice. [See it live @godbolt](https://godbolt.org/g/4A7jmF):

```rust
#![feature(test)] 
#![feature(rustc_private)]
extern crate smallvec;
extern crate test;
use smallvec::SmallVec;

#[inline(never)]
fn clobber<T>(x: T) { test::black_box(x); }

pub fn bar() { 
    // Capacity for 256 `f64`s on the stack.
    // The stack size of `SmallVec` is 256 * 8 + 8 (len) + 8 (discriminant) = 2064 bytes
    let mut v = SmallVec::<[f64; 256]>::new();
    let size = ::std::mem::size_of::<SmallVec<[f64; 256]>>();
    clobber(size);
    for _ in 0..300 {
        v.push(3.14);
    }
    // The vector reallocates to the heap, the size of the active variant
    // is 8 (len) + 8 (capacity) + 8 (ptr) + 8 (discriminant) = 32 bytes
    clobber(v); // memcpy's 2064 bytes instead of 32bytes...
}
```

generates this assembly for the second call to `clobber`:

```asm
  mov edx, 2064
  mov rdi, rbx
  call memcpy@PLT
  mov rdi, rbx
  call example::clobber
```

The layout of `SmallVec` is:

```rust
pub struct SmallVec<A: Array> {
    len: usize,
    data: SmallVecData<A>,
}
enum SmallVecData<A: Array> {
    Inline { array: A },
    Heap { ptr: *mut A::Item, capacity: usize },
}
```

> Note: If `NonZero` would be stable, `SmallVecData` could use it here to remove the 8 bytes of the discriminant. 

So I guess that the problem is that moving an enum just naively generates a memcpy of the whole enum.  I think this is a good default for small enums. When enums get large, they might contain many small variants, and maybe some large ones. 

I don't know if there is an optimal way to solve this problem since adding branches to `memcpy` only some variants might incur a performance cost (unless LLVM knows the value of the active variants and can optimize the branches away). 

We should probably at least always `memcpy` small enums up to some size (16bytes? 256 bytes?) and for larger enums have some heuristic like:

- are all variants approximately equally sized? Then just `memcpy` the whole enum
- are some variants small and some variants large? How many "size classes" are there? Generate as few branches as possible here (ideally two, one for small and one for large variants, but might require more).
Repository: godot
Issue: There seem to be no way to access Blend Shapes values via code
Labels: topic:core,documentation

**Godot version:**
3.0 Beta 2

**Issue description:**
Looks like it's impossible to change values of a Blend Shape in a mesh with a script, or at least it's not documented, even though you can change them in the editor.
Repository: rust
Issue: Undefined reference to `_Unwind_Resume`
Labels: A-linkage,A-LLVM,T-compiler,C-bug

I tried to compile a no_std project with Rust, but setting the `eh_unwind_resume` lang_item does not seem to work properly. Building in release with cargo or -O with rustc works properly, but a debug build fails with an `undefined reference to '_Unwind_Resume'`.

[Here](https://gist.github.com/jefftime/d7e96461138b5aa6895550b63caac66c) is the code I tried to get working.

rustc --version --verbose:
```
rustc 1.25.0-nightly (e6072a7b3 2018-01-13)
binary: rustc
commit-hash: e6072a7b3835f1875e81c9fd27799f9b20a0770c
commit-date: 2018-01-13
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 4.0
```
Repository: godot
Issue: RigidBody gravity affected if CollisionShape attached is rotated/translated when using Bullet physics
Labels: bug,confirmed,topic:physics

**Godot version:**
v3.0-rc1_x11.64

**OS/device including version:**
Debian 9 64-bit

**Issue description:**
Rotating/translating CollisionShape node attached to RigidBody affects physics (gravity) on rigid body when Bullet engine is used. GodotPhysics is unaffected. Basically, rigid body either is not falling down or starts to fly/float.

**Steps to reproduce:**
 Run project attached. Switch between Bullet and GodotPhysics engine.

**Minimal reproduction project:**

[GodotCollisionShapeBug.zip](https://github.com/godotengine/godot/files/1636021/GodotCollisionShapeBug.zip)
Repository: vscode
Issue: Feature Request: Contribute commands with additional arguments
Labels: feature-request,api,menus

Hello, I'm creating an extension to provide easily accessible documentation shortcuts from the command palette in the editor. Currently it does not seem possible to do something like this (where `otherArg` would be an arbitrary argument in package.json):
```
    "contributes": {
        "commands": [
            {
                "command": "extension.doSomething",
                "title": "Example Title",
                "otherArg": "some other argument"
            }
        ]
    },
```

I see that a similar question has been asked here https://github.com/Microsoft/vscode/issues/26436 and also in a resulting (unanswered) SO post here https://stackoverflow.com/questions/43909741/can-i-pass-arguments-to-command-in-contributes-block.

Is this a feature that would be considered? If not, how might this type of thing be accomplished from the extension developer's perspective? I see there is an `args` parameter for command handler functions, but I'm not seeing a way to call `executeCommand` from the package.json file. 

For reference, here is a screenshot of how my equivalent package looks in the command palette in sublime text:
![image](https://user-images.githubusercontent.com/575421/35001510-27321b58-faa4-11e7-9f4b-c26b05408730.png)

Thanks!
Repository: go
Issue: runtime/pprof: labels are not added to profiles
Labels: help wanted,NeedsFix,FeatureRequest,compiler/runtime

### What version of Go are you using (`go version`)?
I have tested on:
go version go1.9.2 darwin/amd64
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`)?
darwin: GOARCH=amd64 GOOS=darwin
linux: GOARCH=amd64 GOOS=linux

### What did you do?
pprof labels that I add using pprof.Do() do not appear in the goroutine profile.

Steps:
- Compile and start: https://play.golang.org/p/SgYgnDqaVKB
- Start "go tool pprof localhost:5555/debug/pprof/goroutine"
- Run the "tags" command
- See no tags, but I expect to see a tag for the label a-label=a-value

I also downloaded the file "localhost:5555/debug/pprof/goroutine"", gunzipped that file, and did not see either the label key nor value in the protobuf file.

When I run "go tool pprof localhost:5555/debug/pprof/goroutine" twice and in the second run run "tags", I see 
```
(pprof) tags
bytes: Total 3
         2 (66.67%): 325.31kB
         1 (33.33%): 902.59kB
```
This shows that labels can work. (I expect no output on the first run, since it is reasonable for no heap memory to have been allocated.)

### What did you expect to see?
I expect to see the tags command output the label key-value pair in the program.

### What did you see instead?
The tags command reports an empty value:
```
(pprof) tags
(pprof)
```
Repository: rust
Issue: Assert well-formedness of spans
Labels: C-enhancement,A-diagnostics,T-compiler

`rustc` currently has peppered throughout the codebase some checks for "backwards spans", spans where their end is earlier than their start. I believe that the current approach of actively checking for this and not fail is very reasonable in beta and stable `rustc`, but in nightly builds I would like to have an assertion so that we expose this incorrectly formatted spans so that the underlying cause can be fixed.

This might take the form of a simple assert and ICEing (not my preference, but it would certainly bring attention to the problem) to generating a diagnostic error and emitting it, allowing the compiler to continue working, but making the problem visible to anyone using the nightly compiler, with text prompting a report in this issue tracker. If we go down the later route, it probably should be a warning, so that anyone using the nightly compiler in production isn't stopped from using it due to a `rustc` bug.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: rust
Issue: Should unit tests spawn new processes instead of threads?
Labels: T-libs-api,C-feature-request,A-libtest,A-process

Imagine a (contrived) piece of code like this:

```
lazy_static!(Q: Mutex<Vec<u32>> = Mutex::new(Vec::new()));

#[test]
fn test_a() {
   {
     Q.lock().unwrap().push(5);
   }
   assert_eq!(Q.lock().unwrap().len(), 1);
}

fn test_b() {
   {
     Q.lock().unwrap().clear();
   }
   assert_eq!(Q.lock().unwrap().len(), 0);

   {
     let q = Q.lock().unwrap();
     q.push(5);
     q.push(6);
   }
   assert_eq!(Q.lock().unwrap().len(), 2);
}
```

This is broken by default because cargo test will by default spawn multiple threads for the tests so the global state of Q.  The user would have to know to pass --test-threads=1 or the test author would have to create a global mutex to synchronize each test on.  This seems like a lot of unnecessary boilerplate, not to mention an unnecessary pain point for new developers to discover when they can't figure out why tests are producing weird results.

There also doesn't seem to be a solution at the moment that would enable you to achieve the benefits of running tests in parallel at all for shared state between tests.  The global mutex approach effectively reduces the test code to implicitly running with --test-threads=1.  Using separate processes by default (or at least providing a decorator to do it easily) would solve the vast majority of such problems without requiring authors to significantly restructure their code.

FWIW, [other](https://github.com/google/googletest/blob/master/googletest/docs/FAQ.md#why-dont-google-test-run-the-tests-in-different-threads-to-speed-things-up) [test](https://stackoverflow.com/questions/12304927/is-there-a-way-to-run-c-unit-tests-tests-in-parallel) frameworks go with the process sharding approach instead of threads.
Repository: flutter
Issue: Add an option to "flutter test/drive/analyze" to make output more machine readable
Labels: a: tests,c: new feature,tool,t: flutter driver,customer: alibaba,c: proposal,P3,team-tool,triaged-tool

Let's make flutter analysis and testing output easier to parse for automation and CI systems.

Adding an option to the flutter test/drive/analyze commands to produce parsable output like JSON would be ideal, e.g. 'flutter test --json'.
Repository: pytorch
Issue: Very slow on CPU
Labels: module: performance,module: rnn,module: cpu,triaged

my model was really slow with pytorch so I tried one of your examples and saw it is slow as well ([seq2seq](http://pytorch.org/tutorials/intermediate/seq2seq_translation_tutorial.html)).

It takes a long time...:
27m 55s (- 390m 53s) (5000 6%) 2.8939
56m 31s (- 367m 27s) (10000 13%) 2.3238
85m 20s (- 341m 23s) (15000 20%) 2.0054
117m 23s (- 322m 50s) (20000 26%) 1.7787
146m 48s (- 293m 36s) (25000 33%) 1.5661

I’m running only on CPU
I’m working on Ubuntu 16.04.3.
64 cores.
Python 3.6.3 :: Anaconda custom (64-bit).

tried using MKL (installed via conda)
didn't help.

Any ideas?



cc @VitalyFedyunin @ngimel @zou3519
Repository: opencv
Issue: Semantic conflicts in cv::InputArray for std::array, float[] and std::vector
Labels: category: core,RFC,future

<!--
If you have a question rather than reporting a bug please go to http://answers.opencv.org where you get much faster responses.
If you need further assistance please read [How To Contribute](https://github.com/opencv/opencv/wiki/How_to_contribute).

This is a template helping you to create an issue which can be processed as quickly as possible. This is the bug reporting section for the OpenCV library.
-->

##### System information (version)
<!-- Example
- OpenCV => 3.1
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->

- OpenCV => master


##### Detailed description

While converting
 - `std::array<float, N>`
 - `std::vector<float>`
 - `float[]`
to `cv::InputArray`,
`std::array` is treated as a column vector, see [here][1]
```.cpp
template<typename _Tp, std::size_t _Nm> inline
_InputArray::_InputArray(const std::array<_Tp, _Nm>& arr)
{ init(FIXED_TYPE + FIXED_SIZE + STD_ARRAY + traits::Type<_Tp>::value + ACCESS_READ, arr.data(), Size(1, _Nm)); }
```

`Size(1,_Nm)`: 1 column, _Nm rows,
while `float[]` and `std::vector<float>` are treated as row vectors,
see [here][2]
```.cpp
template<typename _Tp> inline
_InputArray::_InputArray(const _Tp* vec, int n)
{ init(FIXED_TYPE + FIXED_SIZE + MATX + traits::Type<_Tp>::value + ACCESS_READ, vec, Size(n, 1)); }
```
`Size(n,1)`: n columns, 1 row,
and [here][3]
```.cpp
return szb == szi ? Size((int)szb, 1) : Size((int)(szb/CV_ELEM_SIZE(flags)), 1);
```


[3]: https://github.com/opencv/opencv/blob/master/modules/core/src/matrix.cpp#L1620
[2]: https://github.com/opencv/opencv/blob/master/modules/core/include/opencv2/core/mat.inl.hpp#L119
[1]: https://github.com/opencv/opencv/blob/master/modules/core/include/opencv2/core/mat.inl.hpp#L90


Furthermore, when a `std::vector<float>` is used to
initialize a `cv::Mat`, it is considered as a column vector,
see [here][4]
```.cpp
template<typename _Tp> inline
Mat::Mat(const std::vector<_Tp>& vec, bool copyData)
    : flags(MAGIC_VAL | traits::Type<_Tp>::value | CV_MAT_CONT_FLAG), dims(2), rows((int)vec.size()),
      cols(1), data(0), datastart(0), dataend(0), datalimit(0), allocator(0), u(0), size(&rows), step(0)
```
which confilcts with `cv::InputArray::getMat`, since it returns a row vector
when initialized with `std::vector<float>`.

[4]: https://github.com/opencv/opencv/blob/master/modules/core/include/opencv2/core/mat.inl.hpp#L562

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->