sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: go/types: inconsistent handling of untyped expressions
Labels: NeedsFix

Currently if you type check this code with go/types:

```
var (
    _ int = 0
    _ = int(0)
    _ *int = nil
    _ = (*int)(nil)
)
```

both `0` expressions will have type "int", whereas the first `nil` expression will have type "untyped nil", and the second will have type "*int".  This seems at the least inconsistent.  See http://play.golang.org/p/cw8Ldz1U5D

My expectation was that the `0`s would type check as "untyped int" and the `nil`s would type check as "untyped nil".  The current behavior of rewriting the type of untyped expressions seems to have two negative consequences that I've noticed trying to use go/types:
1. It makes it difficult to identify useless conversion operations; i.e., expressions `T(x)` where `x` is already of type `T`.  Expressions like `int(0)` will trigger as false positives.
2. It causes `types.TypeAndValue.IsNil` to return false for the `nil` subexpression in `(*int)(nil)`, because it doesn't have the type "untyped nil" anymore.

It also seems inconsistent with conversions of already typed expressions, where they're not rewritten.

However, I notice api_test.go has a bunch of tests that seem to explicitly test for this behavior, so it seems intentional?

CC @griesemer
Repository: rust
Issue: Consider having special debugger pretty printers/handling for Unique/Shared/NonZero
Labels: A-debuginfo,P-low,T-compiler,E-medium,T-dev-tools,C-feature-request

A debugger is particularly useful for diagnosing problems in unsafe code, and these types appear reasonably often there. Currently they're printed in a rather ugly way:

``` rust
#![feature(unique)]
use std::ptr::Unique;

struct Bar { y: u8 }
struct Foo {
    ptr: Unique<Bar>,
}
fn main() {
    let mut x = Bar { y: 10 };
    unsafe {
        let f = Foo { ptr: Unique::new(&mut x) };

        drop(f);
    }
}
```

Compiling with `rustc -g unique.rs` and using `rust-gdb unique` to break on the `drop(f)` line allows one to print `f`:

``` rust
(gdb) break unique.rs:13
(gdb) r
...
(gdb) p f
$1 = Foo = {ptr = Unique<unique::Bar> = {pointer = NonZero<*const unique::Bar> = {0x7fffffffdef8}, _marker = PhantomData<unique::Bar>}}
```

Pretty much the only thing that's even slightly interesting there is the `0x7fffffffdef8` and maybe the `unique::Bar`, the layers of `NonZero` and `PhantomData` are just noise. (And even the raw address is pretty useless, and the type is often obvious from context.)

Also, the only way to examine what the pointer points to is to do a pile of field accesses, like:

```
(gdb) p *f.ptr.pointer.__0
$2 = Bar = {y = 10 '\n'}
```

In the best case, it'd be great if `*f.ptr` could work. (Also, `f.ptr.pointer.__0[x]` being written `f.ptr[x]`, for when the `Unique` is representing an array.)

(I guess there may be other standard library types to consider in a similar context: making `rust-gdb` handle them even more nicely.)
Repository: TypeScript
Issue: More strong Promise<T> in lib.es6.d.ts
Labels: Suggestion,Awaiting More Feedback

I think it would be good to be able to define the type of error in `Promise` type. I suggest promise type to be something like this:

``` typescript
interface Promise<T,U> {
    /**
    * Attaches callbacks for the resolution and/or rejection of the Promise.
    * @param onfulfilled The callback to execute when the Promise is resolved.
    * @param onrejected The callback to execute when the Promise is rejected.
    * @returns A Promise for the completion of which ever callback is executed.
    */
    then<TResult>(onfulfilled?: (value: T) => TResult | PromiseLike<TResult>, onrejected?: (reason: U) => TResult | PromiseLike<TResult>): Promise<TResult>;
    then<TResult>(onfulfilled?: (value: T) => TResult | PromiseLike<TResult>, onrejected?: (reason: U) => void): Promise<TResult>;

    /**
     * Attaches a callback for only the rejection of the Promise.
     * @param onrejected The callback to execute when the Promise is rejected.
     * @returns A Promise for the completion of the callback.
     */
    catch(onrejected?: (reason: U) => T | PromiseLike<T>): Promise<T>;
    catch(onrejected?: (reason: U) => void): Promise<T>;

    [Symbol.toStringTag]: string;
}
```

