sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: No unused import for std::f64 if only f64 types used
Labels: A-lints,A-resolve,T-compiler,C-bug

I recently came across several instances of the following problem in a code base:

```rust
use std::f64; // No warning.

fn main() {
    let x: f64 = 0.0;
    println!("{}", x);
}
```

Why this didn't cause a warning baffled me for a while, until I realize that it was actually imported the *type* `f64`, even though I had been using it up until that point as a module like:

```rust
use std::f64;

fn main() {
    println!("{}", f64::consts::PI);
}
```

Then later, when I refactored the code (more complex than this toy example), something like this was left:

```rust
use std::f64; // No warning for "unused" import, but it is not necessary.
use std::f64::consts::PI;

fn main() {
    let x: f64 = 0.0;
    println!("{}", PI + x);
}
```

In this final case, it would be great if `rustc` warned about this since `f64` is always implicitly in scope as a primitive type (I didn't think you could actually import it?).

Is this a case where the unused import lint got confused incorrectly?
Repository: rust
Issue: To debug cargo project cause lots of 'symbol not found' problems on OSX
Labels: A-linkage,O-macos,T-compiler,C-bug

My workspace is on OSX. If I `touch hello.rs`, `rustc -g hello.rs` and then `gdb -q hello` of a single .rs file, there won't be any problem and it will load symbols successfully. However, when I use `cargo new hello --bin`, `cd hello`, then `cargo build` and then `gdb -q target/debug/hello`, it will be a blast on my iterm full of messages as follows:

```
>gdb -q target/debug/hello                                                                           
Reading symbols from target/debug/hello...
warning: `/Users/zhengxiaolin/Documents/eclipse/hello/target/debug/deps/hello-aa762faea86652ac.0.o': can't open to read symbols: No such file or directory.

warning: can't find symbol '_ZN104_$LT$$RF$$u27$b$u20$collections..string..String$u20$as$u20$core..str..pattern..Pattern$LT$$u27$a$GT$$GT$13into_searcher17h12b3d7238e011a15E' in minsymtab

warning: can't find symbol '_ZN116_$LT$collections..borrow..Cow$LT$$u27$a$C$$u20$str$GT$$u20$as$u20$core..ops..AddAssign$LT$$RF$$u27$a$u20$str$GT$$GT$10add_assign17hdd8b6423379d7623E' in minsymtab

warning: can't find symbol '_ZN11collections3fmt6format17h622e78b799d1c558E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$10trim_right17ha60cffd510213a23E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$11into_string17h77e8e55aae74110bE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$12encode_utf1617h4b31c1b570b71bf6E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$12escape_debug17h6eadad2fa42faab1E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$12to_lowercase17hdfeeabf72d2d11edE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$12to_uppercase17hf48dd8c27a89e68dE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$14escape_default17h52d3319153d73dafE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$14escape_unicode17h116b615659071afdE' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$4trim17hbce03c1a35407699E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$6repeat17h6fe0557d17b09553E' in minsymtab

warning: can't find symbol '_ZN11collections3str21_$LT$impl$u20$str$GT$9trim_left17h015cef6fe5ab820fE' in minsymtab

warning: can't find symbol '_ZN11collections5btree3map16unwrap_unchecked28_$u7b$$u7b$closure$u7d$$u7d$14_MSG_FILE_LINE17he2a66a8a2be2ef68E' in minsymtab

warning: can't find symbol '_ZN11collections5slice10merge_sort14_MSG_FILE_LINE17h71c2ec20d499b44fE' in minsymtab
```

and so on.. My paste is only a small part. The no-symbol message has a lot..
Hope to solve the problem~ :)
Repository: rust
Issue: Weird error message for missing symbol if module name is the same as a macro
Labels: C-enhancement,A-diagnostics,A-resolve,A-macros,T-compiler

```
mod format {
    mod sub {
        pub fn foobar() { }
    }
}

fn main() {
    format::foobar();
}
```

```
$ rustc a.rs
error[E0423]: expected function, found macro `format::foobar`
 --> a.rs:8:5
  |
8 |     format::foobar();
  |     ^^^^^^^^^^^^^^ did you mean `format::foobar!(...)`?
  |
  = help: possible better candidate is found in another module, you can import it into scope:
            `use format::sub::foobar;`

error: aborting due to previous error
```

```
$ rustc --version
rustc 1.17.0-nightly (134c4a0f0 2017-03-20)
```

The weird thing is "expected function, found macro". `format::foobar` doesn't look like a macro. This also happens without the submodule `sub` (i.e. with an empty module `format`), the only difference is that no other candidate is suggested.
Repository: kubernetes
Issue: [Storage] Add support for capacity isolation of shared partitions
Labels: priority/important-soon,sig/scheduling,sig/storage,sig/node,kind/feature,milestone/removed,lifecycle/frozen

Based on https://github.com/kubernetes/community/pull/306

This issue is meant to track work items and help collaboration between the community on adding support for capacity isolation of shared partitions.

Note: Priority of these features can change based on the number of collaborators.

**v1.7**

Note: @jingxu97 has already been making progress on some of the items for v1.7.

- [x] Extend EmptyDir API Spec to include `SizeLimit` (Owner: @jingxu97) #45686
- [x] Define new resources in the API to surface node storage capacity (Owner: @jingxu97 ) #44785
- [x] Define new resources in the API to consume local storage (Owner: @jingxu97 ) #44785
- [x] Gate local storage as a resource with an alpha feature gate (Owner: @jingxu97 ) #44785
- [x] Kubelet expose local storage capacity for the primary partitions (Owner: @jingxu97) #46456
- [x] Kubelet supports & enforces storage reservation in Node Allocatable (Owner: @jingxu97) #46456
- [x] Kubelet enforces local storage limits by running a control loop that evicts pods that exceed their storage limits (Owner: @jingxu97) #45686
- [x] Kubelet specifies container overlay limits and enforces them by evicting pods (Owner: @jingxu97) #45686
- [x] Add a scheduler predicate that ensures that local storage is available while binding pods to nodes (Owner: @jingxu97 ) #46456
- [x] Add node e2es to ensure storage limit enforcement (Owner: @jingxu97) #46456 #45686
-------

**v1.8**
- [x] Add cluster e2es to verify scheduler local storage support (Owner: nickren) #51070
- [x] Require storage limits for all pods (or for Gu and Bu pods). Decision TBD (Owner: jingxu97)
- [x] Add local storage to downwards API (Owner: nickren) #49610 #50435
- [x] Extend Quota and Limitranges to support storage (Owner: nickren) #50757
- [x] Extend Metrics API to include storage and expose storage usage (Owner: jingxu97) 
------

**v1.9** 
- [ ] Introduce global limit ranges (Owner: jingxu97)
- [ ] Add default I/O rate limits for logs from containers (Owner: )
- [ ] Minimize disk metrics update latency by introducing support for project quota (Owner: )
- [ ] Extend Node Problem Detector to expose shared partition failures (Owner: )

cc @jingxu97 @kubernetes/sig-node-feature-requests @kubernetes/sig-storage-feature-requests
Repository: opencv
Issue: Setting GPhoto camera widgets (properties) fails due to supplying an incorrect pointer to GPhoto library
Labels: feature,category: videoio

- OpenCV => 3.2.0
- Operating System / Platform => Ubuntu/Linux
- Compiler => g++ 5.4.0
- GPhoto2 => version 2.5.9-3
##### Detailed description

Hello,

While using a GPhoto camera through the VideoCapture interface I noticed that it is not possible to set the values of text widgets in the camera.

While requesting the value of a widget of the type 'text', the getProperty function returns a double, which is actually a pointer to a char array.

Supplying this same value back to the camera's widget results in the failure of the setProperty call (the function returns 'false'). This also happens if pointers to a char array are provided. Because of this, it seems to be impossible to set text-based values for a GPhoto camera through openCV.

While looking at openCV's implementation it seems that instead of passing the pointer to the data, which is the 'double value' argument of setProperty, a pointer to the value argument is passed on to the GPhoto library. So in essence a pointer to a pointer to the data is passed on. This happens on line 793 in opencv/modules/videoio/src/cap_gphoto2.cpp
    ```.cpp
                    CR(gp_widget_set_value(widget, (void* )(intptr_t )&value));
    ```
Replacing it with
    ```.cpp
                    CR(gp_widget_set_value(widget, (void* )(intptr_t )value));
    ```
allows setting the text properties. Now a pointer to the actual data is passed on to the gp_widget_set_value call and the changes are visible after requesting the values through CV_CAP_PROP_GPHOTO2_WIDGET_ENUMERATE.

Also: providing a string to a function by casting its pointer to a double does look a bit strange. I'm also not even sure if it is safe: the double is converted to an int-like type (intptr_t), so can't this result in errors due to rounding? Maybe implementing setProperty functions for other types than 'double' would be better in the future? And also easier to understand?
Repository: TypeScript
Issue: Autocompletion for mapped type with inferred keys and values all the same.
Labels: Suggestion,Domain: Completion Lists,Experience Enhancement

**TypeScript Version:**  nightly 2.3.0-dev.20170324

**Code**

```ts
declare function f<T extends { [P in keyof T]: { x: number } }>(t: T): void;

f({
    arbitraryKey: {
        /*Here*/
    }
});
```

**Expected behavior:**

Autocomplete gives `x`.

**Actual behavior:**

Don't get useful autocomplete.
Repository: go
Issue: x/sys/unix: add missing values from syscall pkg to enable complete migration
Labels: compiler/runtime

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
go tip

### What operating system and processor architecture are you using (`go env`)?
Ubuntu 16.04 and Fedora22, Red Hat 7.x on ppc64le & ppc64

### What did you do?
Trying to migrate Go code from syscall to sys/unix as described in the golang syscall package documentation https://golang.org/pkg/syscall/.  This was the suggested solution for issue https://github.com/golang/go/issues/19560.  While it is possible to fix just the case that is described in this issue, that is not a complete solution.  We want to avoid hitting another issue because of using syscall, so we'd like to migrate use of syscall to sys/unix.  Also having a mixture of references to syscall and sys/unix is confusing since then it is not clear when to use which one.

Issues with migrating from syscall to sys/unix:

1) syscall.Signal and syscall.Errno need to have a type defined within sys/unix so user code doesn't need to use these to convert signals and errnos to the appropriate integer type for the platform.

I was going to try a change for this based on a suggestion by Ian, but I'm not able to get the generator scripts in sys/unix to work.  I get these errors:

GOOS=linux GOARCH=ppc64le ./mkall.sh
could not determine kind of name for C.TIOCGETC
could not determine kind of name for C.TIOCGETP
could not determine kind of name for C.TIOCGLTC
could not determine kind of name for C.TIOCSETC
could not determine kind of name for C.TIOCSETN
could not determine kind of name for C.TIOCSETP
could not determine kind of name for C.TIOCSLTC

This happened on Fedora22 and Ubuntu 16.04.  If I could get some direction on what this might be that would help.

2) The structure SysProcAttr is defined in syscall but not in sys/unix.  It is used in the os package, so I don't think it should be moved to sys/unix.  Seems like it needs an equivalent declaration in os.
Repository: rust
Issue: Move libm bindings into separate crate
Labels: C-cleanup,T-compiler

It is a followup for https://github.com/rust-lang/rust/issues/39473

There is Rust cleanup activity that aims to move complex, platform-specific dependencies outside of `std`. For examples `libc` bindings were moved to its own crate and `std` links to it.

It worth checking if similar thing can be done for `libm` dependency. Decoupling `libm` library from `std` has advantages:
 - clear interface between the libraries
 - external `libm` will have its own release cycle independent of the Rust one. If there is a bug in `libm` crate then it can be released separately without waiting for a new Rust release.
 - external `libm` has more freedom over its implementation. Initially `libm` is going to be just a wrapper over system shared library. But it is be possible to create a version that statically links to openlibm and avoid dynamic linking. It would be great to see a libm version implemented fully in Rust, similar to what [math.rs](https://github.com/nagisa/math.rs) tries to achieve. And users could switch between libm implementation depending on their requirements.


Another question - do math functions like hyperbolic cosine need to be part of std at all? Would it make more sense to remove `libm` dependency from std completely and let users plug math crate manually instead?
Repository: flutter
Issue: How to open the Scaffold's drawer using Flutter Driver?
Labels: a: tests,tool,framework,t: flutter driver,P3,team-framework,triaged-framework

I'm logging this because someone asked and I don't know the answer. I should try it myself and fix it if it's not currently possible.
Repository: go
Issue: proposal: time: add civil time package
Labels: Proposal

I propose a package with minimal implementations of the types Date, Time and DateTime, which represent times without a corresponding location.

A civil time or date does not represent a point or interval of time, but they are useful for representing events transpiring between humans. For example, your birthday begins at midnight on your birthdate regardless of where you are in the world. If you're turning 21, you can buy a drink in New York at midnight, but teleport instantaneously to San Francisco and you'll be denied, because it is 9 PM the day before.

In practice, the main motivation for these types is to represent values in database-like storage systems, like BigQuery and Spanner (and other, non-Google products).

The package currently exists at cloud.google.com/go/civil, and has been in use by the BigQuery and Spanner client libraries for a few months. For now, I'd like to move it to golang.org/x/time/civil. It is probably too esoteric to be worth including in the standard library, but if there were ever a "second-tier" set of packages that augmented the standard library, it could live there. (See #17244.)

A CL is in progress at https://go-review.googlesource.com/c/38571.
Repository: angular
Issue: Child routes disappear immediately instead of playing :leave animation
Labels: type: bug/fix,area: animations,freq2: medium,P3

<!--
IF YOU DON'T FILL OUT THE FOLLOWING INFORMATION WE MIGHT CLOSE YOUR ISSUE WITHOUT INVESTIGATING
-->

**I'm submitting a ...**  (check one with "x")
```
[x] 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**
Child routes disappear immediately without playing animations when the parent route changes.

**Expected behavior**
Either all child routes play their :leave animation, or child routes don't get deleted until the parent route's :leave animation is done).

