sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Can't extend intersection containing constructable type parameter
Labels: Bug

Lets say we have 2 mixins, like this:

```typescript
type Constructable<T = {}> = new (...args : any[]) => T

export const Mixin1 = <T extends Constructable>(base : T) =>

class Mixin1 extends base {
    method1() {
    }
}

export const Mixin2 = <T extends Constructable>(base : T) =>

class Mixin2 extends base {
    method2 () {
    }
}
```

Now we want to declare a `Mixin3` that already includes `Mixin2`:
- First of all this won't work
```typescript
export const Mixin3 = <T extends Constructable>(base : T) =>

class Mixin3 extends Mixin2(base) { // !!! typecheck error here

    method3 () {
    }
}
```
but this form will work
```typescript
export const Mixin3 = <T extends Constructable>(base : T) =>

class Mixin3 extends Mixin2<Constructable>(base) {
    method3 () {
    }
}
```
This is generally fine.

Now, we want to declare `Mixin4` which includes `Mixin3` and `Mixin1`:

```typescript
export const Mixin4 = <T extends Constructable>(base : T) =>

class Mixin4 extends Mixin3(Mixin1(base)) {

    method4 () {
        this.method1() // !!! this method is not "recognized"

        this.method2() // !!! this method is recognized
    }
}
```
Note, that for `Mixin4` the specification of the form `Mixin2<Constructable>` like we did for `Mixin3` is not needed.

It seems the nested application of the `Mixin1` in the declaration of `Mixin4` was not "picked up". Any help is greatly appreciated.

=======================================================================
All the code from above in one snippet:
```typescript
type Constructable<T = {}> = new (...args : any[]) => T

export const Mixin1 = <T extends Constructable>(base : T) =>

class Mixin1 extends base {
    method1() {
    }
}

export const Mixin2 = <T extends Constructable>(base : T) =>

class Mixin2 extends base {
    method2 () {
    }
}


export const Mixin3 = <T extends Constructable>(base : T) =>

class Mixin3 extends Mixin2<Constructable>(base) {
    method3 () {
    }
}


export const Mixin4 = <T extends Constructable>(base : T) =>

class Mixin4 extends Mixin3(Mixin1(base)) {
    method4 () {
        this.method1()

        this.method2()
    }
}
```
Repository: opencv
Issue: Implement HoughCircles mode without internal edge detection
Labels: feature,category: imgproc

Could you implement Hough transform mode without any edge detection for application to the images already containing circles?
Repository: react
Issue: Dangerous strings can reach browser builtins
Labels: Component: DOM,Type: Discussion

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**

A bug, but a well known and worked-around one.

**What is the current behavior?**

```jsx
var x = 'javascript:alert(1)';
ReactDOM.render(
  (<a href={x}>Link</a>),
  document.getElementById('container')
);
```

produces a link that alerts.


**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

* [Load the code above in the codepen REPL](https://jsfiddle.net/Luktwrdm/202/)
* After the REPL loads, click the "Run" button at the top left.
* You should see a blue "link" in the bottom-right pane.
* Click it.  An alert will popup.

The alert should not pop up.

A simple string that reaches an `href` attribute should not cause arbitrary code execution even with user interaction.


**What is the expected behavior?**
A string that reaches a browser builtin like the `HTMLAElement.prototype.href` setter should not cause code execution.

**Discussion**

[Polymer Resin](https://docs.google.com/presentation/d/1hepAXMroHSNTM0NV1aGlntjHrw0a0QOM5X5JvfXv_N0/edit#slide=id.g227691820f_0_198) uses hooks in another webcomponents framework to intercept value before they reach browser builtins where they can be vetted.  A similar approach could work for React.

It allows values to reach browser builtins when they are innocuous or have a runtime type that indicates that the author intentionally marked them as safe for that kind of browser builtin.

For example, an `instanceof SafeURL` would be allowed to reach `HTMLAElement.prototype.href` as would any string that is a relative URL, or one with a whitelisted protocol in (`http`, `https`, `mailto`, `tel`) but not `javascript:...`.

Many developers know that `<a href={...}>` is risky, but if the link is an implementation detail of a custom React element, then developers don't have the context to know which attributes they need to be careful with.  They shouldn't have to either since it is an implementation detail.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

I believe this is widespread across versions.

An earlier REPL I tried showed that it worked on version 16.2.0 from https://unpkg.com/react-dom/umd/react-dom.development.js but I don't know what version the jsfiddle above uses.
Repository: go
Issue: cmd/link: package versioning for shared libraries is incompatible with linkobj builds
Labels: NeedsFix,compiler/runtime

During linkobj builds, __.PKGDEF files are still included in the linker object files, but they're empty stub files that only contain information already present in the .o file, so I'm looking at getting rid of them in that case.

Working on cmd/link, I notice that genhash (used for generating package versions from the __.PKGDEF files for shared library builds) makes two assumptions that are incompatible with this:

1) They assume __.PKGDEF files are the first file in the .a. This is currently true because loadobjfile requires it to be the case, but won't be if we get rid of the __.PKGDEF files from linkobj files (as I intend to do).

2) In linkobj builds, the __.PKGDEF file is largely useless for versioning because it doesn't actually record anything about the package. So the versioning is broken.

