sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Automatic `skipDefaultLibCheck` (and potentially `skipLibCheck`)
Labels: Suggestion,In Discussion,Domain: lib.d.ts,Domain: Performance

This issue is adapted from a work item discussed at #25658.

# Automatic `skipDefaultLibCheck`

`lib.d.ts` is a pretty big file, and it's only going to grow. Realistically, most people don't ever declare symbols that conflict with the global scope, so we made the `skipDefaultLibCheck` (and also the `skipLibCheck` flag) for faster compilations.

[We can suggest this flag to users](https://twitter.com/drosenwasser/status/1007721634193477632), but the truth is that it's not discoverable. It's also often misused, so I want to stop recommending it to people. 😄 

It'd be interesting to see if we can get the same results of `skipDefaultLibCheck` based on the code users have written. Any program that doesn't contribute a global augmentation, or a declaration in the global scope, doesn't really need to have `lib.d.ts` checked over again.

@mhegazy and I have discussed this, and it sounds like we have the necessary information after the type-checker undergoes symbol-merging. If no symbols ever get merged outside of lib files, we can make the assumption that `lib` files never need to get checked. But this requires knowing that all lib files have already had symbols merged up front before any other files the compiler is given.

## Open Questions

* Is the idea to only type-check symbols which have been merged? Or is it to fall back to the worst-case behavior of checking everything when *any* symbol has been merged across files?
  * If it's the only checking merged entities, does `declare class B extend A {}` need to be re-checked if `A` has ever been subsequently merged? How would we keep track of that information?
  * If it's falling back to the worst-case behavior, does this feature actually help anyone outside of the "Hello world" case?

## Cons

* It feels like there are certain interactions we may be overlooking - we will have to be careful about our assumptions in the compiler with this behavior in place.
* Users who edit `lib.d.ts` wouldn't see erroneous changes in a compiler (so we'd likely need a `forceDefaultLibCheck`).

## Pros

* Running with `skipDefaultLibCheck` removes anywhere between 400-700ms on my machine from a "Hello world" file, so we could expect the same here under this behavior.
* Only our team ever needs to run `forceDefaultLibCheck`, reducing the cost for all other TypeScript users.
Repository: rust
Issue: Naming associated type leads to incorrect lifetime errors
Labels: A-lifetimes,A-associated-items,T-compiler,C-bug

[playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=2d6a330fff6b07b13560649dadaf1cae)

This impl compiles:

```rust
unsafe impl<D> TrustedContainer for D
where
    D::Target: TrustedContainer,
    D: ops::Deref,
{
    type Item = <D::Target as TrustedContainer>::Item;

    unsafe fn get_unchecked<'a>(&self, i: usize) -> &Self::Item {
        <D::Target>::get_unchecked(self, i)
    }
}
```

while this this theoretically identical one doesn't:

```rust
unsafe impl<T: ?Sized, D> TrustedContainer for D
where
    T: TrustedContainer,
    D: ops::Deref<Target = T>,
{
    type Item = T::Item;

    unsafe fn get_unchecked(&self, i: usize) -> &Self::Item {
        T::get_unchecked(self, i)
    }
}
```

Type context:

```rust
pub unsafe trait TrustedContainer {
    type Item: ?Sized + TrustedItem<Self>;
    
    unsafe fn get_unchecked(&self, i: usize) -> &Self::Item;
}

pub unsafe trait TrustedItem<A: TrustedContainer<Item=Self> + ?Sized> {
    type Unit;
}

unsafe impl<T: ?Sized, Array: ?Sized, D> TrustedItem<D> for T
where
    T: TrustedItem<Array>,
    Array: TrustedContainer<Item = T>,
    D: ops::Deref<Target = Array> + TrustedContainer<Item = T>,
{
    type Unit = T::Unit;
}
```
Repository: go
Issue: x/crypto/ssh: "ssh: handshake failed: EOF" with 3des-cbc
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.5 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes.

### 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="/home/jae/.local/bin"
GOCACHE="/home/jae/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jae/projects/go/golib:/home/jae/projects/go/gotools:/home/jae/projects/go/mylib"
GOPROXY=""
GORACE=""
GOROOT="/home/jae/projects/go/goroot"
GOTMPDIR=""
GOTOOLDIR="/home/jae/projects/go/goroot/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jae/notes/developement/programming/go/examples/misc-tests/go.mod"
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-build225295978=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

I help maintain the github.com/pkg/sftp library and am helping a user with an ssh issue. They have an SFTP server that only supports some older ciphers, like 3des-cbc and they can't connect successfully. I've tried to simplify and reproduce their issue with some success. I've configured my local openssh server to only accept that cipher, with `Ciphers 3des-cbc` in the sshd_config and was able to connect to it with the openssh client with `ssh -c 3des-cbc localhost`. If I don't specify `-c 3des-cbc` on the command line it won't connect with a negotiation error. So everything seems good on that side.

