sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Attributes on macro does not trigger error or warning
Labels: A-diagnostics,T-compiler,C-bug

Using `rustc 1.25.0-nightly (9fd7da904 2018-01-25)`,

```rust
fn foo() {
    println!("hello world");
}

fn main() {
    #[rustfmt_skip]
    foo ();
}
```

the abvoe code triggers an error:

```
error[E0658]: The attribute `rustfmt_skip` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
  --> test.rs:18:5
   |
18 |     #[rustfmt_skip]
   |     ^^^^^^^^^^^^^^^
   |
   = help: add #![feature(custom_attribute)] to the crate attributes to enable

error: aborting due to previous error
```

However, the following code compiles without any error:

```rust
fn main() {
    #[rustfmt_skip]
    println! ("hello world");
}
```

It looks like the attributes on macros are entirely ignored from the compiler. Is this an expected behavior?
Repository: create-react-app
Issue: Inform the developer about new releases and how to upgrade
Labels: issue: proposal

Hi, guys.

How do you know if there is a new release to update? I usually use `npm-check` but other people could check manually going to [Releases](https://github.com/facebook/create-react-app/releases), among others. Whatever it is, you get the information after requesting manually.

I want to make a proposal to avoid this. If there is a new version, CRA will alert you about this if you run on development mode. So, you could see a message (browser console and terminal) while you are working.

Messages might vary. I'll give you some possible examples as proposals.

- Info: There is a new major release. Read more on...
- Info: There are 2 new major release ahead to your current version. Read more on...
- Info: There is a new minor release. You could upgrade easily just running this command on your terminal...

How cool would be that for developers who want to save time and be focus on the app as much as possible?
Repository: vscode
Issue: Support assigning numeric value to "editor.wrappingIndent"
Labels: feature-request,editor-core

- VSCode Version: 1.19.3

`editor.wrappingIndent` is currently supporting `"none"`, `"same"`, `"indent"`.

The problem with `"same"` is that it is difficult to know where the new line starts, and the problem with `"indent"` is that it is difficult to know where the new block starts. (Also, I don't like `"none"` 😜)

Many IDEs and editors support custom numeric value for wrapping indent.
I hope this feature is also supported in Visual Studio Code.

**Current:** `"editor.wrappingIndent": "same"`
![Current](https://user-images.githubusercontent.com/2531397/35442210-c0ee2cbc-02e9-11e8-8678-9a85dcbf0795.png)

**Desired:** `"editor.wrappingIndent": 1`
![Desired](https://user-images.githubusercontent.com/2531397/35442235-ddcd1fb4-02e9-11e8-8973-ff836bedca8b.png)
Repository: go
Issue: cmd/go: coverage profile should be cached with tests
Labels: NeedsFix

As briefly discussed here: https://twitter.com/_rsc/status/956888213314068481

I don't see why Go shouldn't cache the results of `-coverprofile` when running tests, as test coverage shouldn't vary from run to run, given the same set of arguments.

### What version of Go are you using (`go version`)?

`go version go1.10rc1 darwin/amd64`

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

```
$GOOS="darwin"
$GOARCH="amd64"
```

### What did you do?

Call `go test -coverprofile=coverprofile.out ./...` multiple times.

### What did you expect to see?

Test results cached between runs.

```
$ go test -coverprofile=coverprofile.out ./...
ok  	github.com/bbrks/tmp	2.893s	coverage: 46.1% of statements
$ go test -coverprofile=coverprofile.out ./...
ok  	github.com/bbrks/tmp	(cached)
```

### What did you see instead?

Test results were not cached between runs.

```
$ go test -coverprofile=coverprofile.out ./...
ok  	github.com/bbrks/tmp	2.893s	coverage: 46.1% of statements
$ go test -coverprofile=coverprofile.out ./...
ok  	github.com/bbrks/tmp	2.893s	coverage: 46.1% of statements
```
Repository: go
Issue: gccgo: GOARCH is not validated
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!


### What version of Go are you using (`go version`)?
```
go version go1.9 linux/amd64
```

### Does this issue reproduce with the latest release?
Yes

### What did you do?

```
$ GOARCH=386 go build -v -compiler gccgo ./mypkg/
go build: when using gccgo toolchain, please pass compiler flags using -gccgoflags, not -gcflags
mypkg
# mypkg
version.go:7:9: error: import file ‘strconv’ not found
  "strconv"
$ GOARCH=xxx go build -v -compiler gccgo ./mypkg/
go build: when using gccgo toolchain, please pass compiler flags using -gccgoflags, not -gcflags
mypkg
$ echo $?
0
```

### What did you expect to see?

Failure when the provided `GOARCH` is invalid.

### What did you see instead?
It builds for the default `GOARCH`.

If a valid architecture is provided it tries to build that one, failing if the standard library is not built for it. If a bogus one is provided, no errors are returned and the default one is picked instead.
Repository: flutter
Issue: flutter run usage for iOS (e.g. hotrun/ios) does not include architecture type
Labels: c: new feature,team,tool,P2,team-tool,triaged-tool

It's a little odd that our usage stats report arch type for Android but not iOS:

hotrun/android-arm
hotrun/ios
hotrun/android-x86
hotrun/android-x64
run/android-arm

It seems like either we should add the arch type to iOS or remove them from all of them (and get the arch type through another pivot of the data).

Not a big deal.
Repository: go
Issue: archive/zip: invalid zip64 extra fields as per strict interpretation of APPNOTE.TXT
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
Looking at git master (currently d85a353 of writer.go)

### Description

There seems to be an error in *archive/zip/writer.go* when creating a zip64 extra field when the local header offset is less than UINT32_MAX (e.g. for the first file in the central directory).

https://github.com/golang/go/blob/master/src/archive/zip/writer.go#L114 writes the 64-bit offset of the local header to the zip64 extra field even if the 32-bit offset written at https://github.com/golang/go/blob/master/src/archive/zip/writer.go#L129 isn't equal to 0xFFFFFFFF.

According to APPNOTE.TXT, this isn't allowed as per:
```
      The order of the fields in the zip64 extended 
      information record is fixed, but the fields MUST
      only appear if the corresponding Local or Central
      directory record field is set to 0xFFFF or 0xFFFFFFFF.
```
While Info-ZIP and other implementations may not care about extraneous fields, Microsoft's implementation explodes accordingly at https://referencesource.microsoft.com/#WindowsBase/Base/MS/Internal/IO/Zip/ZipIOExtraFieldZip64Element.cs,120 because it won't expect the field by this logic https://referencesource.microsoft.com/#WindowsBase/Base/MS/Internal/IO/Zip/ZipIOCentralDirectoryFileHeader.cs,92

### Proposed solution

Change https://github.com/golang/go/blob/master/src/archive/zip/writer.go#L126 to say:
```go
	if h.isZip64() || h.offset > uint32max {
```
instead of
```go
	if h.offset > uint32max {
```
to mimic the logic some lines above that decides when to write the zip64 extra field at all.

This seems to be the minimal change to fix the issue, otherwise the extra field might need to vary in size.

P.S. thanks to archive/zip authors for providing a readable reference
Repository: rust
Issue: derived Clone implementations for many-variant enums are unnecessarily large
Labels: C-enhancement,T-compiler,I-heavy,C-optimization

The derived Clone implementations in Firefox weigh 192k [1], which is a lot.

Of that 192k, 79k of that is just for PropertyDeclaration::clone. PropertyDeclaration is a very large enum, but most of the variants are simple POD types. Ideally Rust would coalesce those together, and then generate special cases for the types that need it. Unfortunately, it appears that adding a single non-POD variant causes all the cases to be enumerated separately, as seen in the testcase at [2].

From IRC:

> eddyb	bholley: yeah I think this is a valid issue
> eddyb:	if you do generate that sort of "(partial) identity match" it's unlikely to have anything else collapse it
> eddyb:	LLVM might have a pass for switch-discriminant-dependent-values
> eddyb:	but it probably has serious limitations in practice
> eddyb:	bholley: but yeah this is one of those cases where not scattering in the first place is significantly easier than gathering later`

Ideally we'd do the same for PartialEq, since PropertyDeclaration::eq weighs another 61k.

[1] nm --print-size --size-sort --radix=d libxul.so | grep "\.\.Clone" | grep -v Cloned | cut -d " " -f 2 | awk '{s+=$1} END {print s}'
[2] https://play.rust-lang.org/?gist=0207af76d2e05acdbed913b7df96aa77&version=stable
Repository: godot
Issue: [Bullet] Fast RigidBody always go through walls and Godot Crash because of Collision
Labels: bug,confirmed,topic:physics,topic:3d

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

**Godot version:**
Godot 3 RC3


**Issue description:**
Fast moving Rigidbody3D always go through walls 
the collision is not always detected .. even if i make the wall thick and add more invisible walls to it .. still go through them

problem number 2 is : when i added a collision to Rigidbody .. everything works fine
select player mesh and : Create Convex collision sibling .. works fine

but when i close the project and i open it again Godot Crash or Close it self

and the way to reopen the project is to open the scene that contain that Collision in a Text editor and remove the line of Collision from there
and in this case , this is the line you must remove from "Level.tscn" to open the project

`[node name="PlayerCollisionShape" type="CollisionShape" parent="Player" index="1"]`

**Steps to reproduce:**
use : apply_impulse with higher value inside rigid body 
if you set a lower value it will collide well but not for higher value

and this is the project .. if it didn't open for you .. remove the line from Level.tscn in Text editor

**Minimal reproduction project:**
[FastRigidBody.zip](https://github.com/godotengine/godot/files/1670027/FastRigidBody.zip)
Repository: rust
Issue: Rust make system should respect -j1
Labels: T-bootstrap,C-bug

The build system seems not to respect -j1 for make (origin report is https://bugs.gentoo.org/613794) : 
 
```
# /usr/bin/pstree -Ulnspua 1038
init,1         
  └─sudo,1026 /opt/tb/bin/chr.sh /home/tinderbox/run/17.0-no-multilib_libressl_20180124-193635 /bin/bash /tmp/job.sh
      └─chr.sh,1038 /opt/tb/bin/chr.sh /home/tinderbox/run/17.0-no-multilib_libressl_20180124-193635 /bin/bash /tmp/job.sh
          └─su,1113 - root -c /bin/bash /tmp/job.sh
              └─bash,1125 /tmp/job.sh
                  └─emerge,10956 -b /usr/lib/python-exec/python3.5/emerge --update dev-lang/rust
                      └─sandbox,7479,portage /usr/lib/portage/python3.5/ebuild.sh compile
                          └─ebuild.sh,7621 /usr/lib/portage/python3.5/ebuild.sh compile
                              └─ebuild.sh,7820 /usr/lib/portage/python3.5/ebuild.sh compile
                                  └─python2.7,7838 ./x.py build --verbose --config=/var/tmp/portage/dev-lang/rust-1.23.0-r1/work/rustc-1.23.0-src/config.toml
                                      └─python2.7,7485 ./x.py build --verbose --config=/var/tmp/portage/dev-lang/rust-1.23.0-r1/work/rustc-1.23.0-src/config.toml
                                          └─bootstrap,7486 build --verbose --config=/var/tmp/portage/dev-lang/rust-1.23.0-r1/work/rustc-1.23.0-src/config.toml
                                              └─cmake,23604 --build . --target install --config Release -- -j 12
                                                  └─gmake,23616 -j 12 install
                                                      └─gmake,23742 -f CMakeFiles/Makefile2 all
```

Is there anything which can be improved in the Gentoo package definition or is this a rust issue ?
Repository: rust
Issue: Allow using Fn(A, B, C) -> _ for unconstrained FnOnce::Output.
Labels: T-lang,C-feature-request

`F: Fn(A, B, C) -> R` desugars to `F: Fn<(A, B, C), Output = R>` currently.
`F: Fn(A, B, C) -> _` could easily desugar to `F: Fn<(A, B, C)>`.
More generally, we can allow `T: Trait<AssocTy = _>`, meaning the same as `T: Trait`.

This form would make it easier to be generic over the return type without having to specify it as another generic parameter (which is worse in type definitions than `impl`s, as it leaks to users).

cc @eternaleye (who suggested it) @nikomatsakis @withoutboats @Centril
Repository: rust
Issue:  unsupported cyclic reference between types/traits error only when implicitly using associated type
Labels: A-associated-items,T-compiler,C-bug

Getting `error[E0391]: unsupported cyclic reference between types/traits detected` only when using `T::A` to refer to an assocaited type but it works when using `<T as Test>::A` which seems inconsistent.

```rust
struct Struct<T>(T);
trait Test {
    type A;
    type B;
}

// Compiles
fn test<T>() where T: Test<A = i32, B = Struct<<T as Test>::A>> {
    
}

// error[E0391]: unsupported cyclic reference between types/traits detected
fn test2<T>() where T: Test<A = i32, B = Struct<T::A>> {
    
}

fn main() {
    
}
```
https://play.rust-lang.org/?gist=c2f9100b205db71e6c444501a021e8ac&version=stable
Repository: puppeteer
Issue: Behavior of setViewport() inconsistent in Headful
Labels: bug,upstream,chromium,confirmed,P3

**Environment:**

* Puppeteer: 1.0.0
* Platform / OS: Ubuntu 16.04 LTS (1920x1080@1x)
* Node.js: 8.9.3
* Chromium: 65.0.3312.0 (Developer Build) (64-bit)

**What steps will reproduce the problem?**

Running the following code several times.

```javascript
const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    args: [
      '--start-maximized',
    ],
    headless: false,
  });

  const page = await browser.newPage();

  /**
   * This should make Chromium infer current screen resolution (only in headless = false).
   */
  await page.setViewport({
    width: 0,
    height: 0,
  });

  await page.goto('http://matanich.com/test/viewport-width', {
    waitUntil: [
      'domcontentloaded',
      'load',
    ],
  });

  let result = await page.evaluate(
    () => {
      return window.innerWidth;
    }
  );

  console.log(`Detected window.innerWidth to be ${result}.`);

  await browser.close();
})();
```

**What is the expected result?**

I should get the save `window.innerWidth` all the time.

**What happens instead?**

Seems that _sometimes_ `setViewport()` fails silently and fallbacks to the [default viewport size](https://github.com/GoogleChrome/puppeteer/blob/cb684ebbc4de271c7f2187f4e52c0b3a83cc0122/lib/Page.js#L58) of 800x600.

```
$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 800.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 1855.