My plan here is:

1) Near-term: change cmd/link to not require __.PKGDEF files for non-shared builds, change genhash to error if the archive is missing a __.PKGDEF file, and change cmd/compile to stop producing useless __.PKGDEF files in linkobj files.

   This means shared library, linkobj builds will now explicitly fail, whereas before they would work but be subtly incorrect due to useless package version files.

2) Intermediate-term: have cmd/compile compute the package version hash and include it directly in the link object, so that cmd/link doesn't need the __.PKGDEF at all.

/cc @ianlancetaylor @mwhudson
Repository: go
Issue: net/http: automatically add X-Content-Type-Options: nosniff
Labels: Proposal,Proposal-Hold

Some old browsers have an unfortunate mis-feature where they will detect and interpret HTML in responses that have different `Content-Type`. This is commonly referred to as content sniffing, and is a security risk when attacker-controlled content is served, leading to XSS.

The proposal is to automatically include the `X-Content-Type-Options: nosniff` header when `Content-Type` is one of the values known to trigger content sniffing: `text/plain`, `application/octet-stream`, `application/unknown`, `unknown/unknown`, `*/*` or an invalid value without a slash.

It doesn't solve all issues, for example plugins are still a problem, and even older browsers don't support it, but it's almost free and mitigates the issue in IE8, the most used affected browser (according to https://caniuse.com/usage-table, https://blogs.msdn.microsoft.com/ie/2008/07/02/ie8-security-part-v-comprehensive-protection/).

There should probably be a way to disable it for users that care about the header overhead and are unconcerned by content sniffing. Maybe setting it to an empty string? Is there precedent?

See also #13150

/cc @bradfitz @andybons @rsc
Repository: go
Issue: net: different lists of addresses are returned depending on order of multiple aliases in /etc/hosts on Mac OS with CGO
Labels: NeedsInvestigation

TL;DR - `net.LookupIP` may return a different list of addresses depending on the order of multiple names in an `/etc/hosts` mapping (e.g. `127.0.0.1	my.local localhost`). I don't know if this should be surprising or not; however, I did have a NATS client as well as [an official NATS sample client](https://github.com/nats-io/go-nats/blob/master/examples/nats-sub.go) malfunction on me, and I wondered what the problem might be.

### What version of Go are you using (`go version`)?

go version go1.10 darwin/amd64

### Does this issue reproduce with the latest release?

On latest.

### What operating system and processor architecture are you using (`go env`)?

darwin amd64

### What did you do?

* With the following test code:

```go
package main

import (
  "fmt"
  "net"
)

func main() {
  ips, _ := net.LookupIP("localhost")
  fmt.Printf("IPs: %v\n", ips)
}
```

* With the following `/etc/hosts`:

```
127.0.0.1	localhost my.local       # This line will be varied in the tests below
255.255.255.255	broadcasthost
::1             localhost
```

* Run the test program four times while varying 1) the resolver and 2) the order of `localhost` and `my.local` in `/etc/hosts`. (After changing `/etc/hosts`, run `sudo killall -HUP mDNSResponder`).

```
# localhost FIRST (`127.0.0.1 localhost my.local`) and pure GO resolver:
$ GODEBUG=netdns=go+1 go run junk.go
go package net: GODEBUG setting forcing use of Go's resolver
IPs: [::1 127.0.0.1]
```

```
# localhost FIRST (`127.0.0.1 localhost my.local`) and CGO resolver:
$ GODEBUG=netdns=1 go run junk.go
go package net: using cgo DNS resolver
IPs: [::1 127.0.0.1]
```

```
# localhost SECOND (`127.0.0.1 my.local localhost`) and pure GO resolver:
$ GODEBUG=netdns=go+1 go run junk.go
go package net: GODEBUG setting forcing use of Go's resolver
IPs: [::1 127.0.0.1]
```

