sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: const fn type is missing `const` in error message
Labels: C-enhancement,A-diagnostics,P-low,T-compiler,A-const-eval

```rust
const fn foo() {}

fn main() {
    let _: () = foo;
}
// error[E0308]: mismatched types
// = note: expected type `()`
//             found type `fn() {foo}`
```
I'd expect the found type to be `const fn() {foo}`.
Repository: go
Issue: proposal: runtime: add way for applications to respond to GC backpressure
Labels: Proposal,Proposal-Hold

This is marked as a proposal, but I'd like it to start out as a discussion. Although I believe the need is clear, the correct design is not at all obvious.

Many applications have caches that they could easily drop in response to GC backpressure. However, there is currently no good way to do this.

One obvious example is sync.Pool. If we also had [per-P storage](https://github.com/golang/go/issues/18802), we could rebuild sync.Pool outside the standard library using GC backpressure. Better, folks could [customize the sync.Pool emptying strategy](https://github.com/golang/go/issues/22950) in response to their own needs.

Another example is [interning strings](https://github.com/golang/go/issues/5160).

As to design, there are a few aspects. What does the API look like? When and how does the runtime trigger it? And what system dynamics might result.

One API ideas:

```go
package runtime

// The API below needs better names. And the docs are a mix of user-facing and internal details.

// GCBackpressureC returns a channel that the runtime will close to indicate GC backpressure.
// One the channel has been closed, another call to GCBackpressureC will return a new channel.
// There is only a single, shared channel across all calls to GCBackpressureC.
// This makes the runtime side cheap: a single, lazily allocated channel, and a single close call per round of backpressure.
// The downside is that it could cause a stampede of memory releases.
// Another downside is that there could be logical races in which clients miss backpressure notifications by not obtaining a new channel quickly enough.
func GCBackpressureC() <-chan struct{}

// GCBackpressureC returns a channel that the runtime will send values on to indicate GC backpressure.
// The values have no meaning here, but maybe there's something useful we could send?
// The runtime side here is more expensive. It has O(n) channels to keep track of, and does O(n) work to send signals to everyone.
// On the other hand, by not sending signals to everyone simultaneously it can help avoid stampedes.
func GCBackpressureC() <-chan struct{}
```

As to when the runtime should indicate backpressure, there are several options. It could do it once per GC cycle, as a matter of course. (This matches existing sync.Pool behavior.) It could do it in response to heap growth. Or maybe something else or some combination.

It's unclear what effect this might have on system dynamics. To avoid messy situations like #22950, someone should probably do some hysteresis and/or incremental work. It is unclear whether that should reside in the runtime or in user code.

cc @aclements @rsc @dvyukov @dsnet @cespare
Repository: go
Issue: cmd/go: set .cache/go-build files as read-only
Labels: NeedsDecision,GoCommand

My understanding is that files in .cache/go-build are immutable and strongly named. If so, it might be worth setting them as read-only to help prevent cache corruption.

For example, [as I mentioned on #24661](https://github.com/golang/go/issues/24661#issuecomment-453364210), transitioning mdempsky/unconvert from go/loader to go/packages caused the go/token.File.Name() for cgo-processed files to start pointing into the go-build cache, whereas previously go/loader arranged for them to point to the original unprocessed files. The result was that the `-apply` flag silently started overwriting (and presumably corrupting) go-build cache entries.

Since I sloppily wrote unconvert to overwrite files in place, if the cache entries weren't writable, I believe it would have stopped this corruption. (Admittedly though I don't think this would help if I had properly implemented the write-to-temp-file-then-atomically-rename approach.)

For what it's worth, Git sets files in its .git/objects as read-only.

/cc @rsc
Repository: godot
Issue: Node2D's position property is zero inside _ready function when created in the editor with drag-and-drop
Labels: topic:core,topic:editor,usability

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
Godot 3.1 beta 1


**OS/device including version:**
macOS 10.14.2
Intel Core i7
Intel HD Graphics 4000

**Issue description:**
[I described this in Godot Q&A.](https://godotengine.org/qa/38983/node2ds-position-when-initialized-the-editor-with-drag-drop?state=comment-39007&show=39007#c39007)

I have a node that extends Node2D. I wish to access its position when it's initialized in the editor:

	tool
	extends Node2D
	
	func _ready() -> void:
		if Engine.editor_hint:
			print("Position of ", name, " is ", position)

However, when I drag the node's scene file from the FileSystem window to the main scene editor, the position is printed as (0, 0). Specifically the position is printed twice; first when I start dragging the node's scene file, second when I drop the node onto the scene editor; both times as zero.

![custom_node_position](https://user-images.githubusercontent.com/33398493/51062276-ca1e3600-15cc-11e9-9dbd-d16ca0c0031a.png)

If I save the main scene after adding the node then reopen it, the node's correct position is printed (and the position is only printed once). It's when the node is first created with drag-and-drop that the position is printed as zero.

I am able to get around this by using `call_deferred` in my node's `_ready` function to call a method that accesses the position.

	tool
	extends Node2D
	
	func _ready() -> void:
		if Engine.editor_hint:
			call_deferred("_print_position")
	
	func _print_position():
		print("Position of ", name, " is ", position)

This time when creating the node in a main scene with drag-and-drop, zero is printed when first dragging while the correct position is printed when the node is dropped.

![custom_node_position2](https://user-images.githubusercontent.com/33398493/51062544-a1e30700-15cd-11e9-90da-f985fba1cdcc.png)

**Minimal reproduction project:**
<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
[PositionTest.zip](https://github.com/godotengine/godot/files/2751330/PositionTest.zip)

**main.tscn** is the main scene. **CustomNode.tscn** is the node that is drag-and-dropped onto the main scene.
Repository: rust
Issue: missing_docs false positive on re-export in module with #![allow(missing_docs)]
Labels: T-rustdoc,A-lints,C-bug

This one might be a bit complex to solve. This affects both 2015 and 2018 editions on stable/nightly.

When a `pub` item from a private module in a crate with `#![deny(missing_docs)]` is reexported in a pub module marked `#![allow(missing_docs)]`, the lint still fires.

[2015 (Playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=6b36194a9ba7bde365f4367f1c5a100e) (2018 just needs the `crate::` prefix on the `use` path)
```rust
//! docs for crate
#![deny(missing_docs)]

#[allow(missing_docs)]
pub mod undoc {
    #[allow(missing_docs)] // no effect
    pub use nonpub::Foo;
}

mod nonpub {
    pub struct Foo;
    
    impl Foo {
        pub fn bar() {}
    }
}
```

Both report the same error. The lint marks the original definition point of the item; if it has associated items, those are hit too:
```
error: missing documentation for a struct
  --> src/lib.rs:11:5
   |
11 |     pub struct Foo;
   |     ^^^^^^^^^^^^^^^
   |
note: lint level defined here
  --> src/lib.rs:2:9
   |
2  | #![deny(missing_docs)]
   |         ^^^^^^^^^^^^

error: missing documentation for a method
  --> src/lib.rs:14:9
   |
14 |         pub fn bar() {}
   |         ^^^^^^^^^^^^

error: aborting due to 2 previous errors
```

Interestingly, marking the item's *source* module with `#[allow(missing_docs)]` silences the error: [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=5004f6179265975b7546297d0a3846a2)
```rust
//! docs for crate
#![deny(missing_docs)]

#[allow(missing_docs)]
pub mod undoc {
    pub use nonpub::Foo;
}

#[allow(missing_docs)]
mod nonpub {
    pub struct Foo;
    
    impl Foo {
        pub fn bar() {}
    }
}
```
Repository: flutter
Issue: Cursor scroll in text fields too insensitive in Flutter
Labels: a: text input,c: new feature,platform-android,platform-ios,framework,f: material design,f: cupertino,a: quality,f: gestures,c: proposal,P3,team-design,triaged-design

On Android and on iOS, in both collapsed and expanded selection modes, the single line horizontal scroll is more 'pre-emptive' than our current implementation.

Whereas we try to select the text position based on the drag gesture and bring it into view if it were not, the native texts start scrolling before the drag position is outside the text field. 

This is more aggressive on iOS.
Repository: rust
Issue: Float `signum` returns +/-1 for zeros, mismatching integers (and convention)
Labels: T-libs-api,A-floating-point

The sign/signum function is almost always defined to have signum(x) = 0 if x = 0, e.g. 

- mathematical convention: https://en.wikipedia.org/wiki/Sign_function,
- Java (`java.lang.Math.signum`): https://docs.oracle.com/javase/10/docs/api/java/lang/Math.html#signum(double), 
- numpy (`numpy.sign`): https://docs.scipy.org/doc/numpy/reference/generated/numpy.sign.html,
- Rust integers: `0i32.signum() == 0`.

Currently, `f32::signum` and `f64::signum` do not satisfy this:

https://github.com/rust-lang/rust/blob/79d8a0fcefa5134db2a94739b1d18daa01fc6e9f/src/libstd/f32.rs#L1219-L1220

https://github.com/rust-lang/rust/blob/79d8a0fcefa5134db2a94739b1d18daa01fc6e9f/src/libstd/f64.rs#L1167-L1168

The sign of the signed zeroes can still be reflected when returning zero: `(-0.0).signum()` could return `-0.0` like the Java APIs.
Repository: flutter
Issue: Copy large file from Assets Folder to Application Documents Folder
Labels: c: new feature,framework,a: assets,P2,team-framework,triaged-framework

## Steps to Reproduce

Hi,
  I try to use a large db-file. And therefore, my code copies this file from the Assets folder to the Application-Documents-Folder as can be seen in the code-example below.

For small files, my code works perfectly fine and I can work with my DB perfectly fine.

However, if I try it with a large db-File (>665MB), things start to break as for my Android-part of my Flutter app. (in fact, iOS works perfectly fine, no matter how large the db-File really is....). Only for Android, a large db-File breaks things.

The following Dart code does not work for a large File (>665MB) - (however it works for small files):

```dart
  Future<Database> initializeDatabase() async {

    Directory directory = await getApplicationDocumentsDirectory();
    var dbPath = join(directory.path, "ch_departures.db");

    // copy db file from Assets folder to Documents folder (only if not already there...)    
    if (FileSystemEntity.typeSync(dbPath) == FileSystemEntityType.notFound) {
     ByteData data = await rootBundle.load("assets/ch_departures.db");
     writeToFile(data, dbPath);
    }

    // Open/create the database at a given path
    var departuresDatabase = await openDatabase(dbPath);
    return departuresDatabase;
  }

  // HERE IS WHERE THE CODE CRASHES (WHEN TRYING TO WRITE THE LOADED BYTES)
  void writeToFile(ByteData data, String path) {
    final buffer = data.buffer;
    return new File(path).writeAsBytesSync(
      buffer.asUint8List(data.offsetInBytes, data.lengthInBytes));
  }
```

I tried to play around with the `gradle.properties` File of the Android part of my Flutter App.

Inside gradle.properties, I tried:

`org.gradle.jvmargs=-Xmx3g -XX:MaxPermSize=2048m`

But unfortunately, no success.

Do you have any idea on how to make all this work with a large (>665MB) File ????
Repository: flutter
Issue: BorderRadiusDirectional not supported in BorderRadiusTween
Labels: framework,a: animation,f: material design,customer: money (g3),has reproducible steps,P2,found in release: 3.5,team-design,triaged-design
Repository: scrcpy
Issue: Incorrect color representation of Samsung J7 2017
Labels: display

Happens both over WiFi and USB.

Running commands from [#177](https://github.com/Genymobile/scrcpy/issues/177#issuecomment-397973971):

```bash
adb shell screenrecord /sdcard/test.mp4
adb pull /sdcard/test.mp4
```

results in correct video.

Broken commands:

```bash
scrcpy -b10K -m360
scrcpy -b2M -m600
scrcpy
adb shell screenrecord --output-format=h264 - | ffplay -
```

The video is ultra-smooth, but it looks as if everything below some level of luminosity is interpreted as gray:

Here is screenshot of Samsung Settings:
![screenshot_20190112-191611](https://user-images.githubusercontent.com/8074163/51076874-b8a55e80-169e-11e9-8e71-aa7a7de3e6c1.png)

Here is screenshot of scrcpy:
![screenshot from 2019-01-12 18-57-21](https://user-images.githubusercontent.com/8074163/51076882-d246a600-169e-11e9-82b1-00cb3283c3cf.png)

Android 7.0 (stock, but installed custom kernel)
Samsung Experience 8.1
Kernel 3.18.14-Refined_Kernel-v2.8-Stable-J730F-G (custom kernel)
Model SM-J730F
Repository: go
Issue: x/image/bmp: support 1-bit format
Labels: NeedsDecision,FeatureRequest

Hi, I implemented support for 1-bit bmp files in the reader:

https://github.com/cbrake/golang.org-x-image/commit/25481fe1980277e4b3206c11a3fc15e2ec31eddc

Is there interest merging this (or an improved version)?
Repository: pytorch
Issue: More data type support for gather_map
Labels: module: nn,triaged,enhancement

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
So far we only support Tensor and Dict in gather_map(). Can we also support Number and List like what we do in collate()
## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->
It is possilbe to have a dictionary or list of Number and Tensor when gather the output of model.
## Pitch

<!-- A clear and concise description of what you want to happen. -->

```ruby
  def gather_map(outputs):
        out = outputs[0]
        if isinstance(out, Number):
            return torch.tensor(outputs)
        if isinstance(out, torch.Tensor):
            return Gather.apply(target_device, dim, *outputs)
        if out is None:
            return None
        if isinstance(out, list):
            return type(out)(((k, gather_map([d[k] for d in outputs]))
                              for k in out))
        if isinstance(out, dict):
            if not all((len(out) == len(d) for d in outputs)):
                raise ValueError('All dicts must have the same number of keys')
            return type(out)(((k, gather_map([d[k] for d in outputs]))
                              for k in out))
        return type(out)(map(gather_map, zip(*outputs)))
```
Repository: go
Issue: path/filepath: TestBug3486 fails if GOROOT/test is removed
Labels: Testing,NeedsDecision

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.4 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes, 1.11.4 is the latest (not counting betas?).

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ionasal/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ionasal/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build457575040=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

```
mkdir -p /tmp/tmp3
cd /tmp/tmp3
go mod init example.com/test
cat >main.go <<EOF
package foo

import (
	_ "path/filepath"
)
EOF
go test all
```

### What did you expect to see?

All tests pass

### What did you see instead?

Test failures:

```
--- FAIL: TestBug3486 (0.00s)
    path_test.go:1268: lstat /usr/lib/go/test: no such file or directory
FAIL
FAIL	path/filepath	0.013s
```

(I found a bug for the same test, but the failure mode is different: https://github.com/golang/go/issues/5863)
Repository: flutter
Issue: [google_maps_flutter] Support for Ground Overlay
Labels: c: new feature,customer: crowd,p: maps,package,c: proposal,team-ecosystem,P2,has partial patch,triaged-ecosystem

<!-- Thank you for using Flutter!

     Please check out our documentation first:
      * https://flutter.io/
      * https://docs.flutter.io/

     If you can't find the answer there, please consider asking a question on
     the Stack Overflow Web site:
      * https://stackoverflow.com/questions/tagged/flutter?sort=frequent

     Please don't file a GitHub issue for support requests. GitHub issues are
     for tracking defects in the product. If you file a bug asking for help, we
     will consider this a request for a documentation update.

-->

Hi, I'm developing an app where the main functionality is a Map with a Custom Ground Overlay. I've achieve that with the Ionic Framework but I want to make a Flutter version and I notice that the Ground Overlay Class or functionality is not present in the library at the moment. 

This is what I need:

Android:
https://developers.google.com/maps/documentation/android-sdk/groundoverlay

iOS:
https://developers.google.com/maps/documentation/ios-sdk/overlays

This is a main functionality for my app, so I need this to launch a production Flutter version of my app. Please, take a look at it.

Thanks!
Repository: rust
Issue: Meta tracking issue for `const fn`
Labels: A-attributes,A-diagnostics,metabug,A-stability,T-lang,T-compiler,A-const-eval

This issue tracks the progress of `const fn` as well as const evaluation more broadly.

###  This issue is not for discussion about specific extensions to `const fn` or const evaluation and only exists to provide links to other places that track the progress of specific issues. If you wish to discuss some subject related to const evaluation or `const fn`, please find an existing appropriate issue below or create an new issue and comment here with a link to the newly created issue.

If it's impossible to detect what issue the programmer should be pointed to, they can simply be pointed to this issue.

--------------------

The `const` related issues currently on deck are as follows:

* [x] Control flow: #49146 (1.46)
* [x] Loops: #52000 (1.46)
* [x] Integer arithmetic: #53718
* [ ] Integration with patterns: #57240
* [ ] Floating point arithmetic: #57241
* [x] Panics: #51999 (`#![feature(const_err)]`)
* [ ] Comparing raw pointers: #53020
* [x] Dereferencing raw pointers: #51911
* [x] Raw pointer to `usize` casts: #51910(`#![feature(const_raw_ptr_to_usize_cast)]`)
* [x] Union field accesses: #51909
* [ ] `&mut T` references and borrows: #57349 (`#![feature(const_mut_refs)]`)
* [ ] FromStr: #59133
* [x] `transmute`: #53605
* [ ] Function pointers (`const fn(...)` / `fn(...)`): #63997
* [ ] `const unsafe? extern fn`: #64926
* [x] unsizing casts: #64992
* [ ] platform intrinsics: #66061
* [ ] async blocks in `const fn`s: #85368
* [ ] `mem::discriminant`: #69821(`#![feature(const_discriminant)]`)
* [x] ptr offset methods #71499
* [x] Warnings on long running evaluations: #49980
* [x] Constant propagation not causing errors: #28238
* [ ] `const_maybe_uninit_assume_init` #86722

-----------------

Open RFCs:
* [Calling methods on generic parameters of const fns](https://github.com/rust-lang/rfcs/pull/2632)
  * [ ] `?const` trait bound opt-out: #67794(`#![feature(const_trait_bound_opt_out)]`)
  * [ ] impl const Trait for Ty: #67792(`#![feature(const_trait_impl)]`)

Planned RFCs:
* [Heap allocation in `const fn`](https://github.com/rust-lang/const-eval/issues/20) (this includes everything related to `Box`)

----------------------------

Completed:

- const constructors: #61456
- locals, assignments, and destructuring: #48821
- `unsafe` operations: #55607
Repository: go
Issue: cmd/compile: optimize CAS loops
Labels: Performance,NeedsInvestigation,compiler/runtime

Note: I'm not 100% sure the transformation I'm proposing is correct, or profitable. If it's not feel free to close.

Consider the typical Go CAS loop:

```
    for {
        oldA := atomic.LoadUint64(&A)
        newA := f(oldA)
        if atomic.CompareAndSwapUint64(&A, oldA, newA) {
            return
        }
    }
```

On x64, this gets compiled to: (https://godbolt.org/z/7905Kp)

```
main_pc29:
        movq    "".A(SB), AX
		// (compute newA, store it in CX...) 
        leaq    "".A(SB), DX
        lock
        cmpxchgq        CX, (DX)
        seteq   AL
        testb   AL, AL
        jeq     main_pc29
        // (return...)
```

There are 3 things that jump out:
- `cmpxchgq`, if `A != oldA`, already reloads the updated value of `A` in `AX`, so the first instruction of the loop (reloading `A`) can be skipped from the second iteration onwards
- the `seteq` and `testb` after `cmqxchgq` are not required (they, and the `jeq` can be replaced with a `jnz main_pc29`)
- the address of `A` is reloaded at every iteration: it should be hoisted outside of the loop (note that in the link above `f()` is marked noinline, so it makes sense to reload the address of `A` once `f` returns; but even if you remove the noinline the address is still reloaded even though the register is not reused for other purposes) (#15808?)

Rewritten, the loop could become:

```
        movq    "".A(SB), AX   // atomic.LoadUint64(&A)
        leaq    "".A(SB), DX   // DX = &A
main_pc29:
		// (compute newA, store it in CX...) 
        lock
        cmpxchgq        CX, (DX)
        jnz     main_pc29
        // (return...)
```

Since modifying `atomic.CompareAndSwap*` to return the reloaded value instead of a `bool` is likely not an option, it would be great if the compiler learned to do this kind of transformation (when safe).
Repository: rust
Issue: Tracking issue for future-incompatibility lint `ill_formed_attribute_input`
Labels: A-attributes,A-lints,T-lang,T-compiler,C-future-incompatibility,C-tracking-issue

#### What is this lint about

Previously inputs for many built-in attributes weren't validated and nonsensical attributes like `#[no_std(arbitraty, string = "foo")]` were accepted.
https://github.com/rust-lang/rust/pull/57321 introduced a check for top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) for built-in attributes that produces an error by default, but produces a warning for incorrect attribute forms available on stable that were actually encountered in practice (during crater run).
Currently the list is
```rust
#[doc]
#[ignore(...)]
#[inline = "..."]
#[link]
#[link = "..."]
```
, but it can be extended if more regressions are reported.

#### How to fix this warning/error

Use one of the correct attribute forms suggested by the compiler.

#### Current status
- [x] https://github.com/rust-lang/rust/pull/57321 introduces the `ill_formed_attribute_input` lint as warn-by-default
- [x] https://github.com/rust-lang/rust/pull/65785 makes the `ill_formed_attribute_input` lint deny-by-default
- [ ] PR ? makes the `ill_formed_attribute_input` lint a hard error