$ node setViewportTest.js
Detected window.innerWidth to be 800.
```
Repository: opencv
Issue: Since GPU modules are not yet supported by OpenCV-Python?
Labels: feature,priority: low,category: gpu/cuda (contrib)

Since GPU modules are not yet supported by OpenCV-Python?

Is there any plan to support gpu?
Repository: vscode
Issue: [folding] Allow folding block comment that starts in the middle of the line
Labels: feature-request,editor-folding

An additional request on top of now-closed feature-request [11524](https://github.com/Microsoft/vscode/issues/11524). 

I sometimes like to write my block comments in this form: 
```
let someflag : boolean = false;/*
    this flag does blah blah
    blah blah blah blah*/
let somethingelse : string;
```

So that folding that comment completely removes it from view outside of that trailing start marker. However, the implementation to feature-request 11524 does not detect this type of block comment and only seems to pick up on block comments started on their own new line. I am not sure how popular that style of commenting is, but it would help me a lot of it could be picked up by that feature. 

Thanks.
Repository: bitcoin
Issue: Timeout downloading block
Labels: P2P

When investigating my mempool statistics there are from time to time >15 minutes intervals without blocks followed immediately by two or three fast blocks and it happened too often to be just due to the high variance of exponential distributiion.

Looking into the logs revealed the culprit:

```
grep Timeout -A1 debug.log | tail
2018-01-29 08:45:20 Timeout downloading block 00000000000000000031a8bf543031f89b7a2a445d5b872883b2b5375c251571 from peer=47947, disconnecting
2018-01-29 08:45:22 UpdateTip: new best=00000000000000000031a8bf543031f89b7a2a445d5b872883b2b5375c251571 height=506627 version=0x20000000 log2_work=87.990329 tx=296113862 date='2018-01-29 08:34:56' progress=0.999993 cache=85.3MiB(564264txo)
--
2018-01-29 09:41:12 Timeout downloading block 000000000000000000254d01e7f0d550506ae1d23be0d255e9e650ecbe887e6a from peer=51377, disconnecting
2018-01-29 09:41:13 UpdateTip: new best=000000000000000000254d01e7f0d550506ae1d23be0d255e9e650ecbe887e6a height=506635 version=0x20000000 log2_work=87.990749 tx=296124995 date='2018-01-29 09:31:05' progress=0.999994 cache=88.7MiB(591588txo)
--
2018-01-29 11:33:16 Timeout downloading block 00000000000000000064da61afd140ad94b973d5d355e653111c04edba9ea625 from peer=51664, disconnecting
2018-01-29 11:33:17 UpdateTip: new best=00000000000000000064da61afd140ad94b973d5d355e653111c04edba9ea625 height=506642 version=0x20000000 log2_work=87.991116 tx=296138316 date='2018-01-29 11:22:36' progress=0.999993 cache=94.6MiB(639913txo)
```

The peer seems to be always the same (IP addresses aren't logged):

```
2018-01-29 09:42:12 receive version message: /ViaBTC:bitpeer.0.2.0/: version 70015, blocks=0, us=0.0.0.0:0, peer=51664
```

### What behavior did you expect?

First, I'd expect a shorter timeout (it seems to be 10 minutes).  While a 10 minutes timeout is not that critical for my node, it means that you shouldn't use an unmodified bitcoin core for solo mining or you risk high orphan rate.

Also why is the node not banned?  It is disconnected but it is allowed to immediately reconnect.  Wouldn't it be possible to exploit this behaviour to make the blocks of competitors relay slowly, by just sending the inv message for them but never delivering the content.

This is with bitcoin v0.15.1
Repository: rust
Issue: Wrong error: cannot move out of captured outer variable in an `FnMut` closure
Labels: C-enhancement,A-diagnostics,A-closures,A-borrow-checker,T-compiler,D-terse

> error: cannot move out of captured outer variable in an `FnMut` closure

```rust
struct Foo {
    a: i32,
    b: i32,
    bar: Bar,
}

