sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Template files for Android do not pass IntelliJ Code Inspection
Labels: platform-android,tool,t: gradle,P2,team-android,triaged-android,fyi-tool

## Steps to Reproduce

- Create a new Intellij flutter project
- VCS/Import into version control/Create GIT repository
- Commit changes on unversioned files
- Browse and add unversioned files
- Select all the files
- Do the commit
- Code analysis dialog box says there are errors

![image](https://cloud.githubusercontent.com/assets/2779084/25253665/bbc573f8-25d6-11e7-964c-b08ccb6ab1bb.png)

If you review the errors things are very mysterious and seem like there is a big problem.
If you just commit the project works fine

## Flutter Doctor
```
[✓] Flutter (on Linux, channel master)
    • Flutter at /home/darrell/flutter
    • Framework revision ca2bf1efd0 (3 hours ago), 2017-04-20 11:37:10 -0700
    • Engine revision a5b64899c9
    • Tools Dart version 1.23.0-dev.11.7

[✓] Host Executable Compatibility
    • Downloaded executables execute on host

[✓] Android toolchain - develop for Android devices (Android SDK 25.0.2)
    • Android SDK at /home/darrell/Android/Sdk
    • Platform android-25, build-tools 25.0.2
    • Java binary at: /home/darrell/android-studio/jre/bin/java
    • Java version: OpenJDK Runtime Environment (build 1.8.0_112-release-b736)

[✓] Android Studio (version 2.4)
    • Android Studio at /home/darrell/android-studio
    • Gradle version 3.4.1
    • Java version: OpenJDK Runtime Environment (build 1.8.0_112-release-b736)

[✓] IntelliJ IDEA Community Edition (version 2017.1)
    • Dart plugin version 171.4249.16
    • Flutter plugin version 12.1

[✓] Connected devices
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 7.1.1 (API 25) (emulator)
```
Repository: rust
Issue: Attribute macros invoked at crate root have issues
Labels: A-attributes,T-compiler,A-macros-2.0,C-bug

When invoking some attribute procedural macro with inner form, i.e. `#![foo_attr]` at the crate root, a resolution error occurs:

```rust
#![feature(proc_macro)]
#![foo_attr]
//^ ERROR: cannot find attribute macro `foo_attr` in this scope

extern crate foo_macros;
use foo_attr_macro::foo_attr;
```

This should, ideally, resolve and execute properly.
Repository: react
Issue: Seb's Deprecation Wishlist Umbrella
Labels: Type: Umbrella,React Core Team

I have a list of breaking changes that I'd like to see because I think they're not strictly necessary features, can often be replaced by other APIs and their very existence makes implementations more constrained, even when they're not used.

This list is not meant to be anything we're planning on actively doing. It's just a drop point where I can add things as I think of them.

- [ ] Shallow freeze the `defaultProps` object and make the `defaultProps` property non-configurable/non-writable after the first `createElement` or `createFactory` call. (Enables inlining/resolution of defaults statically.)

- [ ] Treat `key`/`ref` as a separate namespace in JSX. Meaning that objects that are spread onto JSX don't transfer `key` and `ref`. Enables inlining of props object even if spread type is unknown. E.g.

```js
let x = <Foo {...{key:'bar'}} />;
x.key; // null
x.props.key; // 'bar'
let y = <Foo key="bar" />;
y.key; // 'bar'
y.props.key; // undefined
```

- [ ] Drop support for string refs.

- [ ] Drop support for `ReactDOM.findDOMNode(...)` and `ReactNative.findNodeHandle(...)`. These are slower in Fiber and requires a tree to be materialized/stateful/introspectable at arbitrary times/threads even before we know if this will ever get called. Less automatic cleanup. Could possibly have an alternative API that works more like refs. However, just ref forwarding probably solves all legit use cases better.

- [ ] Make `.type` and `.props` private on `ReactElement`s so that they can't be introspected (just like bound functions/closures). This makes optimizations like automatic making components asynchronous/synchronous safe or inlining components several levels deep.
Repository: awesome-mac
Issue: This is a crazy plan. Everybody vote for me.
Labels: vote

I am going to develop an APP for this list. The following is the design draft. Design drafts welcome comments.

![image](https://cloud.githubusercontent.com/assets/1680273/25285918/8b511e20-26ee-11e7-8ffe-53308da93c64.png)


I will use [React Native macOS](https://github.com/ptmt/react-native-desktop) or [Electron](http://electron.atom.io) to develop it. In fact, I prefer to use  [React Native macOS](https://github.com/ptmt/react-native-desktop) to develop. Please give me a suggestion!

 [Electron](http://electron.atom.io)  vote with "👍", [React Native macOS](https://github.com/ptmt/react-native-desktop) vote with "😀".
Repository: neovim
Issue: stderr from clipboard provider is drawn over buffer
Labels: provider,ux,clipboard

- `nvim --version`:

   ```
   NVIM v0.2.0-1395-gce7cba6d
   Build type: Debug
   Compilation: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -I/Users/anrussell/src/neovim/build/config -I/Users/anrussell/src/neovim/src -I/Users/anrussell/src/neovim/.deps/usr/include -I/Users/anrussell/src/neovim/.deps/usr/include -I/Users/anrussell/src/neovim/.deps/usr/include -I/Users/anrussell/src/neovim/.deps/usr/include -I/Users/anrussell/src/neovim/.deps/usr/include -I/Users/anrussell/src/neovim/.deps/usr/include -I/usr/local/opt/gettext/include -I/usr/include -I/Users/anrussell/src/neovim/build/src/nvim/auto -I/Users/anrussell/src/neovim/build/include
   Compiled by anrussell@anrussell-mba

   Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui
   For differences from Vim, see :help vim-differences

      system vimrc file: "$VIM/sysinit.vim"
     fall-back for $VIM: "/usr/local/share/nvim"
   ```

- Vim (version: ) behaves differently? N/A
- Operating system/version: macOS 10.12
- Terminal name/version: iTerm 2
- `$TERM`: screen-256color

### Actual behaviour

When a clipboard provider prints to stderr (such as `lemonade` being unable to connect to a socket), it draws the stderr over the buffer.

### Expected behaviour

It should print a warning in the command line instead.

### Steps to reproduce using `nvim -u NORC`

Set `PATH` to only include lemonade. Do not start the server.

Try to paste.

### Additional Information

I have a pull request forthcoming for this issue, but I'm not sure how to test it. How can I mock a clipboard provider printing to STDERR?
Repository: go
Issue: net: Windows test use PowerShell "getmac", not always available
Labels: Testing,OS-Windows

The Windows tests use PowerShell "getmac", which only works in Windows Server 2008.

In 2012 and 2016, it fails.

Maybe the replacement is now "Get-NetAdapter | select Name,MacAddress" ?

/cc @alexbrainman @mikioh
Repository: go
Issue: runtime: TestSetGCPercent flaky
Labels: Testing,help wanted,NeedsInvestigation,compiler/runtime

Despite CL 41374, I'm seeing a bunch of trybot failures like https://storage.googleapis.com/go-build-log/6c83b9bd/linux-amd64_cce08b9e.log:

```
--- FAIL: TestSetGCPercent (0.17s)
	garbage_test.go:151: NextGC = 172 MB, want 150±20 MB
```

cc @aclements
Repository: pytorch
Issue: Unhelpful CrossEntropyLoss dimension error message
Labels: module: loss,module: cuda,module: error checking,triaged

I believe I've stumbled upon a slight whoops in nn.CrossEntropyLoss(). If the criterion is called with (a, y) where a in (N, C) and y in (N) such that some yi > C, I get the internal error message below (took a while to parse)... seems like this could use a wrapper. A simple note following the internal error would suffice--how about: "Ensure the class dimension of the predictions matches the class dimension of the targets" ?  

THCudaCheck FAIL file=/py/conda-bld/pytorch_1490903321756/work/torch/lib/THC/generic/THCTensorCopy.c line=65 error=59 : device-side assert triggered

System: Ubuntu 16.06, Python 3.6 (conda install).

cc @ngimel
Repository: node
Issue: readline: prompt opt-out behavior
Labels: confirmed-bug,help wanted,readline

* **Version**: v8.0.0-rc.0
* **Platform**: Windows 4 x64
* **Subsystem**: readline

I am not sure if this is a bug or a feature.

Consider this simple echo interface:
```js
'use strict';

const readline = require('readline');

const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout,
});

rl.on('line', (line) => {
  console.log(line);
});
```
It does not use `rl.prompt()` anywhere and with a common input there will be no default prompt:
<details>
<summary>GIF 1:</summary>

![1](https://cloud.githubusercontent.com/assets/10393198/25309441/020b938c-27d6-11e7-806e-a7a5f650e4d1.gif)

</details><br>

However, if a user press DELETE, BACKSPACE or UP button, default prompt immediately and somehow unexpectedly appears shifting the whole line:

<details>
<summary>GIF 2:</summary>

![2](https://cloud.githubusercontent.com/assets/10393198/25309481/24a945d2-27d7-11e7-80ab-2fa1b7c2a24e.gif)

</details><br>

This can be prevented by setting the `prompt` option into the empty line. However, I am not sure if this opt-out rule is an intended behavior.
Repository: TypeScript
Issue: Variable declaration list comments from async functions are removed
Labels: Bug,Effort: Difficult,Domain: Transforms,Domain: Comment Emit

**TypeScript Version:**  2.2.1

**Code**

```typescript
async function example() {
    // result.value will be promise
    const promise = Promise.resolve("foo");
    await promise;

    // result.value will be "foo"
    return "foo";
}
```

**Expected behavior:**

Ignoring `__awaiter` and `__generator`, the output should include `// result.value will be promise`

**Actual behavior:**

```typescript
function example() {
    return __awaiter(this, void 0, void 0, function () {
        var promise;
        return __generator(this, function (_a) {
            switch (_a.label) {
                case 0:
                    promise = Promise.resolve("foo");
                    return [4 /*yield*/, promise];
                case 1:
                    _a.sent();
                    // result.value will be "foo"
                    return [2 /*return*/, "foo"];
            }
        });
    });
}
```
Repository: go
Issue: cmd/compile: postpone argument conversions after inlining
Labels: Performance,NeedsFix,compiler/runtime

Look at this code:

```go
package main

import (
	"fmt"
)

type Log struct {
	Enabled bool
}

func (l *Log) Print(args ...interface{}) {
	if l.Enabled {
		fmt.Println(args...)
	}
}

func main() {
	var x int = 1000
	l := Log{Enabled: false}
	l.Print("data", x)
}
```

If the code is compiled with `-gcflags=-l=4`, `Log.Print()` is inlined into `main()`. Unfortunately, this does not get rid of the expensive argument conversions to empty interfaces.

I know some work has been merged to speed up conversions of common data to empty interfaces, and that's great for when you are actually logging; but if logging is disabled, you can't fully get rid of the overhead. 

I have a real high-performance program where I selectively enable logging for debugging reasons. Unfortunately, even with logging disabled, the overhead is measurable so I'm forced to actually comment out logging lines.

If the above pattern was optimized correctly, I could reword the API of my high-perf logging library to make sure such an optimization triggers for me.
Repository: go
Issue: cmd/compile: add special binary export encoding for iotas?
Labels: ToolSpeed,compiler/runtime

Poking around the export data for the ssa package, I noticed a lot of runs of constants generated by iota--each with an int value + 1 and a line +1 from its predecessory. It is a somewhat common structure that admits of a compact encoding, something like this:

```go
// export
func (p *exporter) iotas(e []*Node) {
    p.tag(iotaTag) 
    p.int(len(e))
    n := e[0]
    p.pos(n)                            
    p.typ(unidealType(n.Type, n.Val()))
    p.value(n.Val())                   
    for _, n := range e {
        p.qualifiedName(n.Sym) 
    }
}

// import
    // ...
    case iotaTag:
        niota := p.int()
        p.pos() // TODO: hook this up and increase by one line at each new node
        typ := p.typ()
        val := p.value(typ)
        for i := 0; i < niota; i++ {
            sym := p.qualifiedName()
            importconst(p.imp, sym, idealType(typ), nodintconst(val.Interface().(int64)+int64(i)))
        }
        return niota
    // ...
```

A possibly even more compact encoding is to detect common prefixes in names across the entire run, which is fairly common. Even without that, this has a pretty significant impact on the ssa package:

```
name        old export-bytes  new export-bytes  delta
Template          19.0k ± 0%        19.0k ± 0%     ~     (all equal)
Unicode           4.45k ± 0%        4.43k ± 0%   -0.31%  (p=0.002 n=6+6)
GoTypes           29.7k ± 0%        29.6k ± 0%   -0.53%  (p=0.002 n=6+6)
Compiler          75.6k ± 0%        74.3k ± 0%   -1.62%  (p=0.002 n=6+6)
SSA               76.2k ± 0%        65.7k ± 0%  -13.79%  (p=0.002 n=6+6)
Flate             4.98k ± 0%        4.98k ± 0%   +0.02%  (p=0.002 n=6+6)
GoParser          8.81k ± 0%        8.81k ± 0%   +0.01%  (p=0.002 n=6+6)
Reflect           6.25k ± 0%        6.10k ± 0%   -2.37%  (p=0.002 n=6+6)
Tar               9.49k ± 0%        9.46k ± 0%   -0.31%  (p=0.002 n=6+6)
XML               16.0k ± 0%        16.0k ± 0%     ~     (all equal)
[Geo mean]        15.1k             14.8k        -1.98%
```

It's not quite obvious that it's worth doing in general--SSA might be somewhat special.

For discussion, if we make another round of export format changes.
Repository: opencv
Issue: Issues Compiling opencv3.2 with CUDA on Mac OS 10.12
Labels: bug,priority: low,category: build/install,category: gpu/cuda (contrib),platform: ios/osx

My env and lib versions:

`Mac OS 10.12`,
`opencv 3.2`(download from [here](https://sourceforge.net/projects/opencvlibrary/) )
`cuda8.0` ,
`qt5` installed via `brew`, 
`Xcode8 & Xcode7`(with CLT to compile cuda stuff)

I intended to install opencv3.2 by compiling source code.

cmake settings like below:

build without `opencv_highgui`  & `opencv_videoio`(if these settings turned on, compiling would fail)

**TURN OFF**  ` WITH_AVFOUNDATION`,`WITH_1394`,`WITH_QT` ,`WITH_QTKIT`,`WITH_QUICKTIME`,`WITH_TBB`,`WITH_IPP`,`WITH_GSTREAMER` ...

**TURN ON** `WITH_CUDA`,`WITH_EIGEN`,`WITH_JASPER`,`WITH_JPEG`,`WITH_LAPACK`,`WITH_OPENEXR`,`WITH_PNG`,`WITH_PTHREADS_PF`,`WITH_TIFF`

with the setting as above compiled successfully!

but without opencv_highgui & opencv_videoio how can I show a image or read camera frames? 

if I build opencv_videoio, and select any one of `WITH_AVFOUNDATION, WITH_QTKIT,WITH_QUICKTIME` will not successfully compiling.

errors like:
(this error generate with quicktime FLAG)

```
 ~/openCV/opencv-3.2.0/modules/videoio/src/cap_qt.cpp:75:5: error: unknown type name 'Movie'
    Movie      myMovie;            // movie handle
    ^

~/openCV/opencv-3.2.0/modules/videoio/src/cap_qt.cpp:103:9: error: use of undeclared identifier 'EnterMovies'
        EnterMovies();
        ^

~/openCV/opencv-3.2.0/modules/videoio/src/cap_qt.cpp:142:5: error: use of undeclared identifier 'ClearMoviesStickyError'
    ClearMoviesStickyError ();
    ^
```
Repository: go
Issue: cmd/compile: big binary and slow compilation times with maps & []interface{} in static code
Labels: ToolSpeed,NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?

go version go1.8.1 darwin/amd64

### What operating system and processor architecture are you using (`go env`)?

darwin_amd64

### What did you do?

I switched some static data from being encoded in the binary as a large raw string to generating Golang code representing data structures, where the data represented covers "all assigned Unicode codepoints", at 31618 elements.

I removed a couple of map[rune]whatever items and constructed them at runtime, to get compiler times down from one minute back to a couple of seconds.

Even after making that change, I did not initially notice that the `unicode.a` file had gone up to 509MB and the executable to 491MB.  I tried a couple of things, but the key was to switch a slice of `[]interface{}` to `[]ConcreteType`.  At runtime I need the `[]interface{}` (to feed to Ferret for substring search) but switching the compiled-in slice from elements of `interface{}` to elements of concrete types brought `unicode.a` down to 4.4MB (from 509MB) and the executable down to 9.4MB.

Code is: https://github.com/philpennock/character
(go get compatible, though `make` will do some embedding)

### What did you expect to see?

Non-degenerate performance in compile times or library/executable sizes.

### What did you see instead?

Something which made me think I was compiling C++, not Golang.  😄
Repository: rust
Issue: include!() in statement position expects an expression
Labels: A-macros,I-needs-decision,T-lang,C-bug

a.rs

```rust
fn main() {
    include!("b.rs")
}
```

b.rs

```rust
fn b() {}
```

rustc 1.18.0-nightly (2bd4b5c6d 2017-04-23)

```rust
error: expected expression, found keyword `fn`
 --> b.rs:1:1
  |
1 | fn b(){}
  | ^^
```
Repository: rust
Issue: Tracking issue for trait aliases
Labels: A-trait-system,B-RFC-approved,T-lang,B-unstable,C-tracking-issue,F-trait_alias,S-tracking-needs-summary

This is a tracking issue for trait aliases (rust-lang/rfcs#1733).

TODO:

- [x] Implement: [tracking issue](https://github.com/rust-lang/rust/issues/55628)
- [x] #56485 — Bringing a trait alias into scope doesn't allow calling methods from its component traits (done in https://github.com/rust-lang/rust/pull/59166)
- [x] #56488 — ICE with trait aliases and use items 
- [x] #57023 — Nightly Type Alias Compiler panic `unexpected definition: TraitAlias` 
- [x] #57059 — `INCOHERENT_AUTO_TRAIT_OBJECTS` future-compatibility warning (superseded by https://github.com/rust-lang/rust/pull/56481)
- [ ] Document
- [ ] Stabilize

Unresolved questions:

- [ ] Are bounds on other input types than the receiver enforced or implied?
- [ ] Should we keep the current behaviour of "shallow-banning" `?Sized` bounds in trait objects, ban them "deeply" (through trait alias expansion), or permit them everywhere with no effect?
- [ ] [Insufficient flexibility](https://github.com/rust-lang/rust/issues/41517#issuecomment-544340795)
- [ ] [Inconvenient syntax](https://github.com/rust-lang/rust/issues/41517#issuecomment-544763195)
- [ ] [Misleading naming](https://github.com/rust-lang/rust/issues/41517#issuecomment-479226997)
- [ ] Which of constraint/bound/type aliases are desirable
Repository: go
Issue: cmd/compile: move arch-specific rewrite rules and ops into arch-specific packages
Labels: Performance,ToolSpeed,NeedsFix,compiler/runtime

Right now, all the .rules files, all the generated code, and all the ops are in package ssa. This monolith has a few downsides: It seems a bit semantically incorrect, and it contributes to issues like #20084, and it makes rebuilding the compiler slower when working on the ssa package.

I'd like to move all the arch-specific stuff into cmd/compile/internal/ARCH. This is non-trivial and does have costs. Rough proposed plan:

1. Export all functions used by rewrite rules, so that they can be called from outside package ssa. There's a lot of this, including API surface we might normally keep private.

2. Everywhere we refer to arch-specific ops in package ssa, add some form of generalization.

3. Set up registration hooks for the value and block rewriters, must as we do now for SSAMarkMoves.

4. Move .rules and ops files to package ssa and teach rulegen about that. Within the generated files, do `import . "cmd/compile/internal/ssa"` to avoid having the teach rulegen to do `ssa.NewValue` for arch rules but just `NewValue` for generic rules. This will also reduce churn in the rules files themselves.

I think that's all that needs doing, but we might find more along the way; I started on this but it was big enough I wanted to discuss first.

Comments?

cc @mdempsky @bradfitz @randall77
Repository: angular
Issue: @ContentChildren not populating from parent <ng-content>
Labels: feature,effort2: days,state: Needs Design,workaround3: complex,area: core,core: queries,core: content projection,P4,feature: under consideration

```
[*] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
```

**Current behavior**
@ContentChildren does not seem to work on Parent <ng-content> containers. Even if the ng-content is a child of the component.

**Expected behavior**
I expect that ContentChildren is filled if it is a child of the component

**Minimal reproduction of the problem with instructions**
https://plnkr.co/edit/J5itJmDfwKwtBsG6IveP?p=preview

Main HTML:

```html
<div>
  <child>
    <test></test>
    <test></test>
    <test></test>
  </child>
  <br><br>
  <parent>
    <test></test>
    <test></test>
    <test></test>
  </parent>
</div>
```
Child Component:

```html
<h2>Child</h2>
<parent>
  <ng-content></ng-content>
</parent>
```
Parent Component:

```html
<h3>Parent</h3>
<ng-content></ng-content>
<div class='length'>Line count : {{length}}</div>
```

**Please tell us about your environment:**
Windows, Angular4
Repository: go
Issue: x/arch/x86/x86asm: 64-bit CMOV is disassembled as 32-bit CMOV
Labels: NeedsFix

These two sequences are disassembled by x86asm with the same string:

```
0f4dd0        CMOVGE AX, DX
480f4dd0      CMOVGE AX, DX
```

If I'm not mistaken, the second is the 64-bit version and should probably use a mnemonic like `CMOVQGE` (or the other one should use `CMOVLGE`).