Or at least have a `Promise<T, U>` type which extends `Promise<T>`.
Repository: angular
Issue: ng-content projection for root component
Labels: feature,area: core,core: bootstrap,feature: under consideration

`ng-content` projection doesn't work for root component. E.g. for the following code:

```
<app>
   <p> Some content that needs to be projected </p>
</app>

@Component({
  selector: 'app',
})
@View({
  template: `<p>Hello world</p>
              <ng-content></ng-content>`
})
class App {}

bootstrap(App);
```

only `<p> Hello world <p>` persists in the DOM after `App` is bootstrapped.

I've reviewed the [design doc](https://docs.google.com/document/d/1BXUFVpImyWN7ynyPKehAesctP0UJTaDYbDTNVkarSeQ/edit) and haven't found such restriction.

[Plunker](http://plnkr.co/edit/10aPDcz0EUML1rjK7S3V?p=preview)
Repository: go
Issue: x/crypto/ssh/terminal: cannot handle xterm based terminals on Windows
Labels: OS-Windows

At work, I use a combination of Windows + Cygwin/MSYS2 to get my job done. Both Cygwin and MSYS2 using a mintty which is a xterm-256color terminal. My preferred backup tool on this setup is [restic](https://github.com/restic/restic). Restic use x/crypto/ssh/terminal for password authentication. This works fine with a standard Dos Box, but not with my bash (Posix) setup [see restic issue #330](https://github.com/restic/restic/issues/330).

So I've changed the terminal code to use the `util_linux.go` version, but syscall.Termios is not defined.
Repository: thefuck
Issue: "git brnch" never completes. Freezes output.
Labels: windows

I am running on windows 7 with git bash.
When I run the command "git add -all" then "fuck" I get "no fucks given"
When I run the command "git brnch" (as per the example) I get no output. I can ctrl-c to continue.
When I turn on the debug flag it appears to stop after 
    "Importing rule: open; took: 0:00:00.000500"
Repository: go
Issue: cmd/go: go test should be more explicit about test failures
Labels: NeedsDecision

In the best case, the output of `go test github.com/blevesearch/bleve/...` is 88 lines long. If one of the early test fails, the error message can easily be scrolled out and short of looking at `$?` or scrolling back manually, the user has no way to know the test run failed.

I propose `go test` prints something visible at the end of the run in that case like:

```
TEST RESULT: FAILED
```

Having a prefix like `TEST RESULT:` may make it easier for tools processing test output to ignore this line in the future, should its format change (by adding the number of tests run/successful, or time it took, etc.).
A `TEST RESULT: OK` might be displayed on success to.

Thoughts?
Repository: go
Issue: cmd/gofmt: Faulty Comment Re-Arrangement in Argument Lists
Labels: NeedsInvestigation

Hi,

I noticed today that gofmt (on the Playground at least) reformats `/* */` comments that are inlined in argument lists inconsistently and in a non-faithful manner to their original ordering in the list:
## Pre-Gofmt

`fmt.Println(/* before first */ "first", /* before second */ "second")`
[demo](http://play.golang.org/p/cBIcd0DWoC)
## Post-Gofmt

`fmt.Println( /* before first */ "first" /* before second */, "second")`
[demo](http://play.golang.org/p/Ouu8UiHMmC)

Notice how in the _Post-Gofmt_ case it moves the comment that occurred _after_ the comma to _before_.

This behavior is incongruent to what happens when the argument lists are spread across multiple lines:
## Newline Distributed Pre-Gofmt

```
package main

import "fmt"

func main() {
    fmt.Println(
    /* before first */ "first")
    fmt.Println(
    /* before first */ "first",
    /* before second */ "second")   
}
```

[demo](http://play.golang.org/p/A21ZkTDdmC)
## Newline Distributed Post-Gofmt

```
package main

import "fmt"

func main() {
    fmt.Println(
        /* before first */ "first")
    fmt.Println(
        /* before first */ "first",
        /* before second */ "second")
}
```

[demo](http://play.golang.org/p/rtgoQRJO1w)

For the _pre_ cases, be sure to click `Format` in the Go Playground demo to see the post-state.
Repository: rust
Issue: println! sometimes panics in drop methods
Labels: P-medium,T-libs-api,A-thread-locals,C-bug

If you try to println!-debug a drop method in a type which is being used in TLS, you can have problems because the TLS variable which holds the local stdout might already have been destroyed, turning your innocent print into a panic with "cannot access a TLS value during or after it is destroyed".  This seems unnecessarily user-hostile.

(I solved the bug in my code, but I'm kinda curious what the recommended way to trace a drop method is.  rt::util::dumb_print?)
Repository: rust
Issue: fs::remove_dir_all rarely succeeds for large directories on windows
Labels: O-windows,E-help-wanted,C-bug,T-libs,A-io

I've been trying to track this one down for a while with little success. So far I've been able to confirm that no external programs are holding long-standing locks on any of the files in the directory, and I've confirmed that it happens with trivial rust programs such as the following:

``` rust
use std::fs;

fn main() {
    println!("{:?}", fs::remove_dir_all("<path>"));
}
```

I've also confirmed that deleting the folder from explorer (equivalent to using SHFileOperation), or using `rmdir` on the command line will always succeed.

Currently my best guess is that either windows or other programs are holding transient locks on some of the files in the directory, possibly as part of the directory indexing windows performs to enable efficient searching.

Several factors led me to think this:
- `fs::remove_dir_all` will pretty much always succeed on the second or third invocations.
- it seems to happen most commonly when dealing with large numbers of text files
- unlocker and other tools show no active handles to any files in the directory

Maybe there should be some sort of automated retry system, such that temporary locks do not hinder progress?

edit:
The errors returned seem somewhat random: sometimes it gives a "directory is not empty" error, while sometimes it will show up as an "access denied" error.
Repository: go
Issue: x/tools/cmd/stringer: Gets confused with pointers to C.struct_xxx types.
Labels: Tools

Save this http://play.golang.org/p/7IHAOsDFqO in `foo.go` and say:

```
stringer -type MyT foo.go
```

Stringer will fail with:

```
stringer: checking package: foo.go:22:2: invalid operation: pfoo (variable of type *invalid type) has no field or method i
```

Stringer works ok with this, though: http://play.golang.org/p/uIrtOCI59N

Another similar program that triggers the same behavior (stringer failure) is this: http://play.golang.org/p/P2t3O0zONt
Repository: rust
Issue: Metadata for DLLs should actually go in the LIB import library on Windows
Labels: O-windows,C-enhancement

Since metadata is only needed when building things, but the DLL is needed at runtime, it would be better if the metadata was moved to the LIB import library instead since that is only needed when building things as well. This would save significantly on space when distributing a binary with DLLs.
Repository: angular
Issue: ViewEncapsulation.None styles bleed into ViewEncapsulation.Native components when siblings
Labels: type: bug/fix,freq1: low,area: core,core: CSS encapsulation,P3

When there are sibling components, one with ViewEncapsulation.Native and the other with ViewEncapsulation.None, the styles that any component stylings are being appended to the shadow root of the one component set to Native. 

~~Plunker: http://plnkr.co/edit/huN8xe0S7xH5CUw4B2P6?p=preview~~
**Updated Stackblitz**: https://stackblitz.com/edit/angular-issue-5059?file=src/app/app.component.html

<img width="491" alt="screen shot 2015-11-01 at 9 58 03 pm" src="https://cloud.githubusercontent.com/assets/79500/10874083/afa88d42-80e3-11e5-8f8e-ad09cd8414df.png">

A component set to Native should not adopt the rest of the CSS rules from non-Native components. In the screenshot of the rendered DOM, the last three style elements are appended to the end of the shadow root, but they are actually declared in the other two components which are set to None and Emulated modes.

If all three components are set to Native, then the rules are applied only to the local component, but when they are mixed the rules bleed over into Native (but don't bleed out of Native).
Repository: opencv
Issue: the problem of stitching module
Labels: bug,priority: normal,affected: 3.4,category: t-api

I built opencv3.0 with extra module xfeatures2d on win 7 with VS 2013, and then I used the below

> # pragma comment(lib, "opencv_core300.lib")
> # pragma comment(lib, "opencv_imgproc300.lib")
> # pragma comment(lib, "opencv_imgcodecs300.lib")
> # pragma comment(lib, "opencv_stitching300.lib")
> # pragma comment(lib, "opencv_xfeatures2d300.lib")

 libraries to built and link stitching_detailed.cpp which located in samples\cpp folder. When I run the program, it showed me as follow

> OpenCL program build log: -D depth=0 -D scn=3 -D PIX_PER_WI_Y=4 -D dcn=1 -D bidx
> =0 -D STRIPE_SIZE=1 -D INTEL_DEVICE
> igdfcl64.dll successfully completed build.
> igdfcl64.dll successfully completed build.
> Error, line 14118: compile failed.

So, what is wrong with the code? I can run the stitching code on Opencv 2.4.11.
Repository: opencv
Issue: "error: (-217) invalid resource handle" when using OpenCV 2.4.11-2.4.x compiled with Cuda 7.5 on second graphic card
Labels: bug,priority: normal,affected: 2.4,category: gpu/cuda (contrib)

This issue only occurs with OpenCV 2.4.11-2.4.x branch compiled with Cuda 7.5 and does not with Cuda 6.5.
Each stream and buffers are alloced and page-locked on the correct device with gpu::setDevice.
It runs well with Cuda 6.5 on multiple GPUs. However it fails on the first OpenCV kernel call on the second GPU (GPU device 1) with the following exception with Cuda 7.5:
"d:\opencv-2.4\modules\gpu\include\opencv2\gpu\device\detail/transform_detail.hpp:386: error: (-217) invalid resource handle\n". Strangely, no issue happens on the first GPU (GPU device 0)

When using directly NPP on Cuda 7.5 with multiple GPUs, no issue happens. Unfortunately, I could not managed to find out what's happening...
I can provide sample code if needed.

Thanks
Repository: rust
Issue: Provide a way of linking libgcc statically
Labels: A-linkage,T-compiler,C-feature-request

gcc et al provide "-static-libgcc" for platforms where a link to libgcc_s.so is undesirable. I need similar functionality in rustc because the cloud I'm deploying to doesn't have that in its runtime.

See issue #29482 for some background.

/cc @alexcrichton
Repository: youtube-dl
Issue: [8tracks] add a flag to return immediately the first 5 playlist items
Labels: request

fetching 8tracks playlists waits for some time to retrieve items which can block for a while (see #7349 for details).
It would be nice to have a flag where it return the first 5 playlist items immediately and exits.
Repository: go
Issue: x/build: builders for alternate buildmodes?
Labels: Builders,new-builder

For -buildmode=shared on linux/386, @mwhudson's current set of patches would borrow the CX register. This seems reasonable to me, but means that assembly that works under -buildmode=exe will not work under -buildmode=shared (see the discussion on http://golang.org/cl/16385).

Should we have a builder that runs the standard library tests compiled with -buildmode=shared? What about c-shared and c-archive?

cc @ianlancetaylor @bradfitz
Repository: TypeScript
Issue: Inconsistent quick info between interface and namespace declaration
Labels: Bug,Help Wanted,Domain: Quick Info

![image](https://cloud.githubusercontent.com/assets/972891/10924083/54d07176-8239-11e5-882f-5c5039621d3a.png)

![image](https://cloud.githubusercontent.com/assets/972891/10924087/58111c46-8239-11e5-98e7-b2b57a809e50.png)
Repository: rust
Issue: Tracking issue for #[bench] and benchmarking support
Labels: T-libs-api,B-unstable,C-tracking-issue,Libs-Tracked

This is a tracking issue for the `#[bench]` attribute and its stability in the compiler. Currently it is not possible to use this from stable Rust as it requires `extern crate test` which is itself not stable.


Core APIs for benchmarking:

* `#[bench]`, which means the function should take a `&mut Bencher` argument and will be run as part of regular tests (and specifically benchmarked with --bench passed to the test binary).

```rust
crate test {
    mod bench {
        #[derive(Clone)]
        struct Bencher { ... }

        impl Bencher {
            fn iter<T, F>(&mut self, inner: F)
            where
                F: FnMut() -> T;
        }       
    }
}
```
Repository: rust
Issue: Produce packaging guidelines
Labels: P-low,T-infra,C-feature-request

Summarize what we've learned into some general guidelines for packagers.

Potential topics:
- Maintaining independently-bootstrapped Rust compilers.
- Packaging Cargo libraries / applications
- Generating offline docs

re https://internals.rust-lang.org/t/perfecting-rust-packaging-the-plan/2767
Repository: ant-design
Issue: Ant Design Users 👨🏻‍💻👩🏻‍💻👨🏻‍💻👩🏻‍💻
Labels: 🗣 Discussion,gitauto

> :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: 
>
> **欢迎去知乎回答这个问题：[如何评价 Ant Design 这个项目？](https://www.zhihu.com/question/33629737)，说出你的真实开发感受即可。**
>
> :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: :star2: 

![](https://gw.alipayobjects.com/mdn/rms_dea682/afts/img/A*1X6BTJtOW2YAAAAAAAAAAABkARQnAQ)

---

如果您和您的公司或组织使用了 Ant Design ，非常感谢您的支持，欢迎留下公司或产品名，您的回复将成为维护者、社区用户和观望者的信心来源。

> 在不泄露信息的前提下，建议把截图晒一晒~
> 无关回复将会定期删除

推荐回复格式：

```
- 产品：
- 公司或组织：（如果可以）
- 链接：（如果可以）
- 截图：（如果可以）
```

---

We appreciate you support if you or your organization is using Ant Design. You are welcome to leave replies about your product and organization here, which could became the confidence of maintiners, communication and undecided watchers.

Recommended reply format:

```
- Product：
- Company or Organization: (if any)
- Link: (if any)
- Screenshot: (if any)
```
Repository: rust
Issue: Tracking issue for `thread_local` stabilization
Labels: A-FFI,T-lang,B-unstable,A-thread-locals,C-tracking-issue,F-thread_local,S-tracking-impl-incomplete

The `#[thread_local]` attribute is currently feature-gated. This issue tracks its stabilization.

Known problems:
- [ ] `#[thread_local]` translates directly to the `thread_local` attribute in LLVM. This isn't supported on all platforms, and it's not even supported on all distributions within the same platform (e.g. macOS 10.6 didn't support it but 10.7 does). I don't think this is necessarily a blocker, but I also don't think we have many attributes and such which are so platform specific like this.
- [x] Statics that are thread local shouldn't require `Sync` - https://github.com/rust-lang/rust/issues/18001
- [x] Statics that are thread local should either not borrow for the `'static` lifetime or should be unsafe to access - https://github.com/rust-lang/rust/issues/17954
- [x] Statics can currently reference other thread local statics, but this is a bug - https://github.com/rust-lang/rust/issues/18712
- [ ] Unsound with generators https://github.com/rust-lang/rust/issues/49682
- [ ] static mut can be given `'static` lifetime with NLL (https://github.com/rust-lang/rust/issues/54366)
Repository: rust
Issue: Tracking issue for `log_syntax`, `trace_macros`
Labels: T-lang,B-unstable,C-tracking-issue,S-tracking-design-concerns

The `log_syntax` feature gate allows use of the `log_syntax` macro attribute, and similarly for `trace_macros`. Both are "nasty hacks that will certainly be removed" (according to the reference manual).
Repository: rust
Issue: Tracking issue for `concat_idents`
Labels: A-macros,T-lang,T-libs-api,B-unstable,C-tracking-issue,Libs-Tracked,S-tracking-design-concerns

Tracks stabilization for the `concat_idents` macro.

**Update(fmease)**: Please see https://github.com/rust-lang/rust/issues/124225#issue-2255069330 (an alternative to this feature).
Repository: rust
Issue: Tracking issue for `link_llvm_intrinsics`
Labels: T-lang,B-unstable,C-tracking-issue,S-tracking-perma-unstable

Tracks ~~stabilization for~~ the `link_llvm_intrinsics` feature, used via `#[link_name="llvm.*"]`.

**Edit**: As this is obviously back-end specific, it will most likely never be stabilized.
Repository: rust
Issue: Tracking issue for the `linkage` feature
Labels: A-linkage,A-attributes,A-FFI,T-lang,B-unstable,C-tracking-issue,S-tracking-perma-unstable

Tracks stabilization for the `linkage` attribute.
Repository: go
Issue: runtime: print all threads in GOTRACEBACK >= all
Labels: NeedsFix,compiler/runtime

Currently, GOTRACEBACK=all is a misnomer. It prints stacks for all goroutines that happen to be non-running or running on the current OS thread, but it does not print stacks for goroutines that are running on other OS threads. This is frustrating. For purely internal reasons, it's currently necessary to set GOTRACEBACK=crash in order to get stacks for goroutines on other threads, but that also gets you runtime frames and an abort at the end, which is often undesirable.

We should make GOTRACEBACK=all (or higher) print stacks for all goroutines, regardless of what thread they're running on. This will make "all" do what it says in the name and will make the only difference between "system" and "crash" be whether or not it aborts at the end of the traceback.

In other words, this is the current behavior of the GOTRACEBACK settings:

|  | none | single | all | system | crash |
| --- | :-: | :-: | :-: | :-: | :-: |
| show user frames | N | Y | Y | Y | Y |
| show runtime frames | N | N | N | Y | Y |
| show other goroutines | N | N | Y | Y | Y |
| show other threads | N | N | N | N | Y |
| abort | N | N | N | N | Y |

This is what it should be:

|  | none | single | all | system | crash |
| --- | :-: | :-: | :-: | :-: | :-: |
| show user frames | N | Y | Y | Y | Y |
| show runtime frames | N | N | N | Y | Y |
| show other goroutines | N | N | Y | Y | Y |
| show other threads | N | N | *Y* | *Y* | Y |
| abort | N | N | N | N | Y |

With this, we would eliminate the distinction between "show other goroutines" and "show other threads", and each GOTRACEBACK level would enable exactly one additional feature.

We could do this using the same signal hand-off mechanism GOTRACEBACK=crash currently uses to interrupt the other threads. Historically we couldn't do this because this mechanism wasn't entirely robust, but it's been improved to the point where it should be reliable.

/cc @rsc @ianlancetaylor @randall77
Repository: rust
Issue: Improve MIR match generation so that we more effecitvely rule out inapplicable match-pairs
Labels: C-enhancement,T-compiler,A-MIR

Once we perform a test -- such as checking a value or a variant -- we then weed out the matches that are invalidated by this test. The current code is no as smart as it could be: for example, if we test and find that a value equals 'c', we ought to be able to rule out that the character also equals 'd'. But, because the test tells us nothing if we find that the character is NOT equal to 'c', we take the simple path right now and say that an equality test against 'c' and an equality test against 'd' are completely orthogonal from one another. Similar limitations exist for range tests, slice length tests, etc. We should do better!
Repository: rust
Issue: Tracking issue for Fn traits (`unboxed_closures` & `fn_traits` feature)
Labels: T-lang,T-libs-api,B-unstable,B-RFC-implemented,C-tracking-issue,F-unboxed_closures,S-tracking-design-concerns

Tracks stabilization for the `Fn*` traits.

Random bugs:

- [x] https://github.com/rust-lang/rust/issues/45510 – type-based dispatch not working
- [ ] https://github.com/rust-lang/rust/issues/42736 – `foo()` sugar doesn't work where you have `&Foo: FnOnce`