struct Bar;

impl Bar {
    fn f<F: FnMut()>(&self, mut f: F) {
        f();
    }
}

fn main() {
    let mut foo = Foo { a: 1, b: 2, bar: Bar };
    let a = &mut foo.a;
    let b = &mut foo.b;
    (|| { // works
        *if true {a} else {b} = 42;
    })();
    
    let mut foo = Foo { a: 1, b: 2, bar: Bar };
    let a = &mut foo.a;
    let b = &mut foo.b;
    foo.bar.f(|| { // doesn't work
        *if true {a} else {b} = 42;
    });
}
```
https://play.rust-lang.org/?gist=4ce6948a92c2fcb281b3cade8574691d&version=nightly

But the second case should work too!
Repository: pytorch
Issue: Rebuild from no-CUDA to CUDA leads to: error: #error "Expected GLOO_USE_CUDA to be defined"
Labels: module: build,low priority,triaged,has workaround

Hello I'm trying to build from source for multinorminal distribution, but I can't get it built.
In contrary, if built with NO_DISTRIBUTED=1 the build passes but of course things like pooling won't work, which is something I need.

- OS: Ubuntu 16.04
- PyTorch version: From master branch
- How you installed PyTorch (conda, pip, source): source 
- CUDA/cuDNN version: 9.1
- GCC version (if compiling from source): 5.4
- Error messages and/or stack traces of the bug
> .../pytorch/torch/lib/gloo/gloo/cuda.h:25:2: error: #error "Expected GLOO_USE_CUDA to be defined"
>  #error "Expected GLOO_USE_CUDA to be defined"
> CMake Error at gloo_cuda_generated_cuda_private.cu.o.cmake:203 (message):
>   Error generating
>   .../pytorch/torch/lib/build/gloo/gloo/CMakeFiles/gloo_cuda.dir//./gloo_cuda_generated_cuda_private.cu.o
> 
> 
But make itself seems to be aware of CUDA 9.1

> Install the project...
> -- Install configuration: "Release"
> -- Installing: .../pytorch/torch/lib/tmp_install/lib/libshm.so
> -- Set runtime path of ".../pytorch/torch/lib/tmp_install/lib/libshm.so" to ""
> -- Up-to-date: .../pytorch/torch/lib/tmp_install/include/libshm.h
> -- Installing: ...pytorch/torch/lib/tmp_install/bin/torch_shm_manager
> -- CUDA detected: 9.1
> -- Added CUDA NVCC flags for: sm_30 sm_35 sm_50 sm_52 sm_60 sm_61 sm_70
> -- Found libcuda: /usr/lib/x86_64-linux-gnu/libcuda.so
> -- Found libnvrtc: /usr/local/cuda/lib64/libnvrtc.so
> -- Configuring done
> -- Generating done
> -- Build files have been written to: .../pytorch/torch/lib/build/gloo
>
Repository: go
Issue: x/playground: feature request: prepopulate file system with contents of $GOROOT/src
Labels: NeedsInvestigation

Adding the $GOROOT contents to the playground file system would make it possible to use more of the `go/*` packages in the playground more easily.

This would be helpful for both reporting bugs in the `go/*` packages and for sharing demonstrations of how to use the `go/*` packages.