```
# localhost SECOND (`127.0.0.1 my.local localhost`) and CGO resolver:
$ GODEBUG=netdns=1 go run junk.go
go package net: using cgo DNS resolver
IPs: [127.0.0.1]                # <---- This is the oddball; no IPv6 address
```

### What did you expect to see?

I expected the returned set of IPs to be the same in all four tests.

### What did you see instead?

The combination of `localhost`-last and `cgo` caused a different set of addresses to be resolved.
Repository: flutter
Issue: Clearer message when opening Android Studio before running flutter build/run
Labels: platform-android,tool,t: gradle,P2,team-android,triaged-android

Opening the gallery in Android Studio by importing the gradle file before `flutter build/run`ing first doesn't create a properly populated local.properties and throws an unclear Flutter SDK not found error in Android Studio.
Repository: TypeScript
Issue: esModuleInterop should work even when compiling to esnext modules
Labels: Suggestion,In Discussion,Domain: ES Modules

**TypeScript Version:**  2.7.2
**Search Terms:** esModuleInterop, esnext, modules, import, export, default

**Code**

With this type definition:

```ts
declare function fn(): void;
declare module "external" {
  export = fn;
}
```

Running with:

```
tsc --esModuleInterop --module esnext
```

Produces these errors when importing:

```ts
import fn1 from 'external';       // error TS1192: Module '"external"' has no default export.
import fn2 = require('external'); // error TS1202: Import assignment cannot be used when targeting ECMAScript modules.
```

But, if you use commonjs modules:

```
tsc --esModuleInterop --module commonjs
```

It works as expected (because of `--esModuleInterop`)

```ts
import fn1 from 'external';       // works
import fn2 = require('external'); // works
```

**Expected behavior:**

It is understandable that the type checker doesn't want to pretend the import is interop'd when it's not compiling in the helpers.

But if you've specified `--esModuleInterop` and `--module esnext` the assumption from the type checker should be that an external system is applying the interop. Otherwise why would you specify `--esModuleInterop`?

**Playground Link:** https://github.com/jamiebuilds/ts-bug
Repository: TypeScript
Issue: Experiment with trailing comma insertion text for object literal completions
Labels: Suggestion,Needs Proposal,Domain: Completion Lists

When I'm adding a new property in the middle of an object literal, there's nothing I love more than getting an immediate parse error and then having to add a comma after the body of a nested object literal/method declaration. It'd be nice to see if we can smooth out the experience here. Maybe we can have comma insertion text after these completions (provided the experience doesn't feel annoying).

