sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: runtime/pprof: add new WithLabels* function that requires fewer allocations
Labels: Proposal,Proposal-Hold

`runtime/pprof.Labels` is used in conjunction with `runtime/pprof.WithLabels` to set pprof labels in a context for performance profiling.
https://github.com/golang/go/blob/c485506b0aae298652448e80fca35036bfa755ac/src/runtime/pprof/label.go#L59

Adding information for fine grained on demand profiling of already running binaries should idealy be very efficient so it can always stay enabled with minimal overhead. The current API could be made more efficient by requiring fewer heap allocations. Pprof information sourced from contexts added by census frameworks is used in large go deployments on every RPC request and thereby small performance gains add up to a larger resource saving across many servers.

The current `runtime/pprof` API requires census frameworks such as OpenCensus to first convert their internal representation of key and value tag pairs (in a slice or map) to a slice of strings for input to `runtime/pprof.Labels`.

https://github.com/census-instrumentation/opencensus-go/blob/df6e2001952312404b06f5f6f03fcb4aec1648e5/tag/profile_19.go#L24

This requires at least one heap allocation for a variable amount of labels. Then internaly the `Labels` functions constructs a `LabelSet` data structure which requires another allocation (the case where this uses more than one allocation will be improved with [cl/181517](https://go-review.googlesource.com/c/go/+/181517) ). All in all this makes two heap allocations per context creation with pprof labels which can potentially be avoided.

I propose to extend `runtime/pprof` to have an API that takes e.g. a mapping/iteration interface such that census frameworks can implement that interface on their internal tag representations (e.g. maps and slices with custom types) and `runtime/pprof` can then source the labels to be set in a new `runtime/pprof.WithLabels*` function without first requiring conversion between multiple internal and external data structures.

[cl/188499](https://go-review.googlesource.com/c/go/+/188499) is a quick prototype as an example how this could look like. Different other ways of making an interface that can be used are possible to reduce allocations. Note that the LabelSet struct cant be changed to an interface itself (which seems the cleaner approach) due being not API backwards compatible.

/cc @aclements @randall77 @matloob
Repository: rust
Issue: Types in error message are incorrect when saying what trait is not implemented
Labels: A-type-system,C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics,T-types

When trying to implement Product for a newtype the error messages saying what I should implement was incorrect.

I tried this code:
```rust
struct MyInt(i32);

impl<__RhsT> ::core::ops::Mul<__RhsT> for MyInt
where
    i32: ::core::ops::Mul<__RhsT, Output = i32>,
{
    type Output = MyInt;
    #[inline]
    fn mul(self, rhs: __RhsT) -> MyInt {
        MyInt(self.0.mul(rhs))
    }
}

impl ::std::iter::Product for MyInt {
    #[inline]
    fn product<I: ::core::iter::Iterator<Item = Self>>(iter: I) -> Self {
        iter.fold(
            MyInt(::core::iter::empty::<i32>().product()),
            ::core::ops::Mul::mul,
        )
    }
}
```

I expected to see this happen:

It complain that there's no Mul implemented for `MyInt * MyInt`

Instead, this happened: It complained about not being able to multiply `i32 * MyInt`
```
error[E0277]: cannot multiply `MyInt` to `i32`
  --> tests/lib.rs:17:14
   |
17 |         iter.fold(
   |              ^^^^ no implementation for `i32 * MyInt`
   |
   = help: the trait `std::ops::Mul<MyInt>` is not implemented for `i32`
   = note: required because of the requirements on the impl of `std::ops::Mul` for `MyInt`

error[E0277]: cannot multiply `MyInt` to `i32`
  --> tests/lib.rs:19:13
   |
19 |             ::core::ops::Mul::mul,
   |             ^^^^^^^^^^^^^^^^^^^^^ no implementation for `i32 * MyInt`
   |
   = help: the trait `std::ops::Mul<MyInt>` is not implemented for `i32`
   = note: required because of the requirements on the impl of `std::ops::Mul` for `MyInt`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0277`.
error: Could not compile `derive_more`.
```

## The weird part
The correct error message is shown when you remove the unrelated Mul implementation.
```rust
struct MyInt(i32);

impl ::std::iter::Product for MyInt {
    #[inline]
    fn product<I: ::core::iter::Iterator<Item = Self>>(iter: I) -> Self {
        iter.fold(
            MyInt(::core::iter::empty::<i32>().product()),
            ::core::ops::Mul::mul,
        )
    }
}
```

## Meta

`rustc --version --verbose`:
rustc 1.36.0 (a53f9df32 2019-07-03)
binary: rustc
commit-hash: a53f9df32fbb0b5f4382caaad8f1a46f36ea887c
commit-date: 2019-07-03
host: x86_64-unknown-linux-gnu
release: 1.36.0
LLVM version: 8.0
Repository: pytorch
Issue: Doesn't install the python module "torch"
Labels: module: build,triaged

I've built the FreeBSD package, here is the log: https://people.freebsd.org/~yuri/py36-pytorch-1.2.0.log

However, it didn't install the "torch" module, see the plist: https://people.freebsd.org/~yuri/py36-pytorch-1.2.0-plist.txt

The shar archive of the FreeBSD port: https://people.freebsd.org/~yuri/py-pytorch.shar

What could be wrong?
Repository: rust
Issue: Redundant semicolons are parsed as an empty tuple semicolon statement
Labels: A-parser,T-compiler,C-bug

```rust
fn foo() {
    let _ = 3;;;;
}
```

Given the above example, the rustc parser used to silently drop the redundant semicolons (`;;;`)  from the AST. However, recently the parse has changed how it treats the redundant semicolons - they are now parsed as a semicolon statement with an empty tuple:

```rust
Stmt {
    node: StmtKind::Semi(Expr {
        node: ExprKind::Tup(vec![]),
        ..
    }),
    ..
}
```

Found this while updating rustc-ap-syntax to 562.0.0 (which is built from the commit fc8765d6d8623b2b5b4ca1d526ed1d7beb3fce18) in rustfmt.
Repository: rust
Issue: Warn about non-printable characters in string literals
Labels: C-enhancement,A-lints,A-diagnostics,A-parser,T-lang,T-compiler,E-medium

Currently a string literal with control characters like `\0` or `\v` is accepted without any warnings. The only exception is `\r`, which gives a hard error.

It makes more sense to treat all non-[printable](https://en.wikipedia.org/wiki/ASCII#Printable_characters), non \t, \n ASCII characters as a warning. 

Steps to fix:

1. Add  `NonPrintableAsii` to [EscapeError](https://github.com/rust-lang/rust/blob/ef1ecbefb8719e408150738664d443a73f757ffd/src/librustc_lexer/src/unescape.rs#L11)
2. Produce this error somewhere around [here](https://github.com/rust-lang/rust/blob/ef1ecbefb8719e408150738664d443a73f757ffd/src/librustc_lexer/src/unescape.rs#L135-L137)
3. Add lexer-level [tests](https://github.com/rust-lang/rust/blob/ef1ecbefb8719e408150738664d443a73f757ffd/src/librustc_lexer/src/unescape/tests.rs)
4. Handle this "error" in [`unespcape_error_reporting`](https://github.com/rust-lang/rust/blob/ef1ecbefb8719e408150738664d443a73f757ffd/src/libsyntax/parse/unescape_error_reporting.rs#L38). Note that, unlike other real errors, this one should be just a warning.
5. Adjust the affected ui tests

I am not sure how to make this warning work with `#[allow]` lint infrastructure: we definitely can't do this in the lexer.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: youtube-dl
Issue: Viki old subtitles sync
Labels: subtitles,geo-restricted

<!--

######################################################################
  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.08.13. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Search the bugtracker for similar site feature 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 site feature request
- [x] I've verified that I'm running youtube-dl version **2019.08.13**
- [x] I've searched the bugtracker for similar site feature requests including closed ones


## Description

<!--
Provide an explanation of your site feature request in an arbitrary form. Please make sure the description is worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient. Provide any additional information, suggested solution and as much context and examples as possible.
-->
Some shows of the site viki had updated their subs link sometime back because the original subs weren't synced properly, Some example shows being Dream High and Pinocchio.

For example:- 

[https://www.viki.com/videos/91001v-dream-high-episode-1](url) this episode uses subtitle from the link [https://api.viki.io/v4/videos/91001v/subtitles/en.vtt?app=100000a&sig=8b1dd0339766408903c35af2f6cd1f4184af187c&stream_id=78495332&t=1566130938&token=kQ_BXDV5TLSHhRI9rKVRQmPru0024185034uti00j8h5lU000_01x](url)

but the one which gets downloaded is the other one.. included in the zip are both the files the one with correct in its name is the proper one.. when comparing you can see the difference in timestamps
[Dream High - 1x01 - Episode 1.en.forced.zip](https://github.com/ytdl-org/youtube-dl/files/3513013/Dream.High.-.1x01.-.Episode.1.en.forced.zip)
Repository: go
Issue: x/crypto/scrypt: implementation not compliant with RFC 7914?
Labels: ExpertNeeded,NeedsInvestigation

See: https://tools.ietf.org/html/rfc7914. In particular, [Section 2: scrypt Parameters](https://tools.ietf.org/html/rfc7914#section-2):

> The CPU/Memory cost parameter N ("costParameter") must be larger than 1, a power of 2, and less than 2^(128 * r / 8).  The parallelization parameter p ("parallelizationParameter") is a positive integer less than or equal to ((2^32-1) * 32) / (128 * r).

Compare with: https://github.com/golang/crypto/blob/master/scrypt/scrypt.go#L200.

That is, it doesn't enforce `N < 2^(128 * r / 8)` as far as I can tell (I'm not fluent in Go). In the [Go playground](https://play.golang.org/p/M927ae0ZcQJ) I find that `N`'s upper limit when `r` is `1` is `16777215` such that `N=262144`, `r=1`, `p=8` won't cause scrypt to choke even though it should per the RFC.

Context: https://github.com/ethereum/go-ethereum/issues/19977.
Repository: youtube-dl
Issue: Download from medici.tv as logged in user account
Labels: question

<!--

######################################################################
  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:
- Look through the README (http://yt-dl.org/readme) and FAQ (http://yt-dl.org/faq) for similar questions
- Search the bugtracker for similar questions: http://yt-dl.org/search-issues
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm asking a question
- [x] I've looked through the README and FAQ for similar questions
- [x ] I've searched the bugtracker for similar questions including closed ones


## Question

<!--
Ask your question in an arbitrary form. Please make sure it's worded well enough to be understood, see https://github.com/ytdl-org/youtube-dl#is-the-description-of-the-issue-itself-sufficient.
-->
I tried to download a video from medici.tv. The trailer video can be downloaded without any problem with youtube-dl. But I tried to download the whole video - so I logged in in my account.

With youtube-dl I gave -u USERNAME and -p PASSWORD as well. But there is still only the trailer video which is downloaded. It seems that trailer and whole video have the same URL.

Thanks.
Repository: flutter
Issue: AnimatedIcon textDirection has no affect on icon directionality
Labels: framework,f: material design,a: quality,a: typography,has reproducible steps,P2,found in release: 3.7,found in release: 3.10,team-design,triaged-design

i just set textDirection to TextDirection.rtl but this makes no difference when setting to TextDirection.ltr .
flutter doctor -v:
```
[✓] Flutter (Channel stable, v1.7.8+hotfix.4, on Linux, locale en_US.UTF-8)
    • Flutter version 1.7.8+hotfix.4 at /home/abed/.local/flutter
    • Framework revision 20e59316b8 (4 weeks ago), 2019-07-18 20:04:33 -0700
    • Engine revision fee001c93f
    • Dart version 2.4.0

 
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /home/abed/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: /usr/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_212-8u212-b03-0ubuntu1.18.04.1-b03)
    • All Android licenses accepted.

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/setup/#android-setup for detailed instructions).

[✓] IntelliJ IDEA Community Edition (version 2019.2)
    • IntelliJ at /opt/idea-IC
    • Flutter plugin version 38.2.4
    • Dart plugin version 192.6459

[✓] VS Code (version 1.36.1)
    • VS Code at /usr/share/code
    • Flutter extension version 3.2.0

[✓] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 9 (API 28) (emulator)

! Doctor found issues in 1 category.

```
Repository: react
Issue: Refactor ProfilerContext to use reducer instead of multi-state
Labels: Type: Enhancement,Component: Developer Tools,React Core Team

The `ProfilerContext` is currently comprised of several pieces of related state, each managed with `useState`. This necessitates awkward checks like [this](https://github.com/bvaughn/react-devtools-experimental/blob/4697f5b37967b85b2c844044aeebb5b1a740875d/src/devtools/views/Profiler/ProfilerContext.js#L126-L131) or even worse like [this](https://github.com/bvaughn/react-devtools-experimental/blob/4697f5b37967b85b2c844044aeebb5b1a740875d/src/devtools/views/Profiler/SnapshotSelector.js#L62-L73) or [this](https://github.com/bvaughn/react-devtools-experimental/blob/source/src/devtools/views/Profiler/Profiler.js#L71-L83).

This context should be refactored to use a single reducer (`useReducer`) like `TreeContext`. This is a bit more involved at the moment because of suspense and the `ProfilerContext` being higher level than the suspense cache. Although maybe we could work around this by using some sort of [subscription](https://github.com/bvaughn/react-devtools-experimental/blob/4697f5b37967b85b2c844044aeebb5b1a740875d/src/devtools/views/Profiler/ProfilerContext.js#L118-L124)?

See related issues like #16441 and commit [4697f5b](https://github.com/bvaughn/react-devtools-experimental/commit/4697f5b37967b85b2c844044aeebb5b1a740875d).
Repository: godot
Issue: Path3D Curve's points and control points are indistinguishable
Labels: enhancement,topic:editor,usability,topic:3d

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.1.1 stable
<!-- Specify commit hash if non-official. -->

**Issue description:**
In the editor, the points in a curve and their respective control points(handles) are very similar (ie: both are orange circles with white border). After adding a lot of points, it's very difficult to identify the exact path without zooming in and out. If the level has a lot of props it's very difficult to trace path.

Any possible differentiation between those points(actual and control) would be helpful:
1) Color
2) Border/Outline
3) Shape

eg: Inkscape uses shapes to distinguish (and colors for indicating active selection).
<!-- What happened, and what was expected. -->

**Screenshot:**
![GodotPathNodeIssue](https://user-images.githubusercontent.com/26964275/63226870-85f7b180-c1fd-11e9-8a5e-9e2a8cda748a.PNG)


**Steps to reproduce:**
1. Open a project
2. In a 3D scene add a Path node and add a lot of points to it
3. Try dragging control points out from many points(left-click & drag from a point by pressing Shift key)
4. Then try to distinguish the actual points from the control points

**Minimal reproduction project:**
[PathCurveIssue.zip](https://github.com/godotengine/godot/files/3513213/PathCurveIssue.zip)

<!-- Recommended as it greatly speeds up debugging. Drag and drop a zip archive to upload it. -->
Repository: godot
Issue: Using `HashMap::get` with a null value crashes the engine when the key type is `const char *`
Labels: bug,topic:core,confirmed,crash

Godot 3.2 master

It crashes because it then uses `hash_djb2`, which doesn't check for `NULL`.
https://github.com/godotengine/godot/blob/ef37f00525643e391e19b79f84fc6fd15762b3be/core/hashfuncs.h#L50-L60
Repository: godot
Issue: FileAccessMemory::eof_reached() is likely off by one
Labels: bug,topic:core,confirmed

Godot 3.2 master

Found out `eof_reached` is implemented this way in `FileAccessMemory`:
https://github.com/godotengine/godot/blob/ef37f00525643e391e19b79f84fc6fd15762b3be/core/io/file_access_memory.cpp#L136-L139

Which is off by one. EOF should trigger at `length`, not one after `length`.
It is further confirmed by this other function, which does check `index == length`:

https://github.com/godotengine/godot/blob/ef37f00525643e391e19b79f84fc6fd15762b3be/core/io/file_access_memory.cpp#L169-L172

This didn't cause any bug yet because this class isn't used much and luckily mostly used with `get_line()`, which checks string null-termination and then doesn't hit buffer overrun.
Repository: rust
Issue: Transition rustc Parser to proc_macro token model
Labels: C-cleanup,A-parser,T-compiler

Currently, there are two different approaches for dealing with composite tokens like `>>` in rustc.

1. Keep tokens in composed form, and split into pieces, `>` and `>`, when necessary.
2. Keep tokens decomposed, with jointness information, and join tokens when necessary.

At the moment, the first approach is used by the parser, and the second approach is used by the proc_macro API. It would be good to move the parser to the decomposed approach as well, as it is somewhat more natural, more future-compatible (one can introduce new tokens) and having two of a thing is bad in itself!

Here are some relevant bits of the code that handle composed model:

* Composed tokens as produced by [rustc_lexer](https://github.com/rust-lang/rust/blob/71e2882973e63b9ddc837a61ac8631e6451d31a9/src/librustc_lexer/src/lib.rs#L271-L281)
* Composed tokens preserved by the [token cooking](https://github.com/rust-lang/rust/blob/71e2882973e63b9ddc837a61ac8631e6451d31a9/src/libsyntax/parse/lexer/mod.rs#L306)
* Here's the bit when we produce [a TokenTree](https://github.com/rust-lang/rust/blob/71e2882973e63b9ddc837a61ac8631e6451d31a9/src/libsyntax/parse/lexer/tokentrees.rs#L207-L210), consumed by the parser. Note that, although we are tracking jointness here, the tokens are composed.
* Here's the bit of the parser which [decomposes](https://github.com/rust-lang/rust/blob/71e2882973e63b9ddc837a61ac8631e6451d31a9/src/libsyntax/parse/parser.rs#L700-L736) tokens on the fly.

Here are the bits relevant to decomposed model:

* Gluing tokens in [TokenStreamBuilder](https://github.com/rust-lang/rust/blob/71e2882973e63b9ddc837a61ac8631e6451d31a9/src/libsyntax/tokenstream.rs#L412-L429)
* [Token::glue](https://github.com/rust-lang/rust/blob/71e2882973e63b9ddc837a61ac8631e6451d31a9/src/libsyntax/parse/token.rs#L554-L612)

Note that the `tt` matcher in `macro_rules` eats one composed token, and this is affects language specification.
That is, when we transition to decomposed model, we'll need to fix [this code](https://github.com/rust-lang/rust/blob/71e2882973e63b9ddc837a61ac8631e6451d31a9/src/libsyntax/ext/tt/macro_parser.rs#L903-L905) to eat one *composed* token to maintain backwards compatibility.
Repository: storybook
Issue: Addon-docs: Allow linking within mdx with addon-links
Labels: feature request,addon: docs,mdx

**Is your feature request related to a problem? Please describe.**
I can't seem to get linking using `addon-links` within an mdx file.

Neither of these options worked for me:
![2019-08-16_13-02-50](https://user-images.githubusercontent.com/1977804/63227689-e3184680-c1ae-11e9-9087-4b9f3ec5ec23.png)

**Describe the solution you'd like**
Allow linking to sections, stories, and when implemented, articles, within an mdx file.

**Are you able to assist bring the feature to reality?**
No
Repository: flutter
Issue: Support JIT mode in production/release builds.
Labels: c: new feature,tool,t: gradle,P3,team-tool,triaged-tool

## Use case

Using flutter in environments where AOT isn't needed, like kiosk or desktop environments.

For certain use cases AOT adds little benefit, and can even impede performance (the JIT mode apparently can perform better).

## Proposal

Add the ability to build a 'release' mode of the flutter engine that only supports JIT. This would be basically the debug build without debugging features (observatory, etc) that might affect security and performance.
Repository: opencv
Issue: VNG demosaicing does not support 16U or Neon
Labels: feature,category: imgproc,priority: low

##### System information (version)
- OpenCV => 4.1.0
- Operating System / Platform => Ubuntu 16.04 64 Bit
- Compiler => GCC 5.4.0

##### Detailed description
VNG debayering options [do not support 16U images](https://github.com/opencv/opencv/blob/19a4b5137149e43fa85bef16707c40b535d195b4/modules/imgproc/src/demosaicing.cpp#L1719). The documentation is not clear about this. It would be great to see VNG support for 16U images. It would also be great to see adoption of universal intrinsics for arm SIMD support. 

##### Steps to reproduce
Attempt to debayer/demosaic a 16U image with VNG:
```
terminate called after throwing an instance of 'cv::Exception'
  what():  OpenCV(4.1.0) /path/to/opencv/modules/imgproc/src/demosaicing.cpp:1719: error: (-215:Assertion failed) depth == CV_8U in function 'demosaicing'

Aborted (core dumped)
```
Repository: terminal
Issue: Feature Request: ⬇️ button to appear when scrolled many pages up
Labels: Issue-Feature,Area-UserInterface,Area-Extensibility,Product-Terminal

# Description of the new feature/enhancement

Sometimes people using the Terminal need to scroll very far up, and read a lot of previous output. They then want to return immediately all the way to the bottom of the terminal, to see the latest output.

**Currently**: users scroll a lot to get to the bottom of the terminal.

**Proposed**: when scrolled more than X lines up, a ⬇️ button should appear that scrolls to UI all the way down to the latest output. I'll leave the UI discussion up to you.