sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: create-react-app
Issue: Code coverage comments like `/* istanbul ignore file */` are ignored for jsx files
Labels: issue: needs investigation

### Is this a bug report?

Yes

### Did you try recovering your dependencies?

Yes - I have a minimum repo to reproduce.

### Which terms did you search for in User Guide?

istanbul comment
coverage comment

### Environment

 System:
    OS: Windows 10
    CPU: x64 Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
  Binaries:
    Yarn: 1.12.3 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: 42.17134.1.0
    Internet Explorer: 11.0.17134.1
  npmPackages:
    react: ^16.7.0 => 16.7.0
    react-dom: ^16.7.0 => 16.7.0
    react-scripts: 2.1.2 => 2.1.2
  npmGlobalPackages:
    create-react-app: Not Found

### Steps to Reproduce

Code coverage comments like `/* istanbul ignore file */` are ignored for jsx files. When you set up a new app, adding this line to `index.js` doesn't work. This seems to be related to the Babel config as pure JS files work fine.

Here's an example repo:
1. Clone https://github.com/dbartholomae/coverage-bug
2. Run `npm test` (note that the command is modified in package.json and includes the coverage flag)

This could be related to #5756 

### Expected Behavior

Neither `index.js` nor `index-no-jsx.js` should show up in the coverage-report.

### Actual Behavior

`index.js` shows up in the coverage-report.

### Reproducible Demo

See "Steps to Reproduce"
Repository: rust
Issue: Rework `char::eq_ignore_ascii_case` parameter type
Labels: C-enhancement,T-libs-api,A-str

Right now:

    pub fn eq_ignore_ascii_case(&self, other: &char) -> bool {
        self.to_ascii_lowercase() == other.to_ascii_lowercase()
    }

This means that `'a'.eq_ignore_ascii_case('b')` doesn't compile.  Instead the user must type `'a'.eq_ignore_ascii_case(&'b')`.  I would like to allow for both *without breaking backwards compatibility*.

One option would be to change the signature to the following:

    pub fn eq_ignore_ascii_case<C: AsRef<char>>(&self, other: C) -> bool {
        self.to_ascii_lowercase() == other.as_ref().to_ascii_lowercase()
    }

This would require us to implement `AsRef<char>` for `char` and `&char` to facilitate this.
Repository: opencv
Issue: build failed using mingw dshow module in master
Labels: category: build/install,incomplete,platform: other

<!--
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).

Please:

* Read the documentation to test with the latest developer build.
* Check if other person has already created the same issue to avoid duplicates. You can comment on it if there already is an issue.
* Try to be as detailed as possible in your report.
* Report only one problem per created issue.


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 => 4.0 (master)
- Operating System / Platform => Windows 7
- Compiler => MinGW GCC 8.1

##### Detailed description

<!-- your description -->

##### Steps to reproduce

<!-- to add code example fence it with triple backticks and optional file extension
    ```.cpp
    // C++ code example
    ```
 or attach as .txt or .zip file
-->
```
cmake.exe -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -G Ninja ..
```
Repository: TypeScript
Issue: grammar errors should be reported as syntactic diagnostics
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.3.0-dev.20181222

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

**Code**

```ts
// @filename: test.js
function test(...args,) {} // trailing comma not allowed

class C {
  async static foo() {} // modifiers are in the wrong order
}

@decorator // invalid decorator location
async var v = 1; // invalid modifier location

let {...rest: rest} = {}; // rest property cannot have a property name
```

**Expected behavior:**

All errors above are reported in JS files as they result in parse errors when executed.

**Actual behavior:**

The above file has no errors. They are not reported as syntax errors because TypeScript's parser is more permissive than the spec in many cases. Since grammar errors are only reported during type-checking they are ignored in JS files without `// @ts-check`.

Other JS parsers, e.g. javascript VMs, emit a parse error for the code above.

**Related Issues:** 
#6107 suggests moving grammar errors to the binding phase
#6802
Repository: rust
Issue: Adding --emit=asm speeds up generated code because of codegen units
Labels: A-driver,T-compiler,C-bug