![2d31b568-b367-4b01-b9fa-3a3e190e98b4](https://user-images.githubusercontent.com/972891/37860886-2099a532-2eec-11e8-867a-b619e68b784b.gif)
Repository: youtube-dl
Issue: Making lazy-extractors fails
Labels: cant-reproduce

I was trying to compile with lazy-extractors enabled and got  the following error:

```
$ make lazy-extractors 
/usr/bin/env python devscripts/make_lazy_extractors.py youtube_dl/extractor/lazy_extractors.py
WARNING: Lazy loading extractors is an experimental feature that may not always work
Traceback (most recent call last):
  File "devscripts/make_lazy_extractors.py", line 89, in <module>
    src = build_lazy_ie(ie, name)
  File "devscripts/make_lazy_extractors.py", line 57, in build_lazy_ie
    s += '\n' + getsource(ie.suitable)
  File "/usr/lib/python2.7/inspect.py", line 700, in getsource
    lines, lnum = getsourcelines(object)
  File "/usr/lib/python2.7/inspect.py", line 689, in getsourcelines
    lines, lnum = findsource(object)
  File "/usr/lib/python2.7/inspect.py", line 528, in findsource
    raise IOError('source code not available')
IOError: source code not available
Makefile:111: recipe for target 'youtube_dl/extractor/lazy_extractors.py' failed
make: *** [youtube_dl/extractor/lazy_extractors.py] Error 1
```
Repository: godot
Issue: Implement automatic cleanup of .godot/ folder items (.import/ in 3.x)
Labels: enhancement,topic:editor,confirmed,topic:import

**Godot version:**
Godot 3.0.2.stable.official

**Issue description:**
I really like Godot 3's new resource workflow with the .import files and .import folder.
I like that all the source files and settings can be kept in source control.

However, I don't like how Godot never deletes the .stex/.sample/.md5 files for deleted resources in the .import folder. It just feels like the .import folder is accumulating trash more and more until eventually I can't stand it anymore and decide to delete the whole folder and wait for a full re-import. It just bugs me and is something that kind of needs to be managed, when it's supposed to be something you can ignore.

Sometimes I'm also not sure if it affects the editor's knowledge of whether the actual file still exists. (Eg. it is using the .import cache but actually there is no resource file anymore) making me unsure if the image I see in the editor still actually exists. (But that is kind of a separate issue ... because currently even if I delete the resource file and the related .import folder files, the image in the editor is still there. I would expect it to disappear since the editor should know that the file doesn't exist anymore ... it even deleted the .import import settings file for it already! EDIT added as #17734)

It looks like the editor knows how to cleanup the .import import settings files that are in the res folder when the source resource is deleted. I would suggest also cleaning up the .stex/.sample/.md5 files in the .import folder at the same time.

**Steps to reproduce:**
* Delete or rename a resource file in the res folder using an external file explorer.
* Activate Godot
* Go back to external file explorer to see that the .import file next to the resource file has been deleted (this is good)
* Check inside the .import folder to see that the files related to that resource are still in there. (why not delete them too?)

Using the internal file manager actually results in the same thing when renaming. When deleting it does remove the imported resource but leaves the .md5 file.
Repository: rust
Issue: Long Compile Time (with Optimization) with Large Arrays (2-3 hours)
Labels: A-LLVM,I-compiletime,T-compiler,C-bug

## Summary

I have gotten very long compile time (2 hrs plus) when I tried to compile a code that has a large array inbuilt in the code when I turn optimization on. When the code is compiled without optimization, it has a acceptable compile time (10+ seconds).

The array contains 130,000 + strs.

## Details

I tried this code:

```
$ cargo build
   Compiling alliteration-gen v0.1.0 (file:///<REDACTED>)
    Finished dev [unoptimized + debuginfo] target(s) in 11.23 secs
$ cargo build --release
   Compiling alliteration-gen v0.1.0 (file:///<REDACTED>)
^C

```

I expected to see this happen: With the non-optimized code running in 11 seconds, the optimized one shouldn't take more than a few minutes.

Instead, this happened: When i waited for it to compile, it took 10039.81 secs (2 hrs 47 mins).

I replicated the problem again on a different Cargo project path and different machines and faced the same issue (didn't fully compile them as it would take very long. I waited for 5 minutes for each machine).

## Environment

Machines tested:

1. Ubuntu 16.04 (Dell XPS 9360 Intel i5-7200U; 8GB RAM)
2. Kali Linux 2018.01 (Old Laptop with i5)
3. Windows 10 with msvc (Desktop Intel i5 4570 3.2GHz; 8GB RAM)

Cargo project files attached. 
[nolib.zip](https://github.com/rust-lang/rust/files/1844460/nolib.zip)

## Meta

`rustc --version --verbose`:
rustc 1.22.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.22.1
LLVM version: 4.0

rustc 1.24.1
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.24.1
LLVM version: 4.0

rustc 1.24.1 (d3ae9a9e0 2018-02-27)
binary: rustc
commit-hash: d3ae9a9e08edf12de0ed82af57ba2a56c26496ea
commit-date: 2018-02-27
host: x86_64-pc-windows-msvc
release: 1.24.1
LLVM version: 4.0
Repository: flutter
Issue: Flutter analyze dives deep into the build/ tree
Labels: tool,c: performance,P2,team-tool,triaged-tool

Analyzer looks into the volatile build/ tree. In fact it steps into ANY not hidden
(dot) directory tree. This is time wasted at every invocation.

## Steps to Reproduce
```
% flutter create -a kotlin -i swift exapp ; cd exapp && flutter build
  # flutter build populates build with some 200MB+ /

% mkdir -p build/kotlin/live_examples/bundled/dartcode/

% echo 'noneSuchType x = 0;'> build/kotlin/live_examples/bundled/dartcode/fail.dart

% flutter analyze
Analyzing /testbed/flutter/exapp...
    error • Undefined class 'noneSuchType' at build/kotlin/live_examples/bundled/dartcode/fail.dart:1:1 • undefined_class
    1 issue found.
    (Ran in 14.6s)

```

## Logs
N/A

## Flutter Doctor
```
[✓] Flutter (Channel beta, v0.1.5, on Linux, locale pl_PL.utf8)
    • Flutter version 0.1.5 at /testbed/lib/flutter
    • Framework revision 3ea4d06340 (4 weeks ago), 2018-02-22 11:12:39 -0800
    • Engine revision ead227f118
    • Dart version 2.0.0-dev.28.0.flutter-0b4f01f759

[✓] Android toolchain - develop for Android devices (Android SDK 26.0.2)
    • Android SDK at /testbed/lib/Android/Sdk
    • Android NDK at /testbed/lib/Android/Sdk/ndk-bundle
    • Platform android-27, build-tools 26.0.2
    • ANDROID_HOME = /testbed/lib/Android/Sdk
    • Java binary at: /testbed/lib/Android/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)

[✓] Android Studio (version 3.0)
    • Android Studio at /testbed/lib/Android/android-studio
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)

[✓] Connected devices (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 6.0 (API 23) (emulator)

• No issues found!
```
Repository: rust
Issue: rustdoc exposes private use rebindings in the signature of public functions.
Labels: T-rustdoc,C-bug

Rust will document the `test` function the following code as taking a `ThisIsTotallyNotAnOption<String>` rather than a `Option<String>`. This is confusing at first glance because without looking at the source or actually following the link, there is no indication as to what the type actually is.

```rust
use std::option::{Option as ThisIsTotallyNotAnOption};
pub fn test(o: ThisIsTotallyNotAnOption<String>) { }
```
Repository: rust
Issue: rustdoc `[src]` link for modules goes to `mod x;` when the module is re-exported across crates
Labels: T-rustdoc,C-bug,A-cross-crate-reexports

When I click the master `[src]` link at https://doc.rust-lang.org/std/fmt/ I get taken to https://doc.rust-lang.org/src/alloc/lib.rs.html#178 which is a bit surprising.

I would have expected to be taken to something like https://doc.rust-lang.org/src/alloc/fmt.rs.html#11-567 which is the destination of the `[src]` link at https://doc.rust-lang.org/alloc/fmt/index.html
Repository: go
Issue: x/crypto/argon2: Add AVX2 implementation
Labels: NeedsDecision,Proposal-Crypto

This is a feature request for adding an AVX2 implementation of Argon2. Currently there is a generic / pure Go and an amd64 SSE4.1 implementation. 
An AVX2 implementation can improve performance about ~30 %. The AVX2 implementation requires Go 1.10 because of some instructions which are not supported by the assembler in earlier releases.

See also: google/fscrypt#82 

/cc @FiloSottile
Repository: rust
Issue: Windows: success of canonicalizing r"\" depends on whether set_current_dir has been called
Labels: O-windows,C-enhancement,T-libs-api,A-io

## Problem: sometimes `Path::new(r"\").canonicalize() fails

Note: apparently this isn't _necessarily_ [against the spec](https://stackoverflow.com/a/151875/1036670) (a better link to the windows spec would be nice)

> In Windows it's relative to what drive your current working directory is at the time. If your current directory is in the C drive then C:\ would be the root. If the current directory is the D drive then D:\ would be the root. There is no absolute root.

Regardless of whether it is against the spec or not, I think basing the "root location" off of the `current_dir` is a best practice. At the very least, having `canonicalize(r"\")` fail is unexpected.

## Full Report
I hit this problem during one of my tests for [path_abs](https://github.com/vitiral/path_abs). The way I handle it is thorny (and there is still a TODO hidden in there).

The below test _passes_ on windows (and linux obviously):
```
    if cfg!(windows) {
        let result = Path::new(r"\").canonicalize();
        assert!(result.is_ok(), "Should work before set_current_dir is called: {:?}", result);
    }
    let tmp = tempdir::TempDir::new("ex").unwrap();
    let tmp = tmp.path();
    let tmp_abs = PathArc::new(&tmp).canonicalize().unwrap();
    env::set_current_dir(&tmp_abs).unwrap();
    if cfg!(windows) {
        let result = Path::new(r"\").canonicalize();
        assert!(result.is_err());
        println!("Got ERR cananonicalizing root: {}", result.unwrap_err());
    }\
```

The way I handle this in `path_abs` is the following:
- If the first component is `Root`
- Get the `current_dir` and use it's root instead.

That code [is here](https://github.com/vitiral/path_abs/blob/e6b8b31a70f8e9d03bba3350b229fe9cb26feed6/src/arc.rs#L378) (it's messy and tied to resolving the absolute path in general).

# Rust Info
Running in Windows Appveyor: https://ci.appveyor.com/project/vitiral/path-abs
```
  stable installed - rustc 1.24.1 (d3ae9a9e0 2018-02-27)
```