sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: [RFC] Refactor types to be a `(TypeCore, Substs)` pair
Labels: C-cleanup,T-compiler

Currently, [the `Ty<'tcx>` type][ty] is a reference to [a struct (`&TyS`)][tys] that packages up [a big ol' enum `TypeVariants`][tv]. As part of [chalkification](https://github.com/rust-lang/rust-roadmap/issues/8), we would like to be able to write more efficient "decision tree" like procedures that branch on this type. This would be made nicer by factoring out the type into two parts, a "core" and a "substs". This core would be roughly equivalent to the existing `TypeVariants`, but without the recursive references to other types, which would be uniformly packaged up in the `substs`.

[ty]: https://github.com/rust-lang/rust/blob/171d2857560a3c109d59d946bf3ff74a42d0ab33/src/librustc/ty/mod.rs#L538
[tys]: https://github.com/rust-lang/rust/blob/171d2857560a3c109d59d946bf3ff74a42d0ab33/src/librustc/ty/mod.rs#L498-L504
[tv]: https://github.com/rust-lang/rust/blob/171d2857560a3c109d59d946bf3ff74a42d0ab33/src/librustc/ty/sty.rs#L95-L184

Thus I imagine that the `TyS` struct would change to something like this:

```rust
pub struct TyS<'tcx> {
    pub sty: TypeVariants<'tcx>, // this is the "core" part
    pub substs: &'tcx Substs<'tcx>, // this is the "substs" part, extracted from `TypeVariants`
    pub flags: TypeFlags,

    // the maximal depth of any bound regions appearing in this type.
    region_depth: u32,
}
```

(Incidentally, this new notion of `TypeVariants` could maybe subsume the existing [`SimplifiedType`](https://github.com/rust-lang/rust/blob/171d2857560a3c109d59d946bf3ff74a42d0ab33/src/librustc/ty/fast_reject.rs#L19-L36), though that's not super important.)

### Steps

This transition is best made in steps:

- [x] #42171: refactor ProjectionTy to store def-id of associated item + substs
    - PR: #42297
- [x] [transition `TyTuple` to use a substs](https://github.com/rust-lang/rust/blob/171d2857560a3c109d59d946bf3ff74a42d0ab33/src/librustc/ty/sty.rs#L163)
    - This would make things more regular, but we "lose" the fact that tuples are always composed of types at the moment. Probably not important in practice.
- [x] [remove the `ClosureSubsts` type used in `TyClosure` and make it into a normal substs](https://github.com/rust-lang/rust/blob/171d2857560a3c109d59d946bf3ff74a42d0ab33/src/librustc/ty/sty.rs#L153) 
- [x] [do the same for `GeneratorSubsts`]

### Unknowns

It's not 100% clear that this is a good plan, though the individual refactorings above all seem like good steps regardless. Some complicating factors:

- `TyFnPtr` embodies a `PolyFnSig`, which carries a binder. 
- Existential types carry where-clauses (eventually, function pointers may do the same, to address https://github.com/rust-lang/rust/issues/25860)

cc @eddyb, who first suggested this to me
cc @tschottdorf, who implemented #42297, a step along this path (and an important step for ATC regardless)
Repository: electron
Issue: Add support for SVG nativeImage
Labels: enhancement :sparkles:,component/tray,platform/all

<!--
Thanks for opening an issue! A few things to keep in mind:

- The issue tracker is only for bugs and feature requests.
- Before reporting a bug, please try reproducing your issue against
  the latest version of Electron.
- If you need general advice, join our Slack: http://atom-slack.herokuapp.com
-->

* Electron version: 1.6.10
* Operating system: elementary OS 0.4.1 Loki

### Expected behavior

It should be possible to set a tray image in SVG format. This would allow tray icons to adapt to the current theme (ie. appear white on black, or black on white).

### Actual behavior

The image must be supplied as a PNG or a JPG and therefore does not adapt to the platform's theme.

### How to reproduce

```
new Tray('/path/to/image.png');
```
Repository: rust
Issue: introduce region-clauses into the `ParamEnv`, use to replace the `body_id`
Labels: C-cleanup,A-trait-system,T-compiler

When we are in a closure body, we often gain additional implied "outlives" relation based on the types of the closure arguments. Consider this:

```rust
foo(|x: &T| ...)
```

Here, the type of `x` will be `&'0 T` for some anonymous region `'0`. Within the function body, then, we can conclude that `T: '0`. We currently handle this through a variety of messy schemes. As part of [chalkificaton](https://github.com/rust-lang/rust-roadmap/issues/8), I would like to consolidate this into a cleaner, more uniform handling of environments and universes. This issue lays out an "evolving" plan for doing that.

### Current handling

Currently, for every trait obligation that we have to prove (e.g., `T: Debug`), we have an `ObligationCause`  -- this is *primarily* used for debugging, in that it specifies *why* we have to prove this thing. However, this type also carries a `body_id` identifying the closure it came from. When we wind up having to prove an outlives relationship like `Foo: 'a`, we record this in the fulfillment context (a kind of record of things we have yet to prove), and we track the `body_id` where the obligation was incurred. Then, after type-checking, in the region-checking phase, we walk down the AST and figure out -- for each closure body -- what outlives facts we know at that point in time.  We then pull out the list of outlives obligations from the fulfillment cx for a given body-id and try to prove them, using those facts. This whole process is complex and fragile.

### Roughly how I want it to work

We now have the ability to have every obligation have its own, distinct environment (we used to have just one ambient environment). This means that instead of having this ad-hoc `body_id` field, we can just extend the environment when we enter into a closure body. So, for example, when type-checking the body of the closure in the beginning, our environment would be extended with a `T: 'a` outlives clause. We can do this right away, just as soon as we start type-checking the closure.  This environment is automatically propagated to sub-goals, so when we wind up with some outlives obligations that we have to prove, they will have `T: 'a` in their list of clauses (i.e., the facts that they can draw upon). This means that regionck doesn't have to do anything "special" -- rather, the input to regionck will change from being a flat list of obligations, to obligations that can carry more environmental information.

There is one complication here:

- when we first start type-checking closures, we often have not yet inferred the types of the arguments yet. This is partly why the current scheme defers everything until regionck. But this is ok, we can still insert "outlives" obligations that contain inference variables. We'll give them their final values before we go and solve things.

### Actual steps

OK, I ran out of time for this part. =)
Repository: kubernetes
Issue: Consolidate pod-nannies
Labels: kind/cleanup,sig/scalability,sig/autoscaling,sig/instrumentation,priority/important-longterm,lifecycle/frozen

Follow-up of https://github.com/kubernetes/kubernetes/pull/46700#discussion_r119539877

There are a lot of pod-nannies in the cluster already, each of them consuming non-zero amount of resources (90+MB of memory, 50+m cpu). It would be much more preferable to have only one nanny which can be configured to scale multiple pods.

Maybe this should be a separate controller? With an API representation?

/cc @piosz @wojtek-t
Repository: create-react-app
Issue: Move more things to react-dev-utils
Labels: issue: proposal

I want to make react-scripts easier to fork/extend.  I think the way to do that is to move as much as possible into react-dev-utils so that react-scripts can be a smaller package that changes less frequently.  Then you can always just update the react-dev-utils to get most new features in react-scripts.

This should also make ejecting much less painful, as ejected projects still depend on react-dev-utils

My proposal is to move:

1. config/webpackDevServer.config.js - This can just take `publicPath` and `appPublic` as additional options
2. config/polyfills.js - this can just be moved as is - do we want to include it in what gets ejected still, or just reference it from react-dev-utils?  I feel like just referencing it probably makes the most sense.
3. config/env.js - This will need to take `dotenvPath` as an argument, and `delete require.cache[require.resolve('./paths')];` will have to be done elsewhere.
4. each of the three jest transforms - these can just be moved as is, and then they won't need to be ejected either.
5. scripts/utils/createJestConfig.js - this will just need to take `paths.testsSetup` and `paths.appPackageJson` as arguments.

I then think we should add a `pathUtils` module in react-dev-utils, containing `resolveApp`, `getPublicUrl`, `getServedPath` and `resolveOwn`.  This should simplify `config/paths.js` quite a bit.

At this point, I think we should re-evaluate what else needs moving.  If nobody objects, I'll start submitting pull requests for these changes.
Repository: vue
Issue: Transition group classes not being properly deleted when using v-show
Labels: improvement,has PR,transition

### Version
2.3.3

### Reproduction link
[https://jsfiddle.net/ma7moudat/u82ugj8z/1/](https://jsfiddle.net/ma7moudat/u82ugj8z/1/)

### Steps to reproduce
Set up a transition group that automatically rotates through a list of items and shows one item at a time (a slider if you will).



### What is expected?
The last item disappears and the new item appears at the specified intervals.

### What is actually happening?
Everything seems to be running perfectly fine, but if you leave the window for a minute or so (go to a new tab or another window) and then come back, the transition group becomes a mess, because the transition classes get added over and over without being removed from the items.

So you would get something like this!

```<div class="item crossfade-enter-to crossfade-enter-to crossfade-leave-to crossfade-enter-to crossfade-leave-to crossfade-enter-to crossfade-leave-to crossfade-enter-to crossfade-leave-to crossfade-enter-to crossfade-leave-to crossfade-enter-to crossfade-leave-to crossfade-enter-to crossfade-leave-to crossfade-enter-to crossfade-leave-to .........">```

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: Wishlist: compiler should give hint when trying to use Box<Trait> as Trait
Labels: A-type-system,C-enhancement,A-diagnostics,A-trait-system,T-compiler,T-types

If I have a function:
```
fn foo<F: Foo>(f: F) { ... }
```
and I pass it `Box<Foo>`, this fails because `Box<Foo>` doesn't actually implement the `Foo` trait. Ideally it should, but as a stop-gap the compiler should hint at that problem, because it wasn't obvious to me that a boxed trait object doesn't implement that trait.
Repository: flutter
Issue: Do plugins need to know about hot reload and hot restart?
Labels: engine,P2,a: plugins,team-engine,triaged-engine

I think it would be an OK design choice if they didn't.  But it's probably better if they do.

If we need to add new API to teach plugins about hot-reload or hot-restart we might need to do that sooner rather than later.

FYI @mravn-google
Repository: react
Issue: Error when `__source` is provided to production build
Labels: Type: Enhancement,Component: Developer Tools,React Core Team

Currently if the `__source` transform is enabled together with the production build there are no indicators of a poorly performant configuration. https://facebook.github.io/react/ even has it.

We already check for the [existence of a `__source` field](https://github.com/facebook/react/blob/master/src/isomorphic/classic/element/ReactElement.js#L203). So we can just reuse the same check to issue something in prod mode if it exists.

The problem is that we don't have any warning module in prod and it is unclear if it would get attention or even considered to spammy in prod.

We could throw but that might be too extreme since a misconfiguration would kill the site.

We could also use this to set a flag on the `__REACT_DEVTOOLS_GLOBAL_HOOK__` object. The icon in the devtools extension could use this to indicate a misconfigured build.
Repository: go
Issue: x/build: restore performance benchmarking dashboard
Labels: Builders,NeedsFix

In a trybot run in https://storage.googleapis.com/go-build-log/dd2f2f0c/linux-amd64_19b3a9d1.log , after the build and the tests are complete, I see this:

    ##### 
    iteration: 0
    start-time: 2017-06-02T00:53:45Z
    building testgo failed: exit status 1
    can't load package: package .: no buildable Go source files in /tmp/workdir/go-parent
    
    Error: tests failed: dist test failed: bench:bench-cmd-go.exe -test.bench . -test.benchmem -test.run ^$ -test.benchtime 100ms: exit status 2
Repository: vscode
Issue: Have ctrl+click work the same way as in Visual Studio
Labels: feature-request,editor-core

we use  dblclick LBtn to select a word, but using ctrl +LBtn  is a good way,
in vs studio we could do the following:
1. basic:  press  ctrl and click a word,  the word is selected.
2. advanced: when a word is selected ,  press ctrl+shift and select another word,   so we could select from the start of the  first word to the end of the last word
3.advanced: with ctrl down, we clicked a word, don't release the LBtn, move the mouse to  some where in the middle of the next word ,  the whole next word will be  selected.  this is the same effect as the  "ctrl + right"
Repository: go
Issue: x/net/bpf: bpf VM only supports running programs with big endian
Labels: NeedsInvestigation

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
go version go1.7.4 linux/amd64

### What operating system and processor architecture are you using (`go env`)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/egon/devel/go"
GORACE=""
GOROOT="/usr/lib/go-1.7"
GOTOOLDIR="/usr/lib/go-1.7/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build717134135=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

### What did you do?
I am using x/net/bpf so that I can simulate a bunch of bpf programs generated by libseccomp-golang in the net/bpf VM to validate a small txt->bpf compiler. 

I ran into the problem that the x/net/bpf VM assumes BigEndian byte order. However libseccomp-golang generates code in host byteorder (which happens to be little endian on my machine) so the simulation is not working as expected. 

### What did you expect to see?

I was hoping the VM would let me control the endianness. Please consider the following diff, it is fully backwards compatible but it will let me run libseccomp generated bpf programs inside the VM.

<pre>

diff --git a/bpf/vm_instructions.go b/bpf/vm_instructions.go
index 516f946..2263c3f 100644
--- a/bpf/vm_instructions.go
+++ b/bpf/vm_instructions.go
@@ -134,6 +134,10 @@ func inBounds(inLen int, offset int, size int) bool {
        return offset+size <= inLen
 }
 
+// VmEndianness controlls what byte order the bpf.VM is using.
+// The default is binary.BigEndian
+var VmEndianness binary.ByteOrder = binary.BigEndian
+
 func loadCommon(in []byte, offset int, size int) (uint32, bool) {
        if !inBounds(len(in), offset, size) {
                return 0, false
@@ -143,9 +147,9 @@ func loadCommon(in []byte, offset int, size int) (uint32, bool) {
        case 1:
                return uint32(in[offset]), true
        case 2:
-               return uint32(binary.BigEndian.Uint16(in[offset : offset+size])), true
+               return uint32(VmEndianness.Uint16(in[offset : offset+size])), true
        case 4:
-               return uint32(binary.BigEndian.Uint32(in[offset : offset+size])), true
+               return uint32(VmEndianness.Uint32(in[offset : offset+size])), true
        default:
                panic(fmt.Sprintf("invalid load size: %d", size))
        }
</pre>
Repository: rust
Issue: Add span to E0271 errors pointing at the "found" associated type bound
Labels: C-enhancement,A-diagnostics,T-compiler,D-papercut

This code produce next error:

```rust
fn foo<F, R>(f: F)
    where F: FnOnce() -> R,
          R: IntoItem<Item=()> 
          { }

trait IntoItem {
    type Item;
}

struct S;

impl IntoItem for S {
    type Item = u32;
}

fn main() {    
    foo(|| S);
}
```
error:
```
 35 |     foo(|| S);
    |     ^^^ expected u32, found ()
    |
    = note: expected type `u32`
               found type `()`
    = note: required by `foo`
```

This is not correct, because expected type of foo is () (see functon signature).
I'm ask to swap "expected" and "found" notes, because is very confused. For rust
beginners this is embarassing (e.g., an error often occurs when works with `tokio` crate).

It's also incorrect because underlining is on "foo" keyword, but should to argument.

This error might look like this:
```
35 |     foo(|| S);
   |         ^^^^ expected (), found u32
   |
   = note: expected type `()`
              found type `u32`
   = note: required by `foo`
```

I suggest making a conclusion about this error easier, such as this:
```rust
fn foo(v:u8){ }
fn main(){
    foo(25u16); //expected u8, found u16 <-- this is correct
}
```
Repository: rust
Issue: Could we clarify type error messages that involve traits + closures?
Labels: C-enhancement,A-diagnostics,A-trait-system,A-closures,T-compiler

After a typo, I recently received the following error message:

```
error[E0277]: the trait bound `bintree::simple::BuilderError: std::convert::From<[closure@src/bintree/simple.rs:244:24: 244:51]>` is not satisfied
   --> src/bintree/simple.rs:243:24
    |
243 |               let kind = node.kind()
    |  ________________________^
244 | |                 .ok_or(|| BuilderError::MissingTag)?;
    | |____________________________________________________^ the trait `std::convert::From<[closure@src/bintree/simple.rs:244:24: 244:51]>` is not implemented for `bintree::simple::BuilderError`
    |
    = note: required by `std::convert::From::from`
```

The problem was that I used `ok_or` instead of `ok_or_else`. What I'd like to have seen (and what would have saved me a few minutes) is an additional line suggesting something like: « This operation does not work with a closure. »

Could we perhaps detect that the scope contains no implementation of `From<T>` where `T` is a closure? This could, of course, be extended to other traits, but I suspect that it is worse for `Result<>`, since the call to `from` is not visible in the syntax.
Repository: kubernetes
Issue: 406 unacceptable error for POSTing without a content type to the LIST endpoint is wrong
Labels: sig/api-machinery,lifecycle/frozen

When you POST to /resources, if you don't specify ContentType you get an error message that is incorrect (only suggests stream types).
Repository: go
Issue: cmd/gofmt: puts `else if` comments in wrong place
Labels: NeedsDecision

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
play.golang.org

### What operating system and processor architecture are you using (`go env`)?
play.golang.org

### What did you do?
Ran this: https://play.golang.org/p/xJ0-Cq8ZYi and clicked `format`

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
here it is: https://play.golang.org/p/xJ0-Cq8ZYi

### What did you expect to see?
I expected the B and C branch comments to be aligned the same way the A branch comment is..

### What did you see instead?
Instead they were indented as if they were part of the previous block.

I get how this is a tricky issue, but if there is a blank line and the comment is right before the next block, I think it should be indented for that block.

Thanks!
Repository: youtube-dl
Issue: Add Support for weyyak.z5.com
Labels: site-support-request

Hello
I need to add support for this new website to download form it 
http://weyyak.z5.com/player/1349010,episode
Because when I try to download from it I see this error
http://s9.postimg.org/xp6tx73jz/screenshot_27.png
Thanks.
Repository: go
Issue: cmd/link: debugging fails with -linkmode external on macOS
Labels: help wanted,OS-Darwin,NeedsInvestigation,Debugging,compiler/runtime

lldb HEAD works with linkmode internal on macOS Sierra:

```
$ go build -gcflags "-N -l" -x test.go
WORK=/var/folders/ry/v14gg02d0y9cb2w9809hf6ch0000gn/T/go-build450234285
mkdir -p $WORK/command-line-arguments/_obj/
mkdir -p $WORK/command-line-arguments/_obj/exe/
cd /Users/filippo/code/misc/rustgo
/usr/local/Cellar/go/1.8.1_1/libexec/pkg/tool/darwin_amd64/compile -o $WORK/command-line-arguments.a -trimpath $WORK -N -l -p main -complete -buildid 671e0e95e61f5bf7c157a090a3801fe9766c1a0a -D _/Users/filippo/code/misc/rustgo -I $WORK -pack ./test.go
cd .
/usr/local/Cellar/go/1.8.1_1/libexec/pkg/tool/darwin_amd64/link -o $WORK/command-line-arguments/_obj/exe/a.out -L $WORK -extld=clang -buildmode=exe -buildid=671e0e95e61f5bf7c157a090a3801fe9766c1a0a $WORK/command-line-arguments.a
mv $WORK/command-line-arguments/_obj/exe/a.out test

$ sudo /usr/local/opt/llvm/bin/lldb test
(lldb) target create "test"
Current executable set to 'test' (x86_64).
(lldb) b main.main
Breakpoint 1: where = test`main.main at test.go:5, address = 0x000000000104bf20
(lldb) run
Process 5724 launched: '/Users/filippo/code/misc/rustgo/test' (x86_64)
Process 5724 stopped
* thread #6, stop reason = breakpoint 1.1
    frame #0: 0x000000000104bf20 test`main.main at test.go:5
   2
   3   	package main
   4
-> 5   	func main() {
   6   		println("foo")
   7   	}
```

But fails with linkmode external:

```
$ go build -gcflags "-N -l" -ldflags "-linkmode external" -x test.go
WORK=/var/folders/ry/v14gg02d0y9cb2w9809hf6ch0000gn/T/go-build843720462
mkdir -p $WORK/command-line-arguments/_obj/
mkdir -p $WORK/command-line-arguments/_obj/exe/
cd /Users/filippo/code/misc/rustgo
/usr/local/Cellar/go/1.8.1_1/libexec/pkg/tool/darwin_amd64/compile -o $WORK/command-line-arguments.a -trimpath $WORK -N -l -p main -complete -buildid 09e299344f906f0b167907ec8bcdd857d3794aa0 -D _/Users/filippo/code/misc/rustgo -I $WORK -pack ./test.go
cd .
/usr/local/Cellar/go/1.8.1_1/libexec/pkg/tool/darwin_amd64/link -o $WORK/command-line-arguments/_obj/exe/a.out -L $WORK -extld=clang -buildmode=exe -buildid=09e299344f906f0b167907ec8bcdd857d3794aa0 -linkmode external $WORK/command-line-arguments.a
mv $WORK/command-line-arguments/_obj/exe/a.out test

$ sudo /usr/local/opt/llvm/bin/lldb test
(lldb) target create "test"
Current executable set to 'test' (x86_64).
(lldb) b main.main
Breakpoint 1: where = test`main.main, address = 0x000000000404d060
(lldb) run
Process 5854 launched: '/Users/filippo/code/misc/rustgo/test' (x86_64)
foo
Process 5854 exited with status = 0 (0x00000000)
```

This appears to be a regression to #8973