sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: bootstrap overrides -O in CFLAGS for LLVM
Labels: A-LLVM,T-bootstrap,C-bug,requires-custom-config

At OpenBSD, for building lang/rust package, we switched from using standard LLVM version (3.9.1) to embedded LLVM version, in order to be able to update LLVM at 4.0.0.

The switch has a big performance impact: the build of rust passed from approx 2h (build with linking to external LLVM) to 12h (with 2h for building LLVM itself). And every program built with rustc had a similar performance impact (build time for cargo raise by a factor of 8).

I passed lot of time to found the issue (comparing source tree between stock LLVM-3.9.1 and `src/llvm`, reviewing cmake options and finally comparing compiler command-line). It appeared that LLVM embedded version is build without optimization (no `-O2` in `CFLAGS`).

As workaround, I removed the filter out of `-O` options from [bootstrap code](https://github.com/rust-lang/rust/blob/master/src/bootstrap/lib.rs#L821), and the build time come back to something more coherent: only 4h (with 2h for LLVM itself - so it is similar to what we had before).

In order to check the LLVM comand-line at compilation, I also added `cfg.define("CMAKE_VERBOSE_MAKEFILE", "ON");` to `src/bootstrap/native.rs`.

I dunno if the issue is only on OpenBSD or could be found on other platform. Maybe Linux adds some optimization by default on the compiler ? or it is LLVM that doesn't enable same optimizations set depending the platform ?
Repository: youtube-dl
Issue: [MDR] Support playlists
Labels: request

- [x] I've **verified** and **I assure** that I'm running youtube-dl **2017.02.17**
- [x] At least skimmed through [README](https://github.com/rg3/youtube-dl/blob/master/README.md) and **most notably** [FAQ](https://github.com/rg3/youtube-dl#faq) and [BUGS](https://github.com/rg3/youtube-dl#bugs) sections
- [x] [Searched](https://github.com/rg3/youtube-dl/search?type=Issues) the bugtracker for similar issues including closed ones
- [x] Bug report (encountered problems with youtube-dl)

- Single audio: http://www.mdr.de/kultur/videos-und-audios/audio-radio/operation-mindfuck-robert-wilson100.html
- Playlist: http://www.mdr.de/kultur/videos-und-audios/index.html

**description**
After recent changes on their site the download from MDR Radio is no longer working.

**log**
```
youtube-dl.exe -v http://www.mdr.de/kultur/videos-und-audios/audio-radio/operation-mindfuck-robert-wilson100.html
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'http://www.mdr.de/kultur/videos-und-audios/audio-radio/operation-mindfuck-robert-wilson100.html']
[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2017.02.17
[debug] Python version 3.4.4 - Windows-XP-5.1.2600-SP3
[debug] exe versions: ffmpeg N-67100-g6dc99fd, ffprobe N-67100-g6dc99fd, rtmpdump 2.4
[debug] Proxy map: {}
[generic] operation-mindfuck-robert-wilson100: Requesting header
WARNING: Falling back on generic information extractor.
[generic] operation-mindfuck-robert-wilson100: Downloading webpage
[generic] operation-mindfuck-robert-wilson100: Extracting information
ERROR: Unsupported URL: http://www.mdr.de/kultur/videos-und-audios/audio-radio/operation-mindfuck-robert-wilson100.html
Traceback (most recent call last):
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpqajgst4a\build\youtube_dl\YoutubeDL.py", line 696, in extract_info
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpqajgst4a\build\youtube_dl\extractor\common.py", line 369, in extract
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\rg3\tmpqajgst4a\build\youtube_dl\extractor\generic.py", line 2579, in _real_extractyoutube_dl.utils.UnsupportedError: Unsupported URL: http://www.mdr.de/kultur/videos-und-audios/audio-radio/operation-mindfuck-robert-wilson100.html
<end of log>
```
Repository: react
Issue: event.preventDefault in click handler does not prevent onChange from being called
Labels: Type: Bug,Component: DOM

**Do you want to request a *feature* or report a *bug*?**

Bug!

**What is the current behavior?**

When rendering an `input` element of type `checkbox` with an `onClick` and `onChange` handler, `onChange` is still called even though `event.preventDefault()` is called in the `onClick` handler.

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar (template: https://jsfiddle.net/reactjs/69z2wepo/).**

http://jsfiddle.net/rf3w7apc/

**What is the expected behavior?**

Calling `event.preventDefault` in the `onClick` handler should prevent the default action  from occurring (or undo its effect), which is to update the value of the `input` element. This should stop any `change` event listener from being invoked. See https://jsfiddle.net/L1eskzsq/ for expected behavior

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

Tested using a build from master, macOS 10.12.2, verified in:

* Chrome  56.0.2924.87 (64-bit)
* Firefox 51.0.1 (64-bit)

Safari 10.0.2 calls the `change` event listener in both cases.
Repository: go
Issue: cmd/objdump: implement all disassemblers
Labels: NeedsFix,compiler/runtime

Teach objdump how to disassemble all the supported architectures.
Tracking bug for all the architectures involved.  We're currently missing 4.

s390x: #15255
mips: #19158
mips64: #19156
~~arm64: #19157~~
Repository: rust
Issue: Linking with LLD
Labels: A-linkage,I-compiletime,T-compiler,C-feature-request

LLVM 4.0 is shipping with LLD enabled, though AFAIK it is not yet production-ready on all platforms. I believe we've got an LLVM upgrade planned soon to resolve AVR/emscripten problems anyway, so now's the time to start determining what we might need to do to support it, how it impacts compiler performance/binary size/runtime performance compared to our usual linkers, and what platforms on which we might want to enable it by default.

**Current status (2020-04-24) summarized at https://github.com/rust-lang/rust/issues/39915#issuecomment-618726211**

Possible problems:
* LLD has internal parallelism, and is not documented to have jobserver support, which can lead to poor contention resolution in practice
Repository: TypeScript
Issue: Unsafe type-incompatible assignments should not be allowed
Labels: Suggestion,Awaiting More Feedback

**TypeScript Version:**  2.1.6

**Code**

```ts
interface StringOnly {
  val: string;
}

interface StringOrNull {
  val: string | null;
}

const obj: StringOnly = { val: "str" };

// should not be allowed
const nullable: StringOrNull = obj;

nullable.val = null;

// obj is now in a bad state
```

**Expected behavior:**
The sample should not compile, as it's not safe.  Type casts/assertions should be required to override type incompatibility errors here.  (Or, of course, cloning the object itself `const nullable: StringOrNull = { ...str };`).

For comparison, Flow does _not_ allow the sample code.  

**Actual behavior:**
The sample compiles and further accesses of `str.val` will likely result in exceptions.

**EDIT**: Removed all references to `readonly`, as discussion of that modifier is overshadowing the issue.
Repository: go
Issue: cmd/compile: rewrite interface args by actual type args in functions called only with a single set of argument types
Labels: Performance,compiler/runtime

Sometimes programs use only a single set of interface implementations for every function call accepting interface args. In this case the compiler may safely rewrite such functions, so they'll accept actual type args instead of interface args.
This brings the following benefits:
- removal of interface conversion overhead;
- removal of interface method call overhead;
- reducing memory allocations, since escape analysis may leave variables on stack that is passed to interface functions;
- inlining short interface method calls and further optimizations based on the inlining.

The idea may be extended further. For instance, the compiler may generate specialized functions for each unique set of arg types passed to interface args (aka `"generic" functions` :)) . But naive implementation may lead to uncontrolled code bloat and performance degradation, so it must be carefully designed beforehand. One possible idea - specializing the function only if the following conditions are met:
- all the interface methods for the arg implementation may be inlined (i.e. may lead to performance optimizations);
- the function body is short (i.e. reducing generated code bloat).

This could inline and optimize `sort.Interface` implementations inside `sort.Sort` calls.
Repository: flutter
Issue: Restarting ballistics misses a frame
Labels: framework,a: fidelity,f: scrolling,a: quality,P2,team-framework,triaged-framework
Repository: kubernetes
Issue: Need pattern for updating controllers that works with extensions (TPR/Aggregated) 
Labels: area/extensibility,sig/apps,lifecycle/frozen



Users may also write their own controllers as extensions  -- Aggregated API Servers  (AASes) or Third Party Resources (TPRs).  

Controllers (core or extensions) may contain pod templates. 
Those podTemplates need to be updateable, and that should cause a rollout of the new desired state.

We already support rollouts for deployments by creating a new replicaSet each time we see an update to the controller.

There is [a proposal for how to do this for daemon sets](https://github.com/kubernetes/community/pull/366).  That may eventually use stand-alone pod templates (`/api/v1/podtemplates`).  As noted on that proposal by @janetkuo, the proposed pattern cannot be used by extensions.  

This issue summarizes some problems with extensions that want to have podTemplates.

- **Some Extensions cannot use `observedGeneration`**
  - `templateGeneration` is a field that updates every time the `.spec.podTemplate` of the controller is updated.  It happens in the API server.
  - AAS can support the `observedGeneration`.
  - TPR-based controller can not.
- **Extensions cannot use hashes to compare embedded and standalone pod templates**
  - Deployment computes a `pod-template-hash`.  One issue is that you can GET an object once before a master upgrade, and then GET it after, and it will be different, even though the object was not updated by the user.  This is because new defaulted fields can be added by the new version of the API server code.
  - If an AAS object includes a podTemplate in its controller Spec, then presumably it will have defaulting too.  But that will be vendored from Kubernetes, and so the version of the defaulting in the AAS may be different from the version in the Primary API Server.  
  - TPRs cannot have defaulting.  So they cannot compare their hashes (which are stable) with podTemplate hashes, which are not.
- **Extensions cannot use deep equality to compare embedded and standalone pod templates**
  - Same reasons as above. 

This makes it hard to build controllers that are extensions and have updating and pod templates.

Some things that would solve that problem:

1. If we never used embedded pod templates and just used standalone podTemplates.  So, you have to create at least two objects to make a controller.  But this works poorly with declarative config (apply).
2. If we never apply defaulting or conversion to embedded pod templates. Let that happen at pod creation time.  I like this.  It puts TPR and AAS and core controllers on the same footing.
3. If we figured out a way to generalize the `observedGeneration` pattern to work with TPRs.  

I like 2 but it looks like the most work.  @thockin pointed out that recent changes to defaulting make it difficult to make defaulting not happen in embedded pod templates.
Repository: rust
Issue: `#[deprecated]` does nothing if placed on an impl item.
Labels: A-lints,A-trait-system,T-compiler,C-bug,T-types,L-deprecated

Given the following two crates:

```rust
#![crate_name = "foo"]

pub struct Foo;
pub struct Bar;

pub trait IntoBar {
    fn into_bar(self) -> Bar;
}

#[deprecated(note = "Just pass `Bar` instead")]
impl IntoBar for Foo {
    fn into_bar(self) -> Bar {
        Bar
    }
}
```

```rust
extern crate foo;

use foo::*;

fn main() {
    let _ = Foo.into_bar();
}
```

I would expect the second crate to see a deprecation warning on the use of `Foo.into_bar()`. Instead, both crates compile successfully with no errors. I think that allowing deprecations on impls is a useful option to provide to authors (one that I was looking to do, and found this while seeing if it would work). However, if we do not wish to provide that ability to library authors, placing the `#[deprecated]` attribute on an impl should result in a compiler error.
Repository: go
Issue: x/build: auto-detect flakes
Labels: Builders,FeatureRequest

Request from @danp:

When the build system is idle, run builds of tip branches periodically (every 5 min?) to see if builds alternate between "ok" and "failed" state. Maybe auto-file flake bugs if test failures aren't consistent.
Repository: go
Issue: x/build/cmd/coordinator: write proper scheduler
Labels: Builders,NeedsInvestigation

Currently if there are N builds waiting on a buildlet type (due to lack of machines or quota), the current implementation is a bunch of goroutines fighting over a mutex.

It's random who wins and gets the buildlet.

We should have them register interest and when a buildlet becomes available, pick the highest priority one.

Example priorities in order:

* trybot run with a +2 already
* trybot run
* normal run of a build at tip of a release branch
* normal run of a build at tip of master branch
* normal run of a build at tip of dev branch
* normal run of a build not at tip
* idle flake detection (#19177)

etc.

/cc @danp @kevinburke
Repository: rust
Issue: Enum associated functions can name-clash with variants, but cannot be called.
Labels: A-lints,T-compiler,C-bug

### Description

It's currently possible to name a function associated to an enum identically to the name of one of its variants.

This function cannot be called (see below), but rather than warning at the point that the function is defined, the compiler only emits an error upon trying to call said function (and in some cases - see the 'Alternate Reproduction' - it doesn't even do that).

https://is.gd/EZQ9mL
```rust
#[derive(Debug)]
enum X {
    a
}
impl X {
    fn a() -> X {
        X::a
    }
}
fn main() {
    println!("{:?}", X::a())
}
```

yields:

```rust
rustc 1.15.1 (021bd294c 2017-02-08)
error: `X::a` is being called, but it is not a function
  --> <anon>:13:22
   |
13 |     println!("{:?}", X::a())
   |                      ^^^^^^
   |
   = help: did you mean to write `X::a`?
note: defined here
  --> <anon>:3:5
   |
3  |     a
   |     ^

error: aborting due to previous error
```

### Expected behaviour:

Emit an error at the point (`fn a() -> X`) that the function is defined.

### Alternate reproduction

Even more confusing is the code:

https://is.gd/S15gOw
```rust
#[derive(Debug)]
enum X {
    a(),
    b,
}

impl X {
    fn a() -> X {
        X::b
    }
}

fn main() {
    println!("{:?}", X::a())
}
```

This compiles and runs.
Any guesses whether the variant or the function wins? :smile:
Repository: rust
Issue: rustc --test should not check linking when using --emit=metadata or -Z no-trans
Labels: C-feature-request,A-libtest

Suppose I have a library configured with `panic = "abort"`:

```
$ cargo init --lib foo
$ cd foo
$ nano Cargo.toml
$ more Cargo.toml
[package]
name = "foo"
version = "0.1.0"
authors = ["Wilfred Hughes <me@wilfred.me.uk>"]

[dependencies]

[profile.dev]
panic = "abort"
```

I'm unable to build with with `--test`:

```
$ cargo rustc -- --test
   Compiling foo v0.1.0 (file:///home/wilfred/tmp/foo)
error: the linked panic runtime `panic_unwind` is not compiled with this crate's panic strategy `abort`

error: aborting due to previous error

error: Could not compile `foo`.

To learn more, run the command again with --verbose.
```

As discussed in https://github.com/rust-lang/cargo/issues/3166#issuecomment-252120541 this is because the test harness needs unwinding on panic.

However, I get the same error with `-Z no-trans`:

```
$ cargo rustc -- -Z no-trans --test 
   Compiling foo v0.1.0 (file:///home/wilfred/tmp/foo)
error: the linked panic runtime `panic_unwind` is not compiled with this crate's panic strategy `abort`

error: aborting due to previous error

error: Could not compile `foo`.

To learn more, run the command again with --verbose.
```

This causes problems in editor integration like https://github.com/flycheck/flycheck-rust/issues/47 . We want to pass `--test` as otherwise we don't get syntax checking on test files. However, we get the above error for projects with abort-on-panic.

Could we teach `--test` to ignore the runtime when we pass `-Z no-trans`?
Repository: rust
Issue: error[E0275]: overflow evaluating the requirement `_: std::marker::Sized`
Labels: A-diagnostics,T-compiler,C-bug

Reduced test case:

```rust
#![recursion_limit = "5"]

fn main() {}

trait Serialize {}

struct Ser<'a, T: 'a>(&'a T);

impl<'a, T> Ser<'a, T> where Ser<'a, T>: Serialize {
    pub fn new(value: &'a T) -> Self {
        Ser(value)
    }
}

impl<'a, T> Serialize for Ser<'a, Option<T>> where Ser<'a, T>: Serialize {}

fn serialize<'a, T>(value: &'a T) where Ser<'a, T>: Serialize {
    Ser::new(value);
}
```

Output in rustc 1.17.0-nightly (536a900c4 2017-02-17):

```rust
error[E0275]: overflow evaluating the requirement `_: std::marker::Sized`
  --> a.rs:20:5
   |
20 |     Ser::new(value);
   |     ^^^^^^^^
   |
   = note: consider adding a `#![recursion_limit="10"]` attribute to your crate
   = note: required because of the requirements on the impl of `Serialize` for `Ser<'_, std::option::Option<_>>`
   = note: required because of the requirements on the impl of `Serialize` for `Ser<'_, std::option::Option<std::option::Option<_>>>`
   = note: required because of the requirements on the impl of `Serialize` for `Ser<'_, std::option::Option<std::option::Option<std::option::Option<_>>>>`
   = note: required because of the requirements on the impl of `Serialize` for `Ser<'_, std::option::Option<std::option::Option<std::option::Option<std::option::Option<_>>>>>`
   = note: required because of the requirements on the impl of `Serialize` for `Ser<std::option::Option<std::option::Option<std::option::Option<std::option::Option<std::option::Option<_>>>>>>`

error: aborting due to previous error
```

Without `#![recursion_limit = "5"]`, the error message is similar but much larger. If this isn’t a bug, at least the diagnostic should be improved.
Repository: opencv
Issue: findCirclesGrid does not check circularity to detect blob
Labels: RFC

##### System information (version)
- OpenCV => 3.2(master)
- Operating System / Platform => Windows 10 Pro 64bit
- Compiler => Visual Studio 2015

##### Detailed description
* findCirclesGrid [uses SimpleBlobDetector](https://github.com/opencv/opencv/blob/3.2.0/modules/calib3d/include/opencv2/calib3d.hpp#L750) by default.
* filterByCircularity of  SimpleBlobDetector::Params is 'false' by default.
* As a result, findCirclesGrid does not check circularity to detect blob by default.

I think that this is a issue of findCirclesGrid.
Could you please give me your comment?

##### Steps to reproduce

 ```cpp
#include <opencv2/core.hpp>
#include <opencv2/imgproc.hpp>
#include <opencv2/calib3d.hpp>
#include <opencv2/imgcodecs.hpp>
#include <opencv2/highgui.hpp>

#include <vector>
#include <iostream>

//#define USE_CIRCULARITY

int main(int argc, char** argv)
{
    cv::Mat img = cv::imread("circles5.png", cv::IMREAD_COLOR);
    if (img.empty())
    {
        std::cerr << "could not load image." << std::endl;
        return -1;
    }

    cv::Size pat_size = cv::Size(7, 7);
    std::vector<cv::Point2f> points;

#ifdef USE_CIRCULARITY
    cv::SimpleBlobDetector::Params param;
    param.filterByCircularity = true;
    param.minCircularity = 0.8f;
    param.maxCircularity = 1.0f;
    cv::Ptr<cv::FeatureDetector> blobDetector = cv::SimpleBlobDetector::create(param);

    bool found = findCirclesGrid(img, pat_size, points, cv::CALIB_CB_SYMMETRIC_GRID | cv::CALIB_CB_CLUSTERING, blobDetector);
#else
    bool found = findCirclesGrid(img, pat_size, points, cv::CALIB_CB_SYMMETRIC_GRID | cv::CALIB_CB_CLUSTERING);
#endif

    std::cout << "findCirclesGrid: " << (found ? "Found" : "Not found") << "pattern" << std::endl;
    cv::drawChessboardCorners(img, pat_size, points, found);
    cv::imshow("img", img);
    cv::waitKey(0);

    return 0;
}
 ```
Repository: vscode
Issue: [Feature Request] Undo branches
Labels: feature-request,undo-redo

Undo branches / undo tree allows you to undo some changes,
then make a new change, while keeping all changes available in the undo tree.
The undo tree can therefore prevent awkward scenarios such as:
 * Losing all redo futures by accidentally pressing a button during undo
 * Copying the file or save it with git when trying multiple alternatives

This screen-cap showcases how it works in Emacs with undo-tree.

![wpid-undo-tree1](https://cloud.githubusercontent.com/assets/908496/23103901/811d0352-f6c3-11e6-8dfa-b8690faa034f.gif)

https://github.com/Zalastax/vscode/commit/c5699711d21dece88c7c608f6d8ae277f72a0081 contains the changes to the model that are needed, but several questions remain to be answered. I'm interested in completing the feature but need further input before proceeding.
* How should the UI look? Graphics / ASCII, clickable?
* Should the tree be formatted like in Emacs undo-tree (as short tree as possible) or like Vim's Gundo http://screenr.com/M9l (one state per line sorted by time)?
* What unit-tests should be added?

You can try out the current changes by compiling my fork and you'll find 'History Tree' in the Edit menu. Clicking the menu item will console.log a function that changes what redo future is selected (just like in the gif).
Repository: rust
Issue: making a temporary tuple for pattern matching tries to move borrowed content
Labels: A-diagnostics,A-borrow-checker,T-compiler

[playground link](https://is.gd/Bunuc0)

This works, even though it looks like it's moving out of shared pointers, because of the `ref` keyword:

```rust
fn works(foo_opt1: &Option<Foo>, foo_opt2: &Option<Foo>) {
    if let Some(ref foo1) = *foo_opt1 {
        if let Some(ref foo2) = *foo_opt2 {
            println!("this works")
        }
    }
}
```

However this very similar code does not work:

```rust
fn doesnt_work(foo_opt1: &Option<Foo>, foo_opt2: &Option<Foo>) {
    if let (Some(ref foo1), Some(ref foo2)) = (*foo_opt1, *foo_opt2) {
        println!("this does not compile!");
    }
}
```

We get this error:

```

   |
13 |     if let (Some(ref foo1), Some(ref foo2)) = (*foo_opt1, *foo_opt2) {
   |                                                ^^^^^^^^^ cannot move out of borrowed content
```

It looks like the temporary tuple created on the right is a moving operation that can't be "undone" by the `ref` keyword. Could the compiler be smarter about this, or would that be unsound somehow?
Repository: rust
Issue: Range* should overrride more methods of Iterator
Labels: I-slow,C-enhancement,T-libs-api

Like nth, last, count, max, min,... maybe even sum and product (using a direct formula).
Repository: go
Issue: gccgo: add AIX support
Labels: OS-AIX

### What version of Go are you using (`go version`)?
Snapshots from gcc SVN repository


### What operating system and processor architecture are you using (`go env`)?
AIX 6.1/7.2 on Power7/8


### What did you do?
We are currently porting gccgo to AIX. This issue will be used to submit and discuss our changes.