I then try to connect with a simple program using x/crypto/ssh set to use that same cipher and get the error `ssh: handshake failed: EOF` and the openssh server spits out the following in the log.

```
May 15 20:41:26 XXX sshd[12686]: Bad packet length 1474871687. [preauth]
May 15 20:41:26 XXX sshd[12686]: ssh_dispatch_run_fatal: Connection from 127.0.0.1 port 53234: Connection corrupted [preauth]
```

My simple program to reproduce is..
```
package main

import (
	"fmt"
	"net"
	"os"

	"golang.org/x/crypto/ssh"
	"golang.org/x/crypto/ssh/agent"
)

func main() {
	sshagent, err := net.Dial("unix", os.Getenv("SSH_AUTH_SOCK"))
	if err != nil {
		panic(err)
	}
	signer := ssh.PublicKeysCallback(agent.NewClient(sshagent).Signers)

	sshConfig := &ssh.ClientConfig{
		User:            os.ExpandEnv("$USER"),
		Auth:            []ssh.AuthMethod{signer},
		HostKeyCallback: ssh.InsecureIgnoreHostKey(),
	}
	sshConfig.SetDefaults()
	sshConfig.Ciphers = []string{"3des-cbc"}

	_, err = ssh.Dial("tcp", "localhost:22", sshConfig)
	fmt.Printf("%v\n", err)
}
```

### What did you expect to see?
No error and have it connect.

### What did you see instead?
ssh: handshake failed: EOF

Thanks.
Repository: youtube-dl
Issue: [Site support request] Vudu.com - Free movies and TV shows
Labels: site-support-request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2019.05.11. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2019.05.11**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single video: https://www.vudu.com/content/movies/details/Storks/784456
- Single video: https://www.vudu.com/content/movies/play/311378/ADVERT_CONTENT
- Playlist: https://www.vudu.com/content/movies/details/I-Dream-of-Jeannie-Season-3/311376


## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

Vudu is a USA-only (geo-restricted) streaming platform that provides ad-supported movies and tv shows along with paid content, the site is geo restricted (even the login is geo restricted) but creating an account is free. Closed Captions/subtitles are provided as well.

From what I can gather the content is streamed using MPEG-DASH but I'm not sure if it is DRM protected. It probably is but I thought I'd ask anyway.
Repository: create-react-app
Issue: React npm start con't run and open the localhost:3000
Labels: issue: needs investigation

> app@0.1.0 start C:\Users\mohammad ahmad\Desktop\React Projects\app
> react-scripts start

Starting the development server...

events.js:174
      throw er; // Unhandled 'error' event
      ^

Error: spawn cmd ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:240:19)
    at onErrorNT (internal/child_process.js:415:16)
    at process._tickCallback (internal/process/next_tick.js:63:19)
Emitted 'error' event at:
    at Process.ChildProcess._handle.onexit (internal/child_process.js:246:12)
    at onErrorNT (internal/child_process.js:415:16)
    at process._tickCallback (internal/process/next_tick.js:63:19)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! app@0.1.0 start: `react-scripts start`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the app@0.1.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\mohammad ahmad\AppData\Roaming\npm-cache\_logs\2019-05-15T20_48_25_193Z-debug.log
Repository: svelte
Issue: afterUpdate docs should mention recursion protection
Labels: stale-bot,temp-stale,documentation

In src/internal/scheduler.js, `flush()` protects against recursion caused by `afterUpdate` with its `seen_callbacks` variable.

This may lead to surprising behaviour, if the user depends on multiple but finite invocations of their `afterUpdate` callback, so it should be documented.
Repository: TypeScript
Issue: const TemplateStringsArray for TaggedTemplateExpression
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

TemplateStringsArray, TaggedTemplateExpression

## Suggestion

<!-- A summary of what you'd like to see added or changed -->

There shouldn't be a type `TemplateStringsArray`, it should be a `const string tuple type`, so we can write code:

```ts
interface SQL<TSA, VS> {
  texts: TSA;
  values: VS;
}

function sql<TSA extends readonly string[], VS extends any[]>(texts:TSA, ...values: VS): SQL<TSA, VS> {
  return { texts, values };
}

// then
let s: SQL<['select * from person where a=', ' and b=', ''], [number, Date]> = sql`select * from person where a=${1} and b=${new Date()}`;
```


## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->
Just like in the above code, we can test the sql at compile time or use a TypeScript Language Service Plugin *(in fact, I'm writing it[ts-sql-plugin](https://github.com/xialvjun/ts-sql-plugin) and then come across this problem)*.

## Examples

<!-- Show how this would be used and what the behavior would be -->

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

There is another issue is alike. https://github.com/microsoft/TypeScript/issues/16552#issuecomment-492919476

Besides, `TemplateStringsArray` is `ReadonlyArray<string>`, it should be const anyway.
Repository: pytorch
Issue: NVRTC_ERROR unknown when using self-built libtorch
Labels: module: build,triaged

Hi, I am doing inference with my own GPU model. When i use the released nightly version of libtorch from official website, there is no issue. Then I build libtorch from the same version of pytorch source and use the self-built version of libtorch to do inference, it shows the following error:

pytorch/torch/csrc/jit/fuser/cuda/fused_kernel.cpp:196: NVRTC_ERROR unknown:
operation failed in interpreter:
:
operation failed in interpreter:

Aborted (core dumped)

For some reasons I have to build libtorch from source, but seems the flags i use to build libtorch are not the same as the official ones used to build nightly version. Anyone know how the nightly version of libtorch is built and what are the flags used to build?  Thanks a lot!. 

The following is my local environment:
Linux16.04;
CUDA 9;
libtorch nightly verison: May 13, 2019
Repository: vue-element-admin
Issue: 开启Fixed Header，打开el-dialog后的Navbar样式问题
Labels: enhancement :star:

## Bug report（问题描述）

#### Steps to reproduce（问题复现步骤）
1. 开启Fixed Header
2. 打开el-dialog

#### Screenshot or Gif（截图或动态图）
![WechatIMG173](https://user-images.githubusercontent.com/1300315/57836447-4e8afa80-77f3-11e9-8819-7ad1f37a3054.jpeg)

#### Link to minimal reproduction（最小可在线还原demo）
https://panjiachen.github.io/vue-element-admin/#/table/complex-table
Repository: go
Issue: crypto/tls: make it clear that implementation is compliant with RFC 5246
Labels: Documentation,NeedsFix

In #31933, @swanandt  pointed out that the following note at the top of the [crypto/tls package](https://golang.org/pkg/crypto/tls/):

> Package tls **partially implements** TLS 1.2, as specified in RFC 5246

may be misinterpreted as a warning about non-compliance with the RFC 5246. This is not the case, as @FiloSottile explained:

> As far as I know, we implement everything that is REQUIRED by RFC 5246, so we are in full compliance with it.

It may be useful to slightly change the wording of the doc to make it completely clear the only *optional* features (like DHE, topic of the discussion at #31933) are currently not implemented, and so the package is fully compliant with RFC 5246.
Repository: PowerToys
Issue: 'Show desktop' button, option to minimize per monitor
Labels: Idea-New PowerToy

When clicking the 'Show desktop' button, all windows are minimized across all monitors. It would be nice to have the option to only show the desktop on that specific monitor and keep windows on other monitors untouched.
Repository: flutter
Issue: BackdropFilter performance issue
Labels: framework,engine,c: performance,customer: crowd,a: images,has reproducible steps,P2,team-engine,triaged-engine,found in release: 3.19,found in release: 3.20

Hi, I'm using a BackdropFilter widget as a cell background in a list.

But this widget totally cripples the application, the performances are very bad and the UI lags very much.

This is my custom widget:

```dart
class FrostedBox extends StatelessWidget {

  final Widget child;
  final double sigmaY;
  final double sigmaX;
  final Color _color = AppColors.whiteText.withOpacity(0.1);


  FrostedBox({@required this.child, this.sigmaX = 8, this.sigmaY = 8});

  @override
  Widget build(BuildContext context) {
    return Stack(
      children: <Widget>[
        ClipRect(
            child: BackdropFilter(
              filter: ImageFilter.blur(sigmaX: this.sigmaX, sigmaY: this.sigmaY),
              child: new Container(
                  decoration: new BoxDecoration(
                      color: _color
                  )
              ),
            )
        ),
        this.child
      ],
    );
  }
}
```

It seems that the BackdropFilter constantly repaints itself. I've tried to use a stack to reduce the amount of things it rebuilds, but still, the lag is very high.

I think that the problem is that every time I scroll the list, the blur effect on the single cell it's rebuilded costing a lot of performances

Any tip? Am'I using the wrong widget?
Repository: TypeScript
Issue: [3.5.0-dev.20190516] Incorrect type error for mixin
Labels: Bug,Fix Available

When using the [mixin pattern](https://www.bryntum.com/blog/the-mixin-pattern-in-typescript-all-you-need-to-know/), there are 2 main notations to define the type of the mixin entity.
The mixin pattern:
```ts
export type AnyFunction<A = any>        = (...input : any[]) => A
export type AnyConstructor<A = object>  = new (...input : any[]) => A
export type Mixin<T extends AnyFunction> = InstanceType<ReturnType<T>>

export const Box = <T extends AnyConstructor<object>>(base : T) =>
class Box extends base {
    value       : any
}
```
1st notation:
```ts
export type Box = Mixin<typeof Box> {}
```
2nd notation:
```ts
export interface Box extends Mixin<typeof Box> {}
```
The 1st notation can not be used for recursive definitions (#29872). Because of that we primarily use 2nd notation. It works fine in most cases, however I found a case, when it produces invalid type error. The full snippet to reproduce the problem below.

Note:
-  The typechecker correctly figures out that there's no `zxc` property on `this`, inside the `observe` method of `Quark` mixin. 
-  In that method, it does not complain about the `this.value` usage
- It does complain, when `value` is used on function argument
- If you'll switch the `Quark` mixin to the 1st notation, the error will disappear

Expected behavior:
- No type errors for the definition of `test` function below

```ts
export type AnyFunction<A = any>        = (...input : any[]) => A
export type AnyConstructor<A = object>  = new (...input : any[]) => A
export type Mixin<T extends AnyFunction> = InstanceType<ReturnType<T>>

export const Box = <T extends AnyConstructor<object>>(base : T) =>
class Box extends base {
    value       : any
}
export interface Box extends Mixin<typeof Box> {}

export const Observable = <T extends AnyConstructor<object>>(base : T) =>
class Observable extends base {
    observe () : Quark {
        return
    }
}
export interface Observable extends Mixin<typeof Observable> {}

export const Quark = <T extends AnyConstructor<Box & Observable>>(base : T) =>
class Quark extends base {

    observe () : Quark {
        // No error here!
        this.value
        
        // error: Error:(28, 14) TS2339: Property 'zxc' does not exist on type 'Quark'.
        this.zxc
        
        return
    }
}
export interface Quark extends Mixin<typeof Quark> {}

const test = (a : Quark) => a.value // <-- Error:(35, 28) TS2339: Property 'value' does not exist on type 'Quark'.
```
Repository: rust
Issue: Should Thumb bugs get increased visibility, e.g. Tier 1 status?
Labels: O-Arm,I-needs-decision,T-lang,T-compiler,T-infra,WG-embedded

Spawned off of discussion here: https://github.com/rust-lang/rust/pull/58605#issuecomment-484929150

Do we need to explicitly revise stuff in our tagging/tests/release processes to try to decrease risk of Thumb bugs?

Namely these two points: 

> we may want to expand the number of items tested in the thumb-* tests contained in https://github.com/rust-lang/rust/tree/master/src/test/run-make

and:

> There was a discussion at the 2018 all hands about making the thumb targets tier 1, however this was not done as @alexchrichton mentioned that the concept of tiers was going away, or was being retooled.
> 
> If not, I'd like to reintroduce the discussion of making the thumb targets an official tier one target, as it already has some of the ground work laid to claim this
Repository: go
Issue: x/tools/cmd/goimports: does not find import with package in vendor/, GOFLAGS="-mod=vendor" and empty $GOPATH/pkg directory
Labels: NeedsInvestigation,modules,Tools

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12.4
</pre>

goimports from from https://github.com/golang/tools, commit `d1a3278ee74994e9aa609e9e711c616bba677d5d`


### Does this issue reproduce with the latest release?
Yes, reproducible with go 1.12.5



### What operating system and processor architecture are you using (`go env`)?

```
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/fho/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/fho/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="/tmp/testproject/go.mod"
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-build188015067=/tmp/go-build -gno-record-gcc-switches"
```


### What did you do?
1. Create a new golang project using go.mod.
The project has a a `main.go` file that imports the external dependency `github.com/lib/pq`.
The external modules are downloaded into `vendor/` via `go mod vendor`.

```
mkdir -p /tmp/testproject
cd /tmp/testproject
go mod init "testproject"
echo 'package main

import (
	"fmt"
	"github.com/lib/pq"
)

func main() {
	var test pq.StringArray

	fmt.Println(test)
}' > main.go
go mod vendor
```
2. Remove the `"github.com/lib/pq"` import from main.go:
```
sed -i '/"github.com\/lib\/pq"/D' main.go
```
3. Remove `$GOPATH/pkg`, run goimports with `GOFLAGS=-mod=vendor`:
```
sudo rm -rf $(go env GOPATH)/pkg
GOFLAGS="-mod=vendor" goimports -d main.go
```



### What did you expect to see?
goimports detects the missing `github.com/lib/pq` import and shows it in the diff.


### What did you see instead?
goimports  **does not** find the missing `github.com/lib/pg` import and prints no diff.