**Minimal reproduction of the problem with instructions**
Here's a version of the crisis center with animations added to all components to show the issue:
https://plnkr.co/edit/QKdb7ucKDX5JX4kKiOJ1?p=preview

Animating from Heroes > Crisis Center works smoothly, however when animating from Crisis Center > Heroes, the list disappears immediately without playing the ':leave' animation.

**What is the motivation / use case for changing the behavior?**
Smoothly animating nested routing.

**Please tell us about your environment:**
<!-- Operating system, IDE, package manager, HTTP server, ... -->
Windows 10, node, asp.net core, Visual Studio (or just plunkr).

* **Angular version:** 4.0.0
<!-- Check whether this is still an issue in the most recent Angular version -->

* **Browser:** all
 
* **Language:** TypeScript 2.2
Repository: go
Issue: cmd/compile: Unnecessary register high-bytes rezeroing after unsigned right shift
Labels: Performance,compiler/runtime

Please answer these questions before submitting your issue. Thanks!

#### What did you do?
Hello up there. Please consider the following function:

```go
package xxx

const hextable = "0123456789abcdef"

func HexHi(v byte) byte {
        return hextable[v>>4]
}
```
(https://play.golang.org/p/6t7Bq7lw2k)

it compiles to the following assembly:

```
#include "funcdata.h"

TEXT ·HexHi(SB), $0-16 // bbb.go:5
        NO_LOCAL_POINTERS
        // FUNCDATA $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB) (args)
        // FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) (no locals)
        MOVBLZX    v+0(FP), AX  // bbb.go:6
        SHRB       $4, AL
        MOVBLZX    AL, AX                                 <-- NOTE
        LEAQ       go.string."0123456789abcdef"(SB), CX
        MOVBLZX    (CX)(AX*1), AX
        MOVB       AL, _r1+8(FP)
        RET
```

where:

1. `v` was byte-zero-extend loaded from stack argument `MOVBLZX    v+0(FP), AX`
2. `v` was shifted right by 4 `SHRB       $4, AL`

and then

3. compiler makes sure that higher bytes of AX are zero `MOVBLZX    AL, AX`

Step 3 is not neccessary since original `MOVBLZX    v+0(FP), AX` is zero-extend move and after it AX[31:8] is zero and logical right shifts preserve that property (even more: for unsigned v, i if we know at some time that v is <= A, for v>>i we can know that it is <= A/2^i).

#### What did you expect to see?

No high-bytes rezeroing after right shift on zero-extended byte-loaded register.

#### What did you see instead?

Unneccessary high-bytes rezeroing instruction emitted.


#### Does this issue reproduce with the latest release (go1.8)?

Yes.

#### Possibly related issues

#18575

#### System details

```
go version devel +ecc6a81617 Sat Mar 25 00:35:35 2017 +0000 linux/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/kirr/go"
GORACE=""
GOROOT="/home/kirr/src/tools/go/go"
GOTOOLDIR="/home/kirr/src/tools/go/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build279220346=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version devel +ecc6a81617 Sat Mar 25 00:35:35 2017 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +ecc6a81617 Sat Mar 25 00:35:35 2017 +0000 X:framepointer
uname -sr: Linux 4.9.0-2-amd64
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.0 (stretch)
Release:	9.0
Codename:	stretch
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.24-9) stable release version 2.24, by Roland McGrath et al.
gdb --version: GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
```

Thanks beforehand,
Kirill

/cc @randall77
Repository: go
Issue: cmd/compile: arm64: emit double-register loads and stores in lowering
Labels: Performance,NeedsFix,compiler/runtime

ARMv8 has "double-register" loads and stores (`ldp` and `stp`), which the present SSA backend does not emit.

Since these instructions can accept any general-purpose register (unlike the corresponding ARMv7 instructions `ldrd` and `strd`), they shouldn't require any changes to the register allocator in order to get them working. I think things will "just work" if `ldp` returns a tuple of the loaded values.

In particular, I'd expect this change to make the sequence of instructions preceding and following a call op (with the existing ABI) to be reduced by up to a factor of 2. We can also use `stp` to zero 16 bytes at once.

The `stp` rule should be expressible with the existing SSA rewrite rule infrastructure. The `ldp` rule is more challenging, because there is no way to iterate the uses of a memory value in the rewrite rules. We may have to introduce an architecture-dependent pass just before lower to combine adjacent 4- and 8-byte loads into paired 8- and 16-byte loads.

CC: @williamweixiao I'm happy to take this on, but please let me know if you have similar work planned.
Repository: opencv
Issue: Provide centroids and areas of new markers returned by watershed
Labels: feature,category: imgproc

##### System information (version)
- OpenCV => ALL
- Operating System / Platform => ALL
- Compiler => ALL

##### Detailed description
Current implementation of `cv::watershed()` only updates the input labels, but does not report the new centroids or areas. Although it can be computed externally through extra iterations, it is redundant to perform these operations as it can be carried out in parallel while updating the labels with less cost.

##### Current signature
```.cpp
void watershed(InputArray image, InputOutputArray markers);
```

##### Desired signature
```.cpp
void watershed(InputArray image, InputOutputArray markers, InputOutputArray centroids = noArray(), InputOutputArray stats = noArray());
```
OR
```.cpp
void watershed(InputArray image, InputOutputArray markers, OutputArray centroids = noArray(), OutputArray stats = noArray());
```