With the following rust code:
```rust
pub fn main() {
    print_triples();
    println!("hello");
}


fn print_triples() {
    let mut i = 0 as i32;
    for z in 1.. {
        for x in 1..=z {
            for y in x..=z {
                if x*x + y*y == z*z {
                    i = i + 1;
                    if i == 1000 {
                        return;
                    }
                }
            }
        }
    }
}
```
I get:
```
/tmp/pythagoras$ rustc --emit=link -O simple.rs
/tmp/pythagoras$ time ./simple
hello

real	0m0.290s
user	0m0.287s
sys	0m0.002s
/tmp/pythagoras$ rustc --emit=asm,link -O simple.rs
/tmp/pythagoras$ time ./simple
hello

real	0m0.005s
user	0m0.002s
sys	0m0.002s
/tmp/pythagoras$ rustc --version
rustc 1.32.0-nightly (400c2bc5e 2018-11-27)
/tmp/pythagoras$
```
Repository: neovim
Issue: UI extension work (tracking issue)
Labels: enhancement,ui,ui-extensibility

Tracking/discussion issue for planned UI enhancements. NB: being mentioned on the list below is not a guarantee for being done at any specific time scale, nor is the order necessarily indicative of readiness/priority (except perhaps for the smaller follow-up items for multigrid, which I hope to get done pretty soon). Feel free to add stuff.

- [x] multigrid (#8455 **merged**)
  - [x] improve size handling: non-screen functions should use requested size, not grid allocated size.
  - [x] `:term` sizing issues (fix `terminal_resize`)
  - [x] mouse support (#9429)
  - [ ] messages on dedicated grid (when not `ext_messages`)
- [x] floating windows (#6619)
  - [x] for `!ext_popupmenu`: pum as float (#9530)
  - [x] for `ext_popupmenu`: add tests for grid anchoring 
  - [x] `nvim_win_close` to close window by id.
  - [x] Ex-commands for floats (#9663)
      - [ ] #9920
  - [x] `pumblend` but for floats (because why not)
- [x] `ext_messages` (#7466)
- [ ] `ext_windows`: UI control of layout and wincmds (#8707)
- [x]  use `ext_popupmenu` events for wildmenu to support info and pum (#9607) 
- [ ] `ext_statusline` (I have some ideas/pre-WIP code...)
- [ ] external columns (number, signs) by transmitting `wline_T` info (no work done)
- [ ] "tabgrid" (#7541 but with multigrid)
- [x] transmit UI highlight definitions for `ext_popupmenu` using `hl-Pmenu`, etc. (#10504)
    - [x] ensure that we always use concrete rgb colors for `default_colors_set`
    - [ ] allow subscribing non-default groups
- [x] UI control of `ext_popupmenu` #9445 
    - [ ] For `ext_cmdline` maybe `nvim_call_function('setcmdpos')` already works (check + add docs/test)
Repository: neovim
Issue: Comments autoformatted even without formatoptions 'c' flag
Labels: bug-vim,needs:vim-patch

<!-- Before reporting: search existing issues and check the FAQ. -->

Note: I also filed this as a vim issue [here](https://github.com/vim/vim/issues/3746).

- `nvim --version`: 0.3.1
- Vim (version: 8.1.146) behaves differently? no
- Operating system/version: NixOS 18.09
- Terminal name/version: st-0.8.1
- `$TERM`: st-256color

### Steps to reproduce using `nvim -u NORC`

```
nvim -u NORC
:set fo=ta<cr>i% test<cr>% test
```

### Actual behaviour

On typing the second '%', autoformatting kicks in, and the two lines are combined into one. The final result is a single line:

```
% test % test
```

### Expected behaviour

Since `:set comments` gives a string including ":%", I expect that when I type the second '%', neovim recognizes the second line as a comment and does not combine the two lines into one, since `formatoptions` does not include the `c` flag. My expected final result is:

```
% test
% test
```

### Explanation

The documentation for `fo-table` says:

> With 't' and 'c' you can specify when Vim performs auto-wrapping:
> value	action
> ""	no automatic formatting (you can use "gq" for manual formatting)
> "t"	automatic formatting of text, but not comments
> "c"	automatic formatting for comments, but not text (good for C code)
> "tc"	automatic formatting for text and comments

When we use `set fo=ca`, we get the nice behavior where no automatic formatting is done outside of comments, but comments reflow automatically. The documentation above leads me to expect the symmetric behavior for `set fo=ta`, where no automatic formatting is done within comments, but the rest of the text reflows automatically. The example above shows that the behavior is not symmetric the way the documentation suggests, unless I'm misunderstanding the documentation.

One reason I want to use `set fo=ta` is for editing Markdown files--if it worked the way I expected, I could set the `comments` option so that code blocks are considered as comments. Then I could get automatic formatting in most of the file, yet avoid automatic formatting within code blocks.
Repository: TypeScript
Issue: Lots of async-specific code in computeSuggestionDiagnostics
Labels: Bug,Domain: Refactorings

There's lots of async-specific code in computeSuggestionDiagnostics. It should probably be in the async codefix.
Repository: TypeScript
Issue: "is not a constructor" should be detected in compile time as "used before its declaration."
Labels: Suggestion,Awaiting More Feedback,Experience Enhancement

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.2
This repository demonstrates that I run in to the issue in ts@next. 
https://github.com/qballer/tsbug

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
constructor, lexical scope, run time error vs compile time
**Code**

```ts
const b = getB() 

function getB() {
    // will throw C is not a constructor in runtime 
    return new C() // ** 
}

// Will generate:  Class 'C' used before its declaration.
// const instanceOfC = new C()

class C {}
```

**Expected behavior:**
Should generate:  Class 'C' used before its declaration.

**Actual behavior:**
Explodes in runtime with 'is not a constructor' error.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
[Playground](http://www.typescriptlang.org/play/#src=const%20b%20%3D%20getB()%20%0D%0A%0D%0Afunction%20getB()%20%7B%0D%0A%20%20%20%20return%20new%20C()%0D%0A%7D%0D%0A%0D%0Aclass%20C%20%7B%7D)
[Repo](https://github.com/qballer/tsbug)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: You-Dont-Know-JS
Issue: "abc".match( RegExp.prototype ) gives an error
Labels: for second edition

When you call `"abc".match( RegExp.prototype )` the console will give an error: Method RegExp.prototype.exec called on incompatible receiver [object Object]
 
To avoid this, you need to convert RegExp.prototype to a String, like this:

`"abc".match( RegExp.prototype.toString() );  \\null`

which returns `null` because the match method could not find any string with the pattern of `"/(?:)/"`.

When match finds something it will return an **Array Object,** for example: `"abc".match(/ab/); `returns` ["ab"];`

PR #1397
Repository: TypeScript
Issue: Optional fields affecting keyof operator in generic class decorators
Labels: Suggestion,In Discussion,Domain: Mapped Types

**TypeScript Version:**  3.2.2

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
class decorator keyof typescript 

**Code**

```ts
function View<T>(name: string, fields: (keyof T)[]) {
  return (target: new(...args: any[]) => T) => {
    // Do something with fields
  };
}

// works
@View('active', ['street1', 'street2'])
class Address {
  street1: string;
  street2: string;
}

// broken
@View('active', ['street1', 'street2'])
class AddressBroken {
  street1: string;
  street2?: string;
}
```

**Expected behavior:**
Both scenarios should work above.  

**Actual behavior:**
It appears that optional fields are causing the decorator to create invalid types.

```
Argument of type 'typeof AddressBroken' is not assignable to parameter of type 'new (...args: any[]) => { street1: any; street2: any; }'.
  Type 'AddressBroken' is not assignable to type '{ street1: any; street2: any; }'.
    Property 'street2' is optional in type 'AddressBroken' but required in type '{ street1: any; street2: any; }'.
1234
```

**Playground Link:** 
[Playground Sample](http://www.typescriptlang.org/play/#src=%0D%0Afunction%20View%3CT%3E(name%3A%20string%2C%20fields%3A%20(keyof%20T)%5B%5D)%20%7B%0D%0A%20%20return%20(target%3A%20new(...args%3A%20any%5B%5D)%20%3D%3E%20T)%20%3D%3E%20%7B%0D%0A%20%20%20%20%2F%2F%20Do%20something%20with%20fields%0D%0A%20%20%7D%3B%0D%0A%7D%0D%0A%0D%0A%2F%2F%20works%0D%0A%40View('active'%2C%20%5B'street1'%2C%20'street2'%5D)%0D%0Aclass%20Address%20%7B%0D%0A%20%20street1%3A%20string%3B%0D%0A%20%20street2%3A%20string%3B%0D%0A%7D%0D%0A%0D%0A%2F%2F%20broken%0D%0A%40View('active'%2C%20%5B'street1'%2C%20'street2'%5D)%0D%0Aclass%20AddressBroken%20%7B%0D%0A%20%20street1%3A%20string%3B%0D%0A%20%20street2%3F%3A%20string%3B%0D%0A%7D%0D%0A)
Repository: flutter
Issue: Add boxShadow to ClipPath
Labels: c: new feature,framework,P2,team-framework,triaged-framework

Hi there, I'm trying to add a boxShadow to a clipped container, but I can't find any docs or way to do it. The closest thing I could find is this stackoverflow answer, but it seems a bit too low level https://stackoverflow.com/questions/51232532/how-to-add-a-border-to-a-clipped-image

I assume this show could be expanded to request having the ability to add a border or a border shadow to any type of clipped widgets.
Repository: godot
Issue: Nothing gets printed in release build
Labels: bug,topic:core

Godot 3.1 ee6f1fa3f8a7aa48ed9becb0039f39e1c7f395cc
Windows 10 64 bits

I made a release build of the engine to test a change I'm working on, but nothing gets printed in the console. I need to `print()` from GDScript, but even this outputs nothing. Is there something I'm missing?
I also launched Godot with the `-v` flag.

I can't even `printf`, and I also can't place a C++ breakpoint to see what I print, because... it's a release build. This prevents me from testing constrained code regions.
Repository: godot
Issue: Godot crashes on window resize on NVIDIA graphics cards (fixed in `master`)
Labels: bug,platform:windows,topic:rendering,topic:porting,confirmed,crash

___

***Bugsquad edit:** This issue has been confirmed several times already. No need to confirm it further.*

___

**Godot version:**
v3.0.6 (About page lists Godot Engine v3.0.6.stable.official.8314054)

**OS/device including version:**
Windows 10 Pro, NVIDIA Display Driver v417.35
Godot executable console prints 'OpenGL ES 3.0 Renderer: GeForce GTX 1080/PCIe/SSE2'

**Issue description:**
This happens to me with all Godot-built applications I've tried and/or built myself so far. Upon every resize along a corner, the application runs the risk of crashing. This will give no error, but silently exit the application. While it does give a 'server disconnected' error, I presume this is the debugging socket.

- The crash can be triggered by (rapidly) resizing the window by clicking and dragging along the **corners only**. If you resize it slower, it will still crash, but take a longer time.
- This happens with **any** project I've tested so far. To test, I have started a new project, added a single Panel, and built the executable. This will also crash with the step described above.
- It will **not** occur when resizing along only one axis, not along any single edge. 
- It will not occur when maximizing or restoring the window, no matter how often.
- Moving the whole application window off the screen to force repainting will not crash it either. 

<!-- What happened, and what was expected. -->
**Steps to reproduce:**
- Build a Godot application on Windows, or run the project from within the editor. Make sure the project is windowed, and the settings allow for resizing the window.
- Resize the application along any *corner* point. It has to be a corner. Dragging the corner around fast will make the crash occur earlier. If the mouse is jerked around fast enough, it will always crash within a second.
- The application will lock up for a second, then silently crash.

**Minimal reproduction project:**
Any, as far as I can tell. Create a new project, add a panel and build/test it.
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
Repository: rust
Issue: Clarify docs around what libcore users must declare
Labels: C-enhancement,T-libs-api,A-docs

I find [the documentation about what libcore depends on](https://github.com/rust-lang/rust/blob/7a0911528058e87d22ea305695f4047572c5e067/src/libcore/lib.rs#L21-L39) a bit confusing right now. I'm trying to make my `#[no_std]` crate compile after a year on inactivity for context.

Now firstly, this section describes several symbols, but is the actual symbol name relevant (ignoring `memcpy`/`memset`/etc)?  Or do we only care about the existence of some function labeled with the appropriate attribute? The distinction between symbol name and the associated lang attribute is confusing here. 

>rust_begin_panic - This function takes four arguments, a fmt::Arguments, a &'static str, and two u32's. These four arguments dictate the panic message, the file at which panic was invoked, and the line and column inside the file. It is up to consumers of this core library to define this panic function; it is only required to never return. This requires a lang attribute named panic_impl.

It appears that the `#[lang="panic_impl"]` mentioned is already declared in [`libcore/panicking.rs`](https://github.com/rust-lang/rust/blob/7a0911528058e87d22ea305695f4047572c5e067/src/libcore/panicking.rs#L76). It appears that this should refer to `#[lang = "panic_fmt"]` instead, which is what `libcore` users formerly had to declare but is now [implicitly declared by by the new `#[panic_handler]`](https://github.com/rust-lang/rfcs/blob/master/text/2070-panic-implementation.md#panic_implementation). Rustc will complain about missing a `#[panic_handler]` currently. So this section should probably be updated to refer to `#[panic_handler]` instead.

>rust_eh_personality - is used by the failure mechanisms of the compiler. This is often mapped to GCC's personality function, but crates which do not trigger a panic can be assured that this function is never called. The lang attribute is called eh_personality.

It should probably be mentioned that `#[lang="eh_personality"]` seems only necessary if `panic=unwind`. Additionally should perhaps mention `_Unwind_Resume` as well (which theoretically is only necessary for `panic=unwind` builds but can erroneously be required for `panic=abort opt-level=0` builds see #53301). There's actually more of these `eh` functions that should be perhaps mentioned depending on your target. The subtleties are explained in `libpanic_unwind` and `libpanic_abort`.

Along the same lines, the docs of `liballoc` should probably also mention `#[alloc_error_handler]` (see #51540).

I can try writing up a draft or PR but wanted to get feedback first.
Repository: vue-element-admin
Issue: tags-view 的使用问题
Labels: feature

怎么将列表页面和详情页面都使用一个 tags？也就是 tags 处于 active 状态

列表：
![image](https://user-images.githubusercontent.com/16145443/50579762-0d68fe00-0e83-11e9-93e2-e05ae08495bf.png)


详情：
![image](https://user-images.githubusercontent.com/16145443/50579770-1954c000-0e83-11e9-96b8-6fbc6f3d962f.png)
Repository: rust
Issue: Unused symbol breaks Profiled Guided Optimization (PGO)
Labels: A-linkage,C-bug

My crate is structured to build both a `bin` and a `dylib` that is loaded by a 3rd-party program.  The stand-alone `bin` part doesn't actually use any of the external symbols, so despite it sharing code with the `lib` part, it runs fine without the symbols being defined.

However, when I turn on PGO, these undefined symbols cause linking errors.  My expectation is that if my crate works without PGO, it should work with PGO enabled, but maybe that's incorrect?

My actual crate gets these undefined symbols from here:
https://github.com/robsmith11/krust/blob/master/src/kbindings.rs#L483

But this minimal example reproduces the problem:
```
fn main() {
}

extern "C" {
    pub fn f();
}

#[no_mangle]
pub extern fn g() {
    unsafe { f(); }
}
```
```
$ RUSTFLAGS="-Z pgo-gen=/tmp/prof.data" cargo run --release 
    Compiling play v0.1.0 (/home/me/e/code/play)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/target_play/release/deps/play-e890b10933e5432f.play.1uu11z5v-cgu.0.rcgu.o" "-o" "/tmp/target_play/release/deps/play-e890b10933e5432f" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/tmp/target_play/release/deps" "-L" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/tmp/rustcvLfVyu/libprofiler_builtins-4ecfbf392fb1b2b9.rlib" "-Wl,--start-group" "/tmp/rustcvLfVyu/libstd-4f6a41fe25da1d4f.rlib" "-Wl,--end-group" "/home/me/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-cd088bc8787919ee.rlib" "-Wl,-Bdynamic" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil" "-u" "__llvm_profile_runtime"
  = note: /usr/bin/ld: /tmp/target_play/release/deps/play-e890b10933e5432f.play.1uu11z5v-cgu.0.rcgu.o: in function `g':
          play.1uu11z5v-cgu.0:(.text.g+0xa): undefined reference to `f'
          collect2: error: ld returned 1 exit status
```

EDIT:
Not sure whether it's relevant, but removing the `#[no_mangle]` makes